No announcement yet.
  • Filter
  • Time
  • Show
Clear All
new posts

  • Disabling LLDP-MED Thread

    I figured we should probably start a thread dedicated to how to disable LLDP-MED on switches given that recent boot/configuration behavior change on Shoretel phone firmware.


    clear lldp port tx-tlv all

    OR clear lldp-port tx-tlv ----- clear values: medcap, med-pol, med-loc, vlan-id

    Juniper (applies to JunOS based devices):

    set protocols lldp-med disable

    HP Procurve:

    [ no ] lldp config < port-list > medTlvEnable < medTlv >
    Disable network-policy medTlv

  • #2
    hey, Chris

    is there a minimum HP revision level for this? i.e., in my Procurves, all 4-5 years old, I don't see anything in 'show' or 'config' about lldp. am I simply missing it, or did it not appear until after a certian OS revision?


    • #3
      Originally posted by royb View Post
      hey, Chris

      is there a minimum HP revision level for this? i.e., in my Procurves, all 4-5 years old, I don't see anything in 'show' or 'config' about lldp. am I simply missing it, or did it not appear until after a certian OS revision?
      Yes, looks like it might be 10.5 or newer.


      • #4
        thanks much.

        on the same topic, from ShoreTel | Forums - LLPD-MED (Post-298407), Dieter Rencken writes:

        "I understand the frustration that this issue is causing to all involved. To get to the bottom of this please review the information below :

        The root cause of the problem appears to be that when LLDP is enabled on the phone and LLDP is enabled on the network switch and there is a misconfiguration of the network such that there is a duplex mismatch the phones will get into an endless reboot loop. The cause of this problem is not that LLDP is enabled, it is that there is a duplex mismatch; however, having LLDP enabled makes the phone aware of the mismatch and leads it to reboot. Having a duplex mismatch can happen when either the phone or the switch is configured for “auto-negotiate” while the other side is hard configured for full duplex – both sides should be configured for “auto-negotiate” or both should be configured for full duplex. When such a mismatch occurs the phone will generally appear to operate fine – occasionally packets will be dropped which can degrade voice quality or display painting performance; generally due to retransmission of MGCP and packet loss concealment on the RTP stream it won’t be noticed. To alleviate this problem the plan will be to modify the phone firmware to note the mismatch and report it on the LCD, but then continue to boot anyway. Next time you hear of this problem occurring, rather than turning off LLDP in the phone or the switch try adjusting the configuration of the phone or switch network interface to address the root cause. If you find an example where the endless reboot is happening and network configuration is not the cause, please let us know and include as much information as possible about the phone firmware level, the network switch model, and the configuration of the phone and the network switch.

        So rather than disabling LLDP please investigate this as described above. Thanks !"

        we're not on 9.x yet, but will be by spring, upgrading from 7.5. always good to hear about potential issues before they are discovered by surprise. this is good info, thanks for getting into it.


        • #5
          I appreciate and agree with the information above in as far as it goes. But I am largely a switch technician as well and have had several scenarios where the phone would throw this error as a result of LLDP-MED being on and there were no duplex mismatches on the entire network. (Confirmed with a Fluke network discovery tool). It seems that if the phones and the switches do not have LLDP-MED configured identically it throws the same error as if there were duplex mismatches. What shoreTel needs to do, which I have stated in this forum before, is to make LLDP a feature that can be controlled via FTP boot file rather than only at an individual phone level. (It also might have been a good idea to not turn it on by default)


          • #6
            It should be turned on by default because in theory the phone SHOULD ignore LLDP if not configure on data switch or if LLDP is configured incorrectly.


            • #7
              I don't know that I agree with Dieter (who is the product manager for the phones) because we have also experienced the same scenario where duplex is fine and LLDP-MED wasn't configured and the phones looped. Disabling LLDP-MED solves the problem. Based on previous experience with firmware changes, I can ABSOLUTELY see the null LLDP-MED values overwritting the phone's vlan id & tagging config with null values.

              We've left LLDP on in all cases because it is an extremely useful tool in larger environments.


              • #8
                Cisco 4500 series, IOS release 12.2+

                Have not confirmed this on my phones yet or what other network issues this creates. Just looking at it today and found it at the following URL: Catalyst 4500 Series Switch Software Configuration Guide, 12.2(46)SG - Configuring LLDP [Cisco Catalyst 4500 Series Switches] - Cisco Systems

                It can also be configured on an individual port basis for testing. See URL for more details.

                To disable LLDP globally

                configure terminal
                no lldp run

                To enable LLDP globally

                configure terminal
                lldp run


                • #9
                  LLDP MED on Nortel / Avaya ERS Switches

                  On the Nortel (or baystack if you prefer) infrastructure it seems that while LLDP-MED is turned on by default, none of the data is set to be accepted by default, this results in a scenario where the phone sees LLDP-MED as on and tries to send data, when the data is rejected the phone reboots (to try agian? or is this just a failure?). The solution is to turn on the data collection for the data ShoreTel is sending via LLDP-MED. I am still narrowing down what the minimum is that can be on in the switch and still have the phone come up. (I do not like to experiment too much once I get a system working and rarely have dedicated bench time)