OSPF to BGP Re-Distributed, Question

darkerzdarkerz Member Posts: 431 ■■■■□□□□□□
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.
:twisted:

Comments

  • drkatdrkat Banned Posts: 703
    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
  • darkerzdarkerz Member Posts: 431 ■■■■□□□□□□



    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)

    ~
    :twisted:
  • drkatdrkat Banned Posts: 703
    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
  • darkerzdarkerz Member Posts: 431 ■■■■□□□□□□
    *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.

    !
    :twisted:
  • darkerzdarkerz Member Posts: 431 ■■■■□□□□□□
    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"..
    :twisted:
  • unclericounclerico Member Posts: 237 ■■■■□□□□□□
    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
    Preparing for CCIE Written
  • fluk3dfluk3d Member Posts: 141 ■■■□□□□□□□
    I found this link pretty helpful.

    https://supportforums.cisco.com/docs/DOC-5748
    "Imagination is more important than knowledge." - Albert Einstein
Sign In or Register to comment.