Meraki

Pugmiester · ‎Apr 9 2020

Ironically, the setup we did in Azure to test came up almost straight away. Untangling the right options and getting things in the right NSG to start with is more of a challenge there and as you can't change the vMX appliance once it's deployed it meant we had to tear it down and rebuild it again but once we had that done it was up and running.

Pugmiester · ‎Apr 8 2020

Hi @JamesC_AB, It seems you were spot on. The update from Meraki overnight was that they changed something in the back-end of the dashboard and now it's all working without any changes on this end despite them being sure it was a firewall issue on our side. Anyway, we're up and running. Thanks all for the suggestions.

Pugmiester · ‎Apr 1 2020

Hi all, I must be missing something here because it just can't be this hard. The EC2 instance is up and running (using the Meraki setup guide - https://documentation.meraki.com/MX/Installation_Guides/vMX100_Setup_Guide_for_Amazon_AWS) and using the "customer data" from the authentication token. We can reach the appliance's public IP (we have a rule allowing port 80 inbound temporarily to troubleshoot) and it confirms internet access but no connection to the dashboard over port 7734. However, AWS flows confirm it's sending and receiving data from the dashboard over port 80 and port 7734 but it just will not phone home and show up in the dashboard at all. What have I missed?

Pugmiester · ‎Feb 26 2020

Thanks, I was thinking it might be the later and powering down the AP would be the way to go. It's certainly an absolute case of no WiFi being available. Time to start planning for the end of the work day I think.

Pugmiester · ‎Feb 26 2020

Hi all, We're having some really strange WiFi drop off / roaming issues on one of our sites (obviously, my site and none of the other 28 we have across Europe 😞 ) that appear completely random across different client manufactures, drivers versions, you name it. There's no pattern I can find to the disconnections so I'm going round and round in circles with it. However, one stand out difference we have with this particular building is a lot of AP's. We spammed the building with no wireless survey and have 34 AP's over 3 floor, including a conference centre that sees meetings of up to 80-100 people (then of course 100 laptops, plus 100 iPhones, plus 100 personal phones,etc...). I've made changes over the last 3-4 months to the RF Profiles to allow the AP's to adjust their settings as far as possible and we're seeing some of them powering down to 2dB which is suggesting there is more overlap between them than we probably should have. So, this brings me to the point of the question, to try to assess if we do in fact have way too much overlap, I'm looking at disabling a few of the AP's to see what that does to the remaining AP settings and coverage and I'm trying to figure out if I simply disable the SSIDs from an AP, does that shut down the antenna completely. If I switch the SSID to "deploy SSID by TAG", and drop the tag on a few of the AP's does that shut down the radios as well or do I need to power them down completely?

Pugmiester · ‎Dec 11 2019

We're up and running but not without having to tear down the initial installation and start from scratch. That was rather convoluted as well but eventually I managed to unpick it and remove all of the newly created resource groups and the vMX. I had to create a new dedicated subnet in our primary resource group and VNET to be able to attach the vMX LAN interface to which then made it available on the list when building the new vMX. The other subnet I was trying to connect to initially, has been configured as the Azure gateway subnet which seems to exclude it from the selection list. Yeah, I don't know anywhere near enough about Azure to fully understand how all the widgets hang together. It seems overly complicated coming from a physical hardware world but I think it makes enough sense to me now to be able to reproduce this in production when we need to.

Pugmiester · ‎Dec 5 2019

I've just run up against the same issue deploying a vMX. The process never made sense beforehand (I'm in no way any sort of Azure expert) so I just presumed it was my physical world thinking but I don't recall having any options at all to select a subnet/vnet outside the vMX's new resource group. In theory, peering the VNET's should be trivial but I'm hitting a permissions error that we can't make sense of so I've bounced it back to our Meraki sales contact to see if they can help unravel what's happening.

Pugmiester · ‎Nov 18 2019

OK, That's really strange. The internet connection troubleshooting sent me down a particular path and I remembered that many years ago, the subnet we had from our ISP was split into two halves with one half being NAT'd on our old Checkpoint firewall, and the second half of the subnet routed through the Checkpoint. No idea how, I never saw the config. However, switching to 3 IP addresses in the original lower half of the range has the MX's happy again. It's bizarre as there are services using the upper half without issues.. But anyway, we are up and running.

Pugmiester · ‎Nov 18 2019

Thanks for confirming. That's what I was hoping. I'll run through the connection check docs to confirm what I can see. We do have some 1:1 NAT on the HA pair for some locally hosted services but I've confirmed there are no overlapping addresses. The 2 IP's (will be a third for HA once I get basic comms working) are free of any other configuration and I don't think we have ever used them.

Pugmiester · ‎Nov 18 2019

