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
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.
Now let's check if the problem is solved.
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).
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 |
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).
No comments:
Post a Comment