BGP Prefix Advertisement (III)
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 100Now 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 0Sign up for Packetswitch
A collection of articles focusing on Networking, Cloud and Automation
No spam. Unsubscribe anytime.
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.0Now, 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 0ISP-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 iISP-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:59Everything 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 iENT-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.
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, GigabitEthernet2Solution 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.
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 0Now 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 iNow 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:01Suppose, ENT-01 sends some traffic destined for 100.100.x.x, here is what will happen.
- ENT-01 sends the traffic to ISP-02
- 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
- 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
- ISP-02 will send the packets to ISP-01
- 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 changeAs 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 iThe 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 Only Advertises the Best Route
It's crucial to remember that BGP advertises only the best route to its neighbours. What this means is that for each destination, BGP picks the best route based on its path selection algorithm, and that's the only route it advertises.
Take the network 3.3.3.0/24 in the diagram, for example. This network originates from R3 and can reach R5 through multiple paths. One path is through R6 directly, and another is a longer path through R1, R2, and then R4. Despite knowing multiple paths, from R5's point of view, the best route to reach 3.3.3.0/24 is the one through R6, which is directly connected to R3.
Consequently, R5 will not propagate the route that it learned via the longer path to R6 or to any other neighbours it might have. R5 will only advertise the route it considers best which, in this scenario, is the path through R6 to R3 to its neighbors.
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)#endIf 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)