[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Route Target in BGP/MPLS IP VPN
You could do this using two VRFs.
I don't think it is required though (but this could be implementation
dependent). As far as I understand this, a PE never passes on VPN
traffic received from one PE to another PE (i.e. PE has no transit
function). Thus even though the VRF on PE A has more specific entries
for let's say site C in the example below, these would not be valid for
traffic received from another PE -e.g. PE B (because the next-hop is a
PE as well) and the PE would/should only consider 'CE' next-hops as
valid.
cheers,
Eduard
> -----Original Message-----
> From: Bala Venkata [mailto:balavenkata at netscape.net]
> Sent: donderdag 27 januari 2005 10:06
> To: Metz, E.T.
> Cc: fabien.verhaeghe at atosorigin.com; L3vpn at ietf.org
> Subject: Re: Route Target in BGP/MPLS IP VPN
>
> Eduard-
>
> When you say
>
> "This will result in traffic from CE-B to CE-C to go like
> this CE-B ->
> PE-B -> PE-A -> CE-A -> PE-A -> PE-C -> CE-C."
>
> are you assuming that PE-A has two VRF's ? One to import the routes
> from the spokes and the other two export its (CE-A's) routes to them ?
> Just wanted to be clear on your "PE-A -> CE-A -> PE-A" portion.
>
> (btw, it is confusing to call everything "hub and spoke" - I vaguely
> remember coming across the phrase "Central Services" must be in
> Guichard's book...?)
>
>
> Thanks !
>
>
> E.T.Metz at telecom.tno.nl wrote:
> >
> > In a hub-and-spoke VPN, spoke-sites (assuming these do not
> share a VRF
> > when connected to the same PE) cannot communicate with eachother
> > directly, i.e. spoke-PE to spoke-PE. If spoke-sites need to
> communicate
> > with eachother the communication path indeed goes (must go)
> through the
> > hub-CE, the underlying requirement could e.g. be that
> traffic between B
> > and C needs to pass a firewall at A. Note that the hub-PE
> never acts as
> > a 'transit' node in this case. To achieve spoke-spoke
> communication you
> > either need to advertise an aggregate (covering the spoke-subnets or
> > entire VPN) or a default from the hub-site (CE), and ensure that the
> > hub-CE has specific routes to the spoke-CEs pointing to the
> hub-PE. This
> > will result in traffic from CE-B to CE-C to go like this
> CE-B -> PE-B ->
> > PE-A -> CE-A -> PE-A -> PE-C -> CE-C.
> >
> > Hope this helps.
> >
> > cheers,
> > Eduard
> >
> > ________________________________
> >
> > From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] On
> > Behalf Of Fabien Verhaeghe
> > Sent: woensdag 26 januari 2005 14:15
> > To: L3vpn at ietf.org
> > Subject: Re: Route Target in BGP/MPLS IP VPN
> >
> >
> > Thanks for your answer Taras ,
> >
> > What I understood is that Spoke can not communicate DIRECTLY
> > with each other. They have
> > to go through the Hub.
> > But if a packet is received at PE C (from the CE) for a
> > destination address which is in site B he won't
> > have any route that says to go through the Hub.
> >
> > I'm talking about the routing between PEs when I make a
> > reference to RFC1771 9.2.1. Not between CE and PE.
> >
> > Fabien
> >
> > ----- Original Message -----
> > From: TYushkov at microtest.ru
> > To: fabien.verhaeghe at atosorigin.com ; L3vpn at ietf.org
> > Sent: Wednesday, January 26, 2005 1:29 PM
> > Subject: RE: Route Target in BGP/MPLS IP VPN
> >
> > Hi,
> >
> > The main idea of Hub&spoke is the following: spokes may
> > communicate with hub, but spokes can NOT communicate with
> each other.
> >
> > So, everything seems to be ok. Site A can communicate with site
> > B & C, and sites B & C can't communicate with each other.
> >
> > As I can understand we may use: RIPv2, OSPF and EBGP to make
> > routing between PE and CE. So RFC1771 9.2.1 it's not our case.
> >
> >
> >
> > Cheers.
> >
> > Taras
> >
> >
> > ________________________________
> >
> > From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] On
> > Behalf Of Fabien Verhaeghe
> > Sent: Wednesday, January 26, 2005 3:03 PM
> > To: L3vpn at ietf.org
> > Subject: Route Target in BGP/MPLS IP VPN
> >
> >
> > Hi,
> >
> > I've got a question about the use of "Route Target" in BGP/MPLS
> > IP VPN
> > Section 4.3.5 of draft-ietf-l3vpn-rfc2547bis-03.txt states:
> >
> > "Alternatively, suppose one desired, for whatever reason, to
> > create a
> > "hub and spoke" kind of VPN. This could be done by the use of
> > two
> > Route Target values, one meaning "Hub" and one meaning "Spoke".
> > At
> > the VRFs attached to the hub sites, "Hub" is the Export
> > Target and
> > "Spoke" is the Import Target. At the VRFs attached to the spoke
> > site, "Hub" is the Import Target and "Spoke" is the
> > Export Target."
> >
> > If I have 3 sites A,B,C. one CE/PE pair for each site and one
> > VRF per CE/PE.
> > Site A is the hub
> > Site B,C are spoke
> >
> > In A VRF I would have the routes to both sites B and C
> > In B,C VRF I would only have routes to A since with BGP routes
> > learned from IBGP are not
> > advertised to BGP peer in the same AS (RFC 1771 9.2.1).
> >
> > So how can systems in site B communicate with systems in site C?
> >
> > I guess I misunderstood something, and PE connected to site A
> > will actually advertised routes received from site C
> > to site B. But it seems inconsistent with RFC 1771 9.2.1.
> >
> > Can someone explain to me please?
> >
> > Thanks
> > Fabien
> >
>
>