Meraki

jdsilva · ‎Apr 8 2020

255.255.255.255/32 doesn't match 155.231.231.1.

jdsilva · ‎Apr 8 2020

Is that the actual static route you are using? That doesn't make any sense, and it certainly doesn't match what you are trying to ping. What exactly are you trying to do here?

jdsilva · ‎Apr 7 2020

It has a use when you look at a larger, broader rule set. Consider that you have a subnet that you want to create an exception from the global policy for, but for some reason you have a single host in that subnet that you do want to follow the global policy. You'd create the rule for that single host to use the global policy, and then create the rule for the subnet to use the exception.

jdsilva · ‎Apr 7 2020

@GIdenJoe wrote: For HA MX'es don't forget your WAN1 and WAN2 on both appliances need to connect to the same respective upstream ISP circuits. So you'll need to have one ISP come in building 1 and connect that one first on the switch there on an external VLAN and then have two ports connecting to both the WAN1's of the MX'es, so the third link will also be going over the fiberlink. And then the reverse of ISP2. That one will connect first to switch 2 and then back up to the MX'es WAN2. Only if you need to use a VIP. You don't need to do this if you just use the MX IP's.

jdsilva · ‎Apr 7 2020

Yes, you can do this. Just make sure the MX's have a L2 connection between them and this will work. And I'm sure you've got this covered, but if you're doing SX then make sure you have OM3/4 for your fibre run. SX on OM1/2 doesn't support that distance.

jdsilva · ‎Apr 6 2020

OMG, a non-all star cracked the top four! Damn fine work there @DarrenOC !

jdsilva · ‎Apr 3 2020

Woohoo! My example was meant as pseudocode since I didn't have any idea what a null character would be in whatever language that actually is 🙂

jdsilva · ‎Apr 3 2020

I've not used the code you're referring to before, and honestly I only really know a bit of python, but it seems to me that if you were to blank out the secret before you do anything else with the data tat should do the trick? @Mikanator wrote: // Check secret and store event const SECRET = "xxx123"; if(body.sharedSecret == SECRET){ body.sharedSecret = <NULL> <----- Blank secret from data PD.emitCEFEvents([cef_event]); }

jdsilva · ‎Apr 3 2020

SImply put, your only option is PoE. The MV72 does not have any other power input other than power supplied via the Ethernet port. That said, how you get PoE to the camera is up to you. You can use PoE supplied directly off a switch, or you can insert a PoE injector into the mix, and that injector can be powered by any number of methods depending on the model of injector you use.

jdsilva · ‎Apr 1 2020

Hey @SobyKuruvilla , Unfortunately, you can neither convert a RJ45 port to be used for the WAN, or set up a port-channel as the MX does not support LACP. Your only option to get 2Gbps is to use an SFP+ module 😞

jdsilva · ‎Mar 31 2020

Give this a go: https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

jdsilva · ‎Mar 30 2020

There's no functionality to do this within Meraki. You'd need an external <something> to accomplish this.

jdsilva · ‎Mar 30 2020

Frick... I changed my answer on one question and it bit me. The other I legitimately got wrong 😞

jdsilva · ‎Mar 30 2020

Configs belong to a network, not to a device. If you remove a device from a network it does not continue to operate with the config of the network. Removing a device from a network does effectively remove all config from it.

jdsilva · ‎Mar 29 2020

Yes, it does fail over immediately, though I'm not seeing that in any docs.

jdsilva · ‎Mar 27 2020

Did you look at this feature: https://documentation.meraki.com/MX/Site-to-site_VPN/Using_Site-to-site_VPN_Translation That might do what you want?

jdsilva · ‎Mar 25 2020

Oh, sorry @colinster ! My solution is just a repeat of your solution, just on one line. I like the way you think!

jdsilva · ‎Mar 25 2020

@trunolimit wrote: wouldn't this block all access on the LAN? even access to the default gateway? Nope. You cannot block, even with an explicit dedicated rule, traffic to and from the MX IP address itself. Intra-subnet traffic, i.e. between hosts on the same VLAN, does not transit the MX, and therefore it cannot block it.

jdsilva · ‎Mar 25 2020

The RADIUS Access-Request will have the IP of the Meraki device (NAS IP Address) in it. Could you not classify "Meraki clients" by any client where the NAS is a known Meraki device?

jdsilva · ‎Mar 25 2020

I humbly submit the following as my solution to this problem: The parts that are cut off are "10.0.0.0/8,192.168.0.0/16" in both the Source and Destination fields. This single line ACL will prevent all of your subnets from talking to each other, while allowing all your subnets to talk to the Internet.

jdsilva · ‎Mar 25 2020

65535? Seriously though, I've never seen a limit anywhere.

jdsilva · ‎Mar 24 2020

Gotta get me some of those socks!

jdsilva · ‎Mar 24 2020

Hey @Herixon. I would guess that it is related to that link. What I would think is happening is that the STP BPDU's are getting lost in transit on that link, so SW2 is actually transitioning to root because it stops hearing BPDU's from SW1. When SW2's port is designated it thinks it is the root. When its port is root then it agrees that SW1 is the root. If there's no other devices between those two switches then I would certainly look at the components of that link. SFP's, patch cables, the fibre run itself... If you have a tester that's a good place to start, Swapping the modules (one at a time to isolate one as the problem if it is) is another good option.

jdsilva · ‎Mar 20 2020

Oh! I just realized, you can match the returned users' IPv4 address against your client VPN address range! That'll tell you for sure if they're local or remote.

jdsilva · ‎Mar 20 2020

@Paul_Jefferies , The closest thing I see is this: https://api.meraki.com/api_docs/v0#list-the-clients-that-have-used-this-network-in-the-timespan But when I just tried pulling the data from there it would seem that there's no specific field that identifies the client as a VPN client, even though this same data in the Dashboard does show a VPN icon beside the user... So that's lame. You might still be able to use this endpoint if you're not doing any other authentication on your network. If you're not, then the "user" field will always be blank for non-VPN users, and VPN users will have the user field populated. If you can use that to get all the VPN users then you can hit this endpoint: https://api.meraki.com/api_docs/v0#return-the-clients-daily-usage-history to get usage data.

About jdsilva

jdsilva

Community Record

Badges