- About cmr
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
cmr
A model citizen
Member since Feb 6, 2019
yesterday
Community Record
152
Posts
51
Kudos
2
Solutions
Badges
Sunday
1 Kudo
For the MX series in routed mode, you can enable VLANs in the Addressing and VLANs tab. Once you have done this you can assign an access VLAN, or a trunk of multiple VLANs to each LAN port. If you also set up IP addresses for the VLANs then you can route between them. So although you cannot create a router port (in the traditional Cisco sense), you effectively can as you can have 24 VLANs with 24 IP addresses/subnets and apply one to each LAN port of the MX250.
... View more
Friday
1 Kudo
@mvalpreda that is exactly correct, as long as the MX on site 1 can see the internet on WAN1 and the MX on site 2 can also see the internet, they will form a connection (A). If MX1s WAN2 can see MX2s WAN2 then they will form a connection (B). You can then set whether A or B are used as a failover pair, or are load balanced (from each end for outbound traffic). As the internet and the Metro-Ethernet have no direct knowledge of each other then you also end up being able to choose the port the traffic comes in on (by setting where it goes out of at the other end). Remember to set the bandwidth on each WAN port (both up and down if different) if you are using load balancing as it uses those values. You can also set traffic class rules to, for example, send VoIP traffic over the lowest loss / jitter link and file server traffic to prefer the link over the internet.
... View more
Thursday
Please hide your public IP for your own safety. Also if the pubic IP you have listed is the MXs public IP then get rid of the 1:1 NAT. Lastly don't forward such a big range of ports, set up two rules one for 10509 and the other for 10931. However I think that might be the camera sending the stream, not the internal server that you need to address. What do you put into your browser to watch the camera, or is there an application?
... View more
Wednesday
1 Kudo
We run a load balanced dual connected SD-WAN over our two private WAN networks. One is a layer 2 metro Ethernet and the other is a routed MPLS network. You could do the same with direct internet connection replacing our MPLS WAN. In order that the MXs find the cloud you'll either need to have the internet as the primary WAN (for management, the L2 can be primary for the SD-WAN traffic) or have an extra MX as a concentrator at the main site to then route to the internet. As the edge MXs will have an internet connection you'll be better off with the advanced license. You would use the same IP address concept as you have for the WAN port of the MXs that is on the L2 network. We have a single class C network with all our MXs on it. The default gateway is set as the main datacenter in our case as we have a central concentrator there.
... View more
a week ago
Wow, I didn't realise that could you not do that before! We do only use MXs for SD-WAN or public internet access so never needed it, but for a corporate firewall that will make a big difference 🙂
... View more
2 weeks ago
1 Kudo
Have you made sure they are accessing via a rule that doesn't try to use user identity. We have found any device trying to get access through an XG that either isn't identified by STAS, SATC or a client often has random issues, especially but not limited to user identity rules. Even non user identity rules can be affected if you have configured STAS. You can reduce it by reducing the default 120s timeout for the user identity process, we've set it to 30 seconds that does fix most issues.
... View more
2 weeks ago
2 Kudos
On the dashboard the new ports status screen shows connected and speed information against the wrong ports (at least for MX84s, MX100s and MX250s) for us. The CDP information is shown against the correct port. Does anyone else have this issue, we are on n184.
... View more
2 weeks ago
Try 15.19, we are using the 15.x range for a production SDWAN for a 9 site 1500+ employee company and it has worked well.
... View more
2 weeks ago
Please try 1.1.1.1 and 8.8.4.4 just to see if it is simply an issue with the default 8.8.8.8
... View more
2 weeks ago
Also if you are using 802.11b set the minimum bitrate down to 3-5 Mb/s as they max out at 11Mb/s
... View more
2 weeks ago
No, that's what the second email is about, if possible just advertise the current SSID from one AP and if it is better then start adding to minimise overlap of coverage.
... View more
2 weeks ago
Actually, If possible change existing SSID to being selectively enabled to reduce interference, sorry for the confusion!
... View more
2 weeks ago
@celma972 for the bitrate, I meant if you only have 802.1b devices then set the minimum right down and disable the 5GHz. Though I'm not sure disabling 5GHz matters much. I'd try only enabling the SSID in some APs as all the powers are low, probably due to overlap. You can do this by creating a tag on one AP, just type a label such as FL and press return, then setup a new SSID that is only advertised selectively when this tag is on the AP. Change a spare forklift radio to this SSID and see how it responds and how much coverage it has as you walk about (avoiding the other forklifts!). Once you have a map and if it works better, enable on another AP at the edge of the coverage by adding the same tag to that one and see how it changes. If it continues to work well then continue until all forklift areas are served.
... View more
2 weeks ago
@HodyCrouch you might have a point there, our Organizations have the data in Europe according to the bottom of the client page and we do have the Forget button...
... View more
2 weeks ago
1 Kudo
@Merakibgp what are you actually needing to do with this MX450? I'd start with plugging an SFP+ module into Internet1 and connecting that to a normal switch port that has internet access. Once there it will connect to your Meraki dashboard (I do havepresume you a network set up and a code to claim that gives you the 1-10 years of licence for the MX450). You'll need to create a network of type appliance and allocate it. It sounds complex but actually it takes less than 5 mins from nothing to connected and ready to configure rules etc.
... View more
2 weeks ago
1 Kudo
We have done several physical stacks and as @PhilipDAth said, as long as you power them up first on their own before physically stacking them, you will be okay. We have followed the following process: Create the stack in the dashboard by adding the serial numbers Plug in switches on their own with internet access and leave for a few hours Power off switches Install one of the switches in destination and power up, connect devices if needed, to free up space in panel if replacing other switches etc. Install second switch in destination and connect stacking cable(s), then power up Add third etc. if required. As long as you aren't using layer 3 features (we aren't), then it all works fine and there are no connectivity issues for clients, switch reboots etc. We did this with 10.x firmware but haven't added any more yet since moving to 11.x
... View more
2 weeks ago
However Meraki management is so much easier than Ubiquiti, I did have full stack Meraki at home but when the demo licenses ran out I only kept the switch due to the license costs. I replaced the AP with Ubiquiti and a year later am seriously thinking of buying a Meraki AP license just to make the SSID time setting adjustment (for the kid's SSIDs) easier.
... View more
2 weeks ago
If you are replacing a 2km* copper line with 1.99km of fibre and 1m of copper then you will still see most of the latency reduction. It is to do with how quickly the signal propogates either along the metal (usually copper) wire or the glass (sometimes plastic) fibre. The latter can approach the speed of light and is many times quicker! *Imperial equivalents are also applicable 😉
... View more
2 weeks ago
Sorry, I meant a (suitably protected) PC or other device directly on the connection instead of the MX. If the circuit is copper then perhaps they have changed the encoding or similar. Does the ISP own the tail or is it a reseller, or is the tail yours?
... View more
2 weeks ago
Have you tried a different device, even a PC to test with as perhaps the tail circuit has changed or has an issue?
... View more
2 weeks ago
Yes, we use a similar design but we use dumb layer 2 switches for the WAN side of the MXs i.e. Provider 1 -> L2 switch 1 -> WAN 1 on both MX84s. Provider 2 -> L2 switch 2 -> WAN 2 on both MX84s We have 3x IPs from each WAN provider as the HA uses the WAN, not the LAN side in SDWAN mode so that you ensure traffic continuity during failover of MX. One goes to each MX and one is the floating 'virtual' address. On the LAN side we have 1 port from each MX into two different L3 switches that are stacked together (Cisco 3850s in our case). We use a dedicated VLAN and subnet for the MX to 3850 connection but you could trunk if you prefer.
... View more
2 weeks ago
2 Kudos
Security appliance firmware versions MX 15.19 changelog Important notice This is an early-stage beta version for the MX 15 release. Due to this, we recommend taking additional caution before upgrading production appliances. Where applicable, MX 14 or MX 13 releases will provide a more stable upgrade alternative. The DES encryption algorithm is no longer supported for use in formation of VPN tunnels. Creating VPN tunnels using aggressive mode IKE is no longer supported. Supported products notice Z1, MX60, MX60W, MX80, and MX90 devices are not supported on MX 15 and newer releases. Bug fixes Resolved an issue that could result in a device reboot The content filtering matching logic has been significantly refactored. While user-defined whitelists and blacklists will still function the same, other content filtering matches will now be more precise. For example, previously, if google.com was present in the content filtering lists (either due to Search Engines being a part of the top site configuration, or due to having full lists enabled), other google subdomains, such as plus.google.com would also be classified as Search Engines. Known issues After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions Some stability-impacting issues present in MX 14.19 that affect a small population of MX250 and MX450 devices still exist Please note that until certification has been obtained, the Z3C will not be supported on Verizon's network. World-wide device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed in North America and North America device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed outside of North America. When deployed in warm spare / high availability (HA), MX67C and MX68CW do not support using their cellular connectivity to pass client traffic. In this deployment, the cellular connectivity can only be used for device monitoring or network troubleshooting. This is an expected limitation for these platforms. When MX67(C,W) and MX68(W,CW) units are deployed in warm spare / high availability (HA), rebooting the spare appliance may cause a disruption of client connectivity for 10 or more seconds. After making some configuration changes on MX67(C,W) and MX68(W,CW) appliances, a period of packet loss may occur for 10 or more seconds. For a brief period of time upon boot, MX67(C,W) and MX68(W,CW) platforms can become bridged. This increases the likelihood of network loops forming in topologies with multiple inter-connected network devices for this brief period of time. MX67C, MX68CW, and Z3C units must be connected to the Meraki Dashboard initially to retrieve an update to allow for proper use of the integrated cellular connectivity. This is most likely to be an issue when bringing the units online for the very first time. On the MX67(C,W) and MX68(W,CW) platforms, when the MX is providing PoE to a connected device, this information will not be reflected on the Meraki Dashboard. Once a Z3 has been updated to this firmware version it can only run MX 14.31 or MX15.8 and higher. This is an expected result of updates to the device booting mechanisms and this limitation will not be resolved in future releases. Due to an MX 15 regression, client VPN users cannot communicate across non-Meraki VPN tunnels The MX may fail to forward traffic for clients in subnets for which source-based routes are configured Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page Due to MX 15 regressions, the MX may not be able to form non-Meraki site-to-site VPN connections to peers behind a NAT Due to issues still under investigation, there are significant performance regressions. Other Updated the firmware-default scripts used for managing cellular connectivity to match those being provided through the Meraki Dashboard as an out-of-band download. This will not provide a functional difference during normal operation, but may help to improve the consistency of connectivity during some edge-case operations like when the MX is migrated between organizations.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 135 | 2 weeks ago | |
| 87 | 09-10-2019 11:21 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 3 | 428 | |
| 2 | 221 | |
| 2 | 201 | |
| 2 | 461 | |
| 2 | 674 |
