[c-nsp] bgp communities over vpn mpls

Keegan Holley keegan.holley at sungard.com
Mon Feb 28 07:45:42 EST 2011


On Mon, Feb 28, 2011 at 1:52 AM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.com> wrote:

>
> > It depends on the provider.  Extended communities are also used in
> vpn/vrf
> > route filters so honoring any community already seen on a customer
> route is
> > dangerous.
>
> actually: RFC4364 deals with route-target extcomms already attached to
> the eBGP customer routes, and removes all of those which are not
> configured as RT export in the customer VRF on the PE.


I can assure you this isn't true of all vendor implementations.  Also, if a
MPLS provider wishes to allow a customer to use a specific set of
communities all they would have to do is add them to the export policy, so
this doesn't really answer the question.  For example if you run BGP with a
customer you can allow them to advertise extended communities and attach
them to a pre-pend policy to allow customers to prepend individual routes
without your intervention.  This is actually fairly common.  You are right
those communities do have to be in the VRF export policy.

This capability
> allows the customer to specify only a subset of VRFs which should see
> the pfx. Not really useful and not widely used as it would require the
> customer to know exactly about the SP's RT import/export
> structure/assignments, but I wanted to mention that RT extcomm's
> received from the customer do not compromise the route
> isolation/segmentation property of BGP-L3VPN..
>

How so? Communities applied on the cpe could affect import policies of
remote vrf's depending on how your policies are configured. Having it
advertised from the CPE would be the same as having it advertised from the
customer if they are permitted by policy.  Again the communities aren't
stripped by default in all implementations.  Even when they are, they can be
allowed if there is a business case or a misconfiguration.


More information about the cisco-nsp mailing list