[j-nsp] Usage of Route distinguisher in VPLS

Monika M monika.vpls at gmail.com
Wed Jun 27 07:52:40 EDT 2007


Thanks for the reply.
As per section 3.1.2, Route target only identifies the VPLS.
Even in Juniper, if I have a configuration like this,

root# show routing-instances
vplsinst2 {
    instance-type vpls;
    route-distinguisher 100:4;
    vrf-target {
        import target:100:3;
        export target:100:3;
    }
    protocols {
        vpls {
            site-range 15;
            site india {
                site-identifier 7;
            }
        }
    }
}
vplsinstance {
    instance-type vpls;
    interface fe-0/3/1.0;
    route-distinguisher 100:3;
    vrf-target {
        import target:100:3;
        export target:100:3;
    protocols {
        vpls {
            site-range 10;
            site vplsSiteA {
                site-identifier 6;
                interface fe-0/3/1.0;
            }
        }
    }
}

If a NLRI is received with RD as 100:3 and RT as 100:3, it is added to both
the VPLS instances.
Route tables vplsinst2.l2vpn.0 and vplsinstance.l2vpn.0 contain an entry for
the single NLRI.

If the RT configuration is different and RD is same, then the NLRI is
associated only with the VPLS instance which is having the received RT.
Hence VPLS association is basically done with the RT and not with RD. That
is why it looks to me that RD is a redundant field.


Another feedback for the multi-homing input.
 Having different RDs will lead to duplicate packets and loops (if you don't
run STP) as you treat them as two different prefixes and PWs are established
to both the peers leading to problem. I believe it is similar to having
different VE ID configuration stated in the RFC.


-Monika

On 6/27/07, Guy Davies <aguydavies at gmail.com> wrote:
>
> Hi Monika
>
> On 27/06/07, Guy Davies <aguydavies at gmail.com> wrote:
> > Hi Monika,
> >
> > I haven't played around much with VPLS but a quick read of RFC 4761
> > reveals the following...
> >
> > Section 3.5 of RFC 4761 appears to be the key.  It refers to
> > multihoming mechanisms for VPLS and states the following...
> >
> >    In the case where the PEs connected to the same site are assigned the
> >    same VE ID, a loop-free topology is constructed by routing
> >    mechanisms, in particular, by BGP path selection.  When a BGP speaker
> >    receives two equivalent NLRIs (see below for the definition), it
> >    applies standard path selection criteria such as Local Preference and
> >    AS Path Length to determine which NLRI to choose; it MUST pick only
> >    one.  If the chosen NLRI is subsequently withdrawn, the BGP speaker
> >    applies path selection to the remaining equivalent VPLS NLRIs to pick
> >    another; if none remain, the forwarding information associated with
> >    that NLRI is removed.
> >
> >    Two VPLS NLRIs are considered equivalent from a path selection point
> >    of view if the Route Distinguisher, the VE ID, and the VE Block
> >    Offset are the same.  If two PEs are assigned the same VE ID in a
> >    given VPLS, they MUST use the same Route Distinguisher, and they
> >    SHOULD announce the same VE Block Size for a given VE Offset.
> >
> > In section 3.3, it states (paraphrasing) that you MAY configure an RD
> > on a PE for each VPLS.  If you choose not to configure one manually
> > then one will be automatically created for each VPLS.
> >
> > So, (taking 3.3 and 3.5 together) if you want to do multihoming, you
> > MUST manually configure the same RD for the same VPLS on all the PE to
> > which multihomed sites in that VPLS are connected (so it makes sense
> > to configure the same RD on all PE for that VPLS).
>
> Sorry, I should say the following...
>
> So, (taking 3.3 and 3.5 together) if you want to do multihoming *and
> not use STP*, you MUST manually configure the same RD for the same
> VPLS on all the PE to which multihomed sites in that VPLS are
> connected (so it makes sense to configure the same RE on all PE for
> that VPLS).
>
> It has been pointed out to me that using the same RD will have an
> impact on the speed of convergence.  Because the two prefixes are
> viewed as identical, the receiving PE will discard/ignore the other
> 'identical' advertisements.  It must see a withdrawal of the first
> prefix and then an advertisement of the originally discarded/ignored
> prefix before the new prefix will be used.  If the RDs (and hence the
> prefixes) are different, then only the withdrawal of the preferred
> prefix is required to trigger the use of the other prefix.





Rgds,
>
> Guy
>


More information about the juniper-nsp mailing list