Wireless Access

 View Only
  • 1.  MSM765 - Second egress VLAN not working

    Posted Dec 16, 2013 10:46 AM

    Hi,

     

    I am having trouble configuring an MSM765 for multiple VLAN egress.

     

    We have 2 VLANs, data (11) and guest (4). The wireless configuration for the Data VLAN is working without issue however I cannot get the wireless for the Guest VLAN to pick up an IP address from the DHCP server (I get an APIPA address) and if I manually set the address on a wireless client I am unable to ping/tracert the DHCP server.

     

    If I connect to an untagged VLAN 4 port on the 5412zl switch I get an IP address on VLAN4 and can ping/tracert the DHCP server without issue so the problem must be with the MSM765 configuration.

     

    In the controller config I have setup the network profile for VLAN 4 and tagged it on the LAN port (I have also tried the internet port which didn’t help). I have not setup an interface on VLAN4 (there is no interface for VLAN11) but if I do it can pick up a DHCP address.

     

    I have setup a VSC for the Guest wireless, set authentication on, ingress mapping to SSID, virtual access point and wireless mobility. No other options are set.

     

    Under the AP group I have bound the egress VLAN to 4 and sync’d the AP’s

     

    The topology is a little odd in that the DHCP server is hosted upstream by our parent company but since I can access VLAN4 from the switch I don’t think that’s relevant.

     

    I’ve read through a lot of HP documentation but it all seems to reference options (like tunnelling) that I’m not seeing on my screen (documentation for an older firmware version perhaps?)

     

    Appreciate any assistance.


    #DHCP


  • 2.  RE: MSM765 - Second egress VLAN not working

    Posted Dec 18, 2013 04:01 PM
    Hello. If you are using an external DHCP server for your guest wireless VSC and NOT using the DHCP in the controller itself, then you need to configure a couple specific settings on the controller itself and the VSC too.

    Mainly... from the controller -> Network -> Address Allocation, set DHCP Relay Agent as the option for DHCP services and then click Configure, and enable the Client Data Tunnel option (do NOT enable the LAN port option). Then for the primary server address, put in the IP address of your external DHCP server. Then enable the checkbox for Extend VSC to egress subnet.

    Now, under the VSC itself, enable the checkbox for DHCP relay agent, and choose the Forward to egress interface radio button.

    That's really all you need. Obviously routing needs to be setup properly at the switch level and in the controller's routing tables so it can GET to the external DHCP server while it's acting as a relay agent.




  • 3.  RE: MSM765 - Second egress VLAN not working

    Posted Dec 19, 2013 04:52 AM

    Thanks for the reply, unfortunately there are some issues with your suggestion.

     

    Firstly I am using the on board DHCP server to asign addresses to the AP's (which are on a separate VLAN just for the APs) so I cannot configure the relay options.

     

    Having said that the private SSID\VSC is obtaining DHCP addresses fron that VLAN fine without a relay agent configured.

     

    Relays for both VLANs are configured on the switch.

     

    Given that I am trying to egress the wireless traffic directly onto a VLAN that has an existing DHCP and is not traversing any other networks I was working on the premise that the relay wasn't required (which is the case with the private SSID/VSC)

     

    Finally I do not see either of the options you mention under the VSC configuration (there is VSC to VLAN binding under the AP group which is already set)

     

    Thanks



  • 4.  RE: MSM765 - Second egress VLAN not working

    Posted Dec 19, 2013 02:37 PM
    Hello.
    I guess I'm a little confused by your configuration overall. Why are your APs on a seperate VLAN by themselves (and what VLAN is it)? In the countless implementations I've done with MSM I've never had reason to APs put in their own seperate VLANs. In almost all cases, APs are left Untagged in the same VLAN as the switches or other infrastructure devices. So for example, if your switches and routers, etc are managed on the DEFAULT VLAN1, then it's easist to put APs in that same VLAN (as Untagged). The only time I've had APs outside of the of VLAN used for other infrastructure devices (again, switches, routers, etc.) is when the APs are connected back to the controller over Layer 3 (for example, the controller in Building-A manages APs that are in Building-A and also Building-C and Building-D).

    What is it you are trying to accomplish with your MSM product? I'm guessing you want to have TWO different wireless networks, 1) secured wireless (company owned devices, for example) and 2) guest wireless (for non-company owned devices). is that correct?



  • 5.  RE: MSM765 - Second egress VLAN not working

    Posted Dec 20, 2013 05:42 AM

    Hi,

     

    Unfortunately I have inherited the base configuration so I do not know why the APs were put on a separate VLAN (vlan 13)

     

    Yes I am trying to achieve 2 separate wireless networks. One connected to the business LAN (vlan1 - which is working correctly) and another for guest internet access (vlan 4).

     

    I duplicated the existing config with changes to authentication and encryption (none and none) and the egress VLAN number.



  • 6.  RE: MSM765 - Second egress VLAN not working

    Posted Dec 30, 2013 09:53 AM

    This is perhaps the most common implementation.

     

    I'd suggest that you go to http://h20565.www2.hp.com/portal/site/hpsc/public/psi/manualsResults/?lang=en&cc=us&sp4ts.oid=3963981, from there Setup and Install. You will find MSM Implementation guide for 5.4 FW. Even though the FW version is old, the guide is valid.

     

    This contains 5 example implementations. The PDF has over 1000 pages, but you only need to check ~20, the introductions to different solutions - the rest is step-by-step configuration instructions. You're likely to find a suitable solution for your network. Implement that, and fine-tune afterwards to your specific needs.