[c-nsp] ME3600 BGP Route-Maps and IPv6 (WAS: Re: preference on bgp route advertisements)

Reuben Farrelly reuben-cisco-nsp at reub.net
Tue Mar 6 06:29:52 EST 2012


On 6/03/2012 9:46 PM, Mark Tinka wrote:
> On Tuesday, March 06, 2012 04:29:45 PM Reuben Farrelly
> wrote:
>
>> WTF?  The IPv6 prefix has been matched by the IPv4
>> specific route-map sequence 10, and the community from
>> that route map of 38858:2504 'set' on the router. It
>> should be falling through to sequence 100 on account of
>> a no-match on sequence 10, I thought.  I mean it's not
>> even the same friggin protocol...
>>
>> (And no, there's no IPv6 prefix lists defined at all,
>> anywhere, on that switch)
>
> Interesting.
>
> Well, that's one of the reasons we use dedicated routing
> policies for both IPv4 and IPv6, including different route-
> map names as well, to avoid potential issues such as these
> (unintended or otherwise).
>
> Have you tested whether having a dedicated route-map for the
> IPv6 session works around this problem?

Yes - it doesn't work around it.  I have just replicated the route-map 
exactly but removed the IPv4 specific match (seq 10) from the new copy 
and it works as expected (ie correct community set as a default/fall 
through even for IPv6 routes).

And...get this...if I add:

ipv6 prefix-list PERMIT-IPV6-ANY seq 10 permit ::/0 le 48

route-map IBGP-STATICS permit 5
  match ipv6 address prefix-list PERMIT-IPV6-ANY
  set origin igp
  set community 38858:202

at the top of the route-map sequence (which should match first for IPv6 
routes, right?), then IPv6 BGP routes seemingly do NOT match that 
route-map even across session resets - as that (unique) community value 
is never set.

So it looks to me very likely it's a matching problem in that the match 
ip prefix list is matching IPv6 routes when it should be an IPv4 only 
match and then, only a specific IPv4 match.

Only reason I've kept route-maps and other things constant is to 
essentially overlay IPv6 atop of the existing IPv4 network as far as 
possible.  Much easier to administer and support if the 
communities/policies/route-maps are the same etc but obviously this has 
the drawback that a problem with one part of the config can then screw 
up both protocols, or as I have just found out it makes it a bit more 
tricky to work around bugs in one or the other :-(.

Reuben



More information about the cisco-nsp mailing list