The MPLS WG Archive

["Andrew Bartholomew" <Andrewb@layer8.co.uk>]

Robert,

Thanks for the response, please see my comments below.

Regards,
Andrew

--
Andrew Bartholomew

Layer 8 Consultancy                      Observa et sapiens cresces.
Services Limited                             

Tel:   +44 1202 558409
Fax:   +44 1202 556748
Email: Andrewb@Layer8.co.uk



> -----Original Message-----
> From: Robert Raszuk [mailto:raszuk@cisco.com]
> Sent: 10 January 2001 07:31
> To: Andrew Bartholomew
> Cc: mpls@UU.NET
> Subject: Re: route targets and IBGP in mpls VPNs
>
>
> Andrew,
>
> RTs do allow you to control the distribution of routes within each VPN
> among routers participating in the VPN.
>
> > This gives rise to the issue of IBGP speakers propagating
> updates received
> > from one IBGP peer to another, something not normally allowed
> in IBGP, and
> > also begs the question when such an update should be
> propagated, to avoid
> > incorrect updates flooding the VPN.
>
> The propagation of IBGP updates is done only in route relfectors. The
> principles of bgp do not change at all.

Are you assuming here that route reflectors MUST be implemented?  I can give
you an example of route propagation (see below) with only four sites in a
VPN, where route reflectors would be overkill.

>
> > However, the "hub and spoke VPN" and the "firewall in an
> extranet" examples
> > given in the draft suggest that all PEs do have routes to all
> parts of the
> > VPN, just indirect ones in some cases.
>
> Let me give you a small example how hub and spoke would work. Considers
> three PEs: PE1, PE2 & PE3. Let PE1 be the PE connecting hub site and
> PE2/3 the PEs connecting the spoke sites. In the VRFs of PE2/3 you will
> find only local routes and the default out to PE1 hub site. Setting the
> right RT combination allows you to easily achive this.

What if the route to the hub is not the default route?  Can PE2 reach
destinations local to PE3?
These are VPN-IP4 routes and as the draft indicates, this may not always be
applicable (where a site has non-VPN provided access to the Internet).

Having PE1 distribute the default route to PE2 and PE3 would require
additional configuration in addition to the RT values

>
> I am not sure what do you mean by "indirect routes" ??? I am only
> guessing that what you meant to say all the routes but only with
> different next hop (for example pointing at hub PE). If so no as you see
> from the above example default to hub site is what most spoke sites
> would use to get out.

Yes, I mean one whose BGP next hop is not the most direct next hop across
the VPN - one where the RT values have inhibited the installation of fully
meshed (direct) connectivity.

I did not mean "all the routes", consider a firewall example (slightly
different to the one in the draft):

If sites A, B, C, and D are in a VPN, with sites A and B belonging to one
company and sites C and D belonging to another.  There is a firewall at B,
and servers at both A and C.  One would want traffic from D to reach the
server at A via the firewall at B but traffic from D to the server at C
should not need to pass through the firewall at B.

This is an example of where the PE router for site D needs a "direct" route
to the server at C but an "indirect" route to the server at A.  In
particular, use of the default route would not provide the required traffic
flow in the VPN in this case.

> R.
>
> > Andrew Bartholomew wrote:
> >
> > If I understand draft-rosen-rfc2547bis-02.txt  properly I believe some
> > clarification of the use of route targets would be helpful.
> >
> > My understanding is that route targets are used to control the flow of
> > traffic within a VPN, rather than have a full mesh of routes
> between PEs.
> > However, the "hub and spoke VPN" and the "firewall in an
> extranet" examples
> > given in the draft suggest that all PEs do have routes to all
> parts of the
> > VPN, just indirect ones in some cases.
> >
> > Specifically, in section 1.5 of the draft, the "firewall in an extranet"

> > example, it says
> >
> > "This means that it needs to be possible to set up two routes to the
> >    server.  One route, used by sites B and C, takes the traffic directly
> >    to site A.  The second route, used by site D, takes the traffic
> >    instead to the firewall at site B.  If the firewall allows the
> >    traffic to pass, it then appears to be traffic coming from site B,
> >    and follows the route to site A."
> >
> > This gives rise to the issue of IBGP speakers propagating
> updates received
> > from one IBGP peer to another, something not normally allowed
> in IBGP, and
> > also begs the question when such an update should be
> propagated, to avoid
> > incorrect updates flooding the VPN.
> >
> > One could add a rule that if a PE router R installs a route
> with an export
> > RT set S, and the corresponding VPN has an export RT set E (at
> R) such that
> > E-S is not empty, then the route should be propagated by R with
> itself as
> > the BGP next hop and with export RT set E-S.
> >
> > This route should only be considered by other PEs in the VPN
> who do not have
> > an element of S as an import RT, since those that do should use
> the direct
> > route rather than the one propagated by R.  But, I do not see
> how other PEs
> > could determine whether a route had been propagated or not without an
> > explicit indication in the update from R.
> >
> > If propagation of routes between IBGP speakers is not allowed then some
> > sites in a VPN will be unable to reach certain destinations without
> > management intervention - is this really the intention?
> >
> > Regards,
> > Andrew.
> >
> > --
> > Andrew Bartholomew
> >
> > Layer 8 Consultancy                      Observa et sapiens cresces.
> > Services Limited
> >
> > Tel:   +44 1202 558409
> > Fax:   +44 1202 556748
> > Email: Andrewb@Layer8.co.uk

--
Andrew Bartholomew

Layer 8 Consultancy                      Observa et sapiens cresces.
Services Limited                             

Tel:   +44 1202 558409
Fax:   +44 1202 556748
Email: Andrewb@Layer8.co.uk