Wired guest

Unanswered Question
Jan 17th, 2008

Respected members of this community... :) I need help.

The last couple of days i spend implementing unified wireless at a customers site.

We used the latest versions of the controller and WCS software.

This new software offers a new feature, wired guest.

Since we already implemented 802.1x with a guest VLAN on the wired network last year, we wanted to offer the guest access functionality on the wired LAN as well.

So first we implemented wireless guest access, which worked fairly quickly.

Then we added another interface on the controllers, which matched the already existing wired guest VLAN. First we wanted to use that VLAN for wireless guests as well as wired, but we found out that is not possible (so we created a new wireless guest VLAN). Then we added a new WLAN wich we marked for wired guest.

Anyway, we followed the documentation and...could not get it to work.

The network is a layer 3 routed network with 40 or so VLANs. The controllers are connected to the core switch (with nicely configured trunks), which does all the routing.

DHCP is the first thing that didn't work. The interfaces we created on the controllers have the guest lan checkbox checked, ingress interface is the guest VLAN, egress interface is the mngt interface.

The DHCP relay function did not work.

DHCP will work with IP-helper configured on the VLAN interface on the core router, but this al goes outside of the controllers.

This is by the way the major thing i do not understand. With wireless, all traffic goes via de controller through the LWAPP tunel. But with wired, my layer 2 VLAN ends on the core switch, not on the controller.

So what should the default gateway be for that VLAN? The interface VLAN of the coreswitch or one of the controller IP adresses?

Traffic should be directed to the controllers (i guess?) to enable them to catch HTTP and send the redirect to the webauth page.

But if you set the default gateway to the controllers, DNS does not work because the controllers do not forward traffic untill after authentication, but for this to work, you need DNS for the client to start the HTTP session.

Is there anyone out there who has this working, including DHCP?

The customers network is flexible, we can build almost anything we want there, so iw we need to change something, we can.

Wireless guest was no problem at all, and de data WLAN, including 802.1x, auth on AD and dynamic VLAN assignment worked perfectly. So we did get something to work actually... :)

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
ankbhasi Thu, 01/17/2008 - 00:47

Hi Marcel,

While deploying wired guest access we have to make sure that wired guest which is on some pacrticular switch that vlan is only allowed between that switch and the controller and the wired guest should always be on layer 2 switch.

Something like this

Wired guest--L2 switch--Controller--L3 switch

So basically lets say your wired guest vlan on l2 switc his 500 so only vlan 500 should be allowed from that L2 switch and controller and there should be no l3 interface for vlan 500. It is always recommended to have wired guets on l2 switch and then a controller. Once controller performs vlan mapping it will go out of the network with new mapped vlan.

Hope I am able to explain.



koksm Thu, 01/17/2008 - 00:54

Hi Ankur,

I actually tried this.

The client is on a L2 switch (2960), which is connected to the corewitch via fiber/trunk. The coreswitch is the only routing switch.

The VLAN in this case is VLAN100.

I did remove interface VLAN100 from the coreswitch to disable L3 on the core for this VLAN. But, since i have two controllers in this VLAN, which address should be de DG then, that of the anchor controller?

By the way, could not get DHCP to work in this setup. Whatever i tried, no DHCP.

(we are using a microsoft DHCP server)

Any thoughts on this?

ankbhasi Thu, 01/17/2008 - 01:11

Hi Marcel,

So vlan 100 is only allowed between l2 switch and core switch and the from core switch to controller correct?

Also to which vlan it is getting mapped? Can you sniff the port on switch connected to controller and see if the packets which are coming are getting with what tag and when going out with what tag? As of now can you assign a static ip address in the subnet to the vlan which you are mapping just to see the data path is correct? I believe the data path is wrong as is the reason even DHCP is not working.



koksm Thu, 01/17/2008 - 01:44

Yes, this is correct.

This interface is configured as ingress interface, and the egress interface is currently the mngt interface, but i have tried several other ones. DHCP did not work.

We did not try using a static address on the client, but this is something we can try ofcourse as well as sniffing the actual traffic.

But since i followed documentation i was under the impression that it should work and i did something wrong. So i am trying to understand how it works. :)

jafrazie Thu, 01/17/2008 - 10:02

Does this help?


Also keep in mind that the clients and the controller needs L2 adjacency (i.e. the Guest-VLANs would need to be trunked directly to the controller where you define the Guest-WLAN).

I assume you have already deployed an anchor controller for wireless Guest traffic. So, the idea is to leverage the same EoIP tunnel infrastructure also for wired guest traffic. DHCP/DNS traffic should be blindly tunneled across this infrastructure, so your network services should be deployed in the anchor controller location (i.e. DMZ). Keep in mind again, that this design implements a logical L2 connection from the endpoints to the anchor controller.

Hope this helps,

koksm Thu, 01/17/2008 - 23:15

Yes, L2 is in place end to end. Traffic from my wired guest clients is directed to the controller, there is nothing else in that VLAN.

Thanks for the link to the doc, i heard about it yesterday, this wil probebly help me a lot.


This Discussion



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode