cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3787
Views
0
Helpful
14
Replies

BGP modified attribute and Redistribution to OSPF?

Lost & Found
Level 2
Level 2
Hi All,
Q:
1.After changing localpref for 192.168.103.1 on R2, R4 doesn’t received prefix 192.168.103.1 from R2 anymore. although local preference changed to 300 on R2.
Conf:
ip access-list standard NET
 permit 192.168.103.1
route-map RM:-NET permit 10
 match ip address NET
 set local-preference 300
neighbor 10.99.0.11 route-map RM:NET in
And in ospf external routes only advertised routes from R4 appears.
2. What happened to the modified BGP prefixes after we redistribute to other internal routing protocol.
3.  In this scenario R2 and R4 redistribute BGP routes to OSPF, In this case we manipulate the traffic using ospf metric R2 +20 and R4 +100 so that R2 will be the preffered
Incase we need internal host to use R3-R4 path going to 192.168.103.1 what would be the solution?
Sln:
Adding static route
Create selective additional metric on bgp-ospf redistri routemap (Asymetric)
BGP local pref
Ip prefixlist (advertisement)

thanks

1 Accepted Solution

Accepted Solutions

The reason is because local preference comes before EBGP vs IBGP in the best path selection algorithm.

So on R2 you receive the same route via BGP from both E1 and R4. You have changed the local preference on the IBGP route you receive from R4 and so R2 now compares the two routes and because of the local preference chooses the IBGP route.

So R2 now has it's chosen BGP  route but it also has an OSPF route from the redistribution on R4 and this has a lower AD so it is the one installed in the IP routing table.

Which means it will not be redistributing it's BGP route into OSPF because it's BGP route is not in the IP routing table which is why traffic has to go via R4 to get to the remote network.

Jon

View solution in original post

14 Replies 14

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

Local preference is non-transitive, which means it applies to only AS-6501 (r2 and r3) and as long r2 has higher local perf and it is up, all traffic will go through it. 

So, in your case r2 has a higher local pref, so outbound internal traffic will take r1, r2,e1. If r2 fails, than all local traffic will traverse using r3, r4 and e2. If you want to load share traffic between the 2 ISPs (e1 and e2) you can do it by applying local pref per prefix.  see this document:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html#anc27

HTH 

Hi Reza,

That's is correct high localpref will be preferred. But in this case R2 local pref is 300 for prefix 192.168.103.1 so if reaching .103.1 R2 should be the best path. But, on internal we redistribute routes learned from bgp to OSPF so the ospf should have 2 learned in database as external route 1 from R2 which +20 metric and 1 for R4 +100 metric.

In this case after modifying attribute(localpref) on R2, there no more received route in R1 ospf database from R2. So in this case R1 > R3 > R4 is now the preferred path.

Thank you

Hi,

The primary path should be r1, r2, e1.

How did you redistribute BGP to OSPF? (redistribute bgp 6501 metric 10 subnets)

Can you post relevant configs from r2 and r4?

Thanks

Hi Reza,

Here the details.

 

R2#sh ip route

      192.168.103.0/32 is subnetted, 1 subnets

O E2    192.168.103.1 [110/100] via 172.30.0.25, 00:53:58, FastEthernet1/1

C        10.99.0.10/32 is directly connected, Loopback0

O        10.99.0.11/32 [110/4] via 172.30.0.25, 01:13:45, FastEthernet1/1

 

R2#sh ip bgp

r>i192.168.103.1/32 10.99.0.11              0    300      0 15766 64642 i

r                  10.99.4.166                            0 12641 64642 i

*> 10.99.0.10/32    0.0.0.0                  0         32768 i

r>i10.99.0.11/32    10.99.0.11               0    100      0 i

 

R2#sh ip bgp rib-failure

Network            Next Hop                      RIB-failure   RIB-NH Matches

8.8.8.8/32         10.99.0.11          Higher admin distance              n/a

10.99.0.11/32      10.99.0.11          Higher admin distance              n/a

172.30.16.0/20     10.99.0.11          Higher admin distance              n/a

192.168.103.1/32   10.99.0.11          Higher admin distance              n/a

 

R2 Conf:

router ospf 1

log-adjacency-changes

