Btw, in regards to multicast efficiency on large bridged networks with multiple subnets -- we use a more advanced version of MVR that allows us to designated a single VLAN to be used for a multicast group -- at the access switch, an extension to IGMP snooping maps receivers for a group to that group's designated VLAN. This prevents the creation of multiple distribution trees in large multi-subnet bridge domains as well as nicely solve the issue of multicast extranet with firewall bypass. Best regards -- aldrin
On Tue, Dec 18, 2012 at 11:29 PM, Aldrin Isaac <[email protected]> wrote: > Kireeti, > > I'm not clear what difference it makes whether a packet is unicast > forwarded using MAC address or IP address within a subnet as long as > it gets to the intended destination along the most optimal path, > particularly when the price to pay is non-standard behavior > (intra-subnet ARP manglers ;}, etc). I understand the argument about > the sub-optimal routing from a third site, but when the primary sites > end up aggregating prefixes for scaling reasons that argument falls > off the table. One way or other the piper gets paid. > > In terms of the real world issue of getting there from here -- > personally I haven't seen any vendor working towards a standards-based > solution that will allow intra-subnet routing for subnets over > HW/TOR-based PE, let alone intra-subnet routing for subnets that span > across both hypervisor-based PE and TOR-based PE. This makes me leery > of solutions that can only take us half way there, particularly during > the transition phase. So if we're talking about network > virtualization based purely on hypervisors, "route IP, bridge non-IP" > may be realistic if you're willing to accept the caveats, but does not > seem to be otherwise. > > Btw, I understand how multicast may be less than efficient when > building both inter and intra subnet trees for the same IP mcast group > that end up overlapping links (maybe even more than twice) -- but I'd > like to hear your take on any other *insolvable* issues with regard to > multicast. > > Best regards -- aldrin > > > > On Tue, Dec 18, 2012 at 6:06 PM, Kireeti Kompella > <[email protected]> wrote: >> Hi Thomas, >> >> On Dec 18, 2012, at 09:03 , Thomas Narten <[email protected]> wrote: >> >>> Kireeti Kompella <[email protected]> writes: >>> >>>> The solution is simple: route if IP, bridge if not. Yes, one could >>>> do IRB, but why? IRB brings in complications, especially for >>>> multicast. I'm sure someone suggested this already, so put me down >>>> as supporting this view. >>> >>> I'm not sure I understand the difference. >>> >>> From an *NVE* perspective, when it receives a packet (which will have >>> an L2 header), it can look at the Ethertype, and if its IP, it can >>> route it. Otherwise, it can provide normal L2 service. So, in this >>> sense, "route if IP, bridge if not" is straightforward. And more to >>> the point, I assume that if the packet gets L2 service, the entire VN >>> is treated as a *single* broadcast domain. All nodes can reach all >>> other nodes. Right? >> >> Right. >> >>> Just so I understand, how is this different than IRB? What does IRB >>> imply that the above does not? >> >> IRB follows the principle of "bridge when you can, route otherwise". So, an >> IP packet with dest IP in the same subnet actually gets bridged; the >> originator (e.g., the VM) is responsible for ARPing the IP address, slapping >> the right dest MAC on the packet and sending that to the NVE which simply >> forwards based on dest MAC address *without* decrementing the TTL. >> >> If the dest IP is in another subnet, the packet is sent to the gateway >> (which for IRB would be the same NVE), which this time does an IP address >> lookup, decrements TTL and routes the packet. >> >> For multicast, there are even more differences. >> >>> But this is different than what (I believe) Lucy is arguing for. In >>> the case of a multi-subnet VN, you have one VN, but it contains >>> different subnets. Each subnet is intended to be one broadcast domain >>> (i.e., equivalent of a VLAN), so that when sending LL multicast and >>> the like on a specific subnet, such packets are *not* delivered to all >>> nodes in the VN, but only those that are part of subnet. >> >> If one were to configure multiple subnets on a VLAN, I wonder if LL traffic >> goes to all members of the VLAN, or just those in the same subnet as the >> sender. I suspect the former (but don't know). >> >>> This is a more complex type of service to provide. And I'm not sure we >>> need this type of service to be provided by one VN. >> >> Agree. >> >>> A (seemingly >>> simpler) alternative would be to put each subnet in its own VN and >>> allow inter-subnet traffic to be handed as inter-VN traffic. So long >>> as that case is optimized (i.e., the ingress NVE can tunnel directly >>> to the egress NVE without adding triangular routing), this would seem >>> to be a cleaner way to implement this. >> >> Can be done. However, we're on Lucy's topic; mine was "route if IP, bridge >> otherwise"; the goal was to rationalize the need for Layer 2 forwarding for >> non-IP traffic, and inter- and intra-subnet routing. >> >> Kireeti. >> >>> Thomas >>> >>> _______________________________________________ >>> 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
