On 6/03/2012 4:54 PM, Mark Tinka wrote:
For static routes, assigning a tag to the routes and
referencing that in a route-map which is attached to a BGP
policy will get you what you want. The tag is useful to
ensure you don't end up redistributing more routes into BGP
than you should.
For Connected routes, well, to ensure you don't redistribute
interface routes that shouldn't be in BGP, you'd need to add
another match condition such as a prefix list.
You need to evaluate whether the efforts of both options
above are more or less efficient than the 'network'
statement option, in your particular environment.
It's actually rather topical that your two postings today Mark have been
separately about BGP route advertisements and the ME3600's because just
a few hours ago I logged a TAC case on the BGP route-map broken-ness I
am currently seeing on the ME3600/ME3800s I have.
This config (simplified a bit):
router bgp 38858
address-family ipv6
redistribute static route-map IBGP-STATICS
exit-address-family
route-map IBGP-STATICS permit 10
description Customer Subnet
match ip address prefix-list PERMIT-CUSTOMER-SUBNET
set origin igp
set community 38858:2504
!
route-map IBGP-STATICS permit 100
description Set a community on static routed internal only subnets
which are not otherwise defined above
set community 38858:201 no-export
ip prefix-list PERMIT-CUSTOMER-SUBNET seq 20 permit 203.56.29.0/24
ipv6 route 2401:8C00:99::/64 Null0
Gives this:
sw7.nsw#show ip bgp ipv6 unicast 2401:8C00:99::/64
BGP routing table entry for 2401:8C00:99::/64, version 271
Paths: (2 available, best #2, table default)
Not advertised to any peer
Local
2401:8C00::42 (metric 1) from 2401:8C00::41 (124.158.18.41)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 38858:2504
Originator: 203.56.29.230, Cluster list: 124.158.18.41
Local
2401:8C00::42 (metric 1) from 2401:8C00::40 (124.158.18.40)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 38858:2504
Originator: 203.56.29.230, Cluster list: 124.158.18.40
sw7.nsw#
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)
On other platforms such as ISR G1s and ISR G2s running 15.1(4)M3 this
works as expected. IPv4 and IPv6 routes that fall through have these
community values set right.
15.1(2)EY1a, TAC case SR 620949745 for anyone who is interested. The
TAC engineer is currently assessing the business impact and researching.
Bit hard to emphasize the severity of this one in terms of impact to
end users...............
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/
