Wireless Access

Hi,

 

I have a local controller setup that terminates tunneled-nodes on a VLAN 200.  This same controller has a GRE tunnel to another controller in the DMZ that carries that VLAN to eliminate termination of the guest traffic internally.  All DHCP and NAT functionality is done by the controller in the DMZ, with the local controller serving as the authentication/captive portal device.

 

What I am seeing is when the tunneled node comes up, it gets the appropriate user role, gets an IP from the DHCP but can't communicate to the outside world.  Troubleshooting reveals that my device is not getting ARP replies from the default gateway.

 

I have tunnel-loop-prevention enabled, but even disabling this doesn't seem to matter.

Garry,

So this is your topology?

 

Client ------- Mobility Access Switch -------TN------ Controller1 -------- GRE ------- Controller2-------- Internet

 

And the DG is on Controller2 in addition to being the DHCP server and NAT to the Internet?

 

Can you share the user-role you have defined on Controller 1? Is the GRE trusted or untrusted between Controller1 and 2? And once you get an IP, you just see your client doing ARP requests over and over? If you just make the user-role an allow all for testing purposes, do you see a difference?

 

Best regards,

 

Madani

Yes, that is correct. The role user gets is authenticated which has all the default permissions. The only modification is redirect to a tunnel-group for allowall.

Just to clarify, the same controller terminates CAPs with a VAP that uses the same auth profile that is attached as wired to the incoming VLAN. And this setup works flawlessly.

Also to note, once the client receives an ARP-R either because it saw a reply to someone else's ARP-Q or a grat-arp, everything starts working wonders. Thus, I doubt it's relevant to the user role. It seems that the controller is trying to be too smart about broadcast propagation from tunnel-node, but excludes the conversion logic that it applies to the VAP.

Thanks.



Sent with Good (www.good.com)

Garry,

On Controller1, the one terminating the TNs, is there an IP interface at all on that VLAN? One long shot is to turn on "ip local-proxy-arp".

 

If that doesn't work, I'd recommend a TAC case. I've never come across a topology like yours for TN so it would be best for TAC to mock this up and troubleshoot.

 

Best regards,

 

Madani

Hi Madani,

 

Thanks for the suggestion.  Though, I am a bit confused why would proxy-arp on the local SVI would matter.  The VLAN is stretched, effectively from the TN to the DMZ controller.  The only reason why a controller in the middle even has an SVI is to be able to land captive portal onto it.  I've explictely disabled routing on that interface.  

 

Last time I checked, proxy-arp is used to obfuscate L3 topologies, whereas all I need is to get a controller to forward ARP packets which are on the same L2.

Garry,

As I said, it is a long shot as it's the only knob I've ever had to use especially when you turn on tunnel loop prevention to address problems related to ARP. You did say enabling/disabling tunnel loop prevention didn't seem to make any difference but again it was the only knob that I could think of trying.

 

I would go down the TAC route. The MAS is pretty clueless in this situation as all the control is happening at the controller so it is something going wrong up stream.

 

Best regards,

 

Madani

Hi Madani, Thanks for the suggestion. I was able to make this work. It required two things: I had to enable "bcmc-optimization" on the VLAN interface and "no tunnel-loop-prevention". Hopefully, this will help someone in the future.

Garry,

So was "bcmc-optimation" on the TN Controller or your Gateway Controller. I assume no tunnel-loop-prevention was on the TN Controller. Eitherway, glad you got it working and now this is saved in the Community for future users.

 

Best regards,

 

Madani

Madani,

The bcmc-optimization had to be enabled on the SVI of the TN controller.  Same is true for tunnel-loop-prevention.

 

Thanks.