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]