l3vpn@ietf.org
[Top] [All Lists]

RE: Route Target in BGP/MPLS IP VPN

Subject: RE: Route Target in BGP/MPLS IP VPN
From: "Schliesser, Benson"
Date: Thu, 27 Jan 2005 07:10:17 -0600
Marko-

Yes, from a customer perspective there is complete reachability between all 
sites in the VPN. Though, complete reachability and full-mesh connectivity are 
different things.

The rationale I had in mind, from a SP perspective, for creating a 
sub-full-mesh topology while maintaining complete reachability in the VPN, is 
so that the Hub PE node could be used to provide some layered services, that 
might be unique to it amongst PEs. (Firewall, IDS, content caching or 
filtering, QOS policy, etc.)

I agree though, that making spoke-spoke traffic traverse a "Hub" CE is a bit 
more difficult. A customer who wants this sort of topology is just as well off 
with CE-CE tunnels (i.e. GRE) or a pt-pt L2 network (i.e. FR PW/PVC).

Cheers,
-Benson


> -----Original Message-----
> From: Kulmala, Marko [mailto:marko.kulmala@xxxxxxxxxxx] 
> Sent: Thursday, January 27, 2005 6:25 AM
> To: Schliesser, Benson; Fabien Verhaeghe; 
> TYushkov@xxxxxxxxxxxx; jguichar@xxxxxxxxx
> Cc: L3vpn@xxxxxxxx
> Subject: RE: Route Target in BGP/MPLS IP VPN
> 
> Benson,
> 
> Yes, it does support spoke-spoke traffic in that way but 
> spoke-spoke traffic does not go through customer hub site 
> instead it would only through hub PE.
> This is because VRF (import RT=hub, export RT=spoke) in hub 
> PE has also those more specific routes to the spokes.
> Thus, from customer point of view, this is full mesh VPN.
> 
> To make the spoke-spoke traffic go through customer hub site 
> a bit more complex implementation is needed. 
> 
> Marko
> 
> > -----Original Message-----
> > From: Schliesser, Benson [mailto:benson.schliesser@xxxxxxxxxx]
> > Sent: 26. tammikuuta 2005 18:14
> > To: Fabien Verhaeghe; TYushkov@xxxxxxxxxxxx; jguichar@xxxxxxxxx; 
> > Kulmala, Marko
> > Cc: L3vpn@xxxxxxxx
> > Subject: RE: Route Target in BGP/MPLS IP VPN
> > 
> > 
> > If the Hub advertises an aggregate prefix (0/0, 10/8, etc.) then it 
> > should support spoke-spoke traffic, per the draft.
> > (section 5 refers back to 4.3.2, which explains this)
> > 
> > Cheers,
> > -Benson
> >      
> >     
> >     
> > 
> > ________________________________
> > 
> >             From: l3vpn-bounces@xxxxxxxx
> > [mailto:l3vpn-bounces@xxxxxxxx] On Behalf Of Fabien Verhaeghe
> >             Sent: Wednesday, January 26, 2005 3:48 PM
> >             To: TYushkov@xxxxxxxxxxxx; jguichar@xxxxxxxxx; 
> > marko.kulmala@xxxxxxxxxxx
> >             Cc: L3vpn@xxxxxxxx
> >             Subject: Re: Route Target in BGP/MPLS IP VPN
> >             
> >             
> >             Seems clear to me now.
> >              
> >             Maybe in draft-ietf-l3vpn-rfc2547bis-03.txt it 
> should explicitly be 
> > said that the spoke and hub here does not offer connectivity
> >             between the spoke.
> >              
> >                             Thanks all
> >                             Fabien
> >              
> >             ----- Original Message ----- 
> >             From: TYushkov@xxxxxxxxxxxx 
> >             To: jguichar@xxxxxxxxx ; marko.kulmala@xxxxxxxxxxx 
> >             Cc: L3vpn@xxxxxxxx 
> >             Sent: Wednesday, January 26, 2005 3:34 PM
> >             Subject: RE: Route Target in BGP/MPLS IP VPN
> > 
> >             Jim,
> >             Fabien asked us about example in
> > draft-ietf-l3vpn-rfc2547bis-03.txt (4.3.5). In this 
> examples authors 
> > show us how to build hub&spoke VPN without any connectivity between 
> > spokes.
> >             Btw, I agree with you. There is another kind of 
> VPN called 
> > hub&spoke, where traffic between spokes goes through hub. But it is 
> > not the case of 4.3.5.
> >              
> >             Marko,
> >             As I can understand if you want to build 
> hub&spoke VPN with 
> > connectivity between spokes through hub, you have to 
> organize one VPN 
> > per spoke. Each VPN must be "point-to-point" (including one 
> spoke site 
> > and separate (sub)interface on hub site). Than you must organize 
> > routing between these VPN on CE on hub Site.
> >             So, we have as many different VPNs as spoke 
> sites, you want to 
> > connect to hub.
> >              
> >             Cheers
> >             Taras
> > 
> > ________________________________
> > 
> >             From: jguichar [mailto:jguichar@xxxxxxxxx] 
> >             Sent: Wednesday, January 26, 2005 5:11 PM
> >             To: Юшков Тарас;
> > fabien.verhaeghe@xxxxxxxxxxxxxx; L3vpn@xxxxxxxx
> >             Subject: RE: Route Target in BGP/MPLS IP VPN
> >             
> >             
> >             Not exactly. It is actually both of these 
> things and connectivity 
> > between spokes is driven by configuration. In one model 
> spokes cannot 
> > communicate, in another they can (preferably via a firewall at the 
> > hub).
> >              
> > 
> >             Jim Guichard CCIE# 2069
> >             System Architect - MPLS Technologies
> >             
> >             ITD Boxborough
> >             DD: 978-936-1586
> >             Cell: 978-302-0481
> > 
> >              
> > 
> > 
> > ________________________________
> > 
> >                     From: l3vpn-bounces@xxxxxxxx
> > [mailto:l3vpn-bounces@xxxxxxxx] On Behalf Of TYushkov@xxxxxxxxxxxx
> >                     Sent: Wednesday, January 26, 2005 8:43 AM
> >                     To: fabien.verhaeghe@xxxxxxxxxxxxxx; 
> L3vpn@xxxxxxxx
> >                     Subject: RE: Route Target in BGP/MPLS IP VPN
> >                     
> >                     
> >                                             Fabien: "What I
> > understood is that Spoke can not communicate DIRECTLY with 
> each other. 
> > They have
> >                     to go through the Hub."
> >                     Taras:
> >                                             No, spokes can
> > not communicate with each other even through hub. That is idea of 
> > hub&spoke VPN - it is VPN with PARTIAL connectivity.
> >                     Suppose, you have a large data center 
> and some clients of data 
> > center. Clients want to reach data center, but they don't want have 
> > ANY connectivity with other clients due security reasons, 
> for example.
> >                      
> >                     As to BGP routing, I may say, that PE 
> router on site B (spoke Site) 
> > may receive all routes, including routes from site C. But 
> it does not 
> > install routes to site C in its VRF routing table. Route Target of 
> > route from site C do not mach VRF "import" set of route target 
> > attributes.
> >                      
> >                     Taras
> > 
> > ________________________________
> > 
> >                     From: l3vpn-bounces@xxxxxxxx
> > [mailto:l3vpn-bounces@xxxxxxxx] On Behalf Of Fabien Verhaeghe
> >                     Sent: Wednesday, January 26, 2005 4:15 PM
> >                     To: L3vpn@xxxxxxxx
> >                     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@xxxxxxxxxxxx 
> >                     To: fabien.verhaeghe@xxxxxxxxxxxxxx ; 
> L3vpn@xxxxxxxx
> >                     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@xxxxxxxx
> > [mailto:l3vpn-bounces@xxxxxxxx] On Behalf Of Fabien Verhaeghe
> >                     Sent: Wednesday, January 26, 2005 3:03 PM
> >                     To: L3vpn@xxxxxxxx
> >                     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
> >                      
> >                      
> >                      
> >                      
> >                      
> >                      
> >                      
> >                     
> > 
> > 
> ============================================================
> The information contained in this message may be privileged 
> and confidential and protected from disclosure. If the reader 
> of this message is not the intended recipient, or an employee 
> or agent responsible for delivering this message to the 
> intended recipient, you are hereby notified that any 
> reproduction, dissemination or distribution of this 
> communication is strictly prohibited. If you have received 
> this communication in error, please notify us immediately by 
> replying to the message and deleting it from your computer. 
> Thank you. Tellabs 
> ============================================================
> 

<Prev in Thread] Current Thread [Next in Thread>