locked
Moving phones to dedicated voice VLAN has made them slow to sign in RRS feed

  • Question

  • Background:
    - I had a working deployment of Lync, on a non-segmented voice and data network. I only rolled out three test phones, but it was all working (I even got certificates working).

    In order to follow good practice (and be able to support a larger number of devices), I've gone with convention and created a voice VLAN (a VID of 170, as the IP range is 192.168.170.x)

    PCs are in the IP range 192.168.169.x (255.255.255.0), and these devices physically plug in to the PC port on the phones (Aastra 6725). The phone then plugs into the power over ethernet port in the (untagged on the data network and tagged on the voice network (VLAN170)).

    My client device switches are layer 2 managed power over ethernet (HP Procurve 2520G-24). These then plug in to my core switch (also layer 2 managed - HP Procurve 2810G-24). The gateway on my network is a Sonicwall NSA3500, which is layer 3 aware, and uses IP helper to forward DHCP requests from the voice network (Aastra 6725 devices) to the DHCP server on the data network (Windows 2008 R2, configured to serve multiple scopes).

    The IP helper and DHCP work well together, and I can give phones a reserved IP address in the 192.168.170.x range (mac address reservation).

    The problem is that now my phones are reticent to sign in - they take far longer than they did to find the Lync server and authenticate. They do sign in eventually, and stay signed in for say 10-15 minutes at a sign, and then decide to re-sign in.

    I'd welcome any pointers on where I should be looking to speed up the signing in process, and ensure that phones stay signed in.

    Many thanks,

    Nick.

    Tuesday, March 22, 2011 10:23 PM

All replies

  • Sign in process can be delayed due to many different factors:

    * duplicate DNS entries e.g. CNAME, A
    * HLB configurtion
    * Certificate CRL checks
    * VLAN configuration in terms of switch firmware

    I would also run Snooper logs on the FE server, Look into event logs on the FE and client machines and run network trace while the login process is running.

    HTH

    Jim

    Wednesday, March 23, 2011 1:38 AM
  • Update:

    Jim - thanks for the pointers. I've done a lot of packet monitoring since, and the current position is this.

    The wireshark entries have been very interesting, particularly where DNS entries are tried in sequence, so I've been able to add some missing A records.

    Confirmation: if I take the VLAN tagging off the phone port, and let the phone pick up an address in the PC/server subnet (192.168.169.x), the phone signs in very quickly (sub 8 seconds), and stays signed in.

    When I leave the phone in a tagged phone port, here's the sequence of events (all of which work reliably, and might hopefully help someone else out):

    - Aastra 6725 phone broadcasts an LLDP-MED discovery packet
    - It receives a reply from HP Procurve 2520G-PoE switch that VLAN gbvoice (with VID of 170) is configured for voice traffic
    - The phone then sends out a full DHCP broadcast (255.255.255.255) requesting an address
    - The HP 2520G is connected (via a trunk, allowing untagged DEFAULT_VLAN traffic, and tagged gbvoice traffic) to an HP Procurve 2810G
    - The Sonicwall NSA 3500 firewall (layer 3 aware) is configured as the default gateway (192.168.169.254)
    - This packet retains its 802.1q VLAN tag of VID 170, when it's passed up to the Sonicwall's LAN port (X0).
    - The Sonicwall has a virtual subinterface (X0:V170), listening out for traffic with VID 170, and uses an IP helper policy to forward DHCP requests to a specific DHCP server: 192.168.169.21
    - The IP helper packet sends the request as the IP address of the virtual interface (192.168.170.254), and puts the Mac address of the phone in its relay.
    - The DHCP server (Windows Server 2008 R2), is configured to serve two scopes: 192.168.169.x, and 192.168.170.x, and assigns addresses based on Mac-address.
    - The DHCP server replies with an IP address for the phone in the correct scope base on the Mac address (e.g. 192.168.170.1).

    Then the phone gives the option to sign in (either through USB connection or by entering an extension number).

    I wonder if anyone could throw any light on what happens next - the wireshark entries are a little odd.
    I see at least 2 (sometimes 6, but always in pairs) entries:
    - A subnet broadcast from the phone (192.168.170.1) to 192.168.170.255 for TIME.NIST.GOV, then to my pool FQDN, neither of which can be resolved (the firewall drops the packets)
    - After an indeterminate amount of time (can be 20 seconds, but more usually 2-3 minutes), there's then a full broadcast (255.255.255.255), and the DHCP server responds, and sign-in continues as normal.
    - The "Connecting to Lync" stage can be quick or slow, dependent on its mood.

    Among the many things I've tried:
    - A NETBIOS IP helper policy from 192.168.170.x to 192.168.169.x subnet
    - Adding a WINS server to the DHCP and DNS server, and populating the WINS entry in the DHCP scope options.
    - Updating the phones to the CU1 firmware level.
    - Rebooting the DHCP server, DNS server.
    - Putting static entries into the ARP cache, as the Sonicwall lets ARP records expire after 10 minutes.

    To sum up, my questions are:
    - If I separate my voice and data traffic with VLANs, how do the phones communicate with the Media gateway, Lync and Exchange (all on the 192.168.169.x PC/server network)?
    - Is there a need for NETBIOS and / or WINS when it comes to Lync phones?

    Many thanks,
    Nick.
    Monday, March 28, 2011 7:00 PM