Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Toby
Toby
Getting noticed
Member since May 16, 2019
Jan 31 2023
Community Record
23
Posts
4
Kudos
0
Solutions
Badges
Apr 23 2021
6:43 AM
I'm hoping I've missed something but, why can't the default-information originate be configured with Meraki OSPF? I'm dealing with MS OSPF, MS390 specifically. Tried redistributing the default route which exists on the switch, but that does not redistribute due to what I understand is normal OSPF behavior.
... View more
Apr 23 2021
4:56 AM
Hello! I've been doing some more testing and thinking about this and I've run into a design consideration issue. I've concluded (unless I'm mistaken) that it's not possible to reach the IP address the MS390 use for communication with the cloud via the route which I distribute through OSPF. It is possible to reach the IP address of the interface I've setup as an additional interface on the MS390 which is part of the same subnet as the IP used for cloud communications which is setup so that I may redistribute the subnet throughout the OSPF domain. Is this behavior specific to MS390? EDIT: Since MS390 isolates the control traffic from the data traffic it is not possible to reach the mgmt IP via the OSPF route (even if the SVI created in the MS390 to enable the route to be propageted throught OSPF lies within the same subnet), you're essentially creating a dual-purpose subnet/VLAN with some form of segmentaion invisible to the user, it would make more sense not to allow it at all I think. This also creates a little bit of a problem regarding management since you have to resort to static routing for the mgmt features to work as expected. I can see the benefit regarding security, but it should be an option to let the designer of the network take proper measures to secure the mgmt plane themselves. Imagine we'd like to use the subnet which is used for cloud communications for some internal service, for example SNMP. This means that we have to setup an additional IP address for every MS390 used as a L3 device on the subnet which means that we have to use 2x IP addresses per device if we want to achieve this, is this correct? We could also define a new subnet which is used for internal management services such as SNMP, but if we consider that we might want to expand to using MR devices which can only hold a single IP address. Then we'd have to use different designs regarding management of these devices based on what the hardware is. So for example 1 subnet for cloud communications and another for the internal services on MS390 (or dual IP addresses) and then a single subnet for cloud communications and internal services for MR type devices. Would this be the correct assumption?
... View more
Mar 30 2021
5:57 AM
Okay, thanks for the clarification. That why the SVI and MGMT IP cant reach each other I guess, because of the controlplane vs dataplane (I'm a bit rusty it would seem). I'll have some more labbin done on this, cheers!
... View more
Mar 26 2021
8:41 AM
Hello! I'm brand new to L3 Meraki/Meraki OSPF and have a question. I also tried reading this documentation without understanding why the thing I'm trying to do does not work: https://documentation.meraki.com/MS/MS_Installation_Guides/MS390_Series_Installation_Guide https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices#Layer_3_Features https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing https://documentation.meraki.com/MS/Layer_3_Switching/MS_OSPF_Overview#MS_OSPF Is it possible to set up the uplink network which the MS390 use to communicate with the cloud for participation in the OSPF routing domain? I tried setting up another IP on the same subnet/VLAN under "Routing & DHCP", this newly created interface cannot reach anything, not even the mgmt IP of the MS390 itself. Is there some VRF going on under the hood? I tried this because the mgmt subnet cannot be configured for OSPF participation otherwise. I'm guessing I have to set up the mgmt/cloud uplink outside of the OSPF process with the subnet terminating in a border device?
... View more
Feb 25 2021
1:27 AM
Good answer! I'm wondering if this is documented by Meraki somewhere? Been trying to getting a good grip on exactly how this works, but either the documentation which do exist explains this poorly or I'm just failing at finding the correct documentation.
... View more
Feb 22 2021
1:30 AM
1 Kudo
Thanks for the reply! Would be nice to have some documentation or official confirmation of these things. The native vlan for the MX60 was a good pointer, good gotcha there. So I'll move the MX60 onto the new subnet with the MX100, then trunk the ports on the switch connected to the mx60 with allowed vlan 100 and native vlan 1, then match this on the trunk towards the mx100. Then the management and user traffic will be separated on vlan 1 (native) & 100? I've a follow up question (maybe not befitting here, but it's relevant to the solution so I'll post it). Currently the MX100 is configured to drop untagged traffic, meaning I'll have to assign the native vlan (1) to the port of the MX100 in order for this to work. Is there anything specific which happens when you create an interface and assign it to the native vlan on an MX device, thinking of things like sourcing DHCP messages for example, or anything at all which is good to know? Instead of changing the configuration on the MX100 (enabling the native vlan on the port towards the switch), I'll resort to setting up a new vlan (non-native) and tag that on the uplink configuration on the MX60 instead, this should also result in the end-result I'm looking for, right? From the MX60: This means I'll also have to permit vlan 10 to flow through over the trunks between the MX boxes ofc.
... View more
Feb 19 2021
6:24 AM
Hello! We are currently using an MX60 to concentrate an SSID for remote sites using "VPN: tunnel data to a concentrator". I'm interested in changing the subnet on which the MX60 reside, but I'm having trouble understanding exactly what will happen if I do so. The main thing which is confusing me is the original design (which I didn't do), which has the DHCP server assign the clients using the tunneled SSID an IP address on the 10.44.44.0/24 subnet. I'm suspecting that this design simply didn't consider the monitoring aspect. Been reading this: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Tunneling_and_Layer_3_Roaming_-_VPN_Concentration_Configuration_Guide For starters, I'm a bit confused about "3) Optional:", there is no list of VLANs displayed on the page where I configure the SSID to tunnel to the MX60, there is however a field where I can manually enter a VLAN ID (simply a mistake in the documentation?). I'm also however, unsure what to expect from what I think is the solution, so any help or clarification would be much appreciated. Edit: I found this post which also helps in clarifying: https://community.meraki.com/t5/Security-SD-WAN/VLAN-Config-on-Singled-Armed-concetrator-for-SSID-Tunneling/m-p/66929#M16845 Consider above network sketch, everything is currently set up this way with the MX60 operating in Passthrough mode. The MX100 is acting gateway for the SSID and forwards DHCP requests to the central resources etc. The only thing which is not currently active in the sketch is the "green subnet", this is what I'm trying to achieve. The reason for the change is monitoring, which we cant do for the 10.44.44.0/24 subnet. If I tag the SSID at Remote site X with vlan 100 on the page where I configure it to tunnel to the MX60, what exactly will happen. Is the traffic tagged locally on Remote site X, or when the traffic exits the concentrator? If it's tagged exiting the concentrator (which I'm suspecting), if I then change the switchport which connects the MX60 from access vlan 100 to a trunk and permit both vlan 10 and 100. Following I place the MX60/MX100 on the new "green subnet"/vlan 10 (with MX100 still operating as .1 in Vlan 100). Will the user traffic still continue to flow as currently?
... View more
Feb 2 2021
11:28 PM
Thanks for the link 🙂 I've already read it (should have been clear on that), I've swapped MX devices in the past using the method outlined on that page and are familiar with the general procedure. What I was wondering was if there were any specific considerations which needs to be taken into account when swapping a MX which is configured as a wireless concentrator.
... View more
Feb 2 2021
1:19 AM
I'm guessing this is a somewhat silly question, but I like to lean towards knowing over guessing. I'm about to swap a MX60 used as a wireless concentrator for sites around the globe. I'm assuming there are no special considerations I need to regard when performing a cold swap for a concentrator over a "regularly" configured MX?
... View more
Feb 27 2020
1:11 AM
Nice suggestion! I've been looking at the specs and the 67 indeed have higher throughput specified. Out of curiosity, are the actual hardware specs documented somewhere, such as ram/cpu/storage? I've been trying to find such info but failed.
... View more
Feb 26 2020
5:00 AM
These are the devices which are available for me to work with, and it's a temporary solution.
... View more
Feb 26 2020
4:44 AM
As the picture shows if the "ISP router" goes down or some problem arises with the connection it uses the network will become disconnected. I'm wondering if it's a viable option to add the MX67 to supply a backup internet connection via the cellular of the MX67 for the MX80 at the site as suggested in the picture. This would be done by converting the 2nd Lanport of the MX80 to a wanport and connecting it to a lanport of the MX67. Note that the network is currently operating as the picture shows besides whats contained inside the "Suggestion" box.
... View more
Feb 25 2020
12:12 AM
1 Kudo
This logic only holds true is Meraki is following the implementation of LLDP as per 802.1AB-2016. So to verify if "?" actually exists I downloaded a pcap file from "L3 core" and filtered for lldp. I found only two devices which transmitted LLDP packets on the interface "1" going from "L3 core". To determine how LLDP is propagated i had to look at the RFC 802.1AB-2016, as noted in the downloaded pcap file the destination address is "01:80:c2:00:00.0e" which according to the RFC means "nearest bridge". After reading the RFC, I interpret this as the packet will not be forwarded beyond the directly attached LAN segment. And as only the two stations "L3 core" & "L2 switch" was captured it can be concluded that no other device is sitting between these two devices, meaning that (if I'm not missing something) the "?" does not exist. There can be other reasons that "?" is not showing in teh capture, LLDP could be turned of in the device, or it could be a "dumb device". But I find either of these possibilities unlikely. As I wrote in my initial post, several of the devices which by this view is stated to be connected to "?" shouldn't be, as I investigated all the ports of those devices through dashboard and found no evidence of any such link. It's also unlikely that it's a dumb device since the links "1" are fiber, although I'm still waiting to have this confirmed by someone in person. Not sure if the fact that the "L3 core" is a warm-spare pair of Meraki MS devices is what is causing this weirdness. On another note, pretty much every networking device in this network is Meraki, there are a couple of older 2960 switches, but those are not located any where near where the "?" is represented.
... View more
Feb 24 2020
7:33 AM
Hello, I have an issue where I'm unsure what the "?" device is, I'm not even sure that it's an actual device or if there is an issue with the LLDP feature or even a result of how the network is built. The latest addition to the network are the Warm-spare MX firewalls, per this: https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair they are physically cabled according to "Fully Redundant (Switch Stack)". I've also verified that STP treats the redundant links as they should be treated, both links to the 4x stack just prior to "internet" are blocked, and both links to the "L2 switch" are able to pass traffic. I should add that I didn't notice this problem in the following weeks of installing the warm-spare pair, they've been operating for just over a month. We did however connect the redundant links for the warm-spare MXs last week, after which I also didnt initially notice this problem. I'm not sure exactly when it happened but was alerted to it as of today. "1" These links are actually directly connected between "L3 core" & "L2 switch", (asked a colleague to verify this since I'm not physically at the location). This is the only link information I've been able to collect from this view of all the ones connecting to the "?". Also when I look at the other devices which are supposedly connected to the "?" the uplinks to other switches are connected to actual devices within the network. This makes me wonder if the "?" device actually exist or if this view have failed for some reason? When googling my issue there seems like others have had issues with the lldp and topology feature of the dashboard, any ideas as to why this is happening?
... View more
Feb 7 2020
6:36 AM
Hello, I wonder how the process looks when a warm spare pair MX devices firmware gets upgraded. Is it something like described in the following sentence? The spare upgrades it's firmware, followed by it taking over the master role while the primary MX upgrades and once it's done takes back the master role? In addition, I wonder if it is possible to run one of the two MX devices which forms a warm spare pair on the newer firmware for a period of time before upgrading the spare unit? Im guessing no, but I cant seem to find any documentation on the matter.
... View more
Dec 4 2019
12:19 AM
Okay, I imagined as much. Thanks for the help.
... View more
Dec 3 2019
5:10 AM
Hello, I'm in the process of moving a customer site, and as such a temporary reconfiguration of a site from spoke to hub will be needed. This switchover will likely need to be don during production. I've looked for potential effects on the the network when this is done but was unable to find anything. How big can i expect the impact to be for the network in question?
... View more
Oct 25 2019
2:27 AM
I've tried looking at the documentation but I couldn't find anything regarding this. The question is regarding how MX devices process firewall rules. There are two sections which can apply rules, under "Site-to-site VPN" and then under "Firewall". I'm wondering about order of operations in how the traffic is subjected to the two different types of firewall rules. As an example take the following, a host residing behind a spoke in meraki auto-vpn wants to access https on a host located on the hub network. As far as I gather the vpn firewall rules will be subject for the host traffic when entering the vpn tunnel on the spoke. When traffic arrives at the hub MX will the "regular" firewall rules on the hub MX also be ran against the traffic? Or take another example, we have a host on the hub MX which wants to talk to another host behind a non-meraki VPN peer. Will the "regular" firewall rules be ran against the traffic first and following that the vpn firewall rules?
... View more
May 28 2019
1:22 AM
Bear with me but shouldn't this work without using a separate MX? Since the spokes have a default route back to the hub and the hub have the routes to the non Meraki VPN networks, shouldn't the spoke traffic have reachability to the non Meraki VPN networks?
... View more
May 27 2019
5:22 AM
Hello! We have a customer which currently have an ASA source NAT traffic going into a VPN tunnel to an IP different than the WAN IP. They are migrating to MX and I know that MX don't do SNAT, but I think the same end result can be achieved using the following: On the MX I will create a flow preference which points the interesting traffic to the secondary WAN interface on the MX, this interface will be configured with the IP address that the ASA previously used as the source NAT address. I'm also concerned how much of an performance impact this configuration will have on the MX device. If anyone can confirm this to work it would be great.
... View more
May 16 2019
4:12 AM
Hello! I'm trying to set up a customer for MX going from ASA, but have ran into an issue regarding NAT. It concerns 1:1 NAT, I've tried to set up this rule but it can't be configured since the hosts I'm trying to NAT is not on a subnet configured on the MX device. This is due to how the network is set up today and the goal is to try and make as few changes as possible to the network during the change from ASA to MX. I'm unsure if what I'm trying to accomplish is at all doable and which is why I'm asking this question here. If anyone have an idea on how to do this, I would be very grateful. In summary: Can 1:1 NAT rules be configures on an MX device if the host resides on a subnet which is not configured on the MX device.
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 1 | 1966 | |
| 1 | 2882 | |
| 1 | 3612 | |
| 1 | 3408 |
© 2024 Cisco Systems, Inc.