redistribute bgp 65001 metric 20 subnets

network 10.99.0.10 0.0.0.0 area 0

network 172.30.0.26 0.0.0.0 area 0

router bgp 65001

no synchronization

bgp router-id 10.99.0.10

bgp log-neighbor-changes

network 10.99.0.10 mask 255.255.255.255

network 172.30.0.0 mask 255.255.240.0

neighbor 10.99.0.11 remote-as 65001

neighbor 10.99.0.11 update-source Loopback0

neighbor 10.99.0.11 next-hop-self

neighbor 10.99.0.11 soft-reconfiguration inbound

neighbor 10.99.0.11 route-map RM:NET in

neighbor 10.99.4.166 remote-as 12641

neighbor 10.99.4.166 soft-reconfiguration inbound

no auto-summary

 

---------------------------------

 

R4#sh ip route

O        10.99.0.10/32 [110/4] via 172.30.16.25, 01:11:04, FastEthernet1/1

C        10.99.0.11/32 is directly connected, Loopback0

      192.168.103.0/32 is subnetted, 1 subnets

B        192.168.103.1 [20/0] via 10.99.4.174, 00:56:54

 

IDC_WAN01#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path

r>i10.99.0.10/32    10.99.0.10               0    100      0 i

*> 10.99.0.11/32    0.0.0.0                  0         32768 i

*> 192.168.103.1/32 10.99.4.174                            0 15766 64642 i

 

R4 Conf:

router ospf 1

router-id 10.99.0.11

log-adjacency-changes

redistribute bgp 65001 subnets route-map OSPF_MET

network 10.99.0.11 0.0.0.0 area 0

network 172.30.16.26 0.0.0.0 area 0

router bgp 65001

no synchronization

bgp router-id 10.99.0.11

bgp log-neighbor-changes

network 10.99.0.11 mask 255.255.255.255

network 172.30.16.0 mask 255.255.240.0

neighbor 1.1.1.2 remote-as 65001

neighbor 10.99.0.10 remote-as 65001

neighbor 10.99.0.10 update-source Loopback0

neighbor 10.99.0.10 next-hop-self

neighbor 10.99.0.10 soft-reconfiguration inbound

neighbor 10.99.4.174 remote-as 15766

neighbor 10.99.4.174 soft-reconfiguration inbound

no auto-summary

 

192.168.103.1 prefix came from R4 since its has lower distance between ibgp and ospf, So that why causing RIB faulure.

But since i got also received routes from E1 not sure why R2 prefer/saved routes from R4 which is ospf :(

Thanks

The reason is because local preference comes before EBGP vs IBGP in the best path selection algorithm.

So on R2 you receive the same route via BGP from both E1 and R4. You have changed the local preference on the IBGP route you receive from R4 and so R2 now compares the two routes and because of the local preference chooses the IBGP route.

So R2 now has it's chosen BGP  route but it also has an OSPF route from the redistribution on R4 and this has a lower AD so it is the one installed in the IP routing table.

Which means it will not be redistributing it's BGP route into OSPF because it's BGP route is not in the IP routing table which is why traffic has to go via R4 to get to the remote network.

Jon

Hi Jon,

Good Explanation. Thank you. But, want to clarify below.

"The reason is because local preference comes before EBGP vs IBGP in the best path selection algorithm."

1. Regardless whether Local Pref changed or not. R2 received prefix 192.168.103.1 from E1 and R4 which one R2 will use? Routes received from E1 or R4?

2. How about the received routes from E1(ebgp), does R2 advertised it to R4 even though there's a rib failure?

From article "But R2 will advertise this BGP route to R3 regardless of the rib-failure." 

Or since R2 has the highest local pref (Best path), R2 will not advertise learned 192.168.103.1 route to R4 because R2 is the best path? What would be the cause of R2 not adversing 192.168.103.1 route to R4? Is this normal?

R2#sh ip bgp neighbors 10.99.0.11 advertised-routes

  Network          Next Hop            Metric LocPrf Weight Path

*> 4.4.4.4/32      10.99.4.166              0            0 12641 i

*> 10.11.8.1/32    10.99.4.166                            0 12641 64642 i

*> 10.11.9.1/32    10.99.4.166                            0 12641 64642 i

*> 10.99.0.9/32    10.99.4.166                            0 12641 64642 i

*> 10.99.0.10/32    0.0.0.0                  0        32768 i

*> 172.30.0.0/20    172.30.0.25            20        32768 i

*> 172.31.253.1/32  10.99.4.166                            0 12641 64642 i

*> 172.31.254.1/32  10.99.4.166                            0 12641 64642 i

*> 192.168.200.1/32 10.99.4.166                            0 12641 64642 i

- R2 did not advertised 192.168.103.1 because R2 is the best path -Coorect?

3. "So R2 now has it's chosen BGP  route but it also has an OSPF route from the redistribution on R4 and this has a lower AD so it is the one installed in the IP routing table. Which means it will not be redistributing it's BGP route into OSPF because it's BGP route is not in the IP routing table which is why traffic has to go via R4 to get to the remote network."

What would be the best solution for this?

1. Do i need to setup filtering on R2 point upstream(R1)?

2. bgp suppress-inactive <- tried to put in R2 but it doesn't work.

Again thank you for the very informative info.

Regards,

Arvin R.

1) You can't say regardless of whether local pref is changed or not because it matters as I explained.

