[BGP, OSPF, Redistribution] Order of operations?

[NetworkGroover]

Got a goofy setup here that I'm doing for testing and wondering if I'm running into an order of operations thing here, or just brainfarting a simple concept.  I've attached a diagram.  On SPINE1, for BGP, I'm redistributing connected routes with a route map that only allows its loopback and the two /31 subnets connected to it. For OSPF, I'm advertising its loopback and the 10.255.255.255.2/31 subnet.  I'm also redistributing OSPF into BGP, and vice versa.  All is fine and dandy, except LEAF2 is missing the the 10.255.255.0/31 subnet.  Now, I can easily fix this by advertising that subnet into OSPF, but for my education I'm curious.

If I'm redistributing connected routes on SPINE1, which 10.255.255.0/31 is, into BGP, and redistributing BGP into OSPF, why doesn't LEAF2 learn the 10.255.255.0/31 subnet?  Actually now that I think of it, the only reason why LEAF1 has the 10.255.255.2/31 subnet, using the same logic, is because I'm explicitly advertising it into BGP with the redistribute connected command.  Still, I'm missing a probably basic concept here and wondering if this is the "best" way to do this.

[that1guy15]

Your route-map is only allowing OSPF to learn the Loopback prefixes of SPINE1 from BGP.

Either kill the route-map or add the prefix to the prefix-list to test.

[that1guy15]

For best practices, you really have no reason to advertise the transit links. They just take up RIB space and have no value. So I would suggest only advertising the loopback of the device and actual host prefixes. But you might have reasons to advertise them.

Route-maps with redistribute always!

[NetworkGroover]

Your route-map is only allowing OSPF to learn the Loopback prefixes of SPINE1 from BGP.

Either kill the route-map or add the prefix to the prefix-list to test.

Not sure I'm following.  Operationally I know you want to use route-maps for all redistribution, but for testing purposes and laziness with such a small environment, I'm only using a route-map with the redistribute connected command for BGP.  Here's the relevant config on SPINE1:

Code Select Expand

router ospf 100
   router-id 10.2.2.2
   passive-interface default
   no passive-interface Ethernet4/1/1
   redistribute bgp
   network 10.2.2.2/32 area 0.0.0.0
   network 10.255.255.0/31 area 0.0.0.0
   network 10.255.255.2/31 area 0.0.0.0 < -- Added this later to make the route appear on LEAF2
   max-lsa 12000
   maximum-paths 32

router bgp 64500
   router-id 10.2.2.2
   bgp log-neighbor-changes
   bgp default ipv6-unicast
   timers bgp 30 30 < -- Ignore this...
   maximum-paths 32 ecmp 32
   neighbor BGP_GROUP peer-group
   neighbor BGP_GROUP remote-as 64501
   neighbor BGP_GROUP password 7 lZhvoOgU9KnRRlerMRERXQ==
   neighbor BGP_GROUP maximum-routes 12000
   neighbor 10.255.255.1 peer-group BGP_GROUP
   neighbor 2001::1 peer-group BGP_GROUP
   redistribute connected route-map BGP_ADV_RM
   redistribute ospf
   redistribute ospf3

route-map BGP_ADV_RM permit 10
  Description:
  Match clauses:
    match ip address prefix-list BGP_ADV_PF
  Set clauses:
route-map BGP_ADV_RM permit 20
  Description:
  Match clauses:
    match ipv6 address prefix-list BGP_ADV_PF_V6
  Set clauses:

ip prefix-list BGP_ADV_PF
seq 10 permit 10.2.2.2/32
seq 20 permit 10.255.255.0/24 eq 31

ipv6 prefix-list BGP_ADV_PF_V6
seq 10 permit 2000::2/128
seq 20 permit 2001::/112 eq 127

[Otanx]

If I am understanding correctly it is because the BGP route for the /31 is not the best path (the connected is) so it does not get redistributed into OSPF.

-Otanx

[NetworkGroover]

I guess I could always remove the route-map and use network statements instead and see what the result is.. won't be able to do that for a bit though.

[NetworkGroover]

If I am understanding correctly it is because the BGP route for the /31 is not the best path (the connected is) so it does not get redistributed into OSPF.

-Otanx

Sorry, could you reword/elaborate?  I'm a little slow.

[that1guy15]

OSPF redistribute bgp 64500 subnets.

[NetworkGroover]

OSPF redistribute bgp 64500 subnets.

No such option in the OS I'm working with.

