Re: BGP backdoor routes with an AD of 20?

damianbell · ‎07-11-2012

Hi,

I've got a 3560 running BGP and OSPF, and want to prefer the OSPF routes over the BGP ones for particular networks. As such, I've got a config as below:-

router bgp xxxxx

no synchronization

bgp log-neighbor-changes

bgp scan-time 15

network 172.20.68.0 mask 255.255.254.0 backdoor

network 172.20.82.0 mask 255.255.255.0 backdoor

Unfortunately the BGP neighbor bounced last night, and it appears when it came back up it installed the following routes:-

B 172.20.68.0/23 [20/0] via 1.1.1.1, 11:55:31

B 172.20.82.0/24 [20/0] via 1.1.1.1, 11:55:17

My understanding is that BGP should install these with an AD of 200 (and as such prefer my OSPF routes?)

Very basic question I'm sure - absolute noob here. Thanks in advance.

smitesh kharecha · ‎07-11-2012

Hi,

You are absolutely correct.

However, before interpretating why it haven't install OSPF route, can you check whether those prefixes are available in OSPF database table ?

HTH,

Smitesh

damianbell · ‎07-11-2012

Just trying to find them - what's the command for finding them in OSPF?

smitesh kharecha · ‎07-11-2012

show ip ospf database

Edited: And if your Database table is too large, you can also try

show ip ospf database | incl 172.20.68.0

show ip ospf database | incl 172.20.82.0

Regards,

Smitesh

Message was edited by: smitesh kharecha

damianbell · ‎07-11-2012

OK, weird. I'm not seeing entries for either of those networks in the database, but when I run the following I get the following:-

sh ip route 172.20.68.0

Routing entry for 172.20.68.0/23

Known via "ospf 1", distance 110, metric 9816, type intra area

Last update from 172.21.4.2 on Vlan200, 4d12h ago

Routing Descriptor Blocks:

* 172.21.4.2, from 172.31.255.150, 4d12h ago, via Vlan200

Route metric is 9816, traffic share count is 1

sh ip route 172.20.82.0

Routing entry for 172.20.82.0/24

Known via "ospf 1", distance 110, metric 9816, type intra area

Last update from 172.21.4.2 on Vlan200, 4d12h ago

Routing Descriptor Blocks:

* 172.21.4.2, from 172.31.255.150, 4d12h ago, via Vlan200

Route metric is 9816, traffic share count is 1

Seems like the OSPF process is a bit weird along with the BGP process as well - perhaps a reboot?

John Blakley · ‎07-11-2012

It looks like it's an intra area route which could be seen if you do a "sho ip ospf database router". Otherwise, you could also do a "show ip ospf rib" and see if the route is listed in there.

HTH,

John

HTH, John *** Please rate all useful posts ***

damianbell · ‎07-12-2012

Yes, it's an intra-area route - we just run one big Area 0. As for what's going on however, yesterday I implemented 3 static routes to redirect traffic correctly, and then removed them after business finished yesterday. Interestingly, the minute I removed the 3 routes, the OSPF routes then became the correct routes within the routing table, however after reloading the switch the BGP routes were then the primary routes again. Strange.

Looking at this again today, I can't find the routes within the OSPF database, however they're actually in the routing table (after inserting, then removing 3 static routes)...

Routes not in the OSPF database:-

sh ip ospf database | i 172.20.

172.20.64.9 172.20.64.9 695 0x80000D8E 0x000A3A 2

172.20.64.10 172.20.64.10 1678 0x80000D90 0x00E55A 2

172.20.79.1 172.20.79.1 1716 0x80006C89 0x0047E3 9

172.20.79.2 172.20.79.2 1891 0x80001151 0x00ED6B 8

172.20.79.3 172.20.79.3 1419 0x8000114F 0x005DEF 2

172.20.79.4 172.20.79.4 1484 0x80001142 0x00321D 2

172.20.79.5 172.20.79.5 837 0x80001141 0x00EE56 2

172.20.79.6 172.20.79.6 1230 0x80001143 0x00A592 2

172.20.79.7 172.20.79.7 389 0x80006C49 0x0007AC 9

172.20.79.8 172.20.79.8 1266 0x80006C7F 0x00B75F 11

172.20.48.6 172.31.255.143 871 0x80005CD5 0x00E561

172.20.64.49 172.31.255.150 1289 0x80000D8B 0x003B8C

172.20.64.53 172.31.255.152 1701 0x8000078A 0x00FFB6

172.20.76.3 172.20.79.2 1891 0x80001141 0x008F14

172.20.79.14 172.20.79.3 1419 0x8000114D 0x00D9B0

172.20.79.18 172.20.79.4 1484 0x80001140 0x00CFC1

172.20.79.22 172.20.79.5 837 0x8000113F 0x00BBCF

172.20.79.26 172.20.79.6 1230 0x80001141 0x0093EF

OSPF routes in the routing table after inserting then removing 3 static routes: -

sh ip route 172.20.82.0

Routing entry for 172.20.82.0/24

Known via "ospf 1", distance 110, metric 9916, type intra area

Last update from 172.21.0.3 on Vlan200, 11:20:17 ago

Routing Descriptor Blocks:

* 172.21.0.3, from 172.31.255.150, 11:20:17 ago, via Vlan200

Route metric is 9916, traffic share count is 1

Is this expected behaviour? Getting back to the main point, the BGP routes shouldn't be inserting themselves with an AD of 20, right?

Any help most appreciated.

damianbell · ‎07-12-2012

Also, code version is 3560 running 12.2(46)SE

John Blakley · ‎07-12-2012

I labbed this up and I didn't have the same problem you're having. I'm not doing it with a switch though, although that shouldn't matter. You didn't post "show ip ospf rib". Do you have that command available? The expected behavior is exactly what you should expect: ospf route is in the table, when it goes down bgp route takes over, and when ospf neighbor comes back up it should be reentered into the table.

When you reload your ospf neighbor and the ospf neighbor comes up, can you post the following:

sh ip ospf neigh

sh ip ospf rib

Can you also run "debug ip routing" and "debug ip bgp update? while you're rebooting your other device? You should see something like the following for the route that you're concerned about:

Shutting my ospf neighbor down:

*Mar 1 00:18:14.739: RT: add 1.1.1.0/24 via 192.168.12.1, bgp metric [200/0]

*Mar 1 00:18:14.739: RT: NET-RED 1.1.1.0/24

*Mar 1 00:18:14.743: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.0/24 -> 192.168.12.1(main) to main IP table

Bringing the neighbor back up:

*Mar 1 00:26:37.679: RT: closer admin distance for 1.1.1.0, flushing 1 routes

*Mar 1 00:26:37.679: RT: NET-RED 1.1.1.0/24

*Mar 1 00:26:37.679: BGP(0): lost route 1.1.1.0/24 for main IP table

*Mar 1 00:26:37.683: RT: add 1.1.1.0/24 via 10.23.0.3, ospf metric [110/21]

*Mar 1 00:26:37.683: RT: NET-RED 1.1.1.0/24

You can see in the first section after I shut down my ospf neighbor, the bgp route enters the table at AD of 200. When I bring it up, bgp can't install the route because the ospf route has the lower ad. BGP then keeps the route in the bgp table because it's still learning it, but more than likely has a RIB failure do to the higher AD of its route compared to ospf's route.

HTH,

John

HTH, John *** Please rate all useful posts ***

damianbell · ‎07-12-2012

Hi John (and everyone else!),

Appreciate your help thus far. Unfortunately the 3560 doesn't have the "sh ip ospf rib" command available, however in looking at the BGP table I'm getting (this is today after adding and removing the static routes which then install the correct OSPF route):-

sh ip bgp | b 172.20.82.0

r> 172.20.82.0/24 1.1.1.1

...which would indicate RIB-failure - the expected circumstance when OSPF with an AD of 110 is installing the correct route, right?

In just looking at my post above, should the 172.20.82.0/24 route appear in the sh ip ospf database command though? I find it strange it's not in there at all, yet is in the routing table?

Unfortunately I can't run debugs whilst reloading this switch during the day as it's production, and the BGP neighbor is a Verizon box that's out of my control. The next hop OSPF peer is within my control however - do you want debugs off it at the moment, and what might help?

Do you think it might be a code issue?

Again, thanks for your input - it's helpful...

John Blakley · ‎07-12-2012

In just looking at my post above, should the 172.20.82.0/24 route appear in the sh ip ospf database command though? I find it strange it's not in there at all, yet is in the routing table?

OSPF creates your summary routes (172.20.82.0/24) by looking in the routing table. Someone should correct me if I'm wrong, but if you have an ABR that ABR will generate an LSA type 3 in order to describe networks from 1 area to another that it controls. Because you have 1 large area, there won't be any summary LSAs, but you'll have a type 1 LSA from the router that has the link going to 172.20.82.0/24. If you look at that router lsa, you should see that network listed:

OSPF Router with ID (192.168.12.2) (Process ID 1)

Router Link States (Area 0)

LS age: 37

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 192.168.12.1

Advertising Router: 192.168.12.1

LS Seq Number: 80000003

Checksum: 0xC6EB

Length: 48

Number of Links: 2

Link connected to: a Stub Network

(Link ID) Network/subnet number: 192.168.23.0

(Link Data) Network Mask: 255.255.255.0

Number of TOS metrics: 0

TOS 0 Metrics: 10

The advertising router for 192.168.23.0/24 is 192.168.12.1 which is a directly attached network. So, it's normal that you're not seeing the 172.20.82.0/24 in your database because it's not in a different area than area 0. Otherwise, if you were advertising the 172.20.82.0/24 network from, say area 1, the router that was attached to area 1 and area 0 would create a summary lsa and you would see your type 3 lsa describing the 172.20.82.0/24.

I changed the 192.168.23.0/24 to area 1 and here's the database entry:

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

192.168.23.0 192.168.12.1 7 0x80000001 0x00D764

Does that make sense? By all means, if you have a way of updating the ios on this switch you may as well do so. We've seen weirder problems fixed with a code update.

HTH,

John

* Please rate helpful posts *

HTH, John *** Please rate all useful posts ***

Giuseppe Larosa · ‎07-12-2012

Hello John,

your explanation is correct for inter area routes that are listed in summary LSA

However, the involved route 192.168.82.0 is an intra area route and it is part of a Router LSA with an LSA-id that may be different from the IP subnet. (to be noted Router LSA LSA-id = OSPF router-id of the originating node)

To find out the right Router LSA we have to take in account the from A.B.C.D field in the show ip route

show ip ospf database router A.B.C.D detail

>>sh ip route 172.20.82.0

>>Routing entry for 172.20.82.0/24

>> Known via "ospf 1", distance 110, metric 9916, type intra area

>> Last update from 172.21.0.3 on Vlan200, 11:20:17 ago

>> Routing Descriptor Blocks:

>> * 172.21.0.3, from 172.31.255.150, 11:20:17 ago, via Vlan200

>> Route metric is 9916, traffic share count is 1

There should be a Router LSA with LSA-id = 172.21.0.3 or LSA-id = 172.31.255.150 in the database that contains the IP subnet 172.20.82.0/24.

Hope to help

Giuseppe

damianbell · ‎09-13-2012

...so it seems like I've got a definite bug in the toolkit that describes this issue - please check

https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bugIdfilterData&bugId=CSCdz77047&filterData=EMPTY&QueryString=backdoor%3Fst=kw&highLight=true&searchCriteria='backdoor'&isadvancedpage=false&SavedSearchType=false&advkeywords=&page=bstBugDetail&so...

However I'm unsure what version of code I should get to fix it - current version I'm running is:-

Switch Ports Model SW Version SW Image

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

* 1 52 WS-C3560G-48TS 12.2(46)SE C3560-ADVIPSERVICESK9-M

I'm a bit confused as to what the version of code is that will resolve the issue based on the bug CSCdz77047...?

Cheers