Meraki

cmr · ‎Feb 17 2020

Could this be the problem, it is from the screen above when it eventually loads ( about 2 minutes), even when loaded I now cannot navigate anywhere else that doesn't have a dedicated icon, even to log off or change network / org:

cmr · ‎Feb 17 2020

The app also seems to be trying to load too much data, on Android at least, for many screens like below I just get the loading symbol and when it finishes none of the clickable objects work anymore. Even killing the app doesn't help as it just comes back to the same screen, it must be running a background process or caching itself...

cmr · ‎Feb 17 2020

Thanks @joe I've raised a couple of wishes but there seems to be a bug on the usage graph on the usage tab, see one example below for an MX65 that seems to have a warp drive!

cmr · ‎Feb 17 2020

We had one schedule on its own a couple of weeks ago (an MX upgrade) and several MR upgrades about a month ago to 26.6.1 (but from 26.6). I'd log a support ticket.

cmr · ‎Feb 17 2020

1 is true but traffic from WLC to DC edge is not encrypted by WLC so monitor it there. 2 is definitely true 3 is that your WLC is limited to a number and type of APs, we moved away when ours couldn't support enough / newer APs

cmr · ‎Feb 17 2020

Are you looking to use the Fortigate as the edge of one spoke, the edge of a DC, or as a hub? spoke - create a site to site VPN to the MX in the main site, should be okay as long as you don't need access to/from the other sites etc. due to routing issues. edge of a DC - if there is an MX as a concentrator there and it is just an internet edge then this should be fine. hub - just don't even think about it, you lose all the benefits of autoVPN/SD-WAN So, unless you are following 2, or can accept the limitations of 1, it isn't the best idea

cmr · ‎Feb 13 2020

Or you could use an MG21, 4G on the WAN 1 ethernet port.

cmr · ‎Feb 13 2020

MX Uplink IPs Existing MX WAN ports have an IP address from the provider that they are connected to. New MX WAN ports need an additional IP address from each provider Virtual uplink IPs Existing MX WAN ports have an IP address from the provider that they are connected to. New MX WAN ports need an additional IP address from each provider A floating IP address that is held by the active MX is needed from each provider The main benefits are: Outbound traffic always comes from this address, not one MX and then sometimes the other. Inbound traffic to internal services can go to the virtual IP, otherwise you need to know which MX is active by using dynamic DNS or similar with the inherent delays and complexity, it can work though. Regarding the heartbeat, the dashboard will send emails about MX failover and WAN link failover

cmr · ‎Feb 12 2020

Are they set up as an SD-WAN hub and a spoke or two hubs? Do you get an IP address from the same subnet with wired or wireless? Do you have any ACLs configured? Is the SSID bridged to the LAN or another option?

cmr · ‎Feb 12 2020

It is very simple, we have 9x HA pairs of MXs 😀 Note: You need 2 or 3 IP addresses for each WAN/internet connection from your provider. Warm spare MX needs to be in inventory, but not in a network Go to Security & SD-WAN tab for the existing appliance and in the Warm spare box click on Configure warm spare There is a box with Disabled selected, click on Enabled Select the MX serial number that you want to become the warm-spare, it must be the same model as the existing. Depending on how many IP addresses you get from your WAN/internet providers choose Use MX uplink IPs from the Uplink IPs dropdown if you only have two, or choose Use virtual uplink IPs if you have three and enter them below. If you don't have DHCP available to plug the new warm-spare MX into, go to the local status page and enter the WAN IPs, subnet masks and gateways for the WAN link(s). If you do have DHCP that gives the MX internet access then you can configure the WAN IPs from the dashboard by clicking on the page below and then going to the Uplink tab

cmr · ‎Feb 12 2020

Better visibility of power supply states when using the models that connect to the Cisco RPS2300. At the moment the only way of telling that it is working from either the GUI or being in front of the switch is to ... look at the lights on the RPS 🤔 Also the MS1xx switches should support the RPS2300

cmr · ‎Feb 11 2020

