[c-nsp] "continue" in outbound route-map

[Peter Rathlev]

On Sat, 2008-04-19 at 14:33 -0500, Richard A Steenbergen wrote:
> Route-map outbound continue most definitely does not work in SXF, SXH,
>  or SRA. It causes everything to leak through the route-map regardless
>  of your matches, which is a very bad thing if you're applying it to a
>  transit or peer session.

Hm... Thanks for the "heads up". I can see now that I must have misread
my first lab tests; it doesn't work anyway. I don't get any "leak
through" scenario though, it just behaves like if "continue" wasn't
specified. I have the following:

ip vrf VRF_A
 rd 65530:1
 route-target both 65530:1
 exit
!
interface Loopback50
 ip vrf forwarding VRF_A
 ip address 10.65.1.1 255.255.255.0
 exit
!
ip prefix-list POP1-Primary seq 10 permit 10.65.0.0/16 le 32
!
route-map Internal-VPNv4 permit 10
 match ip address prefix-list POP1-Primary
 set local-preference 110
 continue
!
route-map Internal-VPNv4 permit 20
 match route-type local
 set community 64512:251 additive
!
route-map Internal-VPNv4 permit 30
 exit
!
router bgp 65530
 address-family vpnv4
  neighbor VPN-CORE route-map Internal-VPNv4 out
  exit-address-family
 !
 address-family ipv4 vrf VRF_A
  default-information originate
  network 0.0.0.0
  network 10.65.1.0 mask 255.255.255.0
  exit-address-family
 !
 exit
!
ip route vrf VRF_A 0.0.0.0 0.0.0.0 10.60.248.2
!

I left out the rest of the VPNv4/MPLS configuration. With the above, I
would have expected that:

- The 10.65.1.0/24 prefix was marked with local preference 110 AND
community 64512:251
- The 0/0 prefix was marked with community 64512:251.

An iBGP neighbor shows this:

CORE-02#sh ip bgp vpnv4 vrf VRF_A 10.65.56.0
BGP routing table entry for 65530:1:10.65.1.0/24, version 69
Paths: (1 available, best #1, table VRF_A)
  Advertised to update-groups:
     3
  Local
    10.22.248.3 (metric 10) from 10.22.248.3 (10.22.248.3)
      Origin IGP, metric 0, localpref 110, valid, internal, best
      Extended Community: RT:65530:1
CORE-02#sh ip bgp vpnv4 vrf VRF_A 0.0.0.0
BGP routing table entry for 65530:1:0.0.0.0/0, version 69
Paths: (1 available, best #1, table VRF_A)
  Advertised to update-groups:
     3
  Local
    10.22.248.3 (metric 10) from 10.22.248.3 (10.22.248.3)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 64512:251
      Extended Community: RT:65530:1
CORE-02#

The 10.22.248.3 is the POP1 router with the above configuration. The
10.65.1.0/24 prefix only gets the local preference, not the community.
If I add 0.0.0.0/0 to the "POP1-Primary" prefix-list it shows up like
this:

CORE-02#sh ip bgp vpnv4 vrf VRF_A 0.0.0.0
BGP routing table entry for 65530:1:0.0.0.0/0, version 71
Paths: (1 available, best #1, table VRF_A)
  Advertised to update-groups:
     3
  Local
    10.22.248.3 (metric 10) from 10.22.248.3 (10.22.248.3)
      Origin IGP, metric 0, localpref 110, valid, internal, best
      Extended Community: RT:65530:1
CORE-02#

It doesn't matter if I use "continue" or not. This is SXF13, maybe they
"fixed" it, so it doesn't fall through? Otherwise I don't think I
understand what you mean. :-)

> Personally I'm baffled why it took them until SRB to fix such a massive 
> glaring oversight. Route-map in general is already Cisco's weakest area 
> compared to Juniper, and a working route-map outbound continue is one of 
> the few ways to make route-maps even vaguely useable in comparison. Then 
> again, we still don't have named as-path lists, and we still can't match 
> named communities in a policy-list, so the list of absurd oversights is 
> hardly short. For me, route-map outbound continue is the #1 motivator to 
> run SRB+ over SXH right now, and I'm sure this applies to others as well.

I completely agree, the whole route-map thing is a mess. A clean
interface to route-maps is instrumental to avoiding problems -- I find
it very easy to accidentially do something wrong the way they are now.
And that means weeks of lab testing before deploying it anywhere. And
the lack of "continue" support means having to create some weird and
redundant route-maps. :-(

Regards,
Peter