Meraki

PhilipDAth · ‎Oct 11 2017

Does it have a little "pencil": icon to the right of it that you can click on? Failing that, can you not just shorten the name on the LLDP device itself?

PhilipDAth · ‎Oct 11 2017

I stand corrected. Then this makes it much simpler.

PhilipDAth · ‎Oct 11 2017

Group policy can not override WiFi firewall rules.

PhilipDAth · ‎Oct 11 2017

First, your customer can get kit by using the "Try and Buy" program. https://meraki.cisco.com/form/trial The hint really is in the term "WAN" - which implies at least two sites - which means you would need two MX's. And to really show it off, at least one of those MX's should have two circuits attached. Here is a CVD (Cisco Validated Design): https://documentation.meraki.com/MX-Z/Deployment_Guides/SD-WAN_Deployment_Guide_(CVD) This section in particular shows how to configure the magic: https://documentation.meraki.com/MX-Z/Deployment_Guides/SD-WAN_Deployment_Guide_(CVD)#Adding_performance_and_policy_rules

PhilipDAth · ‎Oct 10 2017

Lets see if you have an issue with asymmetric timing of the TCP connection (usually caused by circuits with different send and receive speeds). Could you please try enabling timestamps with the below command and repeating your test. netsh int tcp set global timestamps=enabled You can undo the setting by setting it back to disabled.

PhilipDAth · ‎Oct 10 2017

1701 is only used for control traffic to build the connection. All data is sent over standard IPSEC for the outer layer.

PhilipDAth · ‎Oct 10 2017

Have you tried adjusting the MTU yet?

PhilipDAth · ‎Oct 10 2017

L2TP over IPSec looks exactly the same as IPSec to a provider. It is all encrypted. I'm going to guess an MTU squeeze. Try this experiment; use this command on one machine at one of the sites to display all your interfaces: netsh interface ipv4 show interfaces Note the interface number that is configured with the IP address used for communication. Lets pretend it is interface 10. Then issue this command (change 10 to your interface number): netsh interface ipv4 set subinterface "10" mtu=1400 store=persistent To undo this repeat the command with an MTU of 1500 If this solves it, then do this command on the servers that everyone connects to (rather than having to do it on all the workstations).

PhilipDAth · ‎Oct 10 2017

Yes, the speed is back to normal.

PhilipDAth · ‎Oct 10 2017

I can only come up with complex solutions to your exact requirements. However if you can relax the requirements so that anyone can access the printers, instead of just employees, then add a wireless firewall rule above the "deny" rule, permitting access to only the printers IP address. Here is a screenshot of a pretend configuration.

PhilipDAth · ‎Oct 10 2017

Have you configured any organisation wide site to site VPN firewall rules, on either side? And group policy restrictions on either the VLANs or specific machines? I don't remember trying to ping the MX IPs in this case (third part ipsec vpn). Perhaps try pinging a host behind the MX (and make sure it responds to pings locally as Windows firewall tends to block ping). You can ping an MX IP when it is doing AutoVPN, but this is not that case. Make sure you have the remote VPN subnet configured correctly on both ends. In desperation, try giving one of the MX's a power cycle.

PhilipDAth · ‎Oct 10 2017

Yes, you can just create a supernet route for 192.168.0.0/16 to point to the MPLS router at HQ, just as you have indicated. The MPLS router would need a route pointing to the MX at HQ for MX connected sites as well. I personally prefer this approach: https://documentation.meraki.com/MX-Z/Site-to-site_VPN/Configuring_Site-to-site_VPN_over_MPLS In this scenario, you use AutoVPN over both MPLS and Internet. In this case, every site needs an MX. In this scenario, your MPLS network only has stub networks connecting to each each at each site, and no longer has any knowledge of your networking (it only sees encrypted traffic). In this scenario there are no statics, and failover is completely automatic. It can also detect failures within the MPLS service provider network, as opposed to just local connectivity issues.

PhilipDAth · ‎Oct 10 2017

@lp101 they wont be able to use link aggregation, as you need dual links (or more) between the same two switches (or switch stacks). @Dasilva13 it would be better if you could change your switch design. It would be better to have a pair of core switches, and then run a pair of links between that and each floor, rather than chaining them together floor to floor. If you need to keep the current design then make each port connecting to another switch a trunk port. Leave RSTP turned on, and it will knock one link out to get rid of the loop. You should make one switch the "core" or "main switch", and lower its spanning tree priority (Switch/Switch Settings/under "STP bridge priority" choose the switch/lower the priority to something like 16384). I would not both using root guard. I would make sure every port that is not connected to something that does not need VLAN trunking (aka ports to workstations) are made access ports.

PhilipDAth · ‎Oct 10 2017

The last post I just did took 36s.

PhilipDAth · ‎Oct 10 2017

I haven't used the original method you said (Sentry based tags) but I think it should work. Note that the policy is usually applied when the client connects - not to a current connection. So perhaps you need to wait a bit longer?

PhilipDAth · ‎Oct 10 2017

Giving Kudo's is also very very slow.

PhilipDAth · ‎Oct 10 2017

Has anyone else noticed that making posts and replies at the moment is incredibly slow?

PhilipDAth · ‎Oct 10 2017

You said you had an MX64W which has an integrated access point. If you follow the guide, the rules are applied across both devices (MX and MR).

PhilipDAth · ‎Oct 10 2017

@soomeGUy yes, we are expecting the MS120 to be quite a bit cheaper than the MS225 because they don't have 10Gb/s connectivity.

PhilipDAth · ‎Oct 10 2017

The Cisco Meraki switches using rapid spanning tree. The convergence time, even for a large network, should be no more than a couple of seconds.

PhilipDAth · ‎Oct 9 2017

The built in access points are not as capable as the standalone access points. The guide you are referring to is based on the more capable stand alone access points, which is why it refers to some extra options. In your case, I would mark the traffic as class 46 (EF - Expedited Forwarding).

PhilipDAth · ‎Oct 9 2017

You want to use this configuration (based on tracked routes): https://documentation.meraki.com/MX-Z/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_VPN Hint 1: Change your current static routes to only be active while the next hop responds to ping for the WiFi bridge link. Your static routes will then be used in preference and will fail over to VPN if the next hop stops responding. Hint 2: Make sure you are using AutoVPN (so at least one end needs to be a hub).

PhilipDAth · ‎Oct 9 2017

I would deploy Chrome in single app mode. I see two of the AppSetting options are UrlBlackList and UrlWhiteList. You could configure it to block everything in the blacklist, and then add only the allowed urls to the whitelist. https://www.chromium.org/administrators/url-blacklist-filter-format

PhilipDAth · ‎Oct 9 2017

I haven't run into this issue using other Android phones. Are they using the actual Twitter/Facebook apps, or the mobile version of the web sites?

PhilipDAth · ‎Oct 9 2017

I can't think of anyway to solve this one. You can do inbound 1:many, but not outbound many:1 NAT.

About PhilipDAth

PhilipDAth

Philip D'Ath

Community Record

Badges