Community Record
23
Posts
7
Kudos
2
Solutions
Badges
Nov 18 2021
2:33 PM
I think I already know the answer to this, but I was not able to find this in documentation or on any other community post. Does the Meraki MX Appliance, when running in Passthrough, VPN Concentrator mode, do route summarization before it advertises the connected routes to an upstream router? For example. VPN Network 1 - 10.1.0.0/24 VPN Network 2 - 10.1.100.0/24 VPN Network 3 - 10.1.50.0/24 Can those be summarized into a 10.1.0.0/16 when advertised to an upstream router (from the MX VPN hub) or is it the upstream router's responsibility to summarize the routes before advertising then on word to the rest of the network? I'm thinking that the Meraki VPN hub only advertises the routes it learns through the VPN connection and does not do any route summarization. Secondary question is, I know that there are certain things that Meraki support can enable by request. Is this one of those things?
... View more
May 21 2021
11:30 AM
It was around 2008 and I just landed my first full time networking job. Prior to my arrival, the company had replaced their analog phone system with a 100% VoIP solution using Shoretel. They were experiencing a lot of call issues between the main office and a call center that was about 1/2 mile away. They had a redundant network set up where the primary link was a line of sight radio connection with a T1 as a backup. The primary line of sight radio was an antenna mounted on the top of the main office that shot to an antenna on top of a 20+ story building downtown. In what we called "the turret", there was a small 8 port switch that connected to a second antenna that shot down to the building where the call center was located. I spent weeks working with Shoretel and Proxim (radio vendor). We replaced antennas, combed through the phone system looking for configuration issues, and even replaced that small 8 port switch, but nothing resolved the packet loss and voice quality issues. Finally, I read the data sheet for the Proxim radio and found that it used "Time Division Duplex". For you kids out there, this is where for one period of time, the radio will send and for another period of time it will received, but it will never send and receive at the same time. It's amazing what you learn if you just RTFM. 🙂
... View more
Apr 12 2021
7:58 AM
@Aaron_Wilson I think if you are talking about singular failovers, then yeah, there could be some convergence times. However, we run redundant everything. There are 2 edge routers connected to a different MPLS each. Those are running eBGP through the MPLS to the peers in our data center and to 1 of our call centers that acts as a backup for our current Cisco telephony system. They are also peering with each other for link state information. Those connect to 2 core routers, which for the most part, are running EIGRP and those are peered with each other. There are 2 WAN encryption routers that connect to the core. Those build tunnels from the office to the data center and the call center that has the backup telephony system. Those are using iBGP for the tunnel formation and also peer with each other for link state information. There is also a pair of firewalls in there for edge security. That creates an A and a B path. A is preferred from a routing perspective. There is a total of 6 Cisco routers that are used in that deployment. What I was hoping to do is remove a lot of the complexity by reducing the functionality to a pair of MX250s or MX450s. Simply replace the core routers, WAN encryption routers and firewalls with those MX appliances with the security bundle enabled on them. That does bring up a different question. Can the MXs be configured in a traditional HSRP configuration like what one may configure with a pair of Cisco 6500 core switches. Basically, can a virtual default gateway be configured between a pair of MXs not in HA for each VLAN? If I can get around the HA (warm spare) failover timers, then this may be again be an option. CC: @PhilipDAth
... View more
Apr 12 2021
6:54 AM
@PhilipDAth I understand the likelihood of an HA failover happening is quite small, but as @Aaron_Wilson mentioned, I have been in similar situations. In a previous life, we had redundant ACS servers managing wireless authentication. We lost 1 due to a hardware failure and it had NBD RMA. About 6 hours later we lost the 2nd to a hardware failure and had to have Cisco expedite us an appliance because the other RMA on the previous one would not happen until the next day. While unlikely, it does happen. In our case, at our peak time of the year, we are taking 300 - 500 concurrent phone calls in a single call center. If an HA failover happens, we would drop that many calls which could turn out to be a loss of around $100,000 in that 30 seconds.
... View more
Apr 9 2021
1:59 PM
1 Kudo
Thanks @PhilipDAth. In our situation, even a 30 second call outage that could potentially cause dropped and missed calls is something out sales team cannot live with. I have read a lot about VRRP, HA, etc., and suspected that there would be issues, but I needed a second opinion.
... View more
Apr 9 2021
7:02 AM
We have a number of call center offices and are toying around with the idea of migrating everything to Meraki. We are also migrating to a cloud based telephony system. I read a few other community posts dealing with WAN link failover and how VoIP calls transition between a primary and secondary ISP. My question is, how do calls transition between a primary and secondary MX in the case of a hardware failover? Below is the documented timeouts. Am I correct to assume that if there is a hardware failover that we may lose calls for up to 30 seconds? Am I also correct to assume that any call that was established through the primary MX would be dropped?
... View more
Feb 16 2021
8:44 AM
1 Kudo
After weighing options like spinning up a csr1000v and other things, we decided to implement an ASAv firewall in AWS. This could be done with PaloAlto and other devices. This gets us around the need to do BGP peering as we have done in other traditional data centers. This should satisfy the routing issue by having a single default route from the vMX to the firewall and the firewall with a default route to the Internet and routes to our internal AWS resources. We also have an ASAv that is used for RA-VPN in AWS so putting both the vMX and the RA-VPN ASAv into a DMZ made a bit more sense for us. This provides an additional layer of security outside of what we may have configured with the AWS Security Groups. Below is a basic diagram for anyone else looking for a deployment solution for vMX in AWS.
... View more
Jan 28 2021
1:07 PM
Another idea we have been discussing is spinning up a Cisco CSR1000v inside the same VPC and BGP peering off of that. I was looking for more of an AWS native solution instead of adding virtual routers into the mix. I saw that AWS has BGP for Direct Connects, but haven't found any other document that states where else in AWS BGP is supported.
... View more
Jan 28 2021
1:00 PM
Hi Philip, I was hoping you would show up here. This is not a saved configuration, but when I set this vMX to Hub, I have the option to enable and configure BGP. I have not saved this to know if it will take. I will be doing that in a change window tonight. My plan was to keep this as simple as possible. I read your article about HA and the use of Lambda script. We are opting to do this as if they are 2 different hubs. They are both in the same AWS VPC, but in 2 different AZs. The idea is to configure the MX and Z3 to have both hubs listed like a primary and standby hub. We do that today with MX100s in 2 different data centers.
... View more
Jan 28 2021
7:55 AM
1 Kudo
Thanks for the reply UCcert. I just sent am email to my account manager requesting the assistance of an SE.
... View more
Jan 28 2021
7:36 AM
Meraki Support hasn't been much help either. All they have done is directed me to the BGP configuration guide. https://documentation.meraki.com/MX/Networks_and_Routing/BGP The AWS deployment guide also does not contain information about routing other than adding the AutoVPN subnets to the VPC route table. That appears to be more of a static routing configuration. https://documentation.meraki.com/MX/MX_Installation_Guides/vMX_Setup_Guide_for_Amazon_Web_Services_(AWS) The issue with that is we are in a transition between physical data centers and cloud. I need the subnets that are used by our office or Z3s to be advertised from the MX or vMX that they are connected to. Adding a blanket static route to a VPC would seem to break dynamic routing.
... View more
Jan 28 2021
7:20 AM
There was another post about BGP with the MX that briefly talked about a cloud deployment. https://community.meraki.com/t5/Security-SD-WAN/BGP-Configuration-on-MX/td-p/28710 We have 2 physical data centers that we are decommissioning and moving everything into AWS. In both of those we have BGP peering enable and working great. We have spun up 2 vMXs in AWS. I am about to enable those as VPN Hubs this evening, but I am concerned that they will not route correctly. I have been looking for documentation about how to do BGP peering in AWS. The only documentation I have been able to find pertaining to BGP in AWS deals with Direct Connects, which is not what I need. Has anyone gotten the vMX to work in AWS as a One Armed Concentrator for VPN termination using BGP? If not using BGP, how did you deploy it so that it would route traffic to the internal networks, but still be accessible from the outside?
... View more
Dec 18 2020
8:04 AM
I opened a case with Meraki TAC. We have multiple orgs, but only 1 org contains the access points. The other org is legacy from an acquisition. I had assumed that the only place that the "Login IP ranges" needed to have the external AWS IP address was the org that contained the APs. After adding that same AWS IP to the other org, Orion was able to pull the list of orgs to where I could select the one that had the APs. The solution is to ensure that the public IP Address from Orion is entered into the Login IP ranges in all orgs if one has multiple orgs.
... View more
Dec 17 2020
2:23 PM
Here is some additional information. We ran the external connectivity test from Orion and to shows that https://dashboard.meraki.com is reachable.
... View more
Dec 17 2020
12:21 PM
I saw that there was another post earlier this year for this same issue without a resolution. https://community.meraki.com/t5/Dashboard-Administration/Meraki-Dashboard-Integration-with-enterprise-Solarwind/td-p/74272 We spun up an Orion server in AWS. I have followed the following instructions for monitoring Meraki APs in Orion. https://documentation.solarwinds.com/en/success_center/NPM/content/npm-monitor-meraki-devices.htm I see in both the Firewall information that API requests go to api.meraki.com. However, when selecting "Meraki Wireless:API" in Orion, it defaults the Polling Hostname to dashboard.meraki.com and it is greyed out. The hostname cannot be change to api.merkai.com. When I add the API key, I get an error message that it "Failed to get a list of organizations". To rule out an issue with the API key, I revoked the previous key and generated a new one. Both did the same thing. From the same host that is running Orion in AWS, they have brought up a web browser and are able to get to dashboard.merkai.com. I don't believe that 443 outbound from the AWS host is being blocked. I also looked at Solarwinds support pages. For older versions of Orion (12.1 and 12.2) they noted issues with TLS versions. We are running a 2020.x version. Their other note was setting up Orion to use TLS v1.0, but it looks like Meraki does not support TLS v1.0 since 2018. https://support.solarwinds.com/SuccessCenter/s/article/Meraki-monitoring-Failed-to-get-list-of-organizations-in-NPM?language=en_US Has anyone ran into this issue and found a solution? I am going to go back to my AWS team and see if there is an access policy there that may be blocking this.
... View more
Nov 27 2020
6:06 AM
Aaron, Below is a link to Meraki's documentation for MX Warm Spare - High Availability. https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair The document contains 2 different diagrams, neither of which show a direct link between the MXs. Also, my configuration uses the MXs in One Armed Concentrator mode for VPN termination. That only uses the uplinks for connectivity, also noted in that document. Also, in the following community post the accepted solution notes that when having a connection between the MXs, it can force traffic through the spare as spanning tree my block the port to the primary MX. https://community.meraki.com/t5/Security-SD-WAN/How-to-cable-MX-amp-MS-for-HA/td-p/22765
... View more
Oct 7 2020
10:55 AM
2 Kudos
The thing to remember about a FEX is that it works just like a module in a chassis switch. When connecting a FEX, the configuration is done on the parent switch. In your case, you have a FEX connected to 2x 9ks so both 9ks are acting as the parent. Both 9ks have to have the same identical configuration for the FEX. The below link discusses configuration sync and Active/Active FEX topologies. It is specifically for the N5k, but the theory and design should be similar for N9k. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/operations/n5k_config_sync_ops.html Config-sync is how you can synchronize the FEX configuration between the 2 9ks as long as they are running as a vPC pair.
... View more
Oct 6 2020
8:58 AM
Is the Uplink port on the MX250 configured with the same VLAN as the access port? If you have a VLAN specified on the Uplink port of the MX250, have you tried with leaving the VLAN field blank? Edit: I double checked my configuration which is working. The switch port on the Nexus side is an access port. interface Ethernet1/XX switchport switchport access vlan XX no shutdown The uplink port on my MX100 is not configured with a VLAN tag. I have ran into issues with this before whether to VLAN tag or not.
... View more
Oct 5 2020
3:44 PM
That was the issue I ran into when contacting Meraki support and my Meraki account rep. There was no documentation for connecting Meraki to Nexus running vPC. Since this thread has been solved, I would recommend starting a different thread as I believe the solution your your issue will be different.
... View more
Sep 9 2020
8:47 AM
1 Kudo
I was able to implement this and it works. I did not need to create a separate VLAN. We had an existing VLAN that had an SVI on the upstream VPC Nexus switches. That VLAN also has the interfaces used by the routers that I am eBGP peering with along with the interfaces to the firewall where Internet traffic flows. While I was not able to get a validated design from either Cisco or Meraki support, I do have it working in our environment.
... View more
Sep 2 2020
8:01 AM
1 Kudo
I will find out tomorrow after we get it racked and powered on in our data center.
... View more
Aug 20 2020
8:46 AM
I found another thread with a similar topic about MX-84s connecting to Nexus VPCs. I am looking to deploy 2x MX-100s in One Armed Concentrator HA mode for VPN terminations. I did this in one of our data centers where our core is not using VPC and was able to get it up and running rather quickly. However, in our other data center, the entire core is Nexus VPC. Below is a basic diagram. My understanding is that in One Armed Concentrator mode, the Internet 1 interface is the only one used. It is used for Ingress and Egress traffic as well as the HA heartbeat. Nexus switches have a Peer Link between them. That is used for control plane messages and does not forward traffic. My concern here is that the HA heartbeat will not be seen. The other switches connected to this VPC core are also Nexus and also in VPC mode. The HA heartbeat from the secondary MX100 would have to traverse the switch that it is connected to, down to another switch that has a VPC port channel with both of these cores, then come back up the other nexus switch in order to see the primary HA MX 100. I have asked Meraki Support and my Sales Team if this is even possible. The reply is that this may not be a supported topology. As a work around, I have thought about not deploying both MX-100s in HA, but rather as 2 separate VPN hubs. I would not use the VIP. On the spokes I would define both hubs. I am sure that this would work, but it is not what I consider ideal give the time to transition between hubs if there is a failure. Has anyone deployed One Armed Concentrators in HA mode connected to Nexus switches running VPC?
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 8386 | Feb 16 2021 8:44 AM | |
| 3526 | Dec 18 2020 8:04 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 4565 | |
| 1 | 3880 | |
| 1 | 8386 | |
| 1 | 8582 | |
| 1 | 7029 |
