OSPF conditional default-route with route-map & iBGP routes

Rolf Fischer · ‎10-26-2015

Hi All,

today I came across a behaviour of the route-map option in the OSPF default-information originate command I don't understand.
I have this pretty simple setup:
R1 Loop0: 1.1.1.1/32
R1 Loop10: 10.10.10.10/32
R1 Fa0/0: 192.168.12.1/24

R2 Loop0: 2.2.2.2/32
R2 Fa0/0: 192.168.12.2/24

Relevant configuration:
router ospf 1
 router-id 1.1.1.1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.12.1 0.0.0.0 area 0
!

access-list 10 permit 10.10.10.10
!
route-map 10.10.10.10 permit 10
 match ip address 10
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.12.2 0.0.0.0 area 0
 default-information originate metric-type 1 route-map 10.10.10.10
!
ip route 0.0.0.0 0.0.0.0 Null0
!

Cisco documentation states that the route-map "needs to be satisfied" in order to inject the OSPF 0/0 LSA. I always thought that the prefix referenced by the ACL simply needs to be present in the routing table, but ...

First, with a local static route or an OSPF-learned route everything works like expected:

R2(config)#do show ip ospf database external
            OSPF Router with ID (2.2.2.2) (Process ID 1)

R2(config)#ip route 10.10.10.10 255.255.255.255 null 0

OSPF: Generate external LSA 0.0.0.0, mask 0.0.0.0, type 5, age 0, metric 1, tag 1, metric-type 1, seq 0x80000001

R2(config)#do show ip ospf database external
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Type-5 AS External Link States
  LS age: 15
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x7BAF
  Length: 36
  Network Mask: /0
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 1

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

R1(config)#do show ip ospf database external
            OSPF Router with ID (1.1.1.1) (Process ID 1)

R1(config)#int loop10
R1(config-if)#ip ospf 1 area 0

R1(config-if)#do show ip ospf database external
            OSPF Router with ID (1.1.1.1) (Process ID 1)
                Type-5 AS External Link States
  Routing Bit Set on this LSA
  LS age: 7
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x7BAF
  Length: 36
  Network Mask: /0
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 1

And now we come to the fun part. R2 learns the 10.10.10.10/32 prefix via iBGP:

R2(config)#do show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "bgp 12", distance 200, metric 0, type internal
  Last update from 1.1.1.1 00:00:14 ago
  Routing Descriptor Blocks:
  * 1.1.1.1, from 1.1.1.1, 00:00:14 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

R2(config)#do ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/49/64 ms

R2(config)#do show ip ospf database external
            OSPF Router with ID (2.2.2.2) (Process ID 1)

R2(config)#router bgp 12
R2(config-router)#bgp redistribute-internal

OSPF: Generate external LSA 0.0.0.0, mask 0.0.0.0, type 5, age 0, metric 1, tag 1, metric-type 1, seq 0x80000001

R2(config-router)#do show ip ospf database external
            OSPF Router with ID (2.2.2.2) (Process ID 1)
                Type-5 AS External Link States
  LS age: 7
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x7BAF
  Length: 36
  Network Mask: /0
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 1

I think I know what the bgp redistribute-internal command does but I don't understand at all the effect it has on the OSPF route-map check in such a scenario (Note that there is no BGP default route and no redistribution configured).

Best regards
Rolf

Jon Marshall · ‎10-26-2015

Rolf

If you don't understand it what chance do we have :-)

Can I just clarify what you did -

1) on R2 you have configured the route map using the default-information originate command.

2) to get that advertised you first added a static route for 10.10.10.10 to null0 on R2 and it worked.

3) you then presumably removed that route, added the loopback 10 interface to R1's OSPF process so it is advertised to R2 which then should in theory be able to originate the default route.

But R2 learn't the route via IBGP and obviously until you told R2 to redistribute IBGP routes into the IGP OSPF could not originate the default route.

Is that right or have I got it completely wrong ?

If so where is the BGP configuration in your post ?

Jon

Rolf Fischer · ‎10-26-2015

Jon

Thanks for the quick response!

1) Exactly.

2/3) were just demonstrations that with the presence of a 10.10.10.10/32 route the route-map condition was satisfied and the OSPF 0/0 type-5 LSA was injected. (2) simply with a local static discard-route.

(3) Just to demonstrate the same behaviour when a 10.10.10.10/32 route was learned via OSPF (could be any IGP or eBGP I guess).

