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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
