BGP notes

I'm currently setting up a site to advertise a new address block into our MPLS network.  We are using neighbor <peer IP> soft-reconfiguration inbound on all of our edge devices.

It is worth knowing that in order to update your BGP routing table, you must perform a 'clear ip bgp *' (which tears down ALL of your BGP neighbor relationships) or 'clear ip bgp <peer IP address>.'

This can have negative consequences, being that when you perform this command it will tear down the BGP neighbor relationship and cease communication until the neighbor relationship is rebuilt.  Unlike other interior routing protocols, which automatically update the neighbors with the newly advertised network, BGP peers with external groups..typically ISPs.

ISPs won't typically send their updated BGP routing table to you unless you force them.  The alternative to 'clear ip bgp*' is to perform a soft clear which was implemented in IOS 12.2.

When you perform the "neighbor A.B.C.D soft-reconfiguration inbound" router command - it shuts down the connection (just like a hard reset). When the neighbor resends you it's routing table, BGP stores a copy of the received routing table in memory. This 2nd copy takes up memory, but it serves a useful purpose. Now, when you apply policy changes to a neighbor or out a particular interface, you can configure "clear ip bgp * (or A.B.C.D) soft in" and run the saved copy of the neighbor's routes through your new bgp policy filters. You can make policy changes all you want and your neighbor never has to resend you its routing table, and you never have to tear down the connection between you and disrupt network communication.

The obvious drawback of the soft-reconfiguration inbound command is this does take up a lot of memory because the router stores all of the updates that it receives from the neighbor. So make sure the router has enough memory before turning it on.

It is worth noting that Cisco IOS automatically soft reconfiguration for outbound updates, but the above implementation is required for inbound updates.  

IPsec notes

I love me some packetlife.net..

To sum it up in my own words..

Step 1 is the IKE (Internet Key Exchange) configuration.

IKE relies on ISAKMP (Internet Security and Key Management Protocol) in order to create a secure channel for which IPSEC to negotiate.  An IKE policy determines the attributes that will be used in the ISAKMP session.

To create a policy, the syntax is as follows:

R1(config)# crypto isakmp policy 10
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# ^Z
R1# sh crypto isakmp policy

Global IKE policy
Protection suite of priority 10
    encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
    hash algorithm:         Secure Hash Standard
    authentication method:  Pre-Shared Key
    Diffie-Hellman group:   #1 (768 bit)
    lifetime:               86400 seconds, no volume limit
...

Note:

• Encryption algorithm is used to scramble/unscramble data.
• Hash algorithm is used for data integrity.  Once data is transferred, the hash is compared to verify data consistency. 

It is possible to create up to a maximum of 20 policies.  The lower the priority number, the higher priority it has.  When initiating a connection with another device, the two will compare policies (higher priority/lower numbers) first until they find one that matches.

In this example we are using a pre-shared key.  This means that the vendor/partner on the distant end must have the same key, hash algorithm, encryption algorithm, and Diffie-Hellman group to create a secure channel.  The lifetime does not have to match.  In the event of a lifetime difference, it will defer to that which has the shortest lifetime.  The default is 86400 seconds..or 24 hours.  Shared-keys for authentication are not best practice as it is considered to be the least secure method.  The alternative is to RSA (Rivest-Shamir-Adleman) for authentication.  Here is a link to this implementation! 

Moving on!

Now that we have identified the authentication method, we need to actually identify this key.

R1(config)# crypto isakmp key 0 FooB4r address 172.16.0.6

With this example, we are using option 0 versus option 1.  Since we indicated 0, if you perform a show crypto isakmp key it would show you the following: "FooB4r"

Step 2 is the IPsec configuration

While the IKE policy provides a default for all attributes, we now must explicitly state the encryption and hash algorithm we want to use with transform-set.  The transform set defines the parameters of the IPsec security associations which will carry the actual data.  If you are interested in seeing the existing transform-sets, perform a show crypto ipsec transform-set.  This will show you if it is configured for tunnel or transport mode, as well as the encryption/hash algorithm.  We will indicate this later on, but the transform-set tag is what you indicate in the individual crypto-map to indicate the preferred algorithms.  

Here is an example of the configuration and resulting show command:

R1(config)# crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac

R1(cfg-crypto-trans)# ^Z

R1# show crypto ipsec transform-set

Transform set MyTransformSet: { esp-3des esp-sha-hmac  }

   will negotiate = { Tunnel,  },

As you can see in this example, it is using 3DES for encryption and HMAC_SHA for authentication in tunnel mode.  

Now to reference this transform-set...

crypto map <tag> <sequence number> ipsec-isakmp

 description <I like to use a point of contact for the distant end>

 set peer <IP address of the distant end>

 set transform-set <Previously configured transform-set>

 match address <access-list to identify interesting traffic>

