About Brash

Brash · ‎01-18-2022

Congratulations everyone! And thanks for the warm welcome! 🙂

Brash · ‎01-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 · ‎01-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 · ‎01-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 · ‎12-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 · ‎12-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 · ‎12-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.

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

Community Record

Badges