OSPF, missing external network prefix
Hi. I have a bunch of bird routers. Recently I discovered that at least one prefix from LSADB isn't installed in FIB: (first here's what bird thinks about it) # birdc BIRD 1.4.4 ready. bird> show ospf lsadb lsid 192.168.114.192 Global Type LS ID Router Age Sequence Checksum 0005 192.168.114.192 192.168.0.15 498 80000385 d906 bird> show route for 192.168.114.193 0.0.0.0/0 via 178.161.152.73 on vlan600 [bgpv4sat 2015-12-04] * (100) [AS16285i] bird> show route for 192.168.114.192/26 0.0.0.0/0 via 178.161.152.73 on vlan600 [bgpv4sat 2015-12-04] * (100) [AS16285i] (and the actual FIB) # route -n get 192.168.114.193 route to: 192.168.114.193 destination: 0.0.0.0 mask: 0.0.0.0 gateway: 178.161.152.73 fib: 0 interface: vlan600 flags: <UP,GATEWAY,DONE,PROTO1> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 [root@crystal-alpha:local/etc]# route -n get 192.168.114.192/26 route: writing to routing socket: No such process I really want to inverstigate why. So far I have import ACL in bird, but this prefix doesn't seem to match: protocol ospf ospfv4 { rfc1583compat yes; export filter exportospfv4; import filter importospfv4; area 0.0.0.44 { interface "vlan1"; interface "gre0"; interface "gre1" { cost 15111; }; }; } filter importospfv4 { if net ~ [ 172.16.0.0/31, 172.16.1.80/31, 172.16.1.81/32, 172.16.1.80/32, 172.16.0.0/32, 172.16.0.1/32 ] then { print "ospfv4 import: net rejected: ", net; reject; } if net = 0.0.0.0/0 then { print "ospfv4 import: net rejected: ", net; reject; } else { print "ospfv4 import: net accepted: ", net; accept; } } Anyway, there's no signs of this missing prefix in logs. I've also noticed one more thing, may be important: this prefix is originating from a branch office. It's present and installed on all othe area 0 routers, no matter what vendor they're from, but is missing on the routers which aren't from area 0, but only if they're bird. It's present on Cisco ones (may be a coincident though, since I doesn't have any Cisco device connected with area 0 via bird). Thanks. Eugene.
On Tue, Dec 08, 2015 at 11:28:00AM +0500, Eugene M. Zheganin wrote:
Hi.
I have a bunch of bird routers. Recently I discovered that at least one prefix from LSADB isn't installed in FIB:
Hi Could you send me output of 'show ospf state'? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi/ On 08.12.2015 14:53, Ondrej Zajicek wrote:
On Tue, Dec 08, 2015 at 11:28:00AM +0500, Eugene M. Zheganin wrote:
Hi.
I have a bunch of bird routers. Recently I discovered that at least one prefix from LSADB isn't installed in FIB: Hi
Could you send me output of 'show ospf state'?
Sure. Since it's 80 kilobytes long (it's an enterprise VPN, big enough), I thought it would be more comfortable to provide a link on a text file, here it is: http://tech.hq.norma.perm.ru/files/ospf-state.txt At the time it was taken the situation didn't resolve, I checked. You may also notice that bird there is 1.4.4. I also have 1.5.0 bird with same situation on a different server, and I can provide 'show ospf state' from it, you you need one. Thanks. Eugene.
On Tue, Dec 08, 2015 at 04:49:47PM +0500, Eugene M. Zheganin wrote:
Sure. Since it's 80 kilobytes long (it's an enterprise VPN, big enough), I thought it would be more comfortable to provide a link on a text file, here it is:
http://tech.hq.norma.perm.ru/files/ospf-state.txt
At the time it was taken the situation didn't resolve, I checked.
Seems like the net it is missing also here. Could you get also output of 'show ospf state all'?
You may also notice that bird there is 1.4.4. I also have 1.5.0 bird with same situation on a different server, and I can provide 'show ospf state' from it, you you need one.
That might be useful. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi. On 08.12.2015 17:46, Ondrej Zajicek wrote:
On Tue, Dec 08, 2015 at 04:49:47PM +0500, Eugene M. Zheganin wrote:
Sure. Since it's 80 kilobytes long (it's an enterprise VPN, big enough), I thought it would be more comfortable to provide a link on a text file, here it is:
http://tech.hq.norma.perm.ru/files/ospf-state.txt
At the time it was taken the situation didn't resolve, I checked. Seems like the net it is missing also here. Could you get also output of 'show ospf state all'?
You may also notice that bird there is 1.4.4. I also have 1.5.0 bird with same situation on a different server, and I can provide 'show ospf state' from it, you you need one. That might be useful.
So, here are the files from both 1.4.4 and 1.5.0 versions: (taken from same router the previous output was from) http://tech.hq.norma.perm.ru/files/ospf-state-all-1.4.4.txt (taken from another router) http://tech.hq.norma.perm.ru/files/ospf-state-1.5.0.txt http://tech.hq.norma.perm.ru/files/ospf-state-all-1.5.0.txt I've also noticed that this prefix is missing from 'show ospf state' output files, but present in 'show ospf state all' output files, but along with a IP address of 172.16.5.159. This is an IP address of a router this prefix is originating from (it's an address of it's tunnel most close to the area 0), and it's not directly reachable from the routers which FIB is missing it, so I suppose this may be the reason. I have also noticed that other nssa areas have similar problem (they are present in 'show ospf state all' output with IP address of their originating router, and missing in FIB), on both 1.4.4 and 1.5.0 bird versions. Thanks. Eugene.
On Tue, Dec 08, 2015 at 06:10:20PM +0500, Eugene M. Zheganin wrote:
I've also noticed that this prefix is missing from 'show ospf state' output files, but present in 'show ospf state all' output files, but along with a IP address of 172.16.5.159. This is an IP address of a router this prefix is originating from (it's an address of it's tunnel most close to the area 0), and it's not directly reachable from the routers which FIB is missing it, so I suppose this may be the reason.
Yes, that is expected behavior. Don't know why these routes are available on other Cisco routes. Not sure if 172.16.5.159 should or should not be propagated, perhaps it is just missing. If you have BIRD on originating router, you could remove explicit next hop by setting 'gw = 0.0.0.0;' in the OSPF export filter (on the originating router). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi. On 08.12.2015 18:23, Ondrej Zajicek wrote:
On Tue, Dec 08, 2015 at 06:10:20PM +0500, Eugene M. Zheganin wrote:
I've also noticed that this prefix is missing from 'show ospf state' output files, but present in 'show ospf state all' output files, but along with a IP address of 172.16.5.159. This is an IP address of a router this prefix is originating from (it's an address of it's tunnel most close to the area 0), and it's not directly reachable from the routers which FIB is missing it, so I suppose this may be the reason. Yes, that is expected behavior. Don't know why these routes are available on other Cisco routes. They are (for example this output is from Cisco router and it's not in area 0):
kosm114#sh ip route 192.168.114.192 Routing entry for 192.168.114.192/26 Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 22223 Last update from 172.16.1.50 on Tunnel0, 4d00h ago Routing Descriptor Blocks: * 172.16.1.50, from 192.168.0.15, 4d00h ago, via Tunnel0 Route metric is 20, traffic share count is 1 kosm114#sh ip ospf inter kosm114#sh ip ospf interface Tunnel1 is up, line protocol is up Internet Address 172.16.1.67/31, Area 19 Process ID 10, Router ID 192.168.141.193, Network Type POINT_TO_POINT, Cost: 15111 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:07 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 8, maximum is 50 Last flood scan time is 0 msec, maximum is 112 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.0.15 Suppress hello for 0 neighbor(s) Tunnel0 is up, line protocol is up Internet Address 172.16.1.51/31, Area 19 Process ID 10, Router ID 192.168.141.193, Network Type POINT_TO_POINT, Cost: 11111 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:05 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 3, maximum is 50 Last flood scan time is 0 msec, maximum is 104 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.0.15 Suppress hello for 0 neighbor(s)
Not sure if 172.16.5.159 should or should not be propagated, perhaps it is just missing. If you have BIRD on originating router, you could remove explicit next hop by setting 'gw = 0.0.0.0;' in the OSPF export filter (on the originating router).
Unfortunately, these NSSA prefixes are originating from Cisco devices. Is there some workaround to make these prefixes available in other areas, except of reverting NSSA areas to ordinary ones ? After all the external routes from NSSAs should be visible in other areas, since they are converted from type 7 to type 7 by the ABR, right ? Thanks. Eugene.
Hi. On 08.12.2015 18:23, Ondrej Zajicek wrote:
On Tue, Dec 08, 2015 at 06:10:20PM +0500, Eugene M. Zheganin wrote:
I've also noticed that this prefix is missing from 'show ospf state' output files, but present in 'show ospf state all' output files, but along with a IP address of 172.16.5.159. This is an IP address of a router this prefix is originating from (it's an address of it's tunnel most close to the area 0), and it's not directly reachable from the routers which FIB is missing it, so I suppose this may be the reason. Yes, that is expected behavior. Don't know why these routes are available on other Cisco routes.
So, to summarize, is it bird working not as intended with OSPF NSSA, or, is it Cisco/Juniper equipment that installs wrong prefixes in their FIB ? Thanks. Eugene.
Hi, On 08.12.2015 14:53, Ondrej Zajicek wrote:
On Tue, Dec 08, 2015 at 11:28:00AM +0500, Eugene M. Zheganin wrote:
Hi.
I have a bunch of bird routers. Recently I discovered that at least one prefix from LSADB isn't installed in FIB: Hi
Could you send me output of 'show ospf state'?
One more thing I discovered when investigation this (and I'm really sorry, I should have mentioned this in the first letter) - the missing prefix is from an NSSA area. Eugene.
participants (2)
-
Eugene M. Zheganin -
Ondrej Zajicek