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

[Bernhard Schmidt]

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