Some basic troubleshooting commands to verify status:

show crypto isakmp sa

This command shows the Internet Security Association Management Protocol (ISAKMP) security associations (SAs) built between peers.

show crypto ipsec sa

This command shows IPsec SAs built between peers.  This command gives quite a bit of information.  This will show how many packets have been encapsulated (egress), de-encapsulated (ingress), as well as the encryption and authentication algorithms of the different peers.  

show crypto engine connections active

This command shows each phase 2 SA built and the amount of traffic sent. Since phase 2 (security associations) SAs are unidirectional, each SA shows traffic in only one direction (encryptions are outbound, decryptions are inbound).

debug crypto ipsec
This debug command will show traffic from the source and destination.  Two "SA created" messages will appear with one in each direction.

Note:
We had an issue today configuring this, so I figured I'd share.  I configured IPsec between a Cisco 7206VXR and a Cisco ASA 5520.  The reason the tunnel did not come up was due to mismatched crypto map ACLs.  The IPs need to match!

Also, for some reason the access rule on the outside interface was blocking ISAKMP.  We were allowing UDP port 4500 and 500 and the ESP service.  Not until we allowed IP did the tunnel come up.  When monitoring, we were seeing hits that it was blocking it because of 'Spoofing.'  This is on the vendor site restricting OUR access to their network...so...I honestly don't care and we left the IP service on. :)

Network Time Protocol (NTP)

Network Time Protocol (NTP)

We've run into an issue with NTP..figure I'll trace out my notes here:

Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.

NTP uses a hierarchical, semi-layered system of levels of clock sources. Each level of this hierarchy is termed a stratum and is assigned a layer number starting with 0 (zero) at the top. The stratum level defines its distance from the reference clock and exists to prevent cyclical dependencies in the hierarchy. It is important to note that the stratum is not an indication of quality or reliability, it is common to find stratum 3 time sources that are higher quality than other stratum 2 time sources. This definition of stratum is also different from the notion of clock strata used in telecommunication systems.




It should be noted that a router cannot be a stratum 1 device (cannot connect to a Stratum 0 device such as a GPS clock), a router is not an accurate source of time information.  If this is not important, then using a router as an NTP server may be appropriate. 

DMVPN

First off, what is DMVPN (Dynamic multipoint virtual private network)?  Well, it is essentially a point-to-multipoint overlay VPN tunneling technology.  In addition, it is a scalable and dynamic way of building GRE over IPSec site-to-site tunnels.  It is an IP packet encrypted with IPSec, with a GRE tunnel inside of that. Because of GRE, we are able to run dynamic routing protocols (OSPF, EIGRP, BGP, etc).

• Because DMVPN uses IP transport, any internet connectivity will work...be it a T1, DS3, cable, ethernet, etc.

• Unlike some of the underlying layer 2 tunnel protocols, like frame relay or ATM, DMVPN is built on an overlay VPN tunnels.  The spokes build a tunnel to the hub, and the hub will have a multipoint tunnel back to the spokes.

• Now what makes DMVPN truly dynamic is the ability to create on demand tunnels.  If using at least phase 2, if spoke A wants to talk to spoke B, a dynamic tunnel is built between the two.  We'll talk about the differences between the phases later on.  Furthermore, unlike IPSEC, where if you had 10 sites you would need 10 crypto maps...no change is required on the head-in for DMVPN.  Lastly, the configuration the spokes is stupid easy and templates can be made.

• When to scale?  
• IPSEC: It honestly comes down to the number of endpoints.  Should spoke A want to talk to a new site B..then A must be re-configured to be able to talk to site B.  As the number of sites grow, management of the spokes can become a nightmare!  Orinally, static IPSec tunnels did not support multicast.  To overcome this, you would run a GRE tunnel between the sites.  Furthermore, you put the GRE tunnels inside an IPSEC tunnel.  That is basically what DMVPN does..but it is dynamically with the control-plane protocol NHRP (which will be discussed later).
• Layer 3 MPLS: This first off creates routing complexity.  Most of the time, you're going to need a routing protocol (typically BGP) between you and the ISP.  With that, redistribution and various other technologies can over-complicate the design.  Also MPLS might not support IPV6 of IPV4 and/or multicast.  Next, inter-ISP operability may be an issue.  Should you need two sites to talk where any single ISP is unavailable...you might have issues.

• Traffic Routing:
• Multipoint GRE (mGRE):
• Next Hop Resolution Protocol (NHRP): Mapping between the NBMA (public) address and the private address.
• DMVPN Hub/NHRP server
• DMVPN spokes/NHRP clients

• Traffic Encryption:
• IPSec:

(NHRP):

"Partially meshed NBMA networks typically have multiple logical networks behind the NBMA network. In such configurations, packets traversing the NBMA network might have to make several hops over the NBMA network before arriving at the exit router (the router nearest the destination network). With NHRP and when NHRP is combined with IPsec, the NBMA network is basically a collection of point-to-point logical tunnel links over a physical IP network. This is also true of virtual tunnel networks, for example, generic routing encapsulation (GRE) tunnels. In order for a router to scale the connectivity of this collection of point-to-point links, the links are usually grouped into a single- or multilayer hub-and-spoke network. Multipoint interfaces (GRE tunnel interfaces in this case) can be used to reduce the configuration on a hub router in such a network. This resulting network is an NBMA network.

NHRP is an ARP-like protocol that alleviates these NBMA network problems. With NHRP, systems attached to an NBMA network dynamically learn the NBMA address of the other systems that are part of that network, allowing these systems to directly communicate without requiring traffic to use an intermediate hop."

"NHRP is the catalyst which facilitates dynamic tunnel establishment, providing tunnel-to-physical interface address resolution. NHRP clients (spoke routers) issue requests to the next hop server (hub router) to obtain the physical address of another spoke router."
"Routers, access servers, and hosts can use the NHRP to discover the addresses of other routers and hosts connected to an NBMA network."

DMVPN Phases:

Phase 1: Hub-and-spoke; all traffic traverses the hub router to get to each spoke.
Phase 2: Spokes dynamically build tunnels to communicate.  Each spoke needs a route for every possible spoke.
Phase 3: Same as phase two, but we use summarization.


Note: The head-in device does not need to explicitly define destination IPs.  This is because multipoint tunnels are built dynamically from the DMVPN spokes to the hub router; the hub router doesn't need to be preconfigured with spoke addresses.

Head-in configurations:
ip nhrp authentication <key> <--Must match or tunnel won't come up
ip nhrp map multicast dynamic <---Forwards multicast traffic (required for most routing protocols)
ip nhrp network-id <id> <--Must match or tunnel won't come up
ip nhrp redirect <--For DMVPN phase 3: Tells spoke that it can communicate directly with another spoke
tunnel source <IP> or <interface>
tunnel mode gre multipoint
tunnel key <key> <--Must match or tunnel won't come up
tunnel protection ipsec profile <cyrpto profile> shared <--IPsec protection policy to the tunnel interface

*********************************************************************************

Spoke configurations:
ip nhrp authentication <key> <--Must match or tunnel won't come up
ip nhrp map multicast dynamic <---Multicast traffic is only being allowed from spokes to the hub, not from spoke to spoke.
ip nhrp network-id <id> <--Must match or tunnel won't come up
ip nhrp shortcut <--For DMVPN phase 3:  Responsible for rewriting the CEF entry after getting the redirect message from hub.
ip nhrp nhs <IP address>   <--NHS address of head-in device
ip nhrp map <NHS address> <physical address>  <--Mapping of the head-in NHS address to the physical address
tunnel protection ipsec profile <cyrpto profile> shared  <--IPsec protection policy to the tunnel interface

Notes for EIGRP:
Phase 1:

• Summarization/default routing possible!
• Must disable split-horizon UNLESS we use summarization.

Phase 2:

• Summarization/default routing NOT possible!   Next-hop would point towards the hub, and we would not be able to perform the dynamic spoke-to-spoke tunnels.  Route next-hop MUST point to the spoke tunnel interface, NOT the hub's tunnel interface.
• Must disable split-horizon.
• Must configure "no ip next-hop-self eigrp 1" -- Otherwise, the next-hop would be that of the hub, not the tunnel IP address of the individual spokes.

Phase 3:

• Summarization/default routing possible!
• Disable split-horizon!
• Remove "no ip next-hop-self eigrp 1" .. This is NOT needed for phase 3.  
• NHRP overrides RIB (Compare against FIB--CEF table).  You will see that route still points to hub, while FIB points to destination spoke tunnel IP.

Notes for OSPF:
Phase 1:

• Summarization/default routing possible!
• Point-to-multipoint possible.

Phase 2:

• Summarization/default routing NOT possible!   Next-hop would point towards the hub, and we would not be able to perform the dynamic spoke-to-spoke tunnels.  Route next-hop MUST point to the spoke tunnel interface, NOT the hub's tunnel interface.
• CANNOT use point-to-multipoint (next-hop is hub).
• MUST run broadcast/non-broadcast with the HUB as the DR.  

Phase 3:

• Summarization/default routing possible!
• Can run point-to-multipoint, as next hop does not directly relate to the route.  
• NHRP overrides RIB (Compare against FIB--CEF table).  You will see that route still points to hub, while FIB points to destination spoke tunnel IP.

Notes for BGP:

• HUB can be route-reflector.
• Static neighbor statements would be a P.I.T.A.----so on HUB you can configure BGP dynamic neighbors.