Meraki

Brash · ‎Feb 9 2022

There's quite a few ways you could do this. A lot of it comes down to design choices. Eg. - Will the VM's and ESXi management use the same physical port on the server? - Will the VM's be on the same subnet and VLAN as ESXi Management or different? Assuming your ESXi host and VM traffic will exit the same physical server port onto Meraki switch port 5, you can: - Configure Meraki port 5 as a trunk with Native VLAN 10, or Access VLAN 10 - Leave the VM traffic untagged in ESXi Or if you'd prefer to tag on ESXi, you can: - Configure Meraki port 5 as a trunk port with native vlan 1 - Configure ESXi management to use VLAN 10 - Configure your VM's to use VLAN 10 within ESXi These are just a couple of ways you can configure the devices to have both ESXi and the VM's on VLAN 10 and receiving IP addresses, assuming that's what you're trying to do.

Brash · ‎Feb 9 2022

I'm not quite sure where the VM's fit into your network. But generally speaking, any VM on VLAN 10 will receive an IP from the DHCP server via the relay you setup. VM's on VLAN 1 will receive an IP directly from the DHCP server. VM's on other VLAN's will not receive an IP lease and you will need to configure a DHCP relay for that VLAN somewhere in the network.

Brash · ‎Feb 9 2022

I don't know if it's applicable to Comcast, but check your ISP doesn't do Carrier Grade NAT (CG-NAT). That will prevent you from initiating inbound connections. If you're manual port forwarding for your site-to-site, double check there's no port overlaps. Site-to-site and Client VPN Port Overlap with Manual port Forwarding rules - Cisco Meraki

Brash · ‎Feb 8 2022

For me, it's not an absolute must but definitely a feature that would be nice to have.

Brash · ‎Feb 8 2022

The Meraki appliance will communicate with the cloud with a destination port of TCP 443. However the source port will be dynamic (in the >50000 range). The Meraki cloud will not send any traffic inbound towards to MX on port 443. As verification, If you navigate to "Help" -> "Firewall Info" in the Meraki console, you'll see that the firewall rules required on port 443 are all outbound from the MX, not inbound.

Brash · ‎Feb 8 2022

Congrats everyone! The top 4 killing it as always. Great thread @Troy360, it was a journey of a read. And nice post @ChrisMarriott! Additions like that really benefit the community 👍

Brash · ‎Feb 7 2022

169.254 addresses are present when the client is attempting to obtain an IP address from the DHCP server. Once the DHCP server has responded to the client's request, the 192.x IP address will be adopted. If wired clients are working but wireless clients are not, check the L3 firewall rules on the access point to make sure it can reach the DHCP server (wireless -> firewall & traffic shaping). Also ensure that the client is being placed into the correct VLAN upon connection and authentication. You can also perform a packet capture on the AP (Network -> Packet Capture) and add filters for DHCP to see if the client request is going through and whether the server response is seen coming back.

Brash · ‎Feb 3 2022

@DarrenOC Right, I think you're spot on. I thought I'd read somewhere that the warranty provided by Meraki license was also NBD but it appears I was wrong.

Brash · ‎Feb 3 2022

Hi @AjitKumar The document helps describe the difference between different service levels of Meraki Now. However, from what I understand, there would be no advantage to purchasing Meraki Now (8x5 NBD HW Only) as this is already included with the Meraki license purchase.

Brash · ‎Feb 2 2022

This is probably an easy one but I'm having trouble correlating the information I've been able to find on this. In being quoted for some Meraki gear, the partner has also included RMA ONLY NBD line items (Eg. CON-ROB-MR44HWRL) at extra cost. If I'm not mistaken, Meraki gear already comes with NBD RMA as part of the license cost. What extra service would this line item be providing and is it a requirement to purchase?

Brash · ‎Feb 2 2022

I believe it can be done using an Azure site-to-site VPN and/or Meraki vMX appliance. The following blog (written by a Meraki engineer) provides some detail - Meraki MR 802.1X with Azure Active Directory – APICLI

Brash · ‎Feb 2 2022

