[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
> >   
> 
>