Sorry for responding so late to this - I'm sure you have braindumped it as I did and I had to go back and look at this, but I addressed this just by simply advertising the prefix into OSPF directly, rather than depending on it to be redistributed by BGP - it didn't make sense for me to depend on it that way when it was a directly connected interface.

I also now see/understand what you said about my prefix-list (Big duh on my part).  Unfortunately though, adding that prefix didn't fix the problem (EDIT - Neither did killing the route map and just redistributing all BGP).  Doesn't really matter though and not going to bother figuring out why - I think it's better to simply directly advertise it into OSPF as mentioned above since it resides right off that switch in my case.  In other cases though, would you want to maybe redistribute it instead so that it appears as an external route? Am I making any sense or does it just sound like gibberish?

[NetworkGroover]

For best practices, you really have no reason to advertise the transit links. They just take up RIB space and have no value. So I would suggest only advertising the loopback of the device and actual host prefixes. But you might have reasons to advertise them.

Route-maps with redistribute always!

That's something I'm researching, actually.  Does advertising transit links help at all with troubleshooting, such as with a traceroute and such?

[Otanx]

If I am understanding correctly it is because the BGP route for the /31 is not the best path (the connected is) so it does not get redistributed into OSPF.

-Otanx

Sorry, could you reword/elaborate?  I'm a little slow.

Missed this, and you have it fixed, but..

My understanding is if the route that is being redistributed is not installed in the routing table it will not redistribute. So because the connected route is chosen over the entry in BGP that route will not be included. I could be completely wrong. I don't get to do routing much. It just works.

-Otanx

[NetworkGroover]

If I am understanding correctly it is because the BGP route for the /31 is not the best path (the connected is) so it does not get redistributed into OSPF.

-Otanx

Sorry, could you reword/elaborate?  I'm a little slow.

Missed this, and you have it fixed, but..

My understanding is if the route that is being redistributed is not installed in the routing table it will not redistribute. So because the connected route is chosen over the entry in BGP that route will not be included. I could be completely wrong. I don't get to do routing much. It just works.

-Otanx

Gotcha, and yes I think that's correct. EDIT - I think since we look at what's in the routing table now:

Code Select Expand

SPINE1#sh ip route
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I - ISIS, A B - BGP Aggregate, A O - OSPF Summary,
       NG - Nexthop Group Static Route

Gateway of last resort is not set

B E    10.1.1.1/32 [200/0] via 10.255.255.1, Port-Channel1
C      10.2.2.2/32 is directly connected, Loopback0
O      10.3.3.3/32 [110/20] via 10.255.255.3, Ethernet4/1/1
C      10.255.255.0/31 is directly connected, Port-Channel1
C      10.255.255.2/31 is directly connected, Ethernet4/1/1

We see that the only BGP route is 10.1.1.1/32 - so I imagine that even with no route-map, the only thing that would be redistributed is that route even though we're advertising others via BGP:

Code Select Expand

SPINE1#sh ip bgp neighbors 10.255.255.1 advertised-routes
BGP routing table information for VRF default
Router identifier 10.2.2.2, local AS number 64500
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

       Network             Next Hop         Metric  LocPref Weight Path
* >   10.2.2.2/32         10.255.255.0     -       -       -      64500 i 
* >   10.3.3.3/32         10.255.255.0     -       -       -      64500 i 
* >   10.255.255.0/31     10.255.255.0     -       -       -      64500 i 
* >   10.255.255.2/31     10.255.255.0     -       -       -      64500 i

[that1guy15]

Ah makes more sense.

Just because a local route is part of one protocol does not mean it will redistribute with that protocol into another protocol. So if its local you will also need to redistribute local in OSF as well.

For a deeper understanding do a little research on how protocols actually redistribute between each other.


Also you "subnets" comment was:

router ospf 1
redistribute bgp subnets

else you will just be redistributing any classfull matches.

[srg]

Just because a local route is part of one protocol does not mean it will redistribute with that protocol into another protocol. So if its local you will also need to redistribute local in OSPF as well.

I'm not 100% sure what you mean, but an interface subnet belonging to a protocol will be redistributed with that protocol without the need for redistribute connected. This is at least true in Cisco IOS, I don't know which NOS is used here.

[that1guy15]

If the local interface is natively added then yeah but Im talking about if its redistributed into that protocol,

So static route, redistributed into BGP then BGP redistributed into OSPF. the static will not carry over into OSPF without redistribute connected.

As mentioned its it makes more sense just to add the route to the protocol.