DMZ Anchor DHCP Issue

Hello,
I recently configured a DMZ Anchor controller and both control and data paths are showing 'up'.  When a user connects the the WLAN they are receiving an IP address from the foreign controller interface rather than the DMZ anchor which is configured for an internal DHCP server.  I have the guest WLAN configured with the management interface which has the controller's IP as the DHCP server.
Any ideas?
Thank you,
Scott

Could you please try enabling DHCP Proxy on Anchor Controller:-
 Controller > Advanced > DHCP > Enable DHCP Proxy
When DHCP proxy is enabled on the Cisco WLC, the Cisco WLC unicasts DHCP requests from the client to the configured servers. Consequently, at least one DHCP server must be configured on either the interface associated with the WLAN or the WLAN itself.

Similar Messages

  • WLC 5508 HA Anchor DHCP issue

    Hi Cisco Support Community,
    I am currently notice some issues within my WiFi infrastructure.
    Our infrastructure is setup with a 8510 WLC high availability cluster (AP SSO) and a 5508 WLC high availability cluster (AP SSO) as mobility anchor within the DMZ zone.
    The issue I noticed is that if there is a switchover on the 5508 WLC high availability cluster the users wont be able to receive a DHCP IP address.
    I already read some of the other threads regarding this topic. (About Mobility Anchor: Policy Manager State = DHCP_REQD) (DHCP Anchor controller problem.)
    But unfortunately I was unable to find any solution for my issue.
    We currently have three SSID´s with anchoring active and I have noticed that only the SSID´s with layer 3 security enabled are affected by this issue.
    The one SSID with PSK and MAC Auth are not affected by this issue.
    I already checked the configuration for the SSID´s between the main controller and the anchor controller the SSID´s are configured the same except the breakout interface.
    Even the described SSID with PSK and MAC Auth configured uses the same breakout interface as one of our layer 3 security enabled SSID´s.
    The configuration works so far only in case of failover the clients connected to one of the SSID´s with layer 3 security enabled are unable to receive a IP address by the DHCP server.
    I also performed some troubleshooting for the client on the anchor side.
    I added part oft the troubleshooting outputs as workingssid.txt and notworkingssid.txt to this thread.
    Maybe one of you guys have some advice for me to address the issue.
    Thanks for your support in advance
    With kind regards
    Benedikt

    As far as your L3 roaming is concerned ,Make sure your using latest and most stable firmware for WLC,
    Make sure Mobility group are same and config on WLCs before switchover happens. Make sure if DHCP is out the network then option 43 is set and you are able to get ip from both WLC manually and able to ping. Make sure AP-manager interface virtual ip is set. Make sure SSO is enabled on both controller.
    Check the following link also.
    https://supportforums.cisco.com/discussion/11662541/layer-3-roaming-and-dhcp
    Please confirm and mark it correct answer if your issue resolved.

  • Wierd DHCP Issue

    Hello All,
    I facing a very wierd  DHCP issue and would like to know your thoughts on it.
    I have my wired clients on vlan 1 and wireless cleints(eap-peap) on VLAN 2.
    We are facing an issue where multiple wired clients who were on access port vlan 1 are receiving IP address from wireless subnet(vlan2) -their DHCP server was the WLC virtual gateway IP address(1.1.1.1). This is causing an outage to few wired clients.
    The WLC trunk does not have vlan 1 allowed on its ports and all APs are in local mode and all on access vlan.
    I'm not entirely sure whats causing this, but only way I think this is possible is  that 'A Client' laptop has his network connections  bridged - his wired nic on VLAN 1 and wireless NIC on vlan 2, acting like a WGB, which is causing new wired clients(vlan1) DHCP broadcast request forwared through the bidge mode laptop to AP--> WLC. Do you think this is possible??
    Havent been able to identify which client is causing this issue yet.
    Has anyone faced a similar issue and anyway to block this through WLC/ACS policy?
    Thanks
    Jino

    Hi,
    Might we consider to make use of network monitor to take a look at the traffics for the 1.1.1.1 address?
    How to use Network Monitor to capture network traffic
    Download link here:
    Microsoft Network Monitor 3.4
    Best regards
    Michael Shao
    TechNet Community Support

  • Very weird dhcp issue

    We've started 're-vlanning' our main location here, breaking up depts
    into their own vlans.
    All seems ok so far, aside from a real doozy.
    For the IT vlan, we have one address that will not talk to our web
    content mgmt appliance. It's the 2nd address in our assignable pool,
    and it doesn't matter if it's dhcp or statically assigned, that address
    will not talk to that device.
    That is the *only* device that cannot be reached from this particular
    address in our dept vlan, every other one works fine.
    Any ideas on this?
    Stevo

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    > and it doesn't matter if it's dhcp or statically assigned, that
    > address
    So.... the title of this thread should actually be 'Very weird non-DHCP
    issue', since your own testing confirms this has nothing to do with DHCP?
    If you do a LAN trace on this machine as well as your web content
    management appliance do you see packets on either side? Both sides? If
    not on both sides but you do on the source (workstation) side see
    packets going out, then get LAN traces after each network device
    (switch, router, firewall, etc.) to see when the packets disappear.
    Feel free to post the LAN traces somewhere with descriptions of IPs,
    ports, and what you should be seeing, if you want to post them somewhere
    for review.
    Good luck.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.18 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
    iQIcBAEBAgAGBQJP4jFPAAoJEF+XTK08PnB55aMP/3Rg9u6LX6jFCXGYuex/oXdS
    NZ/liqfCgjyIcykWWeKGgdtm2I7JZOcFiG8YW2le55mcltvCL1VJW +1VGng4kZER
    0f4hjfyQ3CcQ6HIU3RM6VL5U2Pblb80MsEQe0qo0xgtPXipmjs i7Q0xIv9p0wT7A
    7JMkfgM9tfuI5Yro+BDLfSIkFWicKuKs1sKpNugKalPuyyRrzW IiznoalIKFshon
    a40ETLJVZmngBYfqfeZL9nPNsFlveFNXrDkdbl2WbaprsHtNnA NwZfVUIlc5kOCT
    MknY0GXof4/tk149OVCCLgjEzoRtTIZH0BJTHQwW7ANkWUUNYwi49+Mk46V0o awl
    oe1aA+NK9gl2bWXWLCtTro4ERSVMvkcI0OffytrfcBsqdCKg/g3QPMjV3kiVEULI
    xnSTsqFgOl2qO8qGaL6FJtk39ZBnCwqDPtmoNt93OK4hAhWBuA Xihc+kiQHrwkpO
    O04quZu8qQG6A6qwFDr+r+QqarFR3kielfvi7H6o5iLfZn/sDhvijGOAknJVctH8
    j8fezki9PMznkcT+of2Oe4T99K9fChN2WFSgUKdlpkYSjbkmjP fdbWloou+WBjCm
    7hHwnAbKPPgoN8aPPfw9rG9E+K/0YW2kt4wRu79BEDvF6eMv0UdDPE1qPuw1ttmm
    jg2zzMZDkgIG39A0P3u7
    =+fCy
    -----END PGP SIGNATURE-----

  • 6500 DHCP ISSUE

    Hello All,
    I am having an issue do DHCP from the 6500, and was hoping someone cant help. So, I tried to setup DHCP from the FWSM to the clients and this worked fine with giving out the IP, however the gateway for devices on the inside is supposed to be the 6500, not the FWSM, which is why the clinets wouldn't get out to the internet. Do I need to set up DHCP relay on the FWSM or does anyone know the way I can setup DHCP on the 6500 to give out IP's to the clients. Again just to reiterate, when I setup DHCP on the FWSM the clinets get the IP's but do not get out to the internet and when I setup DHCP on the 6500 the clients do not get an IP. Also I know tghis is a dhcp issue becasue when I assign a static address on the network the clients get out fine. Thanks in advance for the help!
    6500 Config
    ip dhcp pool TEST
       network 1.1.1.0 255.255.255.0
       default-router 1.1.1.1
       dns-server x.x.x.x y.y.y.y
    FWSM Config
    FWSM/TEST# show run
    interface Vlan3
    nameif outside9
    bridge-group 1
    security-level 0
    interface Vlan203
    nameif inside9
    bridge-group 1
    security-level 100
    interface BVI1
    ip address 1.1.1.4 255.255.255.0
    passwd 2KFQnbNIdI.2KYOU encrypted
    access-list INSIDE1_IN extended permit ip any any
    global (outside1) 1 x.x.x.x
    nat (inside1) 1 1.1.1.0 255.255.255.0
    access-group INSIDE1_IN in interface inside1
    route outside1 0.0.0.0 0.0.0.0 1.1.1.1 1
    FWSM/TEST#

    Hello Alain,
    Thanks for your quick response. I attached a Diagram of the layout. Just to let you know this is an FWSM with many virtual contexts and most including this one that are Transparent. I understand that I need an access-list on both ends to specifiy so the FWSM opens it, I am just having issue because the FWSM sees this as unsual traffic and the access-list needs to be on-point to work. Thank you for the response and I'll look forward to hearing back from you.

  • VRF and DHCP issue

    VRF and DHCP issue
    We have a 6500 ( 12.2 (33) SXH5 ) that has a VRF running for our guest network. On this 6500 resides the DHCP pool with a range defined for our guest network. We have a stack of 3750's (12.2 (46) SE) connected to the 6500 with a L3 connection. The 3750's have a local guest VLAN with its gateway defined in a VLAN interface. This VLAN on the 3750 has an IP helper address pointing to an IP within the VRF on the 6500. When debugging DHCP on the 6500, a request is received and sent back out. The client never receives this request.
    If a static IP is applied, the client is able to communicate anywhere within the VRF successfully (including pinging the IP within the helper-address. As many posts have pointed out - there is no VRF <name> under the ip dhcp pool <name> within the 6500. I am just wondering if anyone else has run into this and what their solution was.
    Thanks.

    Hi,
    I have tested the dhcp server and vrf on Cisco 3640 and it is working without VRF under the ip dhcp pool. Please ensure that you have configured routing for the dhcp-relay agent(VLAN facing dhcp client on 3750 in your case).

  • DHCP issue in VLAN

    I have a router on a stick setup i guess
    Multi-WAN doing a load balancing in pfSense
    5 Vlans setup on one interface and 1 DMZ setup on another interface
    Vlan 1 being used for Management w/o DHCP Server
    Vlan 24 for intranet Wifi w DHCP Server
    Vlan 30 for intranet w/o DHCP Server
    Vlan 50 for Public Wifi w DHCP Server
    Vlan 100 for Ubiquiti ToughSwitch and APs, w DHCP Server
    Now, the Vlan goes to a Cisco SG500X switch in port 1, trunk mode, Vlan 1UP, 24T, 30T, 50T, 100T
    port 35, trunk mode, Vlan 1T, 24T, 30T, 50T, 100UP, goes to Ubiquti ToughSwitch
    In Ubiquiti ToughSwitch, Vlan 1, 24, 30, 50 all tagged and 100 untagged
    ToughSwitch goes to UAPs with Vlan 24, 30, 50
    Now, my problem is, I'm not able to ping any of the APs
    I'm not able to SSH to any of the APs
    It's like being isolated
    In my firewall settings, I allowed all traffics but still no luck
    Can anyone give me some lights here please?
    THANKS!

    PLEASE USE THE IP ADDRESSES AS YOU WANT
    ########## Config on SG-500 ########################
    interface vlan 1
     ip address 192.168.5.2 255.255.255.0 (PFsense_FWAL_subnet)
     no ip address dhcp 
     ip dhcp relay enable 
     bridge multicast forward-all add gi1/1/1,gi1/1/44,gi2/1/36 
    interface vlan 24
     name "Internal Wifi" 
     ip address 192.168.3.1 255.255.255.0 (Wifi)
     ip dhcp relay enable 
     bridge multicast forward-all add gi1/1/44,gi2/1/36 
    interface vlan 30
     name DMZ 
     ip address 192.168.4.1 255.255.255.0 (DMZ)
     ip dhcp relay enable 
     bridge multicast forward-all add gi1/1/44,gi2/1/36 
    interface vlan 50
     name All 
     ip address 192.168.2.10 255.255.255.0 (ALL)
     bridge multicast forward-all add gi1/1/44,gi2/1/36 
    interface vlan 100
     name Management 
     ip address 192.168.6.1 255.255.255.0 (For AP)
     ip dhcp relay enable 
     bridge multicast forward-all add gi1/1/1,gi1/1/44,gi2/1/36 
    interface vlan 200
     name vMotion (Vmotion)
     ip address 192.168.7.1 255.255.255.0 (v
     bridge multicast forward-all add gi1/1/44,gi2/1/36 
    interface gigabitethernet1/1/1
    switchport mode access
    switchport access vlan 1
    description (Connect-to-pfsense-FWAL)
    interface gigabitethernet1/1/2
    switcport mode trunk
    switchport trunk allowed vlan add 24,30,100,200 
    description (Coonect-to-UBI-Switch)
    ip routing
    ip route 0.0.0.0 0.0.0.0 192.168.5.1 (PF-sense-IP)
    ############## Config on PFsense ######################
    Add routes for all the subnets 
    192.168.2.0 255.255.255.0 192.168.5.2-->(Switch IP)
    192.168.3.0 255.255.255.0 192.168.5.2-->(Switch IP)
    192.168.4.0 255.255.255.0 192.168.5.2-->(Switch IP)
    192.168.5.0 255.255.255.0 192.168.5.2-->(Switch IP)
    192.168.6.0 255.255.255.0 192.168.5.2-->(Switch IP)
    192.168.7.0 255.255.255.0 192.168.5.2-->(Switch IP)
    ############## Config on UBIswitch ####################
    interface gigabitethernet x/x/x
    switcport mode trunk
    switchport trunk allowed vlan add 24,30,100,200 
    description (Coonect-to-cisco-SG500)
    int gi x/x
    switchport mode access
    switchport access vlan 100
    description (Connect-APS)
    int gi x/x
    switchport mode access
    switchport access vlan 100
    description (Connect-APS)

  • DHCP issue with mobility anchor

    Hi Guys,
    I am having a bit of trouble to get the DHCP to work in my configuration. basically I have configured one SSID on two WLCs (running same version of code), I configured WLC 1 as anchor  controller and configured itself as mobility anchor (local), and on foreign controller (WLC2), I have configured the anchor as a mobility anchor. I have added both of the WLCs in each other's mobility list, however WLC1 and 2 are not in the same mobility group. clients are getting IP address through an external DHCP server.
    the problem is that when I used the management interface for the WLAN, I could get IP address through DHCP without any problem, however if I use another dynamic interface created for the SSID, then I could not get IP address anymore. I did another test with two WLCs configured in the same mobility group, then everythnig works fine. I have double checked my configuration for the dynamic interface but could not find anything wrong.
    so my question is
    is it possible to do auto anchoring configuration with two WLCs in different mobility group (different mobility group name), since based on my test management interface works,  but another dynamic interface did not work. in the configuration guide, it says: "you must add controllers to the mobility group member list before you can designate them as mobiolity anchors for a WLAN", does that mean the mobility group name has to be the same for both of the WLCs? if that's the case why does management interface worked?
    thanks in advance for you help.

    Hi Nicolas,
    thanks for your reply, i guess that's where the problem is - I could not ping the dynamic interface from the DHCP server. (eping and mping works fine)
    however I could ping the dynamic interface of the foreign controller (i have created another dynamic interface on the same subnet on the foreign controller, i understand it's not really necessary since we getting IP in the range defined on the anchor controller). the only difference between the two controllers is that the foreign controller enabled LAG, and only connected to the core swithc number 1, but the anchor controlelr is not (it has two connections to two core switches respectively).
    so does this mean I can not use this controller to be a anchor controller if it has two connections to two differnet switches? if yes is there any documentation on this point?
    Thanks very much for your help.

  • DMZ Anchor WLC setup for Wireless Guest Access

    I have the following setup.
    A DMZ WLC 4402 connected to firewall DMZ interface in 10.10.73.0/24 network.
    An Inside WLC 2106 connected to firewall Inside interface in 10.10.71.0/24 network.
    Both WLCs are running the same 4.2.176 code.
    DMZ WLC is anchor to itself and Inside WLC select the DMZ WLC as the anchor point.
    I have setup EoIP between DMZ and Inside WLCs successfully with both the control and data path both show as UP status. >> "show mobility anchor"
    The main issue: Clients cannot obtain IP addresses after connected to Guest SSID.
    1. Inside WLC, the guest WLAN ingress is 802.11b/g radio and egress port is set to management interface (EoIP) of type WLAN.
    What is the DMZ WLC setting? Is the ingress set to "802.11b/g" which does not make sense because the ingress is EoIP from Inside WLC?
    Or I still set as 802.11b/g? Same config as Inside WLC? I read from other threads suggested by Terry that the config must be the same for both WLCs.
    In the Inside WLC, I saw alot of pdu encapsulation errors for broadcast packets which is ffff.ffff.ffff xxxx which I think is the DHCP request from the connected Wireless clients not making through the EoIP tunnel. I have set static ip for the Wireless client but the packets cannot route through the EoIP tunnel to the far end.
    2. DHCP server is provided by DMZ WLC with the scope 10.10.76.0/24. In the Inside WLC, which DHCP server IP adddress to set to? DMZ WLC mgmt ip address? DMZ WLC, the DHCP server is also set to DMZ WLC mgmt ip?
    3. Layer 2 authentication. I read that DMZ WLC is supposed to be the DHCP server, Layer 2 or 3 authentication for Wireless Clients. However, it seems like Inside WLC is required to configure the Layer 2 authentication parameters and the DMZ WLC is set to providing the DHCP service?
    4. Lastly, anyone has done DMZ WLC sending the Wireless clients traffic to Bluecoat proxy server before hitting the Internet?
    Thanks.

    One of the biggest things is to make sure the wlan is configured exactly the same. The DMZ WLC ingress is the management and also is the egress port. You can create a dynamic interface on the DMZ WLC, but this way makes thing easier. The DMZ WLC should provide the dhcp, so the dhcp scope of course will be on the same subnet as the management of the DMZ WLC. The DHCP Server will be the ip address of the management interface of the DMZ WLC. The authentication also has to be configured exactly the same on the inside wlc and the DMZ wlc. Since you are pushing clients through the tunnel to the DMZ WLC, that is where clients will need to get their ip address, since that DMZ WLC has a network interface to the guest network. I haven't had luck when a proxy is involved, but I know there was a post a while ago on how to setup the proxy to allow the wlc to bypass the users initial dns resolution.

  • Guest Wireless Tunnelling - DHCP Issue

    Hi,
    I'm attempting to implement Guest Anchor tunnelling between two WLC's but I've run into an odd issue I cannot find a clear answer to.
    We have two 5508 WLC's, both Running 7.4.100.0.
    The Guest Anchor Controller obviously resides in a DMZ, it's functionality has been proven by connecting an AP directly to it, and connecting the the guest WLAN.
    The two controllers have been configured as Mobility Peers, the Mobility Tunnel between them is up (mping and eping both successful, status is up).
    The Guest WLAN has been replicated on both controllers, I have set the Mobility Anchor on the WLAN. The Guest Anchor has itself as the mobility anchor and the Internal Controller has the Guest Anchor set.
    DHCP is provided by the Guest Anchor's internal DHCP Server. DHCP Proxy is enabled on both Controllers, with the Option 82 format set to AP-MAC. Both Controllers WLAN settings are set to DHCP Server Override, pointed to the Management IP of the Guest Anchor and DHCP Addr. Assignment required.
    The problem I'm experiencing is with connecting clients through the Internal WLC. The Client Associates to the Internal WLC and obtains a lease from the Guest Anchor and connects to the network. A few seconds later the client is dessociated from the internal controller. On every subsequent connection attempt, the client does not recieve a response to it's DHCP Requests, and hence ends up with an apipa address.
    The Message logs on two controllers return the following errors:
    INTERNAL CONTROLLER:
    *apfReceiveTask: Jun 27 14:03:25.839: #APF-4-HANDOFF_END_RCVD: apf_mm.c:1626 Handoff end received in wrong role (peer Ip: 0.0.0.0, sender:GUEST_ANCHOR_IP, Role:0) for mobile Client_MAC
    GUEST ANCHOR CONTROLLER:
    *DHCP Server: Jun 27 14:03:14.466: #DHCP-4-REQIP_NOT_PRESENT: dhcpd.c:559 Received a packet without a requested ip!.
    Has anyone else seen similar behaviour? Does anyone have an ideas what might be causing this?
    Many Thanks,
    Paul

    Hi George,
    Thanks for the reply.
    The Guest WLAN on the Internal Controller is Anchored to the WLC in the DMZ. The Guest Anchor is anchored to itself.
    There are only two controllers in the configuration, so breaking off one of the Anchors isn't really an option.
    I have tested the Guest Anchor as a Standalone WLC by connecting an AP directly to it, in that configuration DHCP works as expected.

  • Wireless Anchor: DHCP Origination?

    I am struggling to figure out where the DHCP should originate and the documentation is not offering much insight.
    We are using the 4.x code on our controllers and want to establish employee access and guest user access. The DHCP for the employees is easy, but what device should issue DHCP to the guest users. We have a 4402 controller on the inside network and a controller in the DMZ that will be the anchor. Thanks in advance!

    Do I have to specify a DHCP override ip address on the internal WLC to point to the DMZ WLC's IP address, or is this handled automatically via the tunnel that is created between the two controllers?
    Would anything be different if the DMZ WLC was managing the DHCP addresses itself, rather than a DHCP server?
    Thanks in advance!

  • Wireless Guest Users DHCP issue

    Dear all
    We have 2 wism as well as Anchor controller
    Guest users are getting ip address from anchor controller.
    We had created DHCP scope on anchor controller itself.
    We had opened particular ports to communicate between guest controller and inside controller for EOIP tunneling to take place.
    Issue is that some times user is getting IP address in the range of AP management vlan.
    Do we require to open ports for bootpc and bootps as well or do we need to create dhcp scope in the switch.
    If any one has faced the above issue pls reply me at the earliest.
    Regards
    -Danish

    If the anchor goes down, or mobility fails, the user should never egress from the Foreign WLC (in my opinion). However, if you are saying that the user gets an IP from the MGMT Interface of the Foreign WLC (not the Anchor), then it is doing exactly what it shouldn't.
    What version of code is this?
    I've seen a lot of deployments implement a "dummy interface" on the Foreign WLC.  So a fake vlan/subnet is created on the WLC and mapped as the default interface for the Foreign's Guest WLAN.   In the event anchoring does fail and the client sticks to the foreign WLC this dummy interface would actually prevent the user from having network access.
    Are you seeing this often?

  • DMZ and DHCP ????

    Hi all: We have setup and DMZ off of our BM39 server. The
    only purpose of the DMZ is to allow a few clients relatively
    unencumbered internet access. We have had lots of problems
    with our BM proxy interfering with secure Citrix implemented
    by some partner we work with (Hospitals).
    We also have visiting review staff from Drug companies as we
    do many drug studies. These visitors often need internet
    access and up to this point I have been placing them on our
    internal subnet. But I am rethinking this and am
    considering moving our visitors to the DMZ instead.
    To do this I want to setup a DHCP server on our BM server
    (Done) to serve up addresses for the DMZ. However during
    testing the clients are not seeing the DHCP server. I
    suspect this is a filtering issue. I currently only have
    one set of filters for the DMZ which allows all traffic from
    the public interface to the DMZ and back.
    I am assuming the DHCP server needs a filter to allow
    traffic but I have no idea what that would look like. Can
    you help me out? Thanks, Chris.

    OK, got this working suing Craig's filter book _ glad to
    have purchased it.
    >>> On 9/21/2009 at 11:05 AM, in message
    <4AB75DE5.CE15.0032.0@N0_$pam.vrapc.com>,
    Chris<cmosentine@N0_$pam.vrapc.com> wrote:
    > Hi all: We have setup and DMZ off of our BM39 server.
    > The
    > only purpose of the DMZ is to allow a few clients
    > relatively
    > unencumbered internet access. We have had lots of
    > problems
    > with our BM proxy interfering with secure Citrix
    > implemented
    > by some partner we work with (Hospitals).
    >
    > We also have visiting review staff from Drug companies
    > as we
    > do many drug studies. These visitors often need
    > internet
    > access and up to this point I have been placing them on
    > our
    > internal subnet. But I am rethinking this and am
    > considering moving our visitors to the DMZ instead.
    >
    > To do this I want to setup a DHCP server on our BM
    > server
    > (Done) to serve up addresses for the DMZ. However during
    > testing the clients are not seeing the DHCP server. I
    > suspect this is a filtering issue. I currently only
    > have
    > one set of filters for the DMZ which allows all traffic
    > from
    > the public interface to the DMZ and back.
    >
    > I am assuming the DHCP server needs a filter to allow
    > traffic but I have no idea what that would look like.
    > Can
    > you help me out? Thanks, Chris.

  • Wireless WISM and 4402 DMZ controller mobility issue

    Hi all,
    I have a really weird wireless mobility issue I need help with. I have a Wism installed in our cat 6 with version 7.0.98.0 of software. I also have a 4402 controller in the DMZ acting as an anchor controller to terminate guest traffic, also running the same version of software. The mobility anchor is setup on 4 SSID's and most of the time I don't have an issue with it.
    However every week or so the data path or control path will randomly go down, so no guest traffic. Timers are configured as 10 seconds for the keep alive count and 20 seconds for the keep alive interval. I have found the following syslog information from our NMS. Not sure what these errors are and if its anything to do with this random mobility issue.
    Any thoughts ??

    A traceback is a device producing a trace of where it was in the software code when the problem occured.
    Most often it's when a function fails/crashes. Although that is not always true.
    If you have the syslog to the deepest level of debug, you will see harmless tracebacks (functions that returned no result but that might be expected). On higher level of debugs only "crashing" tracebacks are shown. In this case, the fact that you have mobility issues and tracebacks related to mobility is highly suspicious.
    TAC can decrypt the traceback hex and find the exact part of code that created the problem. From there, they can link it to an existing bug (or a new one maybe ?).
    Hope this clarifies !
    Nicolas
    ===
    Please rate answers that you find useful

  • DHCP issues for Wired Guest LAN

    Hi Everyone,
    I've a 1751 acting as a DHCP server for client PCs on a guest network A.B.8.x (using an Anchor controller) on the DMZ of my firewall. The 1751 reports the following
    Nov 30 15:35:45: DHCPD: DHCPDISCOVER received from client 0100.1708.37a3.55 through relay A.B.7.y.
    Nov 30 15:42:41: DHCPD: there is no address pool for A.B.7.y.
    I'd tied my guest vlan and corresponding DHCP scope on the router to A.B.8.x, but as A.B.7.x is the DHCP relay for the Anchor controller I don't understand why the DHCP server on the router is not doing what I expected it to.
    As ever any help will be appreciated.
    Many Thanks
    Scott

    Hi Cristian,
    After much pulling of hair and gnashing of teeth I have got it working - what was not clear to me, and it looks as though you've fallen into the same trap, is that the egress interface on the anchor controller (ie the management port) defines the addresses given to the clients. The dhcp scope on your server has to be from the same network as the address of the management interface (so my guest clients get a A.B.7.x address). In fact the ingress interface addresses have no bearing (as I'm sure I read somewhere afterwards!) on how the guest access operates and can (should?) be dummy addresses.
    I tried creating another vlan (with A.B.8.x) on the anchor controller and assigning that to the egress of the guest WLAN on the anchor and I could get A.B.8.x addresses from my DHCP server as I had planned, but, and this is a big but, web authentication just will not instigate. So it would seem that guest access is reliant on using the management interface as the egress on the anchor of the guest WLAN.
    I hope this is helpful,
    Regards
    Scott

Maybe you are looking for