[c-nsp] bgp communities over vpn mpls

[Keegan Holley]

On Tue, Mar 1, 2011 at 12:31 AM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.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.
>
> Hmm, ack.. looks like the behaviour is not specified in the RFC (or I
> missed it)..
>

Guess I never got to that RFC.  Wouldn't be the first time a major vendor
didn't follow an RFC though ;)

>
> > 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.
>
> Not sure I follow? And, BTW: I did not discuss the OP's question about
> getting standard communities across an MPLS-SP-service, this is different
> and straight-forward (only requires the SP allows to send standard
> communities across its core). Just wanted to reply to your comment about the
> danger accepting ext-comms.
>

Ok, np.  If I read your RFC snippet correctly it says compliance requires
that communities not included in the export policy are dropped.  I was
trying to infer that if the provider added the community the customer added
and it was accepted and advertised by the PE router then that should be
compliant.  Did I misunderstand the language?  I have to admit it's been
about three years since I read through an RFC.

>
> > 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
>
> can you give an example, not sure I understand what you refer to..
>

One of my upstreams hands us an internet feed that is just a route leaked
vrf on a Juniper M/MX box.  So we can do both internet and overlaps to other
VRF's.  One of the policies allows customers to advertise extended-comms
with their own AS and a set of all 1's.  This community is accepted by their
PE routers and advertised to all the edge internet routers.  Their internet
routers will then prepend the provider's AS based on the number of ones in
the community, IE: 65534:1111 would prepend routes from customer AS 65534
for times, 65534:111 would prepend three times etc.  The point was that not
all providers wish to strip all customer comms.  If accepted in a controlled
fashion they can be quite useful.

>
> >> 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.
>
> Not sure I understand, but just to highlight the point I was trying to make
> (which might have missed your point completely ;-)
> The case I was referring to was: Imagine you have a vrf
>
> ip vrf foo
>  route-target export 123:123
>  route-target export 456:456
>
> where 456:456 is actually a central service route-target, imported at a
> shared datacenter at a remote PE. If the CE sends an eBGP path to this PE in
> vrf foo with an extended community RT:123:123, the PE (at least the Cisco
> PE) will accept this extcomm and, when converting this into a vpnv4 update,
> will NOT append RT:456:456, so the remote datacenter PE will not import this
> specific prefix. Does this make sense? It might. Is it being used? maybe,
> but likely not often.
> The key point: If the customer appended community RT:999:999, the PE will
> strip this one, so security is not compromised as RT999:999 could belong to
> a completely different customer/vrf..
>

I know that.  Juniper PE's allow you to have more than one community in your
import policy though so it would be accepted on a poorly configured Juniper.
 For example of you had (sorry I'd just botch the code and I don't feel like
logging into a router) the same vrf with a route target of 65534:1234 you
could assert 65534:338 and other communities.  You could then import any
routes tagged with 65534:338 even though it's not your RT.  I'm not sure if
the juniper makes all the  comms part of the NLRI or if it just allows
import policies based on "regular" extended comms, but the same happens if
the comm is asserted by the CPE.  It would have to be permitted in the
export policy on the ingress PE though, so I suppose that doesn't violate
the RFC.