About Brash

Brash · ‎12-20-2021

It depends on what you're looking for. If you're looking for clients, you can find them under Network-Wide -> Clients, and sort by "connected to". If you're looking to find LLDP information about connected devices from the MX's perspective, there's no way to find that in the GUI. However you can pull the information via the API. See the following thread. View LLDP or CDP information on MX device - The Meraki Community If you know it's connected to a Meraki switch and are just trying to identify which port, you can navigate to Switch -> Switch Ports and look at the table column CDP/LLDP for the MX (you might have to add the column using the spanner in the top right of the table). You can also use the search bar to filter on this.

Brash · ‎12-15-2021

I'd say it's a much better idea to block/manage updates from the Windows side using something like group policy and WSUS. Assuming that L7 rule is applied correctly but is just not capturing Windows Update traffic for whatever reason, you could look at blocking the specific domains instead. Ajit's comments in the following thread are pretty good at outlining the options. How to block Windows Updates? - The Meraki Community

Brash · ‎12-14-2021

you mean I have to configure vlans on MX and also in Switch? Yes, the Aruba needs to have the VLAN configured to be able to pass traffic on that VLAN. It doesn't need a VLAN gateway/Virtual Interface though as this will be on the MX. What i have done: Configure 2 Vlans in MX. port 1 of MX is connected to Port 24 on Aruba switch (on MX Native vlan 1 and allowed vlans all) Now on Aruba SW i have configured same 2 vlan. Port 24 is tagged. When you say Port 24 is tagged, do you mean it's allowing tagged traffic or tagging incoming traffic? Mind you, some of this configuration is dependent on what you're trying to achieve as the end goal. The above assumes that the Aruba will be tagging traffic downstream, and sending tagged traffic to the upstream MX where the VLAN gateway resides.

Brash · ‎12-14-2021

You will need to ensure that the Aruba is configured to 'know about' the 3 vlans, and that the port connected to the MX is configured to trunk those vlans. Not sure of the exact syntax on Aruba switches but in Cisco world, that invloves: Creating 3 vlans on the switch: Switch(config)# vlan 1-3 Configuring the port as a trunk Switch(config)# interface gi1/1 Switch(config-if)# switchport mode trunk The following link might help with the syntax/process. Configuring VLANs (arubanetworks.com)

Brash · ‎12-13-2021

Chances are you can configure just about all of this in the firewall on the MX250. Outbound rules can be set with the applicable source/destination subnets & ports to allow/deny. Or you can add an explicit deny all as the last configurable rule. The rest depends on your topology: - Whether the static route is for a WAN port or LAN port or S2S VPN? - Is your MX setup for NAT or No-NAT? Is it common practice to deny all outbound connections in the firewall and only allow wanted outbound connections? It really depends on your use case, traffic flows and security you're putting in place. For example blocking all outbound except for specific allowed rules is a common firewall technique. However for many SMB's it is too much overhead to implement and maintain the rules. Therefore the trade-off may be that they leave the allow any-any rule for an arguably less secure but easier to manage environment.

Brash · ‎12-08-2021

North-South will definitely require solid switches given all of your Management, VM Network and vMotion traffic will be going through it but the requirements for those should be exactly the same as any other server solution (HCI, traditional SAN etc). I can only see PFC being a requirement if you're using the same switches to push the storage traffic across, or presenting the storage directly to other hosts on the network. In that circumstance though, I'd probably just opt for physically separate switches. That said, these are all assumptions. The only HCI solution I've worked on (albeit very closely) is Cisco Hyperflex.

Brash · ‎12-08-2021

I haven't read up on the solution specifics but I'm guessing the PFC requirements is for East-West storage replication/communication between servers. You could use a datacenter switch that only handles this traffic while using Meraki for the host/VM network traffic. Even if it were supported on an enterprise core or access switch, I'd probably avoid it anyway given the need for large buffers and very fast ASIC's. PFC on slow(er) switches or across multiple hops can cause huge performance issues that are just awful to troubleshoot.

Brash · ‎12-08-2021

I haven't seen any documentation suggesting that support is present or is planned. I would say it doesn't align with Meraki's typical target market. PFC is most commonly used for FCOE which you'll primarily find on datacenter switches rather than enterprise core and edge.

Brash · ‎12-07-2021

Seems correct. The VLAN number itself shouldn't matter, so long as you're tagging the incoming VPLS traffic onto the right VLAN so it can hit the SVI.

Brash · ‎12-07-2021

Your main issue I can see is that both MX's will use the same external port for Meraki client VPN, so unless you have multiple external IP's, there's no way you can get both VPN's working from the same IP. Is the issue here that you have users who are configured to VPN to Site-A that you don't want to re-configure for Site-B, or are you just trying to avoid changing the IP on the server?

Brash · ‎12-06-2021

From Meraki, the MS120-8 is a good option if you're just looking at 1G For more than that, you'd be looking at an MS125-24. Otherwise, you could look at a Cisco C3560CX-8XPD-S for a small mGig switch

Brash · ‎12-05-2021

Looks like you've got the parameters correct. Potentially your JSON body is malformed (end of line character or other hidden character causing issues)? I just did a quick test using Postman. PUT: .../v1/networks/<NetworkID</clients/<clientID>/policy Body: { "devicePolicy" : "Group policy" , "groupPolicyId" : "100" } Response: { "mac" : "<Mac Address>" , "groupPolicyId" : "100" , "devicePolicy" : "Group policy" }

Brash · ‎12-05-2021

It looks like you haven't specified "devicepolicy" in the body. Device Policy The policy to assign. Can be 'Whitelisted', 'Blocked', 'Normal' or 'Group policy'. Required. Assumedly for your API call, it should be set to "Group policy"

Brash · ‎12-05-2021

Meraki MX devices are security gateways. Only 1 is allowed in each Meraki network. You won't be able to add a second one unless it is acting simply as a backup to the primary one - (see hot spare). What are you trying to achieve with the second MX?

Brash · ‎12-03-2021

Good find. Certainly better than having to re-run cables.

Brash · ‎12-02-2021

Where are you testing the client VPN from? Inside your network (across the S2S VPN) or outside of your network? Can you show the S2S VPN settings?

Brash · ‎12-02-2021

The port forwarding needs to be configured on the upstream NAT device (assumedly firewall). UDP 500 and 4500 need to be forwarded to the MX's WAN interface IP address.

Brash · ‎12-02-2021

I thought that might be the case given MiM for HTTPS inspection is beginning to get steered away from. That said another service means another additional cost 😞

Brash · ‎12-02-2021

This is typically seen when devices go into power saving mode. The following thread has some additional detail Switch port change link speed - The Meraki Community

Brash · ‎12-02-2021

The client VPN troubleshooting doc is pretty good. Troubleshooting Client VPN - Cisco Meraki As you mentioned, port forwarding UDP 500 and 4500 is key. I suggest checking the MX event log to see if it's getting the client request. The details are under the heading " The MX is Not Receiving the Client VPN Connection Attempt" It actually sounds like you've overlapped ports for the client VPN and the S2S VPN. Take a look at: Site-to-site and Client VPN Port Overlap with Manual port Forwarding rules - Cisco Meraki

Brash · ‎12-02-2021

I've been looking into HTTPS inspection on Meraki MX's recently. I found a thread from 2019 indicating that the feature came into Beta firmware and the following document released https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/HTTPS_Inspection However the doc now seems to be behind a Meraki login (separate from dashboard/community login). Has the doc been removed from public access or am I just doing something silly? And is the feature available in current stable or beta firmware or has it since been removed?

Brash · ‎12-01-2021

No, port-channels are not configurable on MX devices. The MX does however pass through STP packets so you can connect 2 cables to the same network. One will be brought down (due to STP loop prevention) but can be used as a backup if the primary connection fails.

Brash · ‎12-01-2021

In that case, to keep the network traffic on the Mikrotik switch, you'll need to create a VLAN interface on the Microtik switch for the VLAN's and set it as the default gateway instead. Otherwise you can connect both the NAS and the client on the same VLAN. In theory you can also

Brash · ‎12-01-2021

For the traffic flow you described, it sounds like the default gateway for VLAN 4 or VLAN 12 (or both) reside on the upstream MX.

Brash · ‎11-30-2021

You're bang on that CRC's are a Layer 1 or Layer 2 issue. Most commonly it's dirty/loose/broken cables, or occasionally a bad SFP/switchport. It can also be due to MTU mismatch. If it's a 10Gb fiber link, interference is highly unlikely as fiber is relatively unaffected by RF as opposed to copper. In terms of the consistency in timing, a couple of things to note are: - Higher CRC counts will generally correlate with higher network traffic (more packets = more likely for one to be corrupted). Is it possible that at these times the link had a higher utilization in general? - Do you have any scheduled traffic around those times where higher MTU data is being sent (and where a mismatch might be present in the network)? In any circumstance, I would definitely suggest starting with swapping out the cable and continue troubleshooting up the stack from there.

Brash

Community Record

Badges