[j-nsp] vpn-apply-export

Blaz Zupan blaz at inlimbo.org
Mon Nov 10 02:23:10 EST 2003


After upgrading yet another M5 from 5.5R1.2 to 5.7R3.4, I found out that a
customers connection through a L3 MPLS VPN was suddenly broken. Although the
VPN itself was apparently working, the upgraded M5 was not announcing the
static default route configured under the routing instance to the other PE
router (a Cisco 7206 running IOS 12.2(14)S3).

Here is what I had configured:

policy-statement to-ibgp-amis-routes {
    term as8591 {
        from community [ from-customer from-lix from-six ];
        then accept;
    }
    term limited-routes {
        from {
            protocol [ bgp aggregate ];
            as-path limited-routes;
        }
        then accept;
    }
    term everything-else {
        then reject;
   }
}
as-path limited-routes "[0-65535]{0,2}";

This was applied as an export policy on the BGP session towards the Cisco PE.
The Cisco does not have enough memory for the full BGP routing table, so I'm
limiting the number of routes with the above policy.

The routing instance for the L3 VPN had this config:

somevpn {
    instance-type vrf;
    interface fe-0/1/0.308;
    route-distinguisher 12644:1;
    vrf-import vpn-somevpn-import;
    vrf-export vpn-somevpn-export;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop x.x.x.x;
        }
    }
}

I later replaced the vrf-import and vrf-export with "vrf-target
target:12644:1", because it's much nicer and easier.

The above static route was not distributed to the Cisco PE router for unknown
reasons. After some experimentation, I added "static" to this term:

    term limited-routes {
        from {
            protocol [ bgp aggregate static ];
            as-path limited-routes;
        }
        then accept;
    }

The default route suddenly appeared on the Cisco PE router. Obviously the IPv4
unicast policy was affecting the VPNv4 routes, so in the end effect it behaved
like I had vpn-apply-export configured, but I did not.

Am I misunderstanding something or is this a bug? The same configuration was
working flawlessly with 5.5R1.2.


More information about the juniper-nsp mailing list