Meraki

jdsilva · ‎Jan 20 2020

Yeh I'm with @NolanHerring and I wouldn't think that power changing would drop clients, but I wouldn't bet money on it since I've never dived into that topic. Interesting though.

jdsilva · ‎Jan 17 2020

Hey @jsurles , Go to Security & SD-WAN > Firewall and change this setting: This will allow you to reach the local status page from a remote location. Just don't forget to change it back when you're done! 🙂

jdsilva · ‎Jan 16 2020

Hey @ScottPR , For web stuff going to www you would forward ports 80 and 443. For mail you would forward port 25 (for SMTP, wihch is the most likely port). You don't need to do any header based forwarding for this.

jdsilva · ‎Jan 15 2020

This should be the endpoint you want: https://dashboard.meraki.com/api_docs#update-the-policy-assigned-to-a-client-on-the-network

jdsilva · ‎Jan 15 2020

Yup, Nuage is using a 1.0/2.0 version system to describe their platform. I hear lots of promises on the 2.0... But I have yet to see an actual product. This doesn't really apply to other vendors though. If you really want to see hype then check out Gartner's SASE term.

jdsilva · ‎Jan 15 2020

Congrats and welcome to the new All Stars!

jdsilva · ‎Jan 15 2020

The only SD-WAN vendor I'm aware of doing L2 right now is Nuage. I wouldn't be surprised to see others add that in the future... I know the MEF70 spec explicitly puts L2 out of scope for the first iteration, but does state it may be added in the future.

jdsilva · ‎Jan 11 2020

@cmrThat's been updated. Routed mode is now supported: https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets And concentrator and passthru modes are really the same modes, so passthru does work. I think the problem here is what's already been called out. This is for VPN hubs only, spokes will not advertise routes. But I haven't tested this myself.

jdsilva · ‎Jan 7 2020

IMO rootguard is not appropriate here. For Meraki AP's you can set BPDUGuard on the port facing the AP as they don't send BPDU's and can be considered an end device.

jdsilva · ‎Jan 3 2020

Well deserved @TimBecker and @Greenberet ! And a stellar effort from @PhilipDAth @BrechtSchamp @Nash & @NolanHerring ! Awesome work everyone.

jdsilva · ‎Jan 3 2020

I don't think that's correct @BrechtSchamp . I am able to claim a device in an a different Org as long as I remove it from the network in the Org where it currently resides. As well, Meraki docs seems to indicate that as long as a device is not in a network it can be claimed by anyone. https://documentation.meraki.com/zGeneral_Administration/Inventory_and_Devices/Using_the_Organization_Inventory#Claiming_Devices

jdsilva · ‎Jan 2 2020

Just remove it from the network it's in. There's also an "unclaim" button under Organization > Inventory you can use.

jdsilva · ‎Dec 21 2019

@BrandonSis correct: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignment#NAT_Mode Wireless clients cannot use Layer 2 discovery protocols to find other devices on either the wired or wireless network.

jdsilva · ‎Dec 20 2019

I believe so, yup, You got 30 days and then you better pay the man 😉

jdsilva · ‎Dec 20 2019

Yes, if you end up in an expired license situation all of the devices in your Org will cease to function.

jdsilva · ‎Dec 12 2019

Just to add to @AjitKumar 's reply, each MX must have its own unique IP address to maintain a connection to the Meraki cloud. They cannot share one IP for this function.

jdsilva · ‎Dec 11 2019

Only what's available in the local status page. https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page Your other option is to call support. They can sometimes see stuff you cannot with regards to dashboard connectivity. The device may show offline but they mat still be able to access it and recover it.

jdsilva · ‎Dec 9 2019

Not that I've seen, no.

jdsilva · ‎Dec 9 2019

Oh, sorry, I misunderstood the question. Yes, they are normal.

jdsilva · ‎Dec 9 2019

Hey @jwwork , In RSTP, a Topology Change (TC) is generated when a non-edge port moves into the forwarding state. It's for this reason it's important to put BPDU Guard on your host facing ports as that marks them as "edge" so a flap won't generate a TC.

jdsilva · ‎Dec 7 2019

Hey @DukeAtreides , No, there's a hard dashboard limitation that you can only have one MX in a network (except of course for Warm Spare). You could do something where you have MX appliances in two networks, but both physically connect to the same switching infrastructure. We've done this in the past and had some VLANs go to one MX, and other VLANs to the second, with a few routes between them to complete connectivity, but this was far from an ideal set up. That said, I'll ask you the question I always ask when these sorts of questions come up here: Does it really matter? I know you are saying you have a 10gig service, but what are your users actually using? Is the problem that you're maxing out the capacity of the MX leading to dropped packets and poor user experience, or is the problem that you have a service that is well above what you're actually using? If it's the latter then my suggestion would be reduce your services to more appropriate level, and use it as an opportunity to save your business some money (and look good in the process).

jdsilva · ‎Dec 7 2019

It does look like me, doesn't it @BlakeRichardson ...

jdsilva · ‎Dec 5 2019

I don't think anyone is getting out that stain @NolanHerring put in that couch...

jdsilva · ‎Dec 3 2019

Nope, not at this time. Right now Internet flow preferences are src/dst IP/Port only 😞

jdsilva · ‎Dec 2 2019

Congrats to @kuni and @DexterLaBora ! And well done to the usual suspects 🙂

About jdsilva

jdsilva

Community Record

Badges