If you mean something else please clarify.

2) Is this with local preference modified or not ?

Not sure what you mean about R2 advertising BGP route to R3 because R3 is not running BGP.

3) Best solution if you want traffic to go via R2 is not to modify local preference.

Jon

1. What i mean by this is since we have received route 192.168.103.1 from E1 and R4 and lets say we didnot changed the local preference. E1 Ebgp routes will be the most preferred based on bgp path selection? so routes from e1 will be installed on R2? 

2. Please disregard R3 came from an article not related with this issue.What would be the reason why R2 not advertising 192.168.103.1 to it ibgp peer R4?

3. so incase we need to manipulate outgoing traffic, we should do it on ospf metric? but in the end bgp will still the one to decide whether to use/pass E1 or E2 link.

Apologize for creating such confusion. 

Thanks

1) Yes as long as there is nothing before that in the BGP best path selection that is taken into consideration first. If you are playing with BGP you should have this link to hand which covers the best path selection in detail -

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

2) Because the EBGP route received on R2 was not the preferred route ie. the route from R4 was preferred so if R4 is the best path it should not be advertising that route to R4.

3) If you did not modify the local preference then both R2 and R4 would have an EBGP preferred route (again assuming it came down to that in the best path selection) and so manipulating the OSPF metric would work ie. you could influence which exit point was used.

No need to apologise, these things can be confusing anyway :)

Jon

2. last question :) :) to finalize 

"Because the EBGP route received on R2 was not the preferred route"

- So this me if route received is not preferred route it will never be advertise?

"the route from R4 was preferred so if R4 is the best path it should not be advertising that route to R4."

- You mean by this is that since R4 is the preferred path, R4 should not advertise route to R2?

Based on R4 show ip bgp neig R2 advertised-routes command

*> 192.168.103.1/32 10.99.4.174                            0 15766 64642 i <- it advertising the route to r2

Thank you

The key thing to understand is that R2 receives two BGP routes for the same prefix and so it must make a choice between them using the best path selection algorithm.

You modified the local preference so R4 was the path chosen by R2 which means R2 cannot advertise that route to R4 because R2 sees R4 as the next hop.

As for R4 it does not know whether it is the preferred path for R2 or not because you applied the local preference on R2 so it absolutely should advertise the route to R2.

By all means ask as many questions as you like, that is what the forums are for :)

Jon

Noted. 

Thanks thanks for your help Jon. now I understand the issue and how to resolve it.

Again thanks

No problem, glad to have helped.

Jon

Hi Jon,

In addition, Just saw this article from

cisco http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/19345-bgp-noad.html

says

"However the network 130.130.130.0/24 does not have the status code of best route (>). This means that the BGP Best Path Selection Algorithm did not choose this prefix as the best path. Since only the best paths are announced to BGP peers, network 130.130.130.0/24 is not announced to R102. Next, you need to troubleshoot why the BGP path selection criteria did not select this network as the best route."

Mean then only the best route's will be advertise to bgp peer :)

Thank you