On 03/08/2012 07:44 AM, Gert Doering wrote:
If I have a route-map that parses IPv6 routes, but does not match any
IPv6 routes (no match ipv6 ... defined anywhere in any of the route-map
sequence entries) then it matches on the first _IPv4_ route map entry
and sets the community of that IPv6 route to the IPv4 match instead.
That's the bug :)
As far as I have interpreted this behaviour: for an IPv6 route, the
"match ip" statements are just not evaluated, as if "not there at all",
and vice versa for IPv4 routes and "match ipv6".
Yeah, this behaviour is pretty well documented, and I found it quite
surprising the first time I ran into it:
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008047915d.shtml#cmdsredist
The occasion I ran into it was an attempt at laziness, to use the same
route-map for "redis connected" and "redis static". I wanted to use a
tag on static routes to signal "no-export" and wrote a route-map like this:
route-map redis2bgp permit 10
match tag 100
set community no-export
route-map redis2bgp ...
Of course, this fails for "connected" routes; because "match tag" is not
a "supported command" for connected, it's just ignored, meaning the 1st
statement matches for all connected routes.
Basically - match statements that are inapplicable are just IGNORED as
opposed to the match FAILING.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
