IPv6 VRFs

Background Information

1. This post assumes that you are familiar with administering IPv4 VRFs.
2. The old VRF syntax supported only IPv4.
3. To implement IPv6 VRFs, new CLI syntax have been created (IOS 12.2(33)).
4. If you want to create IPv6 VRFs, you must use the new syntax.
5. You can upgrade the old IPv4 CLI configuration to the new syntax.
6. Once upgraded, you cannot revert back to the old syntax.
7. The old VRF syntax ip vrf are deprecated and will be removed in future releases.

Summary

1. vrf definition  to define new VRF.
2. address-family ipv6 to enable this VRF for IPv6 and to define IPv6 VRF attributes.
3. address-family ipv4 to enable this VRF for IPv4 and to define IPv4 VRF attributes.
4. vrf forwarding  to add interface to VRF.
5. vrf upgrade cli to upgrade all VRF configuration to the new syntax structures.
1. If you use non-common-policies option, the existing route-target configuration will be copied to the IPv4 address-family and will only affect IPv4.
2. If you use common-policies option, the existing route-target configuration will be applied to the VRF level, which will affect IPv6 and IPv4 address-families.
6. show vrf to list VRFs, RD, protocols, and interfaces.
7. show vrf detail to view VRF info along with route-targets.
8. show run vrf to list configuration of VRF and associated interfaces.

vrf definition RED

  address-family ipv6

  address-family ipv4

  rd 65000:1

  route-target both 65000:1

interface fa 0/1

  vrf forwarding RED

http://www.cisco.com/c/en/us/td/docs/ios/mpls/configuration/guide/12_2sy/mp_12_2sy_book/mp_vpn_ipv4_ipv6.html

BGP Multipath maximum-paths

Background Information

1. BGP normally only installs one route (the best route) into the RIB.
2. In the past, if we wanted to use ECMP with eBGP, we would just peer using loopbacks, and then use static routes so that the next hop would be load balanced.
3. For iBGP, we would let the IGP take care of the load balancing.
4. BGP currently also has a built-in method of performing load balancing using the maximum-paths command.

Summary

1. maximum-paths ibgp to set the maximum number of paths to install in the RIB.
2. maximum-paths to set the maximum number of eBGP paths to install in the RIB.
3. maximum-paths eibgp to tell the router to load-balance iBGP and eBGP paths.
4. The following must match for a set of load balanced routes:
1. Weight
2. Local-preference
3. AS-Path length
4. MED
5. Neighbor AS (for eBGP multipath)
6. AS-Path
7. IGP metric to next-hop
5. The next-hop must be different for the set of load balanced routes
6. bgp bestpath as-path multipath-relax to be able to load balance across non matching AS-Path.
7. show ip protocols to see the configured maximum paths.
8. show ip cef detail to see the load-sharing method (by default: destination-based).

router bgp 1

  bgp bestpath as-path multipath-relax

  address-family ipv4

    maximum-paths 2

    maximum-paths ibgp 2

BGP Synchronization

Background Information

1. For a transit AS, where the iBGP routers have to transit non-BGP routers to get to another iBGP router, we can potentially blackhole routes if any of the internal non-BGP routers do not know the routes that the edge routers are advertising to other AS.
2. The way we can avoid blackholing routes is to not advertise the route to another AS if our IGP does not know it.  
3. The synchronization feature tells the BGP process to wait for the IGP to learn about the prefix before we can advertise it to another AS.

Summary

1. Older routers have synchronization enabled by default.  Newer routers have it disabled by default.
2. synchronization to tell the router to wait for IGP to learn the prefix before advertising it.
3. no synchronization to tell the router to not wait for IGP to learn the prefix.
4. If you are not running an IGP or the AS is not a transit AS, you should manually disable synchronization.
5. show ip protocols to see whether IGP Synchronization is enabled.

router bgp 1

  no synchronization

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#synch

BGP Soft-Reconfiguration and Route-Refresh

Background Information

1. When we create new policies such as route-maps, we need a fresh unaltered copy of the updates that we received from the neighbors.
2. We cannot use what we have in the BGP tables because we may have already modified those and we cannot trust it to be the originals that were sent.
3. A long time ago, the only way we can get the new policies applied is to reset the peer connection with clear ip bgp.  This will force the peer to resend all the prefixes, allowing us to apply the policies in the new route-map.  However, this causes packet loss while the prefixes are being learned.
4. Then, Cisco came out with the soft-reconfiguration feature.  The way this works is that the router would maintain a copy of all the original received prefixes.  Now, to apply the new policy, we can just clear ip bpg soft and the original received prefixes that were stored would be used and we don't have to reset the peer connection anymore.
5. Another newer solution to this problem is the route-refresh capabilities feature.  A router that is capable of this will inform its peer in its open message sent when establishing adjacency.
6. The route-refresh allows a peer to "ask" another peer to resend its prefixes.  This way, traffic is not blackholed and a whole copy of all the prefixes do not need to be maintained.