Hi all, Before I go completely bonkers, can I run a question by you all to see if I'm in fact trying something impossible. We have an existing MX HA setup on site that's happily running and providing SD-WAN links to an expanding number of our offices but we are looking to move some third party IPSec VPN links over to our Meraki infrastructure as well. To help separate out the traffic from our SD-WAN (We don't need everyone to know about the links, they are for single local services), we're following this article - https://www.willette.works/merging-meraki-vpns/. It makes sense and I've most of the infrastructure up and running with the exception of the primary WAN link. I'm trying to use 3 additional IP's from our available public subnet but the IPSec MX's seem to not want to use them and keep falling back to WAN2. They are part of the same public subnet assigned to interfaces on the HA MX's and I'm half thinking this is the cause. I'm not seeing any errors but they just don't seem to want to use the primary WAN connection. There's a mention in the article about needing a separate organisation for the VPN link to avoid any VPN subnet overlaps but the impression I got from this was avoiding overlaps between third party subnet and a subnet on the SD-WAN but it's not clear. Can anyone confirm if this should be possible or am I going to have to look at a separate organisation?

Pugmiester · ‎Nov 11 2019

Thanks, I knew there would be a way to do it but I've not had enough coffee yet this morning 🙂

Pugmiester · ‎Nov 11 2019

Hi all, A question popped up in our team meeting this morning that I hadn't considered. If a website is dropped into a category by Brightcloud that a local MX happens to block (Parked Domains for example), is there a safe way to allow a management IP address to bypass the URL category list and get unrestricted internet access to be able to confirm the type of site? I'm assuming it's not obvious from the URL or users description. We could of course connect out of band to check it or simply whitelist the URL on the MX but that releases it for all users so I'm kinda hoping there may be a more elegant and controlled option we could consider. Thanks, Martin

Pugmiester · ‎Oct 23 2019

That's my name in the bag for some swag.

Pugmiester · ‎Aug 1 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.

Pugmiester · ‎Jul 31 2019

Hi all, I'm working through the process of migrating one of our offices from a Checkpoint firewall to an MX but I've run up against an issue and I can't think of a sensible way around it. The site has a DMZ behind the Checkpoint firewall with a server that makes connections both to the internet (easy to reproduce) but also to a single server in a data centre across our global WAN. That connection has a policy on the Checkpoint that uses NAT so the connection looks to the data centre server as though it's the firewall making the request and as the local office LAN is a subnet the data centre knows about, it just routes the traffic back. The DMZ server in question is a third party black box so we are hoping to avoid having to connect it directly to the LAN in the office as we cannot be certain how up to date it is. Is there any way I can reproduce that DMZ <> NAT <> LAN functionality with an MX or do I need to starting thinking about having routes for the DMZ subnet advertised across the WAN?

Pugmiester · ‎Jul 11 2019

Congratulations to all. There's certainly a few familiar names on the list that have been really helpful in getting things fixed and helping me understand the transition to Meraki from other technologies.

Pugmiester · ‎Jun 10 2019

Thanks @PhilipDAth, I spotted the VLAN disabled but unfortunately suppers us right now as all of the larger sites have VLAN's enabled we'd need to router around. I was looking at OSPF because I have a little experience with it and only a passing understanding of BGP.

Pugmiester · ‎Jun 7 2019

Hi @PhilipDAth, I'm just butting up against the OSPF restrictions myself. It would be a big help if OSPF was available on an MX in NAT mode to publish the Auto VPN routes to a local LAN gateway for the larger sites we have where the MX will not immediately replace the default router. Looks like a little manual work until we get things organised.

Pugmiester · ‎Jun 3 2019

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

Pugmiester · ‎Jun 3 2019

Thanks @ali_abbass85, I really like the simple diagram idea. One of the many challenges we have is as part of our company reorganisation, we're now becoming centrally responsible for all of these remote sites without having any idea what's on the site yet.

Pugmiester · ‎Jun 3 2019

Hi @SoCalRacer that's the approach we've been considering as the best fit so far. It does involve an amount of cable swapping by the local guys but I think with a bit of Friday afternoon brainstorming we've found a process that should work.

Pugmiester · ‎May 31 2019

Hi folks. We're starting our roll-out of around 25 sites across Europe who will all be receiving a HA pair of MX's (64, 100, 250 depending on site size). The hardware is being shipped directly to site by Meraki and we have a varying level of IT support on each site, from dedicated IT staff through to the guy who fills the coffee machine. We're configuring all the sites ready to support dual internet feeds for future expansion (a task you need the local status page for on an MX64/MX100) and then configuring them for HA. It's a relatively simple task if all the hardware's sat on your desk but a little trickier to achieve on a remote site. A quick Google this afternoon returns a selection of links but none that really walk through the process in enough detail to make it easy to explain to someone remote. Does anyone have a handy guide that we could use to help simplify the process and make it easy to follow?

Pugmiester · ‎May 29 2019

I'm looking forward to a network that does a lot more to manage the client load and connections between the access points to better manage hotspots around the building.

Pugmiester · ‎Apr 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.

Pugmiester · ‎Apr 16 2019

Hi @BrechtSchamp, that's great. Sounds like this shouldn't be a big a headache, just plenty of warning for the affected users and some hand holding to make sure the less technical staff (guest ambassadors) have an authentication app ready to go.

About Pugmiester

Pugmiester

Community Record

Badges