About Pugmiester

JonH

Much respect to the all-stars!

MattPainter701

I've tried using an existing VNET with a new subnet, yet it gives an error on deployment. networkInterfaces/NWT-MXNic was not found. Please make sure that the referenced resource exists, and that both resources are in the same region. Yet they are all in the same region....

BlakeRichardson · ‎11-18-2019

@Pugmiester we run exactly what you are wanting multiple MX on the same ISP subnet with different LANS.

PhilipDAth · ‎11-11-2019

The built int "whitelist" policy can also be applied to a client to bypass all restrictions.

RJordan-CCS · ‎10-23-2019

Done. The magnet sculpture would look smashing next to my collection of hard drive magnets...

Pugmiester · ‎09-09-2019

Hi @PhilipDAth, I'll ask our server team to double check but there was nothing that jumped out last time. We do have the Symantec AV client installed on all of the DC's, all running the same policy but some happily respond and others don't, but not consistently. MX1 might get a response from DC1 but MX2 doesn't. I'm not 100% certain how to confirm the certificates but is one MX works and another doesn't, I would have thought the certificate was OK. I'm just finding it difficult to find a pattern to be able to poke something with a stick.

lucafabbri365 · ‎09-05-2019

Hello all, I got an official answer from sales representative: "Currently, Meraki products are not officially available or purchasable in Russia due to government regulation: they required Meraki datacenter being physically available in Russia, but currently, they aren't." There could be a workaround, but it isn't so flexible: buy a Meraki outside and deliver it to Russia (in some way). If a replacement would be needed (due to some damage, for example), then sent it back, replace it, and re-send. Bye, Luca

Pugmiester · ‎08-01-2019

That's the conclusion I was getting to as well. The good news is, we don't have to rip out the Checkpoint to get the MX's live so for a little extra breathing space I can leave the setup as it is initially so we can work out a solution with a little more breathing time.

Hussam-Bay · ‎07-12-2019

Also you can't configure IPSec vpn between two MX if the WAN ports have private IPs. The MX will not negotiate IPSec unless the port has internet connection, the port status will show failure until it gets internet connection. Hence, if you have two sites connected via MPLS then you can't have VPN between them since the WAN ports don't have internet connection.

hockeydude · ‎06-17-2019

Gateway for MX is IP of upstream router. 1:1 NAT Philip is talking about is for servers/workstations on LAN communicating to internet using upstream router's subnets. So... Pretend MX 10.0.0.2 talks to upstream router 10.0.0.1. Server on LAN has IP 192.168.0.100 which NATs to 10.0.0.100. From there setup rule on upstream router to NAT 10.0.0.100 to whatever subnet is available on WAN. Depending on your public IP block, you can give outbound an explicit IP which would be different from default gateway.

MeredithW · ‎06-03-2019

Congratulations to our contest winners, @Franzman and @nbentsendk! 👏 👏 👏 🎉

Pugmiester · ‎06-03-2019

Thanks @PhilipDAth, not a bad idea at all, especially if there's not a big difference in cost to begin with.

SoCalRacer · ‎05-28-2019

Might check your Cisco profile preferences.

Cmiller · ‎04-17-2019

correct

Pugmiester · ‎04-17-2019

Hi all. So, I logged a ticket with Meraki support and the upshot seems to be that the current mix of Meraki and Catalyst devices is preventing the network from being discovered correctly. I can understand that but I don't get why replacing Catalyst with Meraki hardware has made this particular area less visible to the topology view. Most odd. However, there's mention of LLDP which we don't currently run on the Catalyst devices so I think I'm going to enable it and see if that helps get a better picture of what's connected to what and I'll report back.

MeredithW · ‎03-07-2019

In recent community housekeeping efforts, we are started this new thread for introductions.

Pugmiester · ‎03-01-2019

When we quickly swapped in the boxes last night in place of the existing router, the master picked up the previous internet facing IP so as long as the working device does that I think we will be OK. It's clumsy but if it'll work for us then it will ave to do for now. As I mentioned in my reply to @PhilipDArh above, we should be able to get a secondary connection running for LAN4 so at least the spare MX has a permanent dashboard connection to pickup configuration changes.

MerakiDave · ‎02-06-2019

Agree with previous posts, you're in the Meraki green, no worries! Just wanted to add one thought. We have had customers with small stacks of 3 or 4 pieces of equipment like that right on top of one another, but NOT in an air-conditioned or even well ventilated room. For US$8 they purchased a USB flexible fan stick and plugged it into the USB port of the MX64, and coiled/pointed it to pass air between the equipment. Worked great, and the before/after was a difference of over 30 degrees F.

Pugmiester · ‎11-13-2018

We're on shard n145 but everything seems to be back to normal. We've not had issues previously, I think this is the first issue with dashboard access in the last couple of years.

Pugmiester · ‎10-31-2018

Hi @jdsilva Thanks for the pointer. I hadn't realised the best practice guide had been updated. I've stripped out the HA dedicated patch cable and together with dual connections from each MX to each switch, everything is looking rock solid. I think we have a winner.

Pugmiester · ‎07-06-2018

Thanks jdsilva, that was where I was heading. It's been a long week. 😞 Last night we rolled back to our old firewalls and disconnected the MX's completely from the LAN to be certain we could regain a stable connection for work being completed remotely over the weekend. Not 10 minutes after I finished, one of the links dropped again proving that the MX's have noting to do with the problem. I never believed they did but it was the only change I'd made. I've a solution in place for now using the interface IP addresses in place of the HSRP ones so we're stable but lacking failover. The business is happy with stable for now. I'll close off this question though as we're now 100% certain it's not Meraki related. Thanks everyone for your help pointing me in the right direction.

Pugmiester · ‎05-30-2018

Thanks Philip, I'll take a look.

Pugmiester · ‎05-15-2018

Thanks jwwork, There are a couple of areas out in the warehouse I've just remembered where we are relying on STP to manage redundant links, mainly because the switches are really low capacity with only a single Gig uplink so I couldn't build an Etherchannel with that and a 100Mbps link but thinking about it, the throughput is that low I could switch to a pair of 100Mbps links in Etherchannel and use the gig for a device connection and still have performance to spare, plus break the loop completely.

Pugmiester

Community Record

Badges

Re: Revealing the Meraki Community All-Stars!

Re: vMX and Azure VNET peering

Re: Multiple MX's in different networks but the same organisation on the sa...

Re: Bypass URL filtering for a single client IP address

Re: Time for a survey — and another chance to snag swag!

Re: Retrieving the LDAP list from AD is intermittent at best.

Re: Meraki in Russia?

Re: NAT from the DMZ onto the LAN

Re: MX Limitation

Re: Support for more than 2 WAN subnets on the WAN side

Re: [CONTEST CLOSED] Wi-Fi 6: tell us your hopes and dreams!

Re: Best practice to install remote MX's in HA

Re: Email update language selection

Re: Enabling multi factor authentication after admins are created

Re: Devices missing from the topology view

Re: Please introduce yourself

Re: PPPoE with a primary/standby pair of MX64's

Re: Standing MS and MX hardware on top of each other

Re: Dashboard Page Unavailable

Re: Hot standby MX64 LAN side failure not working as expected

Re: New MX firewalls seem to be affecting other routers on the LAN

Re: Recommendations - Connecting MX to Cisco 4500 resilliently

Re: Legacy network integration best practice