OSPF to BGP Re-Distributed, Question

darkerz

Scenario: OSPF as a backup WAN link, BGP as the main WAN link into MPLS.

When BGP link dies, rolls over to OSPF no problem.

When BGP link is alive, never rolls over to OSPF.

clear ip ospf process - does not work
clear ip route ospf - does not work

The only thing that works is disconnecting the OSPF device manually or shutting it, clearing OSPF routes out and letting BGP come back to save the day.

////////////////////////////////////////////////////////

router ospf 1
router-id 10.10.10.8
log-adjacency-changes
redistribute bgp 65000 metric 1 subnets
network 10.0.1.0 0.0.0.255 area 0
!
router bgp 65000
no synchronization
bgp router-id 65.113.57.1xx
bgp log-neighbor-changes
network 10.0.1.0
redistribute connected
redistribute static
redistribute ospf 1
neighbor 65.113.57.1xx remote-as 209
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.0.1.2

/////////////////////////////////////////////////////////////////



If you were to sh ip route when BGP fails, OSPF will take over all routes.

If you were to sh ip route after BGP is back, OSPF does not budge.


Not sure where I'm in the wrong here, unless theres a specific default metric I'd need to assign to the redistribution points to make BGP preferred? Already tried changing the weight path (higher is better) but to no avail.

drkat

ospf has a lower AD than BGP so you'll need to adjust the AD in order for BGP to take back over


Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1 - Configuring BGP - Cisco Systems

darkerz

Directly connected networks


1
Static routes


20
E-BGP


90
Internal EIGRP


100
IGRP


110
OSPF


115
IS-IS


120
RIP


170
External EIGRP


200
I-BGP


255
Unknown




Unless I am mistakened, my BGP is speaking from AS 65000 to AS 209, does this not constitute EBGP? I'm not having 65000 talk to 65000...

Unless this isn't true eBGP and it's treating it at an iBGP setup?

(This is my edge router talking to a Century Link edge over BGP/MPLS)

~

drkat

what does show ip route tell you about the bgp routes?

I've read IGP beats BGP if routes are stored with the same weights.. can you post

show ip route
show ip bgp
show ip ospf

ive seen where routes treated the same act this way.. i'd like to see how the routes are learned from those commands and see what's up. Maybe the ospf route installed after the bgp route is of the same metric? post those commands

darkerz

*Sep 9 18:59:52.567: %BGP-5-ADJCHANGE: neighbor 65.113.57.153 Up
R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route


Gateway of last resort is 10.0.1.2 to network 0.0.0.0


1.0.0.0/24 is subnetted, 1 subnets
O 1.1.1.0 [110/3] via 10.0.1.2, 00:02:41, FastEthernet0/1
50.0.0.0/32 is subnetted, 1 subnets
O 50.50.50.50 [110/3] via 10.0.1.2, 00:02:41, FastEthernet0/1
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/2] via 10.0.1.2, 00:02:41, FastEthernet0/1
65.0.0.0/30 is subnetted, 1 subnets
C 65.113.57.152 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.1.0 is directly connected, FastEthernet0/1
S* 0.0.0.0/0 [1/0] via 10.0.1.2
R3#sh ip bgp
BGP table version is 23, local router ID is 65.113.57.154
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 10.0.1.2 3 32768 ?
*> 2.2.2.0/24 10.0.1.2 2 32768 ?
*> 10.0.1.0/24 0.0.0.0 0 32768 ?
*> 50.50.50.50/32 10.0.1.2 3 32768 ?
*> 65.113.57.152/30 0.0.0.0 0 32768 ?



Could it be that the static route + redistributing static routes could be messing with the inherit routing properties that should make this not such a difficult problem?

EDIT** Checked, nope.

!

darkerz

Hey everyone, looks like I was able to fix it. Here is the new, working config:

router ospf 1
router-id 10.10.10.8
log-adjacency-changes
redistribute bgp 65000 subnets
network 10.0.1.0 0.0.0.255 area 0
!
router bgp 65000
bgp router-id 65.113.57.15x
bgp log-neighbor-changes
neighbor 65.113.57.15x remote-as 209
!
address-family ipv4
redistribute connected
redistribute static
redistribute ospf 1 match internal external 1 external 2
neighbor 65.113.57.15x activate
neighbor 65.113.57.15x weight 32900
no auto-summary
no synchronization
network 10.0.1.0
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 10.0.1.2
no ip http server
no ip http secure-server

//////////////////////////////////////////



R3#sh ip bgp
BGP table version is 32, local router ID is 65.113.57.154
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.0/24 65.113.57.153 0 32900 209 ?
*> 2.2.2.0/24 65.113.57.153 32900 209 65001 ?
*> 10.0.1.0/24 0.0.0.0 0 32768 ?
*> 50.50.50.50/32 65.113.57.153 32900 209 65001 ?
*> 65.113.57.0/24 65.113.57.153 0 32900 209 ?
*> 65.113.57.152/30 0.0.0.0 0 32768 ?



R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route


Gateway of last resort is 10.0.1.2 to network 0.0.0.0


1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 65.113.57.153, 00:02:39
50.0.0.0/32 is subnetted, 1 subnets
B 50.50.50.50 [20/0] via 65.113.57.153, 00:02:39
2.0.0.0/24 is subnetted, 1 subnets
B 2.2.2.0 [20/0] via 65.113.57.153, 00:02:39
65.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 65.113.57.0/24 [20/0] via 65.113.57.153, 00:02:39
C 65.113.57.152/30 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.1.0 is directly connected, FastEthernet0/1
S* 0.0.0.0/0 [1/0] via 10.0.1.2



Looks like I had to tweak it a little and define my as-209 neighbors weight, then I called the carrier and verified the reason this was happening:

--More--
*Sep 9 19:14:01.015: %BGP-3-NOTIFICATION: received from neighbor 65.113.57.154 1/1 (header synchronization problems) 0 bytes
--More--
*Sep 9 19:14:01.015: %BGP-5-ADJCHANGE: neighbor 65.113.57.154 Down BGP Notification received
--More--
*Sep 9 19:14:29.591: %BGP-3-NOTIFICATION: sent to neighbor 65.113.57.154 1/1 (header synchronization problems) 0 bytes
--More--
*Sep 9 19:15:03.523: %BGP-5-ADJCHANGE: neighbor 65.113.57.154 Up


Was because they did not assign the same weight to me on their end.

I don't fully understand why the set weight defines this process so much, so if anyone has a link or an explaination, I would love it so I don't just go to my boss/peers/study group and just derp out "well, um, yeah NETWORKING"..

unclerico

This is a race condition. If your BGP peer comes up first and exchanges prefixes before your OSPF neighbor does, then the path via BGP will be preferred. The reason why in this case is because eBGP AD = 20 and OSPF AD = 110

The issue you are seeing is that when the BGP peering is up and functioning the OSPF routes have no chance to win. Once the BGP peer goes down now the OSPF routes are installed and then redistributed into BGP. The redistributed routes have a weight of 32768 by default and since it is the very first decision criteria in the tree the OSPF redistributed route will always beat the route coming via MPLS as that will have a weight of 0. When you changed the weight of the neighbor in your last config it made it so that the MPLS route will be preferred. Another way you could have done this is to filter the routes being redistributed into BGP to keep them from going in the first place.

Clearing the ospf process did nothing because it too is a timing thing. Remember, BGP has a default advertisement timer of 30 seconds so if that timer had not lapsed by the time OSPF reconverged then it would continue to use the path via OSPF

fluk3d

I found this link pretty helpful.

https://supportforums.cisco.com/docs/DOC-5748