1.6 BGP ADVERTISING ROUTES USING " NETWORK " command

Advertising / Installing routes in BGP Table

Preconfiguration : 1. Whatever has been configured until the last post (i.e. 1.5 BGP NEXT HOP SELF)
2. Create three loopbacks : Loopback 1, Loopback 2, Loopback 3 on R6 which will be advertised to the BGP routers using the " network " command.

Synopsis :
You have already seen one way of advertising routes into BGP process. What is that ??? It's via redistribution of the IGP routes into BGP.
This method is great but it has some inherent caveats.
1. All the routes in the routing table learned by a particular IGP will be redistributed into BGP.
Now most of the enterprises may not want to advertise their entire network to the ISP,.
2. The above problem can be surmounted by the filtering, by means of route-maps. However, greater the enterprise network, more will be the complexity of the route-map filtering procedures. This can definitely add to the overhead to the router's resources

BGP "network" command enables you to advertise only those networks which you actually need to advertise to the ISP.

R6 configuration

R6(config)#router bgp 400

R6(config-router)#network 192.168.2.1 mask 255.255.255.255

R6(config-router)#network 192.168.2.2 mask 255.255.255.255

R6(config-router)#network 192.168.2.3 mask 255.255.255.255

R6(config-router)#end

R6#

*May 15 13:00:08.856: %SYS-5-CONFIG_I: Configured from console by console

R6#

The R6's output will be as follows :

Fig 1.6.1

  See the Next Hop. The next hop value of 0.0.0.0 means that the routes have been advertised to the BGP process on this router itself i.e. R6.

Similarly, the Weight of 32768 means these routes have been locally generated / advertised into BGP on this router itself.

The " i " value under " Path " column means the BGP route has been generated by the " network " command.
It would have been " ? " in case the BGP route is generated via " redistribution ".

1.5 BGP NEXT HOP SELF

Use the BGP "neighbor <IP> next-hop-self" command in order to avoid using static routes on R1.
(Remember the static route which was created in the post 1.4 so that the next-hop i.e. 5.5.5.5 could be reachable.)

Preconfiguration :  Whatever has been configured until the last post (i.e. 1.4 Injecting IGP into BGP)

So what is this BGP NEXT_HOP_SELF ???
As seen in the last post, when EBGP routes are being advertised to an IBGP peer, the next-hop address of the route is left unchanged. This is the default behavior.
Now, according to this behavior, R1's next-hop address to 60.0.0.0/8 was 5.5.5.5, which was not initially reachable. We created a static route on R1 for ensuring that the path to 5.5.5.5 is available.

(Note : The BGP route can only be a best route i.e. it will enter the routing table, if the next-hop is accessible/reachable.)

However, creating static routes is not always a feasible option. (It would be a nightmare to create static routes, if R2 had, say 50 peers each with wholly different subnet!!!!!!!)

BGP NEXT HOP SELF comes to our rescue, here!!!

What is BGP NEXT HOP SELF all about ???
When BGP NEXT HOP SELF is configured, the next-hop attribute gets modified, no matter to whichever peer (IBGP/EBGP) you are advertising the routes to.

In our case, when R2 advertises the 60.0.0.0 route to R1 with the next-hop-self configuration, R1's next-hop address to 60.0.0.0 becomes 10.0.0.2 (R2's physical IP address i.e. the IP address on which the BGP peering with R1 has been made.)

R2 configuration

R2(config)#router bgp 100

R2(config-router)#neighbor 10.0.0.1 next-hop-self

R4 configuration 

R4(config)#router bgp 100

R4(config-router)#neighbor 20.0.0.1 next-hop-self

R4(config-router)#end

R4#

*May 15 13:04:37.660: %SYS-5-CONFIG_I: Configured from console by console

Now after this configuration, you no longer need the static route on R1.

R1 configuration

R1(config)#no ip route 5.5.5.5 255.255.255.255

R1(config)#no ip route 6.6.6.6 255.255.255.255

(The static route to 6.6.6.6 was created for the routes coming from AS 40 via R4.)

Now let us check R1's output

 

Fig 1.5.1

From Fig 1.5.1, see the Next Hop column of the "show ip bgp" output.

You will see that all the routes are best routes and the Next Hop address is now 10.0.0.2, which is the directly connected subnet, hence already in the routing table.

All other attributes remain the same 

 

1.4 [...contd] INJECTING IGP ROUTES INTO BGP

Injecting IGP routes of AS 200 into BGP 

Preconfiguration : Click Here 


Now that we have received the AS 200 BGP routes (that were IGP injected) on R3 and R2 let's now see the difficulties that we face when a route is advertised from an EBGP neighbor (R5) to an IBGP neighbor (R1).


