[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Route Target in BGP/MPLS IP VPN



E.T.Metz at telecom.tno.nl:
> 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). 
> [...]
> (because the next-hop is a PE as well) and the PE
> would/should only consider 'CE' next-hops as valid.

While this is true for certain types of L2 VPNs, it's not forbidden in
2547bis. Per section 5 and 4.3.2, there are times when a VRF lookup is
performed on traffic incoming from a PE-PE link. Presumably, that
traffic could then be forwarded via a different PE-PE link.

I'll grant that it might be an implementation specific behavior. Perhaps
the I-D could be more specific.

Cheers,
-Benson
 

> -----Original Message-----
> From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org] 
> On Behalf Of E.T.Metz at telecom.tno.nl
> Sent: Thursday, January 27, 2005 11:59 AM
> To: balavenkata at netscape.net
> Cc: L3vpn at ietf.org
> Subject: 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
> > >   
> > 
> > 
> 
>