Category Archives: CCIE R&S

Manual Summarization with BGP on Cisco Routers

BGP

One of the topics that will be featured in my upcoming CBT Nuggets module, Border Gateway Protocol (BGP) – Advertising NLRI, manual route summarization in BGP. This post serves (as well as more to follow) cover the highlights of the video coverage.

There are two methods of performing aggregation with BGP on a Cisco router. You can create a static route that represents the aggregate and then advertise that route using the network command. Or, you can use the aggregate-address command.

Here is an example of the static route approach:

router bgp 65100
   network 192.168.192.0 mask 255.255.248.0
   neighbor 192.168.1.220 remote-as 65200
!
ip classless
ip route 192.168.192.0 255.255.248.0 Null0

Notice how the static route directs to the bit bucket (Null0). This is because it is not an actual network destination. It is an artificial construct to permit the route in the routing table so we can use the network command in BGP. There will be more specific entries in the routing table covered by this advertised summary and the router can follow those instructions. Should all the more specific entries be removed, then the static route has traffic discarded for the summary (this is the desired behavior, typically).

With the aggregate-address command approach, you ensure component routes of the summary exist in the BGP table (thanks to the network statement or redistribution), and the summary address is advertised via BGP. Here is an example:

router bgp 65100
 aggregate-address 192.168.192.0 255.255.248.0 summary-only
 redistribute eigrp 100
 neighbor 192.168.1.220 remote-as 65200

Note that if you forget the summary-only keyword with the aggregate-address command, you will advertise the summary as well as the specific routes. A future post will demonstrate when this approach might be useful.

Cisco – Migrating from STP to RSTP

CCIE

A frequent CCIE-level written exam topic is STP (PVST+) to RSTP (Rapid-PVST) migrations. This post covers the high points you should be aware of.

Some Quick Notes

  • BackboneFast and UplinkFast are no longer necessary in RSTP environments as the equivalent advantages are built-in to RSTP
  • BPDUs are version 2 in RSTP which is compatible with version 0
  • All ports now send BPDUs and they act as a keepalive mechanism
  • The new port roles are designated, root, alternate, and backup
  • The new port states are forwarding, discarding, and learning
  • The new port types are shared, edge (PortFast), and P2P
  • When an RSTP port receives a legacy BPDU, it reverts back to compatible behavior and performance enhancement benefits are lost
  • BackboneFast is configured on all switches in order to function in STP and UplinkFast is configured on access layer devices

Migrating

  • You are not forced into removing the BackboneFast and UplinkFast commands – if they are left in place, they do not impact the operation of RSTP
  • Removing the Uplinkfast command impacts the bridge priority and port cost values, so be sure you consider this
  • CatOS (FLASHBACK!) does not permit the BackboneFast command within RSTP so you must remove it in that legacy case
  • Plan a phased migration and use a maintenance window as traffic flows can be impacted
  • The configuration of the features such as PortFast, BPDUguard, BPDUfilter, root guard, and loopguard are applicable in rapid-PVST+ mode also