Let's see the R1's BGP table

Fig 1.4.9

Let's analyse the output of the above three "show" commands :

 The "show ip bgp" command shows that :
1. The four routes that were injected from IGP to BGP have been received and entered into R1's BGP table.
2. The BGP routes are valid (because they are '*' routes). However, they are not "best" routes (because the '>' is missing). Hence, they will not be entered into R1's routing table.

Now why are they not best routes ???

Take a close look at the output again.....

What is the next-hop for all the routes??? It's 5.5.5.5

Now see the output of "show ip bgp 60.0.0.0". You can see that the next-hop 5.5.5.5 is "inaccessible". Really??? Let's check the routing table. That's right. "5.5.5.5" is not in the routing table because we never advertised the R5's loopback to R1. Wait a moment...... But shouldn't the next-hop for route 60.0.0.0 be 10.0.0.2, i.e. R1's directly connected interface to R2???

Well, here is BGP's another rule for peering :

When an EBGP route is advertised to an IBGP neighbor, the NEXT_HOP attribute is left unchanged.

This is the reason, R2 does not change the next-hop value when advertising the route to R1. No issues. We can solve the problem by simply creating a static route on R1 for 5.5.5.5. Fig 1.4.10 shows how this is done.

Fig 1.4.10

Now let's check if the problem is solved.

Fig 1.4.11

Well from Fig 1.4.11, it does look like all our problems have been solved.

The routes are all "best" routes thanks to the little ">" sign before them. The "i" in the beginning denotes "internal" i.e. learned from an IBGP neighbor. The metric value remains same as that seen on R2. The next-hop i.e. R5's loopback is now reachable because of the static route that we just configured. (Check its humble presence in R1's routing table).
 

1.4 INJECTING IGP ROUTES INTO BGP

Injecting IGP routes of AS 200 into BGP

Preconfiguration :
We will first configure EIGRP as our IGP in AS 200.

R5 configuration :

Fig 1.4.1

R7 configuration :

Fig 1.4.2

 Verification : 

1. Verify the R5's EIGRP neighborship with R7 as shown in Fig 1.4.3

Fig 1.4.3

2. Check the  R5's EIGRP topology table as show in Fig 1.4.4

Fig 1.4.4

3. Check the EIGRP routes that have been installed into R5's routing table.

Fig 1.4.5

Note : You must note that only those routes which are already in the router's routing table will be installed in the BGP table. 

Actual configuration :

Now that we have IGP (i.e. EIGRP) routes installed in R5's routing table, we'll redistribute these routes into BGP.
Fig 1.4.6 shows the EIGRP routes redistribute into BGP. Note that we are not changing/specifiying the metric for BGP to consider for EIGRP learned routes after redistribution.

Fig 1.4.6

 From Fig 1.4.6 you can see that the "show ip bgp" output that the desired IGP routes have been redistributed into the BGP process.
Note that three loopbacks 192.168.1.1/32, 192.168.1.2/32 and 192.168.1.3/32 were previously created and advertised into EIGRP on R7.

From the above output, you can see that :

1. The next hop is 60.0.0.7 i.e. R7's directly connected interface.
2. The metric for BGP is the same as that of the EIGRP metric. Thus, when you redistribute EIGRP into BGP, the BGP takes the EIGRP metric.
3. The local preference is zero.
4. Weight is 32768 because this is the router where the BGP routes have been generated (in our case from EIGRP). This is otherwise zero as you'll see in R2's output in Fig 1.4.7
5. The "?" denotes that the route has been "redistributed" into BGP and not advertised by "network" statement.
MOST IMPORTANT : The '*' in front of the route denotes that the route is valid and '>' shows that it is the best route.

Now we have an EGBP peering between R2 and R5. So let's check R2's BGP table:

Fig 1.4.7

From Fig 1.4.7, you can see that the next hop has been changed to 5.5.5.5 which is the loopback address of R5 on which the EBGP peering with R2 has been established.

This gives us one of the most important rules of BGP that :

The NEXT HOP attribute changes when a route is being advertised to a EBGP peer.

The metric value is, however, retained.
Also pay attention to the AS_PATH attribute (Path column). The route originated in AS 200 which is directly connected to our AS 100. Hence, the AS_PATH list contains only 200.

You will see that in the Fig 1.4.8 shows that R3's "show ip bgp" output will show the AS_PATH of "100 200" . The AS_PATH attribute is a loop prevention mechanism which confirms the PATH VECTOR nature of the BGP Algorithm.

Fig 1.4.8

Note that in Fig 1.4.8, the metric value has been lost, and the next-hop value has again changed to 50.0.0.2 which is R2's directly connected physical interface on which EBGP peering with R3 has been established.

[Continued in the next post]