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

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 at ietf.org [mailto:l3vpn-bounces at ietf.org] On Behalf Of Fabien Verhaeghe
		Sent: Wednesday, January 26, 2005 3:48 PM
		To: TYushkov at microtest.ru; jguichar at cisco.com; marko.kulmala at tellabs.com
		Cc: L3vpn at ietf.org
		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 at microtest.ru 
		To: jguichar at cisco.com ; marko.kulmala at tellabs.com 
		Cc: L3vpn at ietf.org 
		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 at cisco.com] 
		Sent: Wednesday, January 26, 2005 5:11 PM
		To: Юшков Тарас; fabien.verhaeghe at atosorigin.com; L3vpn at ietf.org
		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 at ietf.org [mailto:l3vpn-bounces at ietf.org] On Behalf Of TYushkov at microtest.ru
			Sent: Wednesday, January 26, 2005 8:43 AM
			To: fabien.verhaeghe at atosorigin.com; L3vpn at ietf.org
			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 at ietf.org [mailto:l3vpn-bounces at ietf.org] On Behalf Of Fabien Verhaeghe
			Sent: Wednesday, January 26, 2005 4:15 PM
			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