> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Somesh Gupta > 发送时间: 2012年9月5日 1:51 > 收件人: Ivan Pepelnjak; Balus, Florin Stelian (Florin) > 抄送: [email protected] > 主题: Re: [nvo3] Support for multi-homed NVEs > > Florin, > > Regarding the multi-homing, my assumption is that the > NVE in the hypervisor would not (want to) run a routing > protocol. So as Ivan points out, the standard would > need to accommodate multiple IP addresses per NVE.
If a given multi-homed NVE/PE (e.g., a physical server) doesn't run a routing protocol with the P routers, it seems that different NICs could act as different virtual NVEs/PEs and VMs of a given VPN instance are therefore multi-homed to these virtual NVEs/PEs in either active-standby mode or in active-active mode. Xiaohu > Somesh > > > -----Original Message----- > > From: Ivan Pepelnjak [mailto:[email protected]] > > Sent: Tuesday, September 04, 2012 9:58 AM > > To: Balus, Florin Stelian (Florin) > > Cc: Somesh Gupta; [email protected] > > Subject: Re: [nvo3] Support for multi-homed NVEs > > > > Ah, that other can of worms ;) Mine was simpler. > > > > On the underlay side, we might decide that NVEs have a single IP > > address > > or multiple IP addresses (like some NVGRE load balancing proposals). If > > we decide NVEs have a single IP address (potential per virtual network > > segment), then the rest is implementation details (and we're back to > > MLAG/SMLT land for true redundancy). Alternatively we might implement > > the option of having multiple IP addresses per NVE, and the NVEs might > > use the IP-address-per-link option (thus no need for L2 or MLAG at > > all). > > > > On the overlay side, the real problem (as you stated) is the > > multi-homing of NVO3-to-legacy gateways. I don't see any other need for > > overlay NVE multihoming. > > > > BTW, Nicira has nicely solved the NVO3 gateway multihoming - the whole > > NVO3 network works exactly like VMware's vSwitch: split horizon > > bridging > > (thus no forwarding loops through NVO3), with every VM MAC address > > being > > dynamically assigned to one of the gateways, which also solves the > > return path issues (dynamic MAC learning in legacy network takes care > > of > > that). Maybe we should just use the wheel that has already been > > invented? > > > > Kind regards, > > Ivan > > > > On 9/4/12 6:45 PM, Balus, Florin Stelian (Florin) wrote: > > > I understand the discussion below is about the NVE multi-homing > > towards the IP core, on the tunnel side. > > > > > > We did not focus in the framework draft on the core redundancy as in > > our opinion there was no need to standardize anything here. There are > > no differences from what is available today in regular IP networks: if > > NVEs are multi-homed directly to the next IP router, regular routing > > will take care of it. If there is Ethernet switching in between NVE and > > the next IP hop, L2 resiliency mechanisms need to be employed. From > > what I read below it looks more of an implementation discussion than a > > standardization requirement. Am I right? > > > > > > By Multi-homed NVEs one can also understand a set of NVEs multi-homed > > on the access side to other devices. That is a discussion we need to > > have in my opinion. An use case example: NVO3 network - NVE GWs multi- > > homed to external non-NVO3 networks. Handoff can be VLANs, VPLS PWs, or > > BGP EVPN labels... > > > > > > I think the latter is worth discussing although there are some > > mechanisms and some standardization initiatives in place already. > > > > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:[email protected]] On Behalf > > Of > > >> Ivan Pepelnjak > > >> Sent: Friday, August 31, 2012 12:23 AM > > >> To: 'Somesh Gupta'; [email protected] > > >> Subject: Re: [nvo3] Support for multi-homed NVEs > > >> > > >> This is definitely an interesting can of worms ;) > > >> > > >> While I don't think we should go down the path of IP-A/IP-B networks > > >> similar to some other DC technology, we will face the reality of > > some > > >> NVE elements (hypervisor soft switches) not being underlay IP > > routers. > > >> > > >> We could either: > > >> > > >> (A) ignore the issue and expect the network designer to solve it > > using > > >> any one of the existing NIC teaming/MLAG kludges while retaining a > > >> single encapsulation IP address per NVE; > > >> > > >> (B) provide support for multiple encapsulation addresses per NVE so > > a > > >> multi-homed NVE could have one IP address per physical interface and > > >> send and receive nvo3-encapsulated frames using more than one > > address. > > >> > > >> Option (A) is the easy way out similar to existing MPLS/VPN behavior > > >> and would fit well with existing DC deployments. It would also > > retain > > >> all the server-to-ToR multihoming complexity. > > >> > > >> Option (B) would reduce the complexity of the underlay DC network > > >> (which would become a simple L3 network with single-homed IP > > >> addresses), but we'd have to deal with a bunch of additional > > problems > > >> (peer IP address liveliness check). > > >> > > >> Just speculating ... > > >> Ivan > > >> > > >>> -----Original Message----- > > >>> From: [email protected] [mailto:[email protected]] On > > Behalf > > >>> Of Somesh Gupta > > >>> Sent: Friday, August 31, 2012 6:58 AM > > >>> To: [email protected] > > >>> Subject: [nvo3] Support for multi-homed NVEs > > >>> > > >>> I did not see any mention of multi-homed NVEs in draft-lasserre- > > nvo3- > > >>> framework-03.txt. NVEs are connected together by an L3 network - > > does > > >>> that mean only one? > > >>> Can it be multi-homes to two L3 networks? > > >>> > > >>> Somesh > > >>> _______________________________________________ > > >>> nvo3 mailing list > > >>> [email protected] > > >>> https://www.ietf.org/mailman/listinfo/nvo3 > > >> _______________________________________________ > > >> nvo3 mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