So far everything like expected. But things seem to be different when the route is learned via iBGP. There is no redistribution and the iBGP route is present in the routing table (even pingable), but the condition for the OSPF default-route injection is obviously not satisfied in this case. This did not change until I added the bgp redistribute-internal command under the BGP process:

(R2)
router ospf 1
 router-id 2.2.2.2
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.12.2 0.0.0.0 area 0
 default-information originate metric-type 1 route-map 10.10.10.10
router bgp 12
 no synchronization
 bgp log-neighbor-changes
 bgp redistribute-internal
 neighbor 1.1.1.1 remote-as 12
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.1 next-hop-self
 no auto-summary

For the sake of completeness:

R1#s run | s router
router ospf 1
 router-id 1.1.1.1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.12.1 0.0.0.0 area 0
router bgp 12
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.10 mask 255.255.255.255
 neighbor 2.2.2.2 remote-as 12
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 next-hop-self
 no auto-summary

Thanks.

Jon Marshall · ‎10-26-2015

Right, that makes a lot more sense.

I just did a quick lab and played around with router ids etc. but whatever I did I got the same result as you.

Obviously the "bgp redistribute-internal" command is there primarily because by default if you redistribute BGP into any IGP it will only redistribute EBGP routes because there is a potential to create routing loops if you redistribute IBGP routes.

But you know all this :-)

I can only guess that IOS takes that logic one step further ie. if an IGP cannot trust IBGP routes by default because of a potential routing loop then it cannot trust IBGP routes full stop whether they are being redistributed or not

So by configuring "bgp redistribute-internal" command you are in effect telling OSPF it is okay to use that route and it will not create a routing loop by doing so.

That said I haven't exactly sat down and worked out whether a routing loop could be introduced so it is a best guess at the moment.

Perhaps someone else can provide a more satisfactory answer.

Jon

Rolf Fischer · ‎10-26-2015

I can only guess that IOS takes that logic one step further ie. if an IGP cannot trust IBGP routes by default because of a potential routing loop then it cannot trust IBGP routes
full stop whether they are being redistributed or not

That's exactly what I thought too; but I wouldn't expect such a behaviour and couldn't find any reference on that. Btw, I was unable to find out why one of our CEs didn't inject the default-route in a similar setup and a collegue of mine told me that the bgp redistribute-internal command was missing - but he couldn't explain properly why we need it here.

paul driver · ‎10-26-2015

Hello Rof/Jon

I too agree it’s down the default bgp loop prevention mechanism of BGP.

Your conditional route injection will work for a route prefix originating from an EBGP peering or any other IGP ( ive to tested this) And as you have shown it worked when a null static for that prefix was applied thus the router seen this prefix as valid and accepted it.

That bgp redistribute-internal command as we know negates such this loop prevention and in this case allows ibgp routes to be advertised and seen as valid by the router thus the conditional default gets injected

As you can see OSPF poisons the route before BGP is redistribute into this IGP

Oct 26 16:06:58.118: BGP_Router: unhandled major event code 128, minor 0
*Oct 26 16:06:58.122: OSPF-1 LSGEN: Generate external LSA 0.0.0.0, mask 0.0.0.0, type 5, age 3600, seq 0x80000002
*Oct 26 16:06:58.122: OSPF-1 LSGEN: MTID Metric Metric-type FA Tag Topology Name
*Oct 26 16:06:58.122: OSPF-1 LSGEN: 0 16777215 2 0.0.0.0 1 Base

R2(config-router)#bgp redistribute-internal
R2(config-router)#
*Oct 26 16:08:24.622: BGP_Router: unhandled major event code 128, minor 0
*Oct 26 16:08:24.622: OSPF-1 LSGEN: Generate external LSA 0.0.0.0, mask 0.0.0.0, type 5, age 0, seq 0x80000001
*Oct 26 16:08:24.622: OSPF-1 LSGEN: MTID Metric Metric-type FA Tag Topology Name
*Oct 26 16:08:24.626: OSPF-1 LSGEN: 0 1 2 0.0.0.0 1 Base
*Oct 26 16:08:24.626: OSPF-1 LSGEN: Rate limit LSA generation for 0.0.0.0 2.2.2.2 5

Res

Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Jon Marshall · ‎10-26-2015

Paul

Thanks for that.

It does seem strange that it behaves like this though as really should OSPF care where the route came from as long as it is in the routing table.

Like Rolf, I can't find any documentation that refers to this only to redistributing IBGP routes into an IGP.

I guess it just comes down to an IGP will not use an IBGP route regardless unless you tell it explicitly it can.

Jon