1. Meraki switches should continue forwarding indefinitely if they lose cloud access (at least as long as the license allows) 2. That's a good question. I would assume it stays running until next time it becomes cloud connected but I've never tested this (I'd say very few people have). Might be a good question for your Meraki rep. 3. You can make some changes to switchport configuration and uplink configuration. It's primarily designed is to be able to get the switch cloud connected again after a potentially incorrect configuration change - Using the Cisco Meraki Device Local Status Page - Cisco Meraki 4. Depends on what you mean... Meraki configuration that has been applied more that 30 minutes ago (and the device has not rebooted) is considered 'safe', which then has implications on what happens if it loses access to the cloud. Behavior during Connection Loss to Cisco Meraki Cloud - Cisco Meraki In terms of backing up configuration, it's not exactly a requirement given all configuration is cloud managed but there's a few tools (paid and not paid) that enable this function - IFM - Backup Meraki Config to an offine file

Brash · ‎Jan 31 2022

This should be relatively simple. You can easily create a new subnet, VLAN and SSID alongside the old one to configure, test etc. Then for cutting over users, you can either have them manually connect to the new SSID, or use GPO or an MDM software (Meraki Systems Manager, Intune etc.) to configure the new SSID on each machine. I would transition some key test users over to the new SSID first and make sure it's all working, and once you're happy with it, push out the network settings to all computers and turn off the old SSID. The approach will probably depend on the number of users on the network, its importance to the business and whether all connected devices are managed or not.

Brash · ‎Jan 30 2022

Submitted. Thanks MeredithW!

Brash · ‎Jan 24 2022

I've never tested this in the wild on Meraki gear but your logic is sound. I don't see why this wouldn't work. Also depending on switch model, you could also use a dynamic routing protocol instead of static routes.

Brash · ‎Jan 19 2022

So Good! Didn't realise you can run it dual stack. I'm super excited aye!

Brash · ‎Jan 19 2022

The DNS bad or misconfigured alert can sometimes be a bit of a red herring. I've noticed it can appear when there's drops somewhere between the device and the DNS, just enough that it misses enough DNS replies to raise the alert. Is there any correlation between the AP's that flag the alert and where they're connected to - common switch or network path?

Brash · ‎Jan 19 2022

What @ww said is a great starting point. Just to add, you said you enabled ping any under Security -> Firewall. Was that under outbound rules or security appliance services? The setting under security appliance services is to allow remote IP's to ping the MX via the upstream WAN interface. It doesn't impact downstream. Traffic coming from downstream will adhere to L3 firewall rules and ACL's, so I suggest ensuring that they're setup correctly to allow ICMP.

Brash · ‎Jan 18 2022

Congratulations everyone! And thanks for the warm welcome! 🙂

Brash · ‎Jan 14 2022

Virtual stacking is essentially a feature for ease of management from the dashboard. The switches remain separate in terms of physical operation and network topology. Physical switching on the other hand is where two (or more) switches are physically connected to eachother using the stack ports.They are managed and act as a single switch, providing benefits or redundancy and faster switching of packets between ports on two different stack members. Physical is only supported on certain switch models so make sure to check the Meraki MS Datasheet or the below linked stacking guide. Stacking Guide for reference: Switch Stacks - Cisco Meraki

Brash · ‎Jan 13 2022

Given what you've described, it's quite possibly a firmware. But under the assumption it's not, if you follow the MAC flaps down through the port-channels and switches, which devices and ports to they isolate to?

Brash · ‎Jan 13 2022

This might be what you're looking for: "The MX supports L2TP/IPsec Client VPN and AnyConnect VPN simultaneously. " AnyConnect on the MX Appliance - Cisco Meraki

Brash · ‎Dec 20 2021

Using a repeater will see performance degradation as everything packet is transmitted to the gateway AP, and then re-transmitted onto the LAN. Not to mention the potential of interference. However you can definitely setup repeaters where the performance impact is neglible. Adding additional AP's wouldn't help the performance of the repeater (unless they have a better connection to the repeater than the current AP), as the repeater will only send and receive via one gateway AP. A directional antenna may help if interference is your main problem. Are you seeing high latency or poor signal when looking at the AP health/summary information on the dashboard?

Brash · ‎Dec 20 2021

In terms of AP management, as long as the Unifi controller (wherever it resides) can reach the Unifi Switch and AP's, there shouldn't be any difference from how you currently manage it. In terms of networking configuration and design, you might have to make some adjustments for adding in the MX such as adding the appropriate VLANs, setting DHCP etc.

Brash · ‎Dec 20 2021

As @PhilipDAth said, you can't typically see the MAC addresses of devices connected to the MX. However, you can find LLDP/CDP information using the API - View LLDP or CDP information on MX device - The Meraki Community.

About Brash

Brash

Community Record

Badges