Ethernet Switching
Highlighted
Ethernet Switching

Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎01-23-2020 10:23 AM

I just swapped out three EX3200 running 14.1X53-D40.8 with four EX3400 running 18.2R3-S2.9 and for the most part everything went well. We did run into two phone types no longer working after the upgrade with a specific port setup, Aastra (Mitel) 6757i and Polycom VVX 410.

 

The relevant config on the old switch:

interfaces {
  ge-0/0/0 {
    unit 0 {
      family ethernet-switching {
        vlan {
          members SIP;
        }
      }
    }
  }
}
protocols {
  lldp {
    interface all;
  }
  lldp-med {
    interface all;
  }
}
ethernet-switching-options {
  voip {
    interface access-ports {
      vlan SIP;
      forwarding-class expedited-forwarding;
    }
  }
}
vlans {
  SIP {
    vlan-id 650;
  }
  LAN {
    vlan-id 600;
  }
}

 

On that config, old switch and firmware a packet capture shows the phone powering up, doing lldp, and then successfully performing DHCP tagged on vlan 650.

 

On the new config/firmware, the same phone powers up, does lldp and then tries DHCP tagged on vlan 650 but get's it's offer untagged and thus ignores it. That config:

interfaces {
  ge-0/0/0 {
    unit 0 {
      family ethernet-switching {
        vlan {
          members SIP;
        }
        storm-control default;
      }
    }
  }
}
protocols {
  lldp {
    interface all;
  }
  lldp-med {
    interface all;
  }
}
switch-options {
  voip {
    interface access-ports {
      vlan SIP;
      forwarding-class expedited-forwarding;
    }
  }
}
vlans {
  SIP {
    vlan-id 650;
  }
  LAN {
    vlan-id 600;
  }
}

 

If I set the port to any other vlan, say LAN than the problem phones behave as they did on the old setup, DHCP discover and offer are both tagged 650 and the phones operate normally. Is there an explanation for the change in behavior? For reference, Polycom SoundStation IP 5000 work on the new switch/firmware with the same config without issue.

6 REPLIES 6
Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎01-24-2020 12:46 AM

Is there a difference in the in the tagged/untagged frames sent by the EX switch towards the phone (working and non working) ?

Ideally the voice traffic should be tagged in both the direction irrespective of the version.

Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎01-24-2020 06:27 AM

When things are not working on the new switch/firmware the DHCP offer to the phone arrives untagged (and thus ignored by the phone).

Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎01-24-2020 03:23 PM

From all the description here you have discovered a pretty clear software bug.  Juniper calls these PR (problem Reports).

 

It sounds like you have all the necessary data in hand to report this in which is done via JTAC tickets.  Open a case and support will be able to reproduce the bug.  Confirm if this is a first report or a known PR.  And then get you a service release with the fix when it becomes available.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎04-10-2020 10:30 AM

I opened a case with JTac, they ended up spending a month labbing it in house, can replicate the behavior and today have decided that clearly I'm expecting the switch to somehow manipulate DHCP and thus there isn't actually a problem... I should instead talk to my DHCP vendor and closed the case.  I wish I was kidding.  I guess I get to try and bang the escalation drum now.

Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎04-13-2020 02:48 AM

Based on your data here I would agree an escalation is required.  Did they see in pcaps that the return packet is not being properly tagged for the vlan forward?

 

On what data are they basing the switch performing correctly?

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
Ethernet Switching

Re: Voice VLAN behavior change from EX3200 to EX3400 (14.1x53-D40.8 to 18.2R3-S2.9)

‎04-13-2020 07:45 AM

I have been following this thread from afar, but initial guess was that EX3400-P was not handing DHCP properly for IP Phones, then same basic situation should be there for all ELS-Based EX P switches (or T with external power) and there would be LOTS of Cases and Customer complaints, none of which I am aware of or see on any forums, blogs, etc.

 

@kurlon what I do not understand are 2 of your initial comments.  They are:

 

On that config, old switch and firmware a packet capture shows the phone powering up, doing lldp, and then successfully performing DHCP tagged on vlan 650.      Q: this offer is tagged by the switch?  With VLAN ID?

 

On the new config/firmware, the same phone powers up, does lldp and then tries DHCP tagged on vlan 650 but get's it's offer untagged and thus ignores it.      C: Looks like phone issue to me.

 

#1 The initial DHCP Discover is always an untagged broadcast for the L2 (Ethernet) MAC Destination Address.  It either gets to your DHCP server by flood in L2 VLAN, or is forwarded by some L3 device (to start with in same L2 VLAN) with DHCP-relay/etc configured.

 

Now if your IP Phones DHCP Discover is Tagged, the Phone must have a local VLAN configuration, otherwise how Phone know what VLAN ID in the tagged packet to use?  I believe this would/should be HIGHLY unusual.

 

#2 The eventual DHCP Offer to the end station is also Un-Tagged.  No matter if the DHCP Server (or DHCP-relay agent) response is L2 MAC Source Address.  If the DHCP Offer L2 MAC Destination Address, can either be Unicast or Broadcast back to the client (IP Phone).  This Offer packet will contain the VLAN ID the client should use via DHCP Option 43, which is a field in the DHCP Offer response to the Client.

 

Then Client sends a L2 MAC Destination Unicast (either direct to Server, or via L3 DHCP-Relay device) Request, and Server eventually ACKs.  The Switch (EX3200 or EX3400 or any ELS-EX) learns in what VLAN the destination MAC lives, via this request.  In general for IP Voice, this packet is now tagged by the Phone with VLAN ID it learned from Option 43, noted above.  The switch handles it like any other tagged ingress frame - strips the tag, and learns the VLAN ID, and forwards [only] with in that VLAN - either directed frame (knows L2 Destination MAC Address) or floods (Broadcast Unknown - BUM).  This creates a MAC-VLAN mapping for the Source L2 MAC Address, and the VLAN ID contained in the Tagged Frame.

 

From then on the Phone communication ingress to the switch is Tagged (with proper VLAN ID) and communication to the Phone is also Tagged with VLAN ID Tag associated with the MAC-VLAN ID mapping.

 

The Junos Access Interface setting of "voip" sets the Interface up to accept both Tagged and Untagged frames.  The Untagged Frames are associated with Interface-VLAN association (config).  For Tagged Frames the VLAN association is learned from reading the Tagged Header.  The Interface can only have 1 Untagged association, but multiple Tagged associations, but an External Source MAC needs to belong to one and only one Tagged VLAN [generally].

 

See this link for LOTS of more detailed information- https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP 

 

Especially see this section:

Phone Settings

  • Use dynamic IP address assignment via DHCP (mandatory!).
  • Set VLAN Discovery method to DHCP

SOAPBOX: I see lots of forum questions about Feature X or Y does not work.  This one is a perfect example, IMHO.  If the feature does not work for you, but no one else is complaining and it is a known "normal regular feature that a lot of people use", it is very (99+%?) likely to be something specific to your environment (config/operation/something external) vs the Switch and Junos.  At least that is IMHO.

 

@Kurlon - the specific IP Phones in question, were they also in use for EX3200 deploymemt?  From your problem statement I sort of 'guess' that there are other IP Phones that are working fine after EX3200 replacement by EX3400.  If true, why might you not think situation is more likely with how the IP Phones are operating vs the switch?

 

BTW, if you want, send the case number and I can try to look into what has been going on.  Have these phones, Mittel and Polycom, not being used for last 2 months?