Is anyone else having issues with the MX250 and MX450 not sending out LLDP. It looks like its throwing off the entire topology off and the Dashboard analytics on traffic. I have an MX67 and that works great with the MS250 Switches. Bu the minute I hook up the MX250 or MX450 the topology is off.
Latest stable firmware 14.53. I found out that someone has opened a case in June about the same issue and the backend team is working on it. It only affects MX250 & MX450. They should make this a priority and fix it, it is really screwing up with the dashboard information. Can’t see the details for a client always says insufficient data. That’s only if the device is sitting on the MX.
@Iridium79 fixes for current models appear to be only going into the 15.x release now as 14.54 and 14.55 are only for end of sale models.
We have used 15.x for almost two years with no issues.
What's interesting is it looks at though there was an attempt to resolve this if you look at the release notes for firmware version 15.13.
@Iridium79 our 250s are on a network with Cisco IOS switches and no WiFi (data center) so no topology map, I'll see if the switches get any discovery protocol information from the 250s tomorrow and reply here.
@Iridium79 our MX250s are sending LLDP information as below, they are in single arm concentrator mode, no VLANs, and running 15.42, our other MXs (84s and 100s) are also sending LLDP in routed mode on the same firmware:
@cmrif you look at your dashboard, and click on a client you will see that the MX250 or MX450 is no where to be found on the path, most likely the first thing you will see is client and then switch but no MX unless you have an MX64/65 both wireless and none wireless or MX67/68 both versions.
@Iridium79 so is it perhaps a dashboard issue, I know that when I look at a list of APs they don't show the reboots for firmware upgrades, but if you go into each one the reboots are there. Totally unrelated to this case, but I can definitely see LLDP from the MX250, hence the comment.
Do you expect to see the MX here:
@Iridium79 crossed posts, sorry I see what you mean now! I have the same with MX100s in a full stack Meraki network (MS14.21 and MX15,42), but a second site with MS14.22 and MX16.7 seems to be okay now...
I upgraded the MX100s in the full stack Meraki network that was MS14.21 and MX15,42 so that it is now MS14.21 and MX16.7 and I think that it is now correct apart from missing the non-redundant links to the MXs. There is a root of network diamond, but the default gateway on that site for the switch management VLAN is a Sophos firewall... The top two diamonds are a Cisco IOS switch and a Cisco IOS router:
Unfortunately it did not change on my end. Upgraded MX250 to 16.7 and also the switches to 14.21 and still the MX250 is in the same location as before.
@BlakeRichardson I have a case opened for almost a year now and no update from the development team. Support has their hands tied as it is a development issue. Right now I’m on the latest stable firmware 15.42.1.
@Iridium79 what mode are your MXs in? As you see above, in concentrator mode we see LLDP information coming from the WAN port of the MX250s we have. I'm guessing you are in routed mode and don't see LLDP coming from the LAN ports?
@cmrthis is what I see:
it’s weird my MX is the EFWC. And the main switch is plugged directly into it but their is the box with not enough info box. Same goes for the desk switch that’s plugged into the MX250 which is the EFWC on the image.
Yup, we have a case in as well. We are also not getting LLDP information from our MS390s. We are on the latest beta firmware for both our switches and our MX250, and we still have the LLDP issue. I have it setup to get a check in on the progress every 2 weeks. It's an active problem they are still working on.
They keep updating me every two weeks. They have replicated it in their lab environment and are working on a fix. That's about all they can give me at the moment. But frankly, in most firewalls you don't get LLDP info. I think really our issue is that the topology displays completely wrong, and the clients may look like they are part of a switch that they aren't because of it. So it's really the way they seem to be interacting with the dashboard.
We are also working on our own internal sort of dashboard via APIs, so we don't even have to login to the Meraki Dashboard most days.
@LandrinLong you are lucky they haven’t updated my ticket unless I call in or ask for an update. The last word I got was that the development team won’t work on this issue and was offered to downgrade to an MX105, why would I downgrade. If an MX64 - 105 can create a perfect topology and show which clients are attached to what switch then it should also work on their big boy routers also. Part that gets me is how is Ubiquiti able to get this to work and Meraki a Cisco company can’t. It’s been over a year.
@Iridium79 , all you have to do is ask...that's all I did so that I can update my management and show proof that they are still working on it.
In all honesty, Meraki support staff are some of the best people I've worked with.
If you want to go to Ubiquiti then do it. If you don't like Meraki move on. They work very well for us.
@LandrinLong I def don’t want to go to Ubiquiti I was bringing that up as an example. I really want to stay with meraki. I’ll be honest the answer they gave me rubbed me the wrong way after investing a lot of money on this solution. If you can pm me what they sent you that will be great maybe I rubbed them the wrong way also and got that response.
Thank you. You have giving me some hope that it will be fixed. We are getting ready for a big deployment that’s going to have a bunch of switches. That’s why I’m concerned and need the LLDP fixed. I don’t want to click on a switch 1 and it telling x client is connected to it meanwhile it’s connected to switch 10.
I'm with you there. We had a new location stand up with full Meraki. (32 MS390 switches, an MS425 Agg switch, an MX250 soon to be 2, 33 MR56 APs).
It was kind of a test for us to see if we could replace most of our Cisco with Meraki. We just worked through a QoS/SMB file transfer issue that would determine if we go full Meraki throughout. That test was successful, only because the Meraki support keeps us up to date, and is more than willing to work with us at any point. So even if the product isn't 100% ready for prime time (which I do believe we are currently in that situation), I can still justify moving forward with them due to the support that we have received, and continue to receive.
I'm fairly excited for what the future holds for Meraki, especially with the new addition of the sensors and cameras. Just have faith, Meraki will take care of you.