BGP

BGP Prefix Advertisement (III)

BGP Prefix Advertisement (III)
In: BGP, Cisco

Welcome back to the third part of our BGP course. In this part, we will look at how to advertise prefixes between BGP peers. As we've touched on earlier, simply setting up BGP neighbours isn't enough to start exchanging route information. You need to tell BGP exactly what you want to share using the network x.x.x.x mask x.x.x.x command. There are a few things you need to take into account for this to work properly, so let's dive in.

Overview

Our goal in this section is to configure BGP neighbours across three different Autonomous Systems (AS 1000, AS 100, and AS 2000) to ensure the prefix 100.100.0.0/16, originating from the HQ-01 router, is successfully advertised and propagated.

We're working with a network where HQ-01 is in AS 1000, ENT-01 is in AS 2000, and there are two intermediary ISP routers in AS 100. These ISP routers will establish an iBGP session between each other to pass along BGP routes.

We'll set up the BGP configurations on these routers, ensuring that our prefix 100.100.0.0/16 is not only advertised by HQ-01 but also makes it all the way through the ISP routers and reaches ENT-01 in AS 2000. Let’s start by configuring the BGP neighbours and then proceed to monitor the prefix advertisement.

#HQ-01

router bgp 1000
 neighbor 12.12.12.2 remote-as 100
#ISP-01

router bgp 100
 neighbor 12.12.12.1 remote-as 1000
 neighbor 192.168.12.2 remote-as 100
#ISP-02

router bgp 100
 neighbor 31.31.31.1 remote-as 2000
 neighbor 192.168.12.1 remote-as 100
#ENT-01

router bgp 2000
 neighbor 31.31.31.2 remote-as 100

Now that we've gone through configuring BGP, the neighborships between the routers should be up and running. However, there's an important step remaining, advertising the prefixes. Here is the output from ISP-01 where you can see the neighbours are up but no prefixes received from HQ-01 (PfxRCd - 0)

#ISP-01

#show ip bgp summary
BGP router identifier 12.12.12.2, local AS number 100
BGP table version is 3, main routing table version 3

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.1      4         1000    1488    1488        3    0    0 22:30:04        0
192.168.12.2    4          100    1487    1486        3    0    0 22:27:32        0

BGP network command

Despite successful BGP neighbour establishment, HQ-01 won’t advertise any routes until we explicitly instruct it to. This is where the network x.x.x.x command comes into play. By using this command, we can specify which routes we want HQ-01 to advertise to its BGP neighbours.

When we use the network command in BGP to advertise a specific prefix, BGP has a strict condition it must follow before it can act. For example, if we add network 100.100.0.0 mask 255.255.0.0, BGP will first look at the routing table to verify that an exact match for that prefix exists. Only if there is an exact route match will BGP include that prefix in its own BGP table.

Subsequently, once the prefix is in the BGP table, BGP will advertise this prefix to its neighbours. If, however, the routing table does not contain an exact match for the specific prefix, BGP will not announce that prefix to its peers. Let’s add this command now to start advertising the 100.100.0.0/16 prefix and observe the effects this has on our network.

hq-01(config)#router bgp 1000                        
hq-01(config-router)#network 100.100.0.0 mask 255.255.0.0

Now, if I go and check on ISP-01 again, the prefix received from 12.12.12.1 (HQ-01) should be 1

ISP-01#show ip bgp summary

BGP router identifier 12.12.12.2, local AS number 100
BGP table version is 4, main routing table version 4
1 network entries using 248 bytes of memory
1 path entries using 120 bytes of memory
1/1 BGP path/bestpath attribute entries using 256 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 648 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.1      4         1000    1492    1491        4    0    0 22:32:55        1
192.168.12.2    4          100    1490    1490        4    0    0 22:30:22        0
ISP-01#show ip bgp 

BGP table version is 4, local router ID is 12.12.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/16   12.12.12.1               0             0 1000 i
ISP-01#show ip route bgp

Gateway of last resort is not set

      100.0.0.0/16 is subnetted, 1 subnets
B        100.100.0.0 [20/0] via 12.12.12.1, 00:02:59