Summary

1. neighbor soft-reconfiguration inbound to store a copy of the neighbor's prefixes.
2. bgp soft-reconfig-backup to store a copy of the neighbor's prefix if the neighbor does not support route-refresh.
3. clear ip bgp * soft in to "ask" the peer to resend its prefixes.  When used on a neighbor that has the soft-reconfiguration inbound feature configured, we will use the stored copy instead.  If the soft-reconfiguration feature is not configured for the neighbor, we will send a "route-refresh" request.
4. show ip bgp neighbor received-routes to view the stored copy of the neighbor's prefixes if using the soft-reconfiguration feature instead of the route-refresh capabilities.
5. show ip bgp neighbor to see if the neighbor has the route-refresh capabilities.

router bgp 1

  address-family ipv4

    neighbor 10.1.1.1 soft-reconfiguration inbound

clear ip bgp 10.1.1.1 soft in

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_sftrst.html
http://jaluther.blogspot.com/2012/04/bgp-route-refresh-capability.html

BGP allowas-in

Background Information

1. Sometimes, we need to override the BGP loop prevention mechanism and allow prefixes that contain its own AS.
2. A use case for this would be if you had two sites that used the same AS, but they are separated by an ISP, and both sites peer with the ISP.  The ISP is basically relaying the updates between the two sites.  This wouldn't work because each site will tag updates with its own AS, and then the remote site will drop it because it has the same AS.

Summary

1. Use allows-in neighbor policy to not drop prefixes that have its own AS.
2. Be aware of what effect this could have depending on the topology and policies already in place such as aggregation with as-set.  Check out as-override as an alternative.

router bgp 1

  address-family ipv4

    neigh 10.1.1.1 allowas-in

http://ccieblog.co.uk/bgp/bgp-as-override-vs-allow-as-in

BGP aggregate-address

Background Information

1. Sometimes we want to reduce the size of the BGP table.
2. BGP gives us a way to advertise an aggregate-address.

Summary

1. aggregate-address to define an aggregate address.  If at least one component prefix exists in the BGP table, the aggregate-address will be advertised.  By default, the component prefixes are not suppressed and will be advertised as they normally do.  This is different from the way IGPs summarize.
2. The as-set attribute advertises the component prefix AS as a set.  When a router sees itself in the as-set, it will drop the update.  We sometimes need this to prevent routing information loops.  Keep in mind a component route flap will cause updates.
3. The summary-only attribute suppresses all of the component prefixes.
4. The suppress-map suppresses individual component prefixes.  You can then use unsuppress-map on the neighbor to conditionally unsuppress prefixes that have been suppressed.
5. Use a route-map or an attribute-map to set the attributes of the aggregate.
6. Use an advertise-map to specify which component prefix attributes to use for the aggregate.
7. An inject-map can be used to advertise a more specific route if a more general route exists.

router bgp 100

 address-family ipv4

   aggregate-address IP MASK

     route-map

     summary-only

     as-set

     attribute-map

     advertise-map

     suppress-map

 bgp inject-map exist-map ! Inject a more specific route if aggregate exists

 neighbor X unsuppress-map ROUTE-MAP

BGP Cluster-ID

Background Information

1. Route-reflectors reflect iBGP updates back to other iBGP peers so we don't have to create a full mesh between all iBGP peers.  
2. That means that the other iBGP peers only peer up with the route-reflectors and not each other.
3. This also means that if a route-reflector dies, then the iBGP peers will not have any updates from each other.
4. To protect against the failure of the route-reflector, we can create a redundant route-reflector.  You peer up all iBGP routers to the two redundant route-reflectors.
5. When you have multiple route-reflectors, cluster-id is used to detect routing information loop.  If a route-reflector receives an update with its own cluster-id, the update will be dropped.
6. By default, route-reflectors will use its router-id as the cluster-id.
7. When route-reflectors are configured to have the same cluster-id, they will drop updates from each other.  This means that if an adjacency fails somewhere between a route-reflector and another iBGP router, that route-reflector will no longer have prefixes advertised by the iBGP router because it will not accept the other route-reflectors updates.