BGP As PE-CE With Backboor Link Part 2

Problem Description
When primary link from service provider goes down at that time traffic forwarding works fine with the backdoor link but when the service provider link comes up that path is not preferred.

Please refer to my previous post BGP Routing Table Of R2
R2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 3.1.1.0/30 1.1.1.2 0 1 ?
*> 4.1.1.0/30 0.0.0.0 0 32768 ?
*> 30.30.30.30/32 1.1.1.2 0 1 3 ?
*> 40.40.40.40/32 0.0.0.0 0 32768 ?
Table 1

From the above output it is cleared that the routes which are coming from E-BGP peer are set with weight 0 and the routes which are redistributed in BGP from IGP are set with weight 32768. The above output depicts clearly that the route 3.1.1.0 belongs to R3-R1 wan link and 30.30.30.30 is the loopback address of R3 and coming with weight as 0. 4.1.1.0 is the wan pool of R2-R3 and 40.40.40.40 is the loopback of R2 are showing in BGP table with weight of 32768.

Routing Table Of R2
1.0.0.0/30 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
3.0.0.0/30 is subnetted, 1 subnets
B 3.1.1.0 [20/0] via 1.1.1.2, 00:12:34
4.0.0.0/30 is subnetted, 1 subnets
C 4.1.1.0 is directly connected, FastEthernet0/1
40.0.0.0/32 is subnetted, 1 subnets
C 40.40.40.40 is directly connected, Loopback0
30.0.0.0/32 is subnetted, 1 subnets
B 30.30.30.30 [20/0] via 1.1.1.2, 00:02:47
Table 2

1.1.1.2 is the ip address of service provider router. Lets down the service provider link of R2 and check the output.

BGP table of R2
Network Next Hop Metric LocPrf Weight Path
*> 4.1.1.0/30 0.0.0.0 0 32768 ?
*> 30.30.30.30/32 4.1.1.2 2 32768 ?
*> 40.40.40.40/32 0.0.0.0 0 32768 ?
Table 3

Now compare the outputs of table 3 and table 1. The difference is quite clear the routes which were coming with weight 0 now receiving the same routes with weight 32768. As I have already explained the local routes from IGP to BGP comes with weight 32768 and the E-BGP received routes come with weight 0.
Routing Table Of R2
4.0.0.0/30 is subnetted, 1 subnets
C 4.1.1.0 is directly connected, FastEthernet0/1
40.0.0.0/32 is subnetted, 1 subnets
C 40.40.40.40 is directly connected, Loopback0
30.0.0.0/32 is subnetted, 1 subnets
O 30.30.30.30 [110/2] via 4.1.1.2, 00:06:10, FastEthernet0/1
Table 4

4.1.1.2 is the backdoor link from R2 to R3.

Now the service provider link come up and by default the routing convergence should take place and all the routes should prefer from service provider cloud because E-BGP is having less administrative distance than OSPF. So let’s check what happens when the link comes up.

BGP Routing Table Of R2
Network Next Hop Metric LocPrf Weight Path
*> 3.1.1.0/30 1.1.1.2 0 1 ?
*> 4.1.1.0/30 0.0.0.0 0 32768 ?
*> 30.30.30.30/32 4.1.1.2 2 32768 ?
*> 40.40.40.40/32 0.0.0.0 0 32768 ?
Table 5

R2#show ip bgp 30.30.30.30
BGP routing table entry for 30.30.30.30/32, version 26
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
Local
4.1.1.2 from 0.0.0.0 (40.40.40.40)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best
Table 6
From table 5 and 6 it is cleared that the loopback route of R3 is coming via backdoor link instead of primary link which is up now. Table 6 output exhibit that the route is coming via IGP routing table and now redistributing to BGP.

How to Overcome This Problem
Increase the weight of the E-BGP neighbor by using weight command.
Configuration done on R2
Router bgp 2
Neighbor 1.1.1.2 weight 33000.
Table 7

Output of bgp table after setting weight
Network Next Hop Metric LocPrf Weight Path
*> 3.1.1.0/30 1.1.1.2 33000 1 ?
r> 4.1.1.0/30 1.1.1.2 33000 1 3 ?
r 0.0.0.0 0 32768 ?
*> 30.30.30.30/32 1.1.1.2 33000 1 3 ?
r> 40.40.40.40/32 1.1.1.2 33000 1 3 ?
r 0.0.0.0 0 32768 ?

30.30.30.30 route is coming via routing table as well as from service provider cloud. But the route installed in routing table is from service provider end because of having more weight.


regards
shivlu jain

People who read this post also read :