Everything might look fine from ISP-01's perspective, with a valid (*) and best route (>) to 100.100.0.0/16. You might think we're all set and ready to move on. But, let's not rush — it's crucial to check the other routers as well, specifically ISP-02 and ENT-01.

#ISP-02

ISP-02#show ip bgp
BGP table version is 3, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 * i 100.100.0.0/16   12.12.12.1               0    100      0 1000 i
ENT-011#show ip bgp 
ENT-01#

On ISP-02, while we see that there's a valid route to 100.100.0.0/16, indicated by an asterisk (*), the route isn’t marked as best (since there's no greater-than sign (>). This means ISP-02 hasn't selected it as the best path, so it won't place this route into its routing table, nor will it advertise the route to ENT-01.

So, we need to dig a little deeper and figure out why ISP-02 doesn't recognize the route as the best and address the issue to ensure the prefix is fully propagated through the network.

BGP Next-Hop Behaviour & Reachability

In BGP, the "next-hop" refers to the next destination that packets will be sent to reach a certain network. For BGP to use and advertise a route, the next-hop IP address for that route must be reachable.

0:00
/6:57

Next-hop is a well-known mandatory path attribute. It is recognized by all BGP peers, passed to all peers, and present in all Update messages. (We will cover Path Attributes in detail in the upcoming sections)

In our example, ISP-01 has learned the route to 100.100.0.0/16 and sees the next hop to reach this network as the IP address of HQ-01 (12.12.12.1). ISP-01 can reach this next hop, so it considers the route valid and best and marks it accordingly.

However, ISP-02, which is in the same AS as ISP-01, has learned about the 100.100.0.0/16 network from ISP-01 via iBGP. The catch in iBGP is that the next hop isn't changed when routes are passed along. So, ISP-02 still sees the next hop as the IP address of HQ-01 (12.12.12.1). Here is a capture taken between ISP-01 and ISP-02 and you can see the next-hop IP of 12.12.12.1

If ISP-02 can't reach this next-hop IP, it won't consider the route valid, won't install it in its routing table, and therefore, won't advertise it to ENT-01. Here is a route table of ISP-02 where it doesn't have a route to 12.12.12.x.

#ISP-02

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.10.0.0/16 is directly connected, GigabitEthernet8
L        10.10.50.42/32 is directly connected, GigabitEthernet8
      31.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        31.31.31.0/24 is directly connected, GigabitEthernet1
L        31.31.31.2/32 is directly connected, GigabitEthernet1
      192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.12.0/24 is directly connected, GigabitEthernet2
L        192.168.12.2/32 is directly connected, GigabitEthernet2

Solution 1 - Using an IGP (OSPF)

To solve this, we typically ensure that all iBGP routers within the same AS can reach each other's next-hop addresses, usually by using an IGP like OSPF or by setting up static routes. This ensures that all the necessary next-hop addresses are reachable, allowing routes to be properly installed and advertised. In our scenario, ISP-02 needs to have a reachable route to the next-hop IP address used by HQ-01 to advertise 100.100.0.0/16 in order for it to further advertise this route to ENT-01.

💡
If we decide to use OSPF, we need to enable OSPF on both ISP routers on both interfaces. We also want to make sure we set the interfaces connecting to the eBGP peers as passive-interfaces so, we are not trying to form OSPF neighbourships over these external links.

Let's quickly configure OSPF on both ISP routers and see what happens.

#ISP-01

router ospf 1
 passive-interface GigabitEthernet1

interface GigabitEthernet1
 description hq-01
 ip address 12.12.12.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface GigabitEthernet2
 description csr-02
 ip address 192.168.12.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
#ISP-02

router ospf 1
 passive-interface GigabitEthernet1

 interface GigabitEthernet1
 description isp-02
 ip address 31.31.31.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface GigabitEthernet2
 description csr-01
 ip address 192.168.12.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

Now the route for 12.12.12.x shows up on the ISP-02 router's routing table via OSPF. The BGP also shows a valid and best route for 100.100.0.0/16 (denoted by *>)

#ISP-02

Gateway of last resort is not set

      12.0.0.0/24 is subnetted, 1 subnets
O        12.12.12.0 [110/2] via 192.168.12.1, 00:00:20, GigabitEthernet2
#ISP-02

BGP table version is 4, local router ID is 192.168.12.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>i 100.100.0.0/16   12.12.12.1               0    100      0 1000 i

Now the route should propagate all the way to ENT-01 as shown below.

#ENT-01

ENT-01#show ip bgp 
BGP table version is 4, local router ID is 31.31.31.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/16   31.31.31.2                             0 100 1000 i

ENT-021#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

Gateway of last resort is not set

      100.0.0.0/16 is subnetted, 1 subnets
B        100.100.0.0 [20/0] via 31.31.31.2, 00:04:01

Suppose, ENT-01 sends some traffic destined for 100.100.x.x, here is what will happen.

  1. ENT-01 sends the traffic to ISP-02
  2. ISP-02 will look at its BGP table to find out the next-hop IP for the prefix 100.100.0.0/16, which is 12.12.12.1
  3. Next, ISP-02 will check its own routing table to determine the best IGP route to reach this next-hop IP of 12.12.12.1. This includes choosing the right egress interface and the next-hop IP to use. In this case, the next-hop IP to reach 12.12.12.1 is 192.168.12.1
  4. ISP-02 will send the packets to ISP-01
  5. ISP-01 receives the traffic, looks at its own routing table and forwards the traffic to HQ-01

Solution 2 - BGP next-hop-self

Another way to address the next-hop reachability issue in iBGP is to use the next-hop-self command. This command changes the next-hop address of a BGP route to the IP address of the router that's sending the route when passing it to iBGP peers.

Here's how it applies to our example. ISP-01 receives the prefix 100.100.0.0/16 from HQ-01 with HQ-01's IP as the next hop. When ISP-01 sends this route to ISP-02, it can use next-hop-self to change the next hop from HQ-01's IP to its own IP. This way, ISP-02 will see the next hop as ISP-01, which it can reach because they're directly connected within the same AS. Now, ISP-02 will consider the route valid, install it in its routing table, and then advertise it to ENT-01. Using next-hop-self is a common solution in iBGP configurations to ensure all peers have reachable next-hop addresses.

#ISP-01

router bgp 100
 neighbor 12.12.12.1 remote-as 1000
 neighbor 192.168.12.2 remote-as 100
 neighbor 192.168.12.2 next-hop-self   <<<< Here is the change

As soon as I do this and take the captures from the same interface, you will see a difference. Now the next-hop IP is set to 192.168.12.1 which is directly connected to ISP-02.

If we go back to ENT-01, we should see the prefix and everything looks good.

#ENT-01

ENT-01#show ip bgp 
BGP table version is 6, local router ID is 31.31.31.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  100.100.0.0/16   31.31.31.2                             0 100 1000 i
The key takeaway here is, if the next-hop is unreachable for a specific prefix, the BGP router will not advertise the prefix to its neighbours and will not also instal the prefix in ints own routing table.

BGP Redistribution

You can also redistribute routes from other routing protocols into BGP using the redistribute command. For example, instead of using the network command to inject prefixes into BGP, I could also redistribute the connected routes.

#HQ-01

hq-01(config-router)#no network 100.100.0.0 mask 255.255.0.0
hq-01(config-router)#redistribute connected 
hq-01(config-router)#end

If I go to ISP-01 and check the routes, I should be able to see the prefix 100.100.0.0/16 as shown below.

#ISP-01

isp-01#show ip bgp 
BGP table version is 6, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 r>  10.10.0.0/16     12.12.12.1               0             0 1000 ?
 r>  12.12.12.0/24    12.12.12.1               0             0 1000 ?
 *>  100.100.0.0/16   12.12.12.1               0             0 1000 ?

If you are wondering why are we seeing not only 100.100.0.0/16 but also the other two subnets 10.10.0.0/16, and 12.12.12.0/24, well they are directly connected to the HQ-01 router. (Please ignore 10.10.0.0/16 as I'm just using that as a management subnet)

Written by
Suresh Vina
Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
Comments
More from Packetswitch
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.