I recently upgraded a network with six switches using the stages upgrades option as below: The actual device reboots were: 09:26 (26 minutes after schedule) 09:31 (1 minute after schedule) 10:26 (26 minutes after schedule) 10:56 (26 minutes after schedule) The first device is a 220, the second a 120, the third a stack of a 225 and 210 and the fourth a stack of a 225 and a 210. Probably worth bearing in mind when using this feature that the 2xx switches all reboot 26 minutes into the window but the 1xx switch only waited 1 minute! Is this by design or is it a bug? Anyone else done staged upgrades and experienced the same as above or different?

cmr · ‎Feb 11 2020

Sophos SSL is quite a bit better for client VPN, so the MSP isn't completely wrong:

cmr · ‎Feb 9 2020

@ArshadSafrullaI was actually quite happy with 500Mb/s but I did try as you suggested. The result was a throughput of about 420Mb/s so I re-enabled the rules and got just over 480Mb/s.

cmr · ‎Feb 7 2020

How do the client IP addresses compare to the exchange server's IP address. If the clients and exchange server are both in Denmark and you are doing a client VPN full tunnel to Sweden then it locks you out of anything not on the same subnet and can lock you out of anything local at all. Can they access any local resources when the VPN is connected, printers, other servers etc.?

cmr · ‎Feb 7 2020

For Meraki, 2x stacks of 6x 225/210 switches. Use 250s only if you need absolute power redundancy. 10GbE uplinks to 425 pair. Is Meraki QoS as defined as Cisco IOS, no. If you have complex QoS requirements and are overloading bandwidth then this may swing the decision.

cmr · ‎Feb 7 2020

Seeing as the CDP vulnerability doesn't affect IOS, IOS XE or many other 'midrange' products I'd be quite surprised if they were affected.

cmr · ‎Feb 7 2020

See below, first image is reboot of primary, after warm spare has taken over: and then the below is the warm spare rebooting once primary has taken over vrrp again This is with the 15.x firmware train so 14.x may be different.

cmr · ‎Feb 7 2020

We have upgraded HA routed pairs dozens of times and for most clients there will be no noticeable downtime. What we have seen on a busy site is: Cisco IP SIP phones registered to a server on a remote site may show 'registering' for 15 seconds or so. Citrix XenApp thin clients may see a 'reconnecting' pop up from the taskbar but applications continue to operate normally. For PCs we've not seen any impact. I also think that ongoing SIP phone calls aren't affected but I will need to test to be sure.

cmr · ‎Feb 7 2020

I think the most you could do without SM is disable the SSID or pop up a splash page by enabling one on the event. Depending on the activity on the device they may or may not notice either. If you have an app on the device you could enable a Bluetooth beacon but even that would not be instantaneous.

cmr · ‎Feb 7 2020

As it is on site Exchange then please ignore the internet firewall comment, it shouldn't be the issue. With the VPN disconnected how do they access the Exchange server in Sweden from Denmark?

cmr · ‎Feb 6 2020

I'm guessing you have full tunnel VPN at the customer and the IP address ranges given out for the VPN clients in Denmark don't have a rule on the internet firewall in Sweden that allows them out to Office 365. Either that or the subnet given to the VPN clients in Denmark has no route on the firewall in Sweden. Otherwise please follow the troubleshooting steps above.

cmr · ‎Feb 6 2020

If you need an alternative, a Cisco GLC-T works fine, they are readily available for not much second hand.

cmr · ‎Feb 6 2020

Meraki don't use beta and release candidate in the same way as other vendors. They simply mean that it hasn't been rolled out to more than a certain percentage of users. It is something like: <10% of major version deployed leads to beta <10% of minor version deployed, but >10% major version deployed leads to release candidate. i.e. Stable MR is 26.6, new MR 26.7 comes out, it will be RC, new MR 27.3 comes out, it will be Beta

cmr · ‎Feb 6 2020

We've been using the 15.x train for over six months for our UK WAN and customer internet edge. We haven't had any unexpected issues across 9 sites, thousands of users and ~25 MXs. Big caveats: We don't use the advanced license features We don't use cellular or Wi-Fi models We don't use BGP/OSPF in production We have MX64,65,67,84,100&250 models.

About cmr

cmr

Community Record

Badges