Meraki

GIdenJoe · ‎Sep 7 2019

No problem. It's the one thing I find annoying in my country (Belgium) where ISP's only want to use their own routers and manage the config themselves you always lose end to end visibility and having to e-mail back and forth for information and having to rely on their insights.

GIdenJoe · ‎Sep 4 2019

Enterprise access points usually have a rogue AP feature. In your case you'll have access points with exactly the same SSID and on the same wired network. This will be seen as a true malicious rogue AP because someone could impersonate the SSID to do man in the middle attacks. Because in your case you just want extra connectivity you'll have to make sure to 'whitelist' the ubiquiti AP's on the Meraki side and do the same for the Meraki AP on the ubiquiti side. Also for good roaming you won't be able to use 802.11r because of two vendors so you WPA2-Personal as security option in this case.

GIdenJoe · ‎Sep 4 2019

- First thing to check is if the VLAN is configured correctly on both sides. Does the native VLAN match on BOTH sides? So you'll have to ask how they setup their trunk. If none of the VLANs are native from the provider you'll have to provide a dummy VLAN on your MX or set drop untagged traffic(usually dangerous if you run an HA pair because STP creates potential loops) - Second is of course viewing the DHCP configuration on your MX. - Then you could try to capture traffic on the dashboard (use capture filter (port 67 or port 68)). - Finally it could be a problem on the provider switch with DHCP snooping if enabled blocking your DHCP server.

GIdenJoe · ‎Aug 5 2019

I think you'll need to fetch all your devices and then look at the action batches so you can add all your entries in there and POST the action batch with all the renames. Maybe some good ol' text edit edit/replace will be required.

GIdenJoe · ‎Aug 4 2019

I find it strange you can even enable this feature on non-fiber ports. Normally UDLD is a feature only used between switchlinks to avoid unidirection communication causing spanning-tree to erroneously put a discarding port into designated forwarding due to no longer receiving bpdu's. This error state usually only exists if one fiber of the pair no longer transmits due to optics error or cable error. So if you want to enable this feature, only do it on trunks that connect two switches, since only switches support the protocol. Never enable it between switches and hosts/AP's/Firewalls unless they specifically support the feature and have it enabled. You should also start with alert mode ( = normal mode ) before you do aggressive mode which actually blocks a link in case of a unidirectional link.

GIdenJoe · ‎Jul 31 2019

@Kenneth , I haven't seen the possibility to do that. When configuring as spoke you need to define a hub of it doesn't take the config.

GIdenJoe · ‎Jul 31 2019

I think it rather has to do with the fact that the Meraki MX is not the hub site but rather a spoke. But in the VPN config you need to at least enable one MX as a hub and let every other MX connect to at least one hub. So you're forced to have that extra VPN connection even though you don't have the intention of using it. So it's rather an architectural issue because you can't really enable autoVPN unless support has a way to do this?

GIdenJoe · ‎Jul 29 2019

@Raj66, I found a problem with this behavior. What if you need to define WAN 2 as primary to have the bulk internet traffic leave that way but you want that time sensitive VPN traffic not only to leave your WAN1 MPLS and enter the other side via WAN1 MPLS but the other side also has WAN2 as primary for the same reason. I believe downlink saturation on WAN2 on the other side may very well starve your incoming delay and loss sensitive traffic. Is there a way to escalate this in Meraki to make this behavior configurable outside of using the non-feedback make a wish button?

GIdenJoe · ‎Jul 28 2019

I understand your argument for the simplicity. But would you want car manufacturers to take away the possibility to change your own tires if you have a flat somewhere on the road and you have to wait for a technician from them to get you back on the road? That the config usually should be simple OK, that's true. But for real troubleshooting you need an 'expert' mode. Like when building VPN's to non-meraki peers it would be a great plus to actually see what's going on because a packet capture can't always see everytning (like the contents of the 3rd exchange in main mode IKE). Cisco itself also introduces simplicity with DNA center but they still allow console access. Just saying...

GIdenJoe · ‎Jul 26 2019

This is exactly my main beef with Meraki that when real problems occur you only have a green led and a limited log to troubleshoot and no real control over the inner workings. Basically you have a steering wheel and a clutch. With Cisco “Classic” you have a cockpit with loads of buttons and switches. I wish they would have an expert mode on dashboard or a cli/API interpreter where you input commands or code and see direct results.

GIdenJoe · ‎Jul 22 2019

Ok, thanks again!

GIdenJoe · ‎Jul 20 2019

I do hope they will support MST at some in the future. In scenario’s where clients don’t want to pay for stacked switches in the core you have a single STP topo without the possibility to load balance VLANs across it.

GIdenJoe · ‎Jul 20 2019

If you really need to extend your L2 domain then you could expand you stack. If not make 2 distribution blocks andconnect them L3.

GIdenJoe · ‎Jul 20 2019

