Wireless Access

Hi,

I'm currently working on a configuration, that tunnels Guest Clients to a central DMZ VLAN. I planned to use Tunnel Groups, however it seems the feature is not really working in L2.

Please correct me if I got anything wrong: 

We have 4 MDs in our network - 2 Site MDs (Remote 1 and Remote2) and 2 Central MDs (DMZ1 and DMZ2).

For redundancy reasons, we want to use tunnel groups to force the traffic through the primary tunnel. 

Tunnel Groups are only configured at the Remote site, as they can't be applied at the Central configuration.

I noticed the following problem with the concept: At the Central site, each DMZ MD has two active Tunnels to the Remote MDs and an uplink connection to the wired network. I can't figure out any configuration that would not end in a loop.

The green arrows should display unidirectional traffic flow. The primary tunnels are full duplex, the secondary tunnels are blocked, however able to receive traffic.

1. Client at Remote1 sends an ARP
2. DMZ1 receives the ARP and forwards it via L2 Tunnel to Remote 2 and via wired Ports to DMZ2
3. Remote 2 receives the ARP via it's secondary tunnel group member tunnel and forwards it back to DMZ2 via the primary tunnel - In the meantime, DMZ2 receives the ARP on it's wired Ports and sends it out through both downstream GRE Tunnels.
4. Back to step 1

The command "no inter-tunnel-flooding" prevents the flooding between two GRE tunnels, however it is not fixing the problem.

As both DMZ1 and DMZ2 are linked via wired ports, DMZ2 would receive the ARP on the wired interface and "no inter tunnel flooding" would not work.

Is there any way to have a redundant L2 Uplink to the Central MDs?

Something is wrong with the configuration ... if tunnel-group is configured correctly on the remote controllers. If configured for tunnel-group correctly, the remote controllers should have a single tunnel active and not a tunnel to each DMZ gateway. We would need additional information on the tunnel-group configuration to understand why there are two tunnels from each Remote site to the DMZ gateways.

Hi Charlie,

from my understanding, Tunnel Groups do not prevent the tunnels from being active. It just forces all traffic towards the primary tunnel group connection. The second link is still up but not used as long as the primary tunnel is connected.

Let's simplify the diagram:

If we only have one remote MD and two DMZ MDs. There are two GRE tunnels from the remote MD towards the DMZ. Each DMZ MD terminates one Tunnel.

Config Remote MD:

interface tunnel 1
tunnel source controller-ip
tunnel destination <IP-DMZ1>
tunnel mode gre 2
tunnel vlan <VLANID>
tunnel keepalive
tunnel keepalive 10 3
!
interface tunnel 2
tunnel source controller-ip
tunnel destination <IP-DMZ2>
tunnel mode gre 3
tunnel vlan <VLANID>
tunnel keepalive
tunnel keepalive 10 3
!
tunnel-group test
mode l2
tunnel 1
tunnel 2
!

Each DMZ MD has a tunnel configured towards the remote MD:

interface tunnel 1
tunnel source controller-ip
tunnel destination <IP-RemoteMD>
tunnel mode gre <2|3>
tunnel vlan <VLANID>
tunnel keepalive
tunnel keepalive 10 3
!

Both tunnels will come up. However the configuration of the Tunnel Group on the remote MD will stop the traffic only unidirectional. DMZ2 is still able to send traffic downstream which remote MD1 is receiving and processing.

Any broadcast message would create a loop in this setup

Thanks for the follow-up info. With this, is your issue resolved?

It's more a theoretical design question than a current problem. I'm just wondering if there is any use case for L2 Tunnel Groups as, it does not seem to work without loops. The only ways to get this loop free would be applying "no inter-tunnel-flooding", with the side effect of also blocking UBT connections from uplink tunnel connections or having private vlans configured at the upstream switch

In my opinion, we need to define a context to the use of the  Tunnel group solution. In several production networks I observed, DMZ1 and DMZ2 were geographically apart and they were not inter-connected by an L2 domain. For redundancy purposes, each DMZ had a pair of controllers with VRRP and the L2 GRE tunnel end point was the VIP.

That is where I have seen the tunnel-group design had worked pretty well.

The above design will have issues as highlighted in the thread. I would not recommend it for production.

Hello,

I thought many times at the same setup since I have exactly the scenario where I want to use this configuration....

I have 2 customers who are working together and still seperatly. So they have each their own setup and vlans, but because they are working together, they want to have their own SSID broadcasted on the network of the other, but still being in the end on their own L2 of their network.

So for customer A we have vlan 400 for example and customer B we have vlan 500 for example, they have a site to site VPN between 2 firewalls and then they don't want the vlan of the other on the wired network, so we used a GRE tunnel to pass the vlans 400 and 500 but I am in the same situation that I can't configure this setup without creating loops.... so for now just to have it working, I created standby tunnels which are admin down and where a manual intervention is needed if one of the controllers goes down.

Tunnel group is unpredictable where the tunnel will end up active, so I will have loops if configured this way.