Category Archives: CCNP

Manual Summarization with BGP on Cisco Routers

CCIE R&S, CCNP, , , ,

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.

An Example of a Security Exploit Due to the Native VLAN

CCDA, CCNA Security, CCNP

Native VLAN

In many of our Cisco courses, we learn that networking best practices often point to the non-use of the Native VLAN. But why is this?

It turns out there are security vulnerabilities that could result from having a VLAN not tagged across your trunk links. For example, there is the VLAN hopping attack.

Here is how this attack could work:

Step 1: A bad person at a customer site wants to send frames into a VLAN that they are not part of.

Step 2: This person double tags the frame (Q-in-Q) with the outer frame matching the native VLAN in use at the provider edge switch.

Step 3: The provider edge switch strips off the outer tag (because it matches the native VLAN), and send this frame across the trunk.

Step 4: The next switch in the path examines the frame and reads the inner VLAN tag and forwards the frame accordingly.

Notice this attack is unidirectional. The attacker can send traffic into the VLAN, but traffic will not return. Even still, this is obviously not something we want taking place.

What are possible solutions?

  • Use ISL trunks in the cloud – this becomes less and less possible as ISL trunks fade away.
  • Use a Native VLAN that is outside of the range permitted for the customer.
  • Tag the native VLAN in the cloud.