You should have heard about BGP when learning about more advanced Networking Topics. It’s commonly called the ‘routing protocol of the internet’.

BGP is an amazing tool as it is so versatile. It’s sometimes called slow. However, the feature-set it presents to service providers and large enterprises makes it incredibly useful.

This isn’t an explanation of BGP, far from it. This is designed to show you what BGP sends over the wire and how to read and interpret it.

Below is the topology we are working with:

This is a multi-homed Customer connected to an ISP. They are advertising the ‘10.1.0.0/16’ and ‘10.1.90.0/24’ prefixes out to the ISP from both LON01 and LON02 via the eBGP relationships with the ISP. There is an iBGP relationship between LON01 and LON02 too. Along with an EIGRP adjacency to resolve internal company routes.

As this customer is multi-homed. We have taken advantage of Traffic Engineering aspects of BGP and have configured BGP as follows on LON01:

R2-LON01#sh run | sect ^route-map
route-map RM_LOCALPREF permit 10
 set local-preference 120
route-map RM_BGPMED permit 10
 set metric 50

R2-LON01#sh run | sect bgp
router bgp 65001
 bgp router-id 10.1.0.2
 bgp log-neighbor-changes
 network 10.1.0.0 mask 255.255.0.0
 network 10.1.90.0 mask 255.255.255.0
 neighbor 10.1.0.1 remote-as 65001
 neighbor 10.1.0.1 update-source Loopback0
 neighbor 10.1.0.1 next-hop-self
 neighbor 80.1.10.1 remote-as 100
 neighbor 80.1.10.1 route-map RM_LOCALPREF in
 neighbor 80.1.10.1 route-map RM_BGPMED out

And LON02:

R3-LON02#sh run | sect ^route-map
route-map RM_LOCALPREF permit 10
 set local-preference 110
route-map RM_BGPMED permit 5
 match ip address prefix-list PL_90NET
 set metric 25
route-map RM_BGPMED permit 10
 set metric 100
R3-LON02#sh run | inc prefix-list
ip prefix-list PL_90NET seq 5 permit 10.1.90.0/24
R3-LON02#sh run | sect bgp
router bgp 65001
 bgp router-id 10.1.0.1
 bgp log-neighbor-changes
 network 10.1.0.0 mask 255.255.0.0
 network 10.1.90.0 mask 255.255.255.0
 neighbor 10.1.0.2 remote-as 65001
 neighbor 10.1.0.2 update-source Loopback0
 neighbor 10.1.0.2 next-hop-self
 neighbor 80.1.20.1 remote-as 100
 neighbor 80.1.20.1 route-map RM_LOCALPREF in
 neighbor 80.1.20.1 route-map RM_BGPMED out

Finally, the ISP:

R1-ISP#sh run | sect bgp
router bgp 100
 bgp router-id 80.1.100.1
 bgp log-neighbor-changes
 network 80.1.100.1 mask 255.255.255.255
 neighbor 80.1.10.2 remote-as 65001
 neighbor 80.1.20.2 remote-as 65001

Above you can see that we are using the Local Preference and BGP MED to alter the traffic flow in and out of the Customer.

iBGP

With that out of the way, lets first have a look at an iBGP UPDATE message sent from LON01 to LON02:

In the main body of the packet, we can see that this going from LON01’s Loopback to LON02’s Loopback using the well known BGP TCP port.

We can see that this packet doesn’t just contain a single UPDATE Message, it contains 3!

Looking in the first one:

This breaks the update down further, giving us a Marker. The Marker is used to indicate the use of authentication. In this case, we are not using authentication for BGP.

Lower down in the UPDATE message, we can see the path attributes. The reason that multiple UPDATE messages were packed into this packet, is due to the path attributes being different. Multiple prefixes are sent in a single UPDATE message if the Path attributes are all the same.

Looking within Path attributes for this UPDATE, we see:

Here we can see some common BGP attributes. From the above, we can see that this is an iBGP update. This is due to the AS_PATH being empty. We can also see the NEXT_HOP here too. This is where the router receiving the UPDATE message will need to go to route packets to the prefix or prefixes in the NLRI Section. In this case, the Next Hop is the Loopback0 address on LON01

We can also see some more attributes including the MED and the Local Preference. This has been left at the default for iBGP at 100.

Digging deeper into the NLRI (Network Layer Reachability Information) we can see which prefixes this update is advertising with these attributes:

We can see above that this BGP UPDATE message was for the prefix 10.1.90.0/24. In the topology, this is a subnet used for one of the PC’s connected to LON02 on Gi6/0. Nothing will be done on LON02 with this information, as there is already a directly connected route as the 10.1.90.0/24 network is local to LON02.

When looking at this prefix within the BGP table on LON01, we can see all these attributes:

Looking into the next, UPDATE message within the packet, we see the below:

This is LON01 telling LON02 about the Loopback0 prefix on the ISP router. This was originally learnt via the eBGP relationship between the ISP and LON01. We can see that it’s an iBGP update and we can tell it came from eBGP as there is an AS number in the AS_PATH, AS100 being the ISP.

We can also see that LON01 is telling LON02 that the next hop is its own Loopback0 interface. The MED isn’t set here, but as per our Route Maps, the Local Preference has been set to 120. This makes this route the Best when LON02 compares this route with its own eBGP update from the ISP for the 80.1.100.1/32 prefix:

Looking at the last UPDATE message in the packet sent from LON01 to LON02:

This is LON01 telling LON02 about the summary route 10.1.0.0/16 that LON01 is configured to advertise via the network command. This is a static null0 route that is configured on both LON01 and LON02 to advertise to the service provider. In this case, LON02 will keep this in the BGP table, but this won’t getting into the RIB (Routing Table) unless the static null0 route is removed.

eBGP

Now we have had a look at the iBGP message between LON01 and LON02. Lets see what the ISP sent over the eBGP peering with LON01:

Again, 3 UPDATE messages have been put into a single packet for efficiency.

The top two are the ISP advertising 10.1.0.0/16 and 10.1.90.0/24 that LON02 advertised to it. The third one is the Loopback on the ISP.

Lets have a look at 10.1.90.0/24 and the Loopback:

In this UPDATE we can see that this prefix originated from AS65001 and transited through AS100. When this UPDATE is received by LON01, it will be DENIED because of BGP’s Loop Prevention mechanism. This is to prevent routing loops and a BGP speaker will DENY a prefix when its AS_PATH contains its own AS Number. We can also see that the NEXT_HOP is the ISP router.

Finally, we will look at the ISP Loopback prefix update:

This UPDATE is similar to the others. The AS_PATH only contains AS100 as this is a Connected interface on the ISP router within AS100. Similarly the NEXT_HOP is the ISP Router Gi0/0 interface.

I hope this has helped you understand what is contained within BGP UPDATES sent between BGP speakers!

Categories: Cisco

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *