[c-nsp] Weird behaviour with continue statement in IOS

[Francisco Rivas]

Hi,

We have the same issue with IOS 12.2(18)S5. When we modify the route-map
in any way, after the "clear ip bgp soft" we get the routes, but they
are marked as "VALID", not "BEST". A "clear ip bgp" (hard way) solves
the problem... I've also seen this on production routers, so I had to go
back with the IOS upgrade.
Did anyone opened a TAC case about this??? is a reported BUG???  This
12.2(18)S5 is giving us too much trouble. Besides this bug, we were
facing a high CPU utilization on some routers (the CEF Scanner process
was eating CPU like mad, going back to 12.2(14)s3 solves the problem).
We have opened a TAC for the CEF bug, and they told me that the new IOS
(S6) should be ready for download in a month..

Regards,

Francisco Rivas


On Wed, 2004-07-28 at 08:14, Bernhard Schmidt wrote:
> Evening everyone,
> 
> I just had a tough time tracking a very interesting issue regarding the 
> continue statement in incoming route-maps.
> 
> We're running two 7206VXR NPE-G1 with 12.2(18)S5 Provider Feature Set 
> that terminate eBGP multihop sessions to satellite IP customers. One of 
> the customers requested the possibility to lower the localpreference of 
> a prefix we receive from him by setting a community. So this was the 
> first try:
> 
> ip community-list standard IABG-pref-100 permit 29259:1301
> ip community-list standard IABG-pref-700 permit 29259:1302
> !
> route-map CUSTOMER-in permit 10
>   match community IABG-pref-100
>   continue 100
>   set local-preference 100
> !
> route-map CUSTOMER-in permit 15
>   match community IABG-pref-700
>   continue 100
>   set local-preference 700
> !
> route-map CUSTOMER-in permit 20
>   continue
>   set local-preference 800
> !
> route-map CUSTOMER-in permit 100
>   set community 29259:3500 29259:3502 additive
> !
> 
> Interestingly all prefixes from the customer were accepted as they 
> should (localpref 800, communities added), except the one with 
> 29259:1301 set
> 
>    30763 9107, (received-only)
>      212.109.208.1 from 212.109.208.1 (212.109.208.1)
>        Origin IGP, localpref 100, valid, external
>        Community: 29259:1301
> 
> (no, this was the only entry). I deleted the prefix-list associated with 
> the peer, no difference. I made a soft clear and even a hard clear, no 
> difference. "sh ip bgp neighbor 212.109.208.1" showed dropped prefixes 
> due to the route-map (how can this be, there is no deny statement in 
> there).
> 
> Finally it worked... you want to know how? Watch out:
> 
> BB1#conf t
> Enter configuration commands, one per line.  End with CNTL/Z.
> BB1(config)#route-map CUSTOMER-in permit 10
> BB1(config-route-map)#no continue
> BB1(config-route-map)#continue
> BB1(config-route-map)#continue 100
> BB1(config-route-map)#^Z
> 
> one soft clear later, the problem was gone. I could not believe that (as 
> you can see, these commands did not change anything in the 
> configuration) so I tried it on the second router which has exactly the 
> same configuration and peer. Soft Clear, Hard Clear, nothing worked, but 
> this small repeated statement fixed the problem.
> 
> Unfortunately these are our production router and unfortunately^2 I 
> don't have a lab here to test this problem fast. Did someone see this 
> before?
> 
> Thanks
> Bernhard
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/