Great, thanks for that clarification. Follow up question: As you can see in the wireshark output there is actual traffic going from a private IP = MPLS WAN interface towards a public IP (91.x.x.x) = public internet WAN2 on the other MX. This seems way less common but does happen. The site is about the same as the other encapsulated packets which contain Windows RDP traffic. So there is traffic flowing back from the primary WAN towards the secondary WAN. Would you contribute that to keepalive traffic or does the MX keep track of flows inside the tunnel. So policy router traffic leaving WAN2 and entering WAN1 on the other side getting response over the same tunnel? I also assume that if WAN1-WAN1 tunnel goes down traffic can still exit WAN1 but go through tunnel towards WAN2?

GIdenJoe · ‎Jul 19 2019

Hey, over two years ago I used to work for a Belgian ISP as technician and they were on the forefront of IPv6 in pretty much entire Europe. They also use DHCP-PD for assigning prefixes to customers. They also had their own modem/routers that supported a nifty feature called hiërarchical prefix delegation. That means the ISP assigns a /56 prefix on the WAN side of that modem/router and that further could give out /60 prefixes to downstream routers so they could further subdivide those into /64 client networks. I believe for the global unicast addressing that support on all L3 devices for hiërarchical prefix delegation is crucial to deal with dynamic addressing. If Meraki is to support features like this in the future it is also important that just like on a cisco ISR you can define the subnet part of each of your subnets. So you dynamically get your global prefix from upstream and you put the subnet part in it which is fixed to your preference.

GIdenJoe · ‎Jul 19 2019

I have a question about how the uplink traffic is sent over SD-WAN. I'm hoping a Meraki employee could also give an insight on this. My example below is the following and I have simplified it to one spoke site and the hub. So we have MX'es on all sites with both uplinks in use. WAN1 is connected to an MPLS provider that provides an internet breakout on the MPLS so that autoVPN tunnels can be formed over the WAN1 uplinks. WAN2 is connected to the public internet. Not counting every SA that would be made for every direction and local subnet you should have 4 logical connections. From the hub WAN1 to WAN1 on the spoke, WAN1 hub to WAN2 spoke, WAN2 hub to WAN1 spoke and WAN2 hub to WAN2 spoke. When you define SD-WAN uplink policies you can choose your uplink based on traffic matching criteria. However this only selects your outgoing WAN interface. You have 2 logical tunnels from that uplink towards both WAN uplinks on the other side. So how does the MX handle this and is this configurable? As you can see, on the right part of the drawing, for traffic going from WAN1 to the other side on WAN2 it has to break out of the MPLS and route through the internet to the other side. Another question: outside of actually performing a packet capture like I did below, is there a way to see which logical tunnel the traffic takes? The uplink selection page only shows the selected uplink, and the uplink stats only shows latency, jitter, packet loss and MOS score. No traffic utilization and it's not always as clear which tunnel is always shown. You can clearly see there is actual traffic crossing from the private MPLS IP's to the public address of the other MX.

GIdenJoe · ‎Jun 4 2019

Yep I find this annoying if you have a customer with a multitude of sites (not small sites where you can use templates) and they want the same SSID's in every site...

GIdenJoe · ‎May 8 2019

If all critical devices in your org support 5GHz and your coverage meets the requirement on 5GHz, then go for it!

GIdenJoe · ‎May 8 2019

Is your client showing up as authenticated int the guest logins section?

GIdenJoe · ‎May 8 2019

If you want to keep management inline you'll have to use 10.0.0.1 IP as local IP on the switch and use 10.0.0.2 as default gw. Do mind if you have a switch stack you'll need to have a big enough subnet to support all stackmembers and the SVI of the stack. I never used an out of band solution for this since it gave me some headaches keeping the routing separate from the management.

GIdenJoe · ‎May 4 2019

The problem I have with split networks is that you can't click through on a client with problems from the MX to the switch or AP. So troubleshooting becomes a thing where you're going back and forth between networks. There is however the big problem with combined networks and a L3 switch that you can have duplicate traffic types from ghost clients because in combined networks you can only use track clients by MAC address.

GIdenJoe · ‎May 3 2019

Then please share how you set up your test and what TCP/UDP port you explicitly allowed outbound in a group policy that didn't allow return traffic.

GIdenJoe · ‎May 3 2019

Are you kidding me? I hope this is not the case because that would be plain silly. Applying a group policy that has L3 rules only enforces rules at the MX or MR depending what is closest to you, and those devices do it stateful, so why do you think it would be stateless, that makes absolutely no sense and that would break alot of designs.

GIdenJoe · ‎May 1 2019

Sorry, I'm used more to have MX84 appliances and the WAN's are numbered 1 and 2 instead of 4 and Internet (5). Just wanted to make my point that a packet capture on the dashboard always shows the correct MAC. Yes I did read the post wrong, I thought he meant the outgoing interface of the appliance, not the MAC's on the segments in front of the MX, sorry again 😉

GIdenJoe · ‎May 1 2019

To quickly know of the WAN interface try sending traffic through it and at the same time execute a capture using dashboard on the internet (WAN1 or 2 depending on where you send it). Just use the display you don't even need to use the pcap file option and you can see the mac address your mx uses. In normal circumstances without using VLANs on your WAN, the MAC address on WAN1 is always 1 higher than the system MAC and WAN2 is 2 higher. If using warm spare there is a virtual mac being used but the last part also related to the system mac part.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges