[c-nsp] bgp communities over vpn mpls

[Keegan Holley]

It's not really a problem.  The reality is that these decisions are made
when the service/network is designed and never thought of again.  Peering PE
to PE doesn't change the communities on individual routes or how they are
handled in the network.  Also, many networks peer only the PE to PE or RR/PE
to PE and have all the P routers running an IGP only.  Every network is
different.  You just need a policy that is designed to permit only what you
wish to allow into your network.  It's no different than designing a BGP
policy for internet connections.

On Mon, Feb 28, 2011 at 1:10 PM, Max Pierson <nmaxpierson at gmail.com> wrote:

> > 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.
>
> Would peering PE to PE over the carriers network not negate this problem in
> either scenario??
>
> -
> m
>
> On Mon, Feb 28, 2011 at 6:45 AM, Keegan Holley <keegan.holley at sungard.com>wrote:
>
>> 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.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>