About PhilipDAth

PhilipDAth

> So with that in mind would it make sense to just put it on the MS so we have that wire rate overhead and call it a day? Nothing wrong with that decision.

PhilipDAth

The MX250 might have 10Gbe interfaces, but the actual inter-vlan throughput will be closer to 4Gb/s. Based on the traffic mix, I'd be tempted to do all the routing on the MX ... Putting the VLANs on the MX are straight forward. https://documentation.meraki.com/MX/Networks_and_Routing/Configuring_VLANs_on_the_MX_Security_Appliance If you want to combine routing on the MS425s as well follow this guide: https://documentation.meraki.com/MS/Layer_3_Switching/Layer_3_Switch_Example

PhilipDAth

> MX100 was reconfigured to use a single VLAN over an access port instead of the multiple VLAN trunks that is was using previously The limit is imposed on the MAC address. Any chance you introduced a layer 3 routing device, so all the user traffic now appeared to be coming from a single MAC address?

PhilipDAth

It is a real common problem after Windows 10 updates. @Nash loves this issue.

PhilipDAth

I don't know the answer - but it seems pretty improbable. It does not have redundant compute engines, so can't transition from one software version to another in a hitless manner.

PhilipDAth

So you need to put in a physical "WAN" box which requires an Internet connection and a connection to your environment. I'm sure it is just a matter of money.

PhilipDAth

I would ask the cloud provider if you can buy telehousing from them. You only need 1RU. If they say yes then buy an MX100 yourself and host it in their environment.

PhilipDAth

Note you can not LACP across a virtual stack. You probably want to physically stack the MS425s.

PhilipDAth

The advantage of having the switches doing the L3 is it is wire rate. So if you want to route 10Gb/s between VLANs you can (particularly to your servers). The advantage of using the MX for L3 routing is you can have per-user group policy. To use this feature the users need to be using the MX as their default gateway. If you don't want/need this feature then go with the switches. The MX used to provide better visibility of traffic but with the new "Unique Client Identifier " this is no longer a limitation. https://documentation.meraki.com/MX/Monitoring_and_Reporting/Client_Tracking_Options#Unique_Client_Identifier So if you need the performance more (and the performance you need is greater than the MX can deliver) go with routing on the L3 switches. If you need the additional security controls more do the L3 on the MX. You can also do a mix. Sometimes I have put all the users on a VLAN routed by the MX, and everything else routed by the L3 core.

PhilipDAth

The actual app, VMX100, has to go into its own resource group. When it runs through the Azure setup it comes to a bit about the networking. In that section you need to go into Advanced (in the Azure portal), and select an existing resource group and an existing vnet. You can pretend to do this with a trial run through first before deleting the current VMX.

PhilipDAth

You can only configure it at deployment time. You can not change it afterwards. You have to delete the managed app (VMX) and redeploy. During the deployment you should be able to select the existing resource group and VNET in the networking section (under advanced in the Azure portal).

PhilipDAth

Have you got a Meraki device (like an MX) on something that moves, such as a marine vessel, vehicle, etc? Then you should check out my latest project. I marry a GPS chip to a raspberry Pi to form a GPS server (using the common gpsd), and then use a script to get the GPS co-ordinates from this to update the Meraki devices location on the overview map. If you already have a network gpsd on-board then all you need is the script. https://www.ifm.net.nz/cookbooks/meraki-gps.html For the GNSS people out there - sorry - I know it should be GNSS but the public know the term GPS better.

PhilipDAth

I just remember that when assign the VNET when deploying the VMX in Azure it had to go into an existing VNET. If you used a VNET in the same resource group as the VMX (which is the default) it wont work.

PhilipDAth

It looks like when you have deployed the VMX it was put into it's own VNET. When you are deploying it and you get to the VNET configuration you need to click "Advanced" and select the existing VNET (where your servers are).

PhilipDAth

> Pretty cool huh. Very cool!

PhilipDAth

I've just upgraded our MR45 to it as well.

PhilipDAth

I'm not sure why in that example. AF31 is usually use for more transnational style traffic. Most phones can already DSCP mark their traffic. You don't usually need to remark the traffic from a phone.

PhilipDAth

I know what would be fun - build it into the earth, below ground. It's hard to beat ordinary earth for RF shielding. Plus if your science lab explodes you'll have some containment. 🙂

PhilipDAth

I like the idea off a manual on-off switch. I'd go with your own suggestion. Are you going to build RF shielding into the walls (to make it super quiet)?

PhilipDAth

It sounds like the Meraki cameras may not be a good fit for this use case. You can schedule the video export (for example, schedule it to run over night). https://meraki.cisco.com/blog/2020/01/export-video-on-your-schedule/ Often people use the option of generating a link for exported video, but I can see this is not suitable for your case. I can imagine if you had a long running trial you might need to refer back to it perhaps years later. I've mostly seen the video export feature being used for "minutes" of video, rather than "hours".

PhilipDAth

You can read about the calculator here: https://documentation.meraki.com/zGeneral_Administration/Licensing/Using_the_License_Calculator The link to get to the calculator is this: https://dashboard.meraki.com/manage/dashboard/license_calculator What happens is after you click on it it redirects to the shard you are on so it can lookup what you have now (so links from one person are not likely to work for another person).

PhilipDAth

The vMX can only operate as a VPN concentrator. It can not act as a firewal. https://documentation.meraki.com/MX/Installation_Guides/vMX100_Setup_Guide_for_Amazon_AWS#One-Armed_Concentrator

PhilipDAth

> If not, even if the printer is passive, it should still get the broadcasted ARP request that precedes the pings. And when it does its reply should populate the sticky MAC list if there's free space, right? To the best of my knowledge, traffic is not forward to a port-security port (Cisco Enterprise or Meraki) unless it has something in its MAC address list. This is consistent with the behaviour of stopping a random person plugging in a machine and not being able to see anything.

PhilipDAth

I'm thinking this might be because the printer is not generating any traffic for the switch to learn. Try giving the printer a power cycle after enabling this feature and hopefully it will at least send out an ARP packet so the switch has something to learn. Otherwise manually enter the MAC address.

PhilipDAth

Don't get caught like I did with Cisco Live Melbourne getting can cancelled. I would delay purchasing the tickets, flights and accommodation for as long as possible - at least until the travel restrictions are lifted to China.

PhilipDAth

Community Record

Badges