cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1383
Views
3
Helpful
26
Replies

Strange switching/routing decisions SUP2

VictorAKur
Level 1
Level 1

Hi

I have two 6506s with SUP2 on them. There has been a problem there with maxing out BGP routes on both switches, which was resolved by quite aggressively filtering incoming updates from our transit. Now I have come across a rather strange phenomenon - switch SW2 (the picture is attached) has what looks like a valid IP routing table, but a number of networks get mls switched to the switch SW1. And I cannot do anything about it.

For example the 66.185.180.0/24 network:

Sw2#sh ip route 66.185.180.20

Routing entry for 66.185.180.0/24

Known via "bgp xxx", distance 20, metric 0

Tag 5400, type external

Last update from 166.49.129.9 2d20h ago

Routing Descriptor Blocks:

* 166.49.129.9, from 166.49.129.9, 2d20h ago

Route metric is 0, traffic share count is 1

AS Hops 5

Sw2#sh ip bgp 66.185.180.20

BGP routing table entry for 66.185.180.0/24, version 3701504

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Advertised to non peer-group peers:

x.x.x.x x.x.x.x x.x.x.x .x.x.x

5400 3561 12182 18730

166.49.129.9 from 166.49.129.9 (166.49.166.227)

Origin IGP, localpref 201, valid, external, best

But:

Sw2 #sh mls cef exact-route x.x.x.x 66.185.180.20

Interface: Vl10, Next Hop: 80.68.34.197, Vlan: 10, Destination Mac: xxxxx

Any ideas?

PS Replacing the SUP card is not an issue.

26 Replies 26

As you can see SW1 is preferring to get to 66.185.180.0 via SW2 because the AS Hops is 4 instead of 5 when the BGP is not enabled between the iBGP peers.

I don't see any issues with that, so where is your problem?

Thanks,

Regards,

Sorry I read the first post and as you described SW2 is switching it via SW1 instead of going directly the EBGP peer.

Hello Victor,

Is 166.49.129.9 a directly connected peer? If not can you issue the command show ip route 166.49.129.9 on SW2 while iBGP is running between the 6500s.

Thanks,

Victor,

Let me explain what I am trying to achieve here. Route recursion will happen for both the destination and the next hop. Therefore, the router will first try to find the longest match for the destination subnet. Once found it is going to do another route recursion for the next hop it got from the first step.

What I am afraid off is that SW2 is doing the first route recursion which is correct and then when it recure for the next hop it is finding that the next hop is via SW1. That's why the SW2 is switching this and sending it to SW1 where SW1 believe the route is still via SW2 and here we got the loop. This is incase the 166.49.129.9 is not a directly connected peer.

Hope this clarifies my line of thinking,

Regards,

Hi

unfortunatelly it is indeed a next hop address:

sw2#sh ip route 166.49.129.9

Routing entry for 166.49.129.8/30

Known via "connected", distance 0, metric 0 (connected, via interface)

Redistributing via ospf xxxxx

Advertised by ospf xxxxx subnets

Routing Descriptor Blocks:

* directly connected, via FastEthernet4/5

Route metric is 0, traffic share count is 1

Hello Victor,

Thanks for the feedback. If you remove the filtering you have done in the beginning would issue get resolved? I would also open a case with Cisco to troubleshoot more.

Regards,

I don't know if it would resolve the issue - if I remove the filtering the number of routes will go over the limit the SUP 2 card can support and the SUPs on both swithces will start alerting again. I did remove the filters for this particular network (66.x.x.x) for all prefixes and for about 12 hours it did work and then stoped working again. So I assume filtering may have something to do with it after all. Will it help if I post the actual filters I have installed? I have looked at them many times, but if someone else have a look he may spot the problem that I have missed.

Hello Victor,

As I understood that you removed the filters and things worked until you applied the filter again. Is that right?

It doesn't hurt if you can paste your filters to double check.

Thanks,

I removed only prefixes for 66.x.x.x network. It started working after that and worked for about 12 hours, after which it stopped working again with the filters still off.

Here is the prefix lists:

ip prefix-list ISP-Ingress-In-Strict seq 4004 deny 116.0.0.0/6 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 4008 deny 120.0.0.0/6 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 4011 deny 124.0.0.0/7 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 4013 deny 126.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 4014 deny 202.0.0.0/7 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 4016 deny 210.0.0.0/7 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 4018 permit 218.100.0.0/16 ge 17 le 24

ip prefix-list ISP-Ingress-In-Strict seq 4019 deny 218.0.0.0/7 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 4021 deny 220.0.0.0/7 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 4023 deny 222.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5000 deny 24.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5010 deny 72.0.0.0/6 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5014 deny 76.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5015 deny 96.0.0.0/6 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5020 deny 198.0.0.0/7 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 5022 deny 204.0.0.0/7 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 5023 deny 206.0.0.0/7 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 5032 deny 208.0.0.0/8 ge 23

ip prefix-list ISP-Ingress-In-Strict seq 5033 deny 209.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 5034 deny 216.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 6001 deny 77.0.0.0/8 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6002 deny 78.0.0.0/7 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6004 deny 80.0.0.0/7 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 6006 deny 82.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 6007 deny 83.0.0.0/8 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6008 deny 84.0.0.0/6 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6012 deny 88.0.0.0/7 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6014 deny 90.0.0.0/8 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6015 deny 91.0.0.0/8 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 6016 deny 92.0.0.0/6 ge 22

ip prefix-list ISP-Ingress-In-Strict seq 6020 deny 193.0.0.0/8 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 6021 deny 194.0.0.0/7 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 6023 deny 212.0.0.0/7 ge 20

ip prefix-list ISP-Ingress-In-Strict seq 6025 deny 217.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 7000 deny 189.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 7001 deny 190.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 7002 deny 200.0.0.0/8 ge 25

ip prefix-list ISP-Ingress-In-Strict seq 7003 deny 201.0.0.0/8 ge 21

ip prefix-list ISP-Ingress-In-Strict seq 8001 deny 196.0.0.0/8 ge 23

ip prefix-list ISP-Ingress-In-Strict seq 10200 permit 0.0.0.0/0 le 24

I found it in a blog of a very nice gentleman.

Hello Victor,

Sorry for the delayed reply it was a very busy week. I suggest opening a case with Cisco especially that removing the filtering resolved the issue temporarily.

Regards,

Hello Viktor,

I see that you have added details to the case.

So removing the route filter you face the problem of maximum prefixes in CEF tables.

With the prefix-list applied you see the strange problem you have described in the first posts.

Then you have made a modified version of the prefix-list that doesn't filter the less specific 66/n and for a period of time of 12 hours everything was well but after again the problem.

Let me ask you if you apply the same route-filter on both switches SW1 and SW2 or you use different versions.

This is just a basic check, the prefix-list can be fine by itself but applying two slightly different prefix-lists to the two border routers could lead to unexpected results.

the number of IP prefixes was high even with the prefix-list applied.

Instead of permitting all prefixes with prefixlen le 24 you could get further ip prefix reduction by allowing only /21 or /22 or less specific to be accepted by your router so I would change the last line

ip prefix-list ISP-Ingress-In-Strict seq 10200 permit 0.0.0.0/0 le 22

I would try to have the two switches with far less prefixes : say 150000 prefixes and see what happens.

You could even think to use the maximum prefixes command to make a test with different received prefixes number

neighbor maximum-prefix

Hope to help

Giuseppe

Well...

The box finally collapsed. It crashed and came back in ROMMON. After reload it remained in ROMMON and complained that it lost boot sequence. I got it back to life and reset the bootvar to what it was before.

As a result of the crash the switch seems to have got rid of all the problems with CEF and now routes traffic as it should.

However we ended up taking the box off the front line as it has become a liability.

Thank you everyone for help.

Yet another problem with no real answer.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: