I'm having a hard time finding information about whether implementing ipv6 or using a stretched vlan is a better option for geographically dispersed sites is better. Does anyone know:

  1. Problems with stretched vlans (mac address broadcasting etc)
  2. costs for devices to solve those problems
  3. pros for using IPv6 instead

EDIT. What I am looking for is pros and cons against implementing the equipment required to implement stretched IPv4 vlans vs simply using IPv6 to solve the same problems. Eg admins stretch vlans instead of route because protocol X can't be routed, but IPv6 can encapsulate protocol X so there is no need to worry about that problem.

Edit 2: Lets say that one of the problems to be solved is migrating VMs across physical datacenters, Will IPv6 solve the problem of needing to stretch the vlan?

I am looking for a detailed explanation of which project will provide the most bang for the buck as well as reduce network complexity. So far the answers have centered around them as if they are not related (which I see as them being related as IPv6 removes vlan requirements entirely- making it extremely difficult to implement any vlan stretching infrastructure) - but have the same requirements of supporting multiple datacenters in a dispersed environment. All of my providers support IPv6 and we'll probably get a provider independent /48 (if we go that route)

  • 9
    Stretched VLANs is layer-2 and IPv6 is layer-3. This question is asking to compare apples to oranges... – Sander Steffann Apr 5 '12 at 17:56
  • 4
    I think he knows that, that's why he's asking what he's asking. It would probably be a lot more answerable if he explained the problem he's trying to solve more fully. "geographically-dispersed sites" doesn't tell us much. – mfinni Apr 5 '12 at 18:00
  • 1
    @SanderSteffan yes the layers are different but what are the pros and cons of each one? If you had to replicate data (as a task) which one would you choose? – Jim B Apr 6 '12 at 1:02
  • 3
    What protocol X can be encapsulated in ipv6, that can not be encapsulated in ipv4 and thus be routed? – becomingwisest Apr 6 '12 at 1:29

When looking at the problems related to migrating VMs between physical data centres IPv6 will not make a difference. IPv6 is routed in the same way as IPv4, so you would need stretched VLANs in both cases.

As mentioned previously stretched VLANs are not such a great idea. You might want to consider LISP for this. Cisco has some very good support for that these days, and VM mobility is something they specifically target on the Nexus 7000 (see Nexus 7000 NX-OS Innovations) in their LISP implementation (see Cisco Locator/ID Separation Protocol for Virtual Machine Mobility). And best of all: it supports both IPv4 and IPv6 :-)

| improve this answer | |
  • The problem I see with all of the stretched clan proposals is they all want some proprietary magic, with ipv6 all I seem to need is a vpn tunnel (or so it seems) – Jim B Apr 8 '12 at 17:17
  • An IPv6 VPN tunnel is just the same as an IPv4 VPN tunnel. Both are just two different layer-3 protocols. It doesn't change anything with regard to having to stretch a clan or not. – Sander Steffann Apr 9 '12 at 11:21
  • can you go in to further details about how ipv6 tunnels are the same as IPv4. When I suggest that its the same to some of the networking contacting companies they look at me like I have 3 heads. basically ipv4 tunnels require equipment and ipv6 doesn't (so I'm told) – Jim B Jul 5 '12 at 18:36

You are asking about things that are orthogonal to each other (independent of each other) as if you need to make a choice to implement one or the other. Why?

If you have an IPv4 network between two locations then for simple tasks like copying data between the two locations, there's nothing that IPv6 will do for you that IPv4 can't already do.

As a separate question, you might want to extend vlans to the other location, perhaps because you want to avoid the overhead of a router. This motivation for using stretched vlans would be equally valid for IPv4 or IPv6.

One thing has nothing to do with the other.

You mentioned protocols that can't be routed. Non-IP protocols? In that case you should use stretched vlans. Switching to IPv4 to IPv6 won't suddenly make these protocols routable. You also mentioned tunelling these unroutable protocols in IP (and this tunnel carrier could be either v4 or v6, either one is good). I would not recommend tunelling unless necessary because it will add much more overhead than stretched vlans and complicate the network topology a lot. You should resort to this kind of tunelling if the stretched vlans solution is unscalable or unavailable. Reasons why stretched vlans might be unscalable could porentially include limits of spanning tree protocol capabilities, or MAC address leaning difficulties due to unidirectional layer 2 network flows or too many hosts on a single vlan. Reasons why stretched vlans might be unavailable could include a third party router in the link which is outside of your control and cannot be replaced with a bridge.

| improve this answer | |
  • so if you had a preference why stay with IPv4 and encapsulate instead of v6 and potentially flatten the address space and reduce the number of routers – Jim B Apr 6 '12 at 18:37
  • Reread my answer as well as almost everybody else's comments. IT'S NOT A CHOICE BETWEEN STAYING WITH IPv4 OR FLATTENING THE ADDRESS SPACE. Please (1) state which protocol X you're talking about that needs encapsulation because it supposedly can't be routed, and (2) why you think that using IPv6 somehow "flattens" the address space. – Celada Apr 6 '12 at 18:49
  • it IS a choice between ipv6 or stretched vlans because I only have budget for 1 of those projects. I think that Ipv6 allows me to eliminate vlans altogether, and eliminate any stretched vlan voodoo and just create a vpn tunnel – Jim B Apr 8 '12 at 17:22
  • IPv6 enables you to do no such thing. Nothing you can't already do in IPv4, anyway. – Celada Apr 9 '12 at 16:00
  • can you explain why you can't eliminate vlans? IPv6 doesn't do broadcast so I don;t need to create seperate broadcast domains and can keep a flat address space. – Jim B Apr 10 '12 at 17:25

Layer 2 data center interconnects are basically a horrible idea. See http://blog.ioshints.info/2011/11/busting-layer-2-data-center.html for a great explanation.

You want to route between your sites, which means different subnets and an L3 switch or router (even if that router is just a server configured with static routing).

| improve this answer | |
  • Even MPLS as a layer2 interconect? – Tom O'Connor Apr 6 '12 at 7:04
  • @Tom O'Connor: Yes, even MPLS is bad in this scenario. Putting dispersed sites into the same L2 broadcast domain for whatever reason is a bad idea unless they are really close (like under 1 km) and the links are totally private. Ultimately, there will be IP with ARP and other Ethernet broadcasts running on top of your MPLS pseudo-wire. I know Metro Ethernet providers love to sell "a big layer 2 domain", but that is not a good idea for all the reasons mentioned in the link. MPLS is good for a lot of use cases, but stretching an Ethernet broadcast domain isn't one. – rmalayter Apr 6 '12 at 15:03
  • but since IPV6 doesn't do broadcast like that wouldn't that solve the broadcast problem? – Jim B Apr 6 '12 at 18:36
  • IPv6 does lots of layer 2 multicast on the local link, some of which are basically broadcasts (such as neighbor discovery, which replaces ARP). The end result is the same. Most ipv6 host do things like multicast name resolution as well, which is basically broadcast to all ipv6 hosts. – rmalayter Apr 7 '12 at 3:49
  • Multicast is not broadcast as multicast only goes to some devices. Neighbor discovery in at the application layer unlike arp with is at the network layer and uses the link local address. – Jim B Apr 11 '12 at 17:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.