2

I've got a weird situation. Three doctors offices are merging in two cities and we are planning on merging them into one building in each city. Due to politics and crappy software each office will run pseudo-independently, meaning we have three networks with their own (overlapping) VLAN's. I'm in charge of networking and our office has the nicest networking gear that will get re-purposed for each building. We're running Arista 7150's with EOS 4.21.1F (and also have 7124SX EOS-4.13.14M) and I plan on getting a 1G carrier ethernet circuit between the two buildings. I would use QinQ, but for whatever reason I have never got QinQ to work over WAN links (works everytime in the lab). I've asked the carrier for more information or to allow QinQ before and gotten nowhere, so I'm going to assume it's not in play. My next thought is to go to VXLAN.

I plan on the following physical design (if I can):

        ---- Site A (Arista 7150) ---- Site B (Arista 7150) ----
                          |                 |
Office 1 (Arista 7124SX) -|                 |- Office 1 (Arista 7124SX)
Office 2 (Arista 7124SX) -|                 |- Office 2 (Arista 7124SX)
Office 3 (Arista 7124SX) -|                 |- Office 3 (Arista 7124SX)
  • Can I use QinQ over VXLAN? This would make my life easy as I could assign a SVLAN to each office and be done with it.
  • Assuming I can't use QinQ over VXLAN, would I in theory have to manually map each vlan to an SVI? If so, to make my life easier, can I map each office to a range? AKA Office 1 [VLAN 1-4096 - VNI 10000-14096], Office 2 [VLAN 1-4096 - VNI 20000-24096], Office 3 [VLAN 1-4096 - VNI 30000-34096]

I've also put together the following basic config between sites, but it doesn't seem to be working.

## Site A
interface Ethernet1
    description Customer Port 1 Site A
    switchport access vlan 500
    switchport mode dot1q-tunnel

interface Ethernet23
   description Site A to Site B link
   switchport mode trunk

interface Loopback0
   description VXLAN VTEP IP address
   ip address 1.1.1.1/32

interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 500 vni 1500
   vxlan flood vtep 2.2.2.2

## Site B 
interface Ethernet1
    description Customer Port 1 Site B
    switchport access vlan 500
    switchport mode dot1q-tunnel

interface Ethernet23
   description Site B to Site A link
   switchport mode trunk

interface Loopback0
   description VXLAN VTEP IP address
   ip address 2.2.2.2/32

interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 500 vni 1500
   vxlan flood vtep 1.1.1.1
  • Running layer-2 over a WAN is really not something you want to do if you can avoid it. Why not simply layer-3 connect each site? That way, you can have the same VLAN numbers at each site, but even if the VLAN numbers are the same, they are separate VLANs. We live in a layer-3 world, and there really is nothing that requires all the hosts to be on the same layer-2 LAN. – Ron Maupin Nov 13 '19 at 21:33
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 15 '19 at 20:03
4

Can I use QinQ over VXLAN? This would make my life easy as I could assign a SVLAN to each office and be done with it.

Yes. We're doing Q-in-Q on DCS-7150S-24's currently running EOS-4.20.11.1M.

One thing I noticed when comparing our configs with yours is that your Vxlan1 interface does not have a flood VTEP defined for VLAN 500, just a VNI and a generic flood VTEP. I'm not sure if this makes the difference, but it's woth testing. We have an additional statement like this:

interface Vxlan1
   vxlan vlan 500 vni 1500
   vxlan vlan 500 flood vtep 2.2.2.2
2

VPN links are usually L3 point-to-point routed links which is a much more efficient approach. For Q or QinQ tags to work you'd need L2 VPN and generally, that's not a good solution. L2 forwards broadcasts and other unwanted traffic across the VPN links and wastes bandwidth.

WAN links only support tags when that service is explicitly part of the plan.

Simply let each tunnel router take care of the LAN-side interfaces and VLANs, and route permitted traffic over the VPN link(s). On the far side, the other tunnel router sorts packets back into the required VLANs.

  • Thanks for the answer! But I would prefer to not use a VPN. – vxwhaa Nov 14 '19 at 1:17
  • @vxwhaa ... or any other type of tunnel - you're not connecting them together using public IPs in the LAN, do you? – Zac67 Nov 14 '19 at 7:20

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.