[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 03:29:45 EST 2012


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



More information about the cisco-nsp mailing list