Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Chema-Spain
Chema-Spain
Getting noticed
Member since Sep 19, 2017
Dec 14 2023
Community Record
27
Posts
10
Kudos
3
Solutions
Badges
Nov 24 2023
1:08 AM
Thanks! By configuring manual Port FWD for our vMX I believe we'll solve the issue with standard public IPs in Azure regarding vMX HA. Good Point. Agree with you regarding Meraki's guide for HA. First picture shows a dedicated vnet for each vMX and second picture shows a common vnet for all resources... great! I'll try changing the design to include the RS. I come from networking area so I'm highly more confortable with BGP instead of AZ Functions 🙂
... View more
Nov 24 2023
12:51 AM
Thanks you both for your quick responses. Totally agree with you dynamic routing using AZ Route Server would be much better than using Azure Functions. Unfortunately when I suggest using RS it was not accepted even when I pointed out the limitations with AZ Functions, posible false positives, etc.
... View more
Nov 23 2023
8:34 AM
Hi, My only experience with vMX in Azure was a single vMX without defining AvZones (so basic public IP for the vMX). vMX is a also a FW and customer accepted to connect it directly to the internet. Now I need to deploy an HA Pair in Azure and in this case my customer wants to sit it behind a vPalo_Alto cluster. They also want to deploy each vMX in a different AvZone in the Az Region. I'm aware that by specifying AvZone in vMX deployment automatically makes them to use AZ Standard Public IPs instead of basic ones. From a previous Philip Dath's post I also know standard would make HA from primary vMX to the secondary one to need more convergence time in case primary one fails. My doubt is: Provided I deploy the vMX instances (they could share a single Meraki SDWAN subnet or run two SDWAN subnets) the vMXs would try to register into Meraki cloud directly (using Az internet access). Both vMX would send all their traffic towards reserved AZ IP for sdwan subnet DGw. How could I get they both to send their underlay traffic thru the PA cluster? Meraki AZ vMX deployment guide says RT are not needed for sdwan subnets, they could lead to packet loss. Or do you recommend sitting the fw behind the vMXs? At the end of the day the vMX FW function already protect themshelves. PA FW will serve as Client VPN access and would protect all Az resources but the vMXs. Thanks for your help.
... View more
Oct 22 2023
11:44 PM
Hi, Meraki HA VRRP does not run over internet links. You must be sure you have connectivity thru any vlan (lan side) between both MX, as vrrp heartbeat runs over lan interfaces. Please take a look at heartbeat section: MX Warm Spare - High-Availability Pair - Cisco Meraki Is it possible that this lan-side connectivity could be unstable? Provided this is not the case, I can give you any other possible explanation for your flaps. Regards.
... View more
Oct 3 2023
8:34 AM
Hi, per your explanation I assume your HS peer is properly configured. VRRP for HA pair could be flapping in case its hello packets (mcast towards 224.0.0.18) between both MXs are dropped by the switches. Please check this is not the case. Regarding your topology warm spare MX would not have access to internet in case sw1 fails. I guess there must be some cable missing between your SW2 and internet edge routers. Regards
... View more
Oct 2 2023
8:54 AM
Hi, regarding your second question: Meraki Hub can properly communicate spokes even when they do not share a common underlay. AutoVPN in hub & spoke model covers that scenario without nothing special to be configured. You only need Hub connectivity to both underlays. Imagine you have dual underlay spoke and one loses underlay1 at the same time the other loses underlay 2. They could still communicate each other. Regarding your first question: An MX hub in concentrator mode does not allow you to configure static routes. You could theorically run ebgp in the underlay against the PE (asking Meraki to make it available). However, IMHO it would be a case that does not fit with the purpose of positioning a MX. eBGP in Meraki MX is intended for learning local subnets and propagate AutoVPN learnt routes towards your eBGP local peer and still use AutoVPN (and its embbeded ibgp for wan connectivity) MX hub in route mode can be configured with lan side static routes. However I guess it does not even support eBGP over lan yet. Regardless of the hub type, uplinks do not support eBGP. Only AutoVPN runs ibgp among meraki MX peers. Regards.
... View more
Sep 19 2023
8:18 AM
Hi, I try to follow meraki's recommendations for AutoVPN: Auto VPN Hub Deployment Recommendations - Cisco Meraki Concentrator mode in Hub sites make routing easier. You do not have static routes to configure but you only configure the prefixes to be exported into AutoVPN. Both hubs in your deployment could configure shared prefixes and advertise them from both. You can also configure prefixes that are only present in just one hub site. Spokes will choose the first hub in their list for exact prefixes that both hub sites advertise. I'm not aware you can ask Meraki to turn off hub to hub VPN tunnels behind the scene. However, in case it is possible, take into account one hub could lose connectivity with other hub local (not L2 extended) vlans. HTH.
... View more
Sep 15 2023
4:56 AM
Thanks Brash. That is exactly what I wanted to know. 8 hours. Unregistered means not accesible from the dashboard. This could not be such a corner case scenario. An internal meraki issue with device registration or a DNS attach could cause Org MX to lose control plane without losing data plane. Thanks for your help.
... View more
Sep 15 2023
1:37 AM
I see no issues in having an stretched vlan between your DCs. Traffic inside your server vlan would be L2 switched so east-west traffic inside your server vlan would not pass thru Meraki AutoVPN. Of course, this L2 path should be fully redundant (MLAG, for example) in order to avoid issues. In case a local vlan must connect to a server in the stretched vlan, L3 core in your DC will route the traffic. Server vlan must be enabled in AutoVPN. Both hubs would inject it into AutoVPN. I assume your DCs are deployed in concentrator mode. I would recommend your offices to be reconfigured as spokes. Both would have two hubs so traffic towards server vlan would take the tunnel against first hub in the list. So you can chose the preferred hub for any of your offices (if both offices share a common template, then both would have the same hub preference) Regards.
... View more
Sep 15 2023
1:08 AM
Hi, In any SDWAN solution, the orquestrator provides SDWAN devices with the necessary "session keys" to establish data tunnels among them. In AutoVPN, I would like to know the expected behaviour in a concrete situation: I suppose those keys have a valid lifetime. What happens in case a MX is unregistered but its data plane is working fine when its key lifetime ends? How long can I expect AutoVPN could work without contacting to the Meraki cloud platform? Sorry if this topic has already been discussed here. I took a quick look and found nothing. Thanks!
... View more
Sep 11 2023
12:46 AM
Hi, I have not worked with GX family yet so all I can tell you is based in what I have seen in its product documentation. I have only seen a "block website feature" (only to block domains... in case you configure a subdomain it blocks the whole domain) and L3 firewall. So it seems you can only work in a block-list (former black-list) not in a permit (white) list scheme. L3 FW allows you to add permit or deny rules. However it is based in IP prefixes not in FQDNs. I think you are right and an umbrella license would be needed for your requirements. It can be required from the GO Portal itself. Of course, not for free. Regarding the internet destinations your GX is filtering by default: I'm not aware it could be using any kind of cloud-based content filtering. Anyway, in order to be sure about your needs, I suggest you to ask in the Meraki Go Community. Link below (For some reason Meraki and Meraki GO do not share the same portal nor the same community) Meraki Go Community HTH
... View more
Sep 10 2023
11:34 PM
Hi, Salesforce is mainly a public SaaS service (unless you are talking about private connect Salesforce) hence its traffic is not taking the SDWAN overlay. The rule you're are showing applies to SDWAN VPN traffic so it has nothing to do with internet traffic. Every MX sends non VPN traffic as Local Break Out over the underlay path when it has no vpn route to destination. It then takes the default route present in the underlay table. In your case you have two wan interfaces (I supposed both are internet access circuits). Provided your primary uplink is uplink2, then by default Salesforce would take wan2 uplink. In order to force this traffic to take uplink1 underlay, you should configure the proper rules in the table you can see above the one you are showing, up in the same pane. Table: Flow preference/Internet traffic. The problem here is you should configure one rule per each Salesforce prefix you could be using based in your geography. This table does not support domain names but only IP prefixes. HTH. Regards, Chema.
... View more
Sep 7 2023
1:27 AM
I did not mention it could have been even worse to troubleshoot. I've checked this case in my lab (autosummary in place here): NonMeraki prefix 172.30.30.0/28 AutoVPN 172.30.30.0/29, 172.30.30.8/29 In this case all 3 prefixes are seen inactive in spoke RT. Reason? AutoVPN summarizes both /29 in a /28... and that enters in conflict with nonMeraki announcement. This conflict makes you to have no active route at all. You could go crazy in case you are not aware of AutoVPN default autosummarization. I also checked in case you delete one of the /29s from MX hub then both /28 and the other /29 remain active. This is normal as AutoVPN has no prefix to be summarized.
... View more
Sep 7 2023
12:20 AM
5 Kudos
Hi, this post is not to ask for help but to make you aware of a potential issue you might not know when deploying Meraki AutoVPN. Have you ever experience a rare route table behaviour in a MX where some entries you supposed to be active are not? I just have faced this issue in this environment: One Onprem spoke MX - One vMX in Azure Main path is AutoVPN. Manual BU is non-meraki tunnel against AZ VPN GW. (static entries in AZ subnet RT pointing onprem prefixes towards vMX Virtual Appliance to be removed in case of any issue with AutoVPN tunnel) As Meraki does not allow to publish exactly the same prefixes from both AutoVPN and IPSec tunnel, in non-meraki tunnel we published the real prefix masks and in AutoVPN we configured more specific prefixes for AZ subnets. This way we expected to see the more specific AutoVPN prefixes as active in onprem spoke MX. However, that was not the case. Real subnets in Azure 172.30.6.0/24 and 172.30.7.0/24. As mentioned above, both configured as /24s in nonMeraki tunnel against AZ VPN GW vMX hub injected subnets over AutoVPN 172.30.6.0/25, 172.30.6.128/25, 172.30.7.0/25, 172.30.7.128/25. Result? Spoke route table showing all /25s inactive, both /24 prefixes active, traffic from onprem to Az taking nonMeraki path instead of AutoVPN. After opening a ticket, Meraki explains me what happens here: Autosummarization in AutoVPN is enabled by default. So all 4 /25s are summarized as /23 according to their explanation. However, you never see this /23 prefix (nor active nor inactive, it is not there) in the spoke route table. After Meraki disabling autosummarization behind the scenes (only them can do it and applies to a whole Meraki Org) all /25s prefixes became active and traffic start behaving as expected. At this point I recalled I suffered a similar issue in the past in a customer with 2 hubs. All spoke lan addressing were inside 10/8 and at the same time some prefixes inside 10/8 were also present in the hub sites. We configured the hubs to inject 10/8 prefix in AutoVPN and the result was every spoke only learnt the 10/8 and not other more specific prefix. After opening a ticket they disabled autosummarization and only then every spoke started to learn other prefixes. I suppose Meraki applies Autosummarization in AutoVPN by default in order to ensure large deployments are properly managed without filling MX route tables. However, in many cases I think it would be at least something to be configured by the customer. I'm going to open a make a wish for this... HTH. Regards.
... View more
Jul 30 2023
11:38 PM
Hi, it is mostly webex calling. Only a few fixed Cisco IP Phones. Voice vlan is vlan 8. Customer already has a qos rule for that vlan (only entry configured). Instead of trusting incoming dhcp they are remarking to EF. We are going to tell them to better trust dcsp or even change protocol any to webex-calling udp and cisco RTP ranges and remark both as EF. This way we ensure signalling is not marked as EF. Thanks!
... View more
Jul 28 2023
2:06 AM
Hi, I have always thought Meraki MS would enqueue Real time traffic (i.e. EF DSCP flows) in a dedicated Queue by default. However, reading Meraki documents they say all traffic is sent to default queue in case you do not enable qos. In a MS there is not a button to enable qos so It seems you only enable other queues (there are 6 queues) when you add any qos rule. Once you do this, it seems to start managing the default DSCP to CoS Queue mapping table (you can then edit this table if default mappings do not completely fullfill your requirements). Is there any way to check qos scheduling in order to see packet loss or packet delay in Meraki MS FIFO queues? I think it is not possible, just asking to ensure I'm right. Another doubt is what a MS does with any incoming DSCP packet field not explicitly trusted or remarked in a Qos rule. Would MS reset DSCP to 0 or would it keep it transparently? I can only see in Meraki docs all traffic not matching any qos rule is sent to Cos 0 default queue. I have a very large customer warehouse with a non recomended MS cascade topology where mobile wifi calls (roaming in place) are suffering poor quality. We have been able to slightly improve voice quality after running a wifi site survey and some fast roaming and other wifi stuff. However, I was wondering maybe using a dedicated queue for voice would also help here. In all other customer we had never configure QoS in MS network. Mostly because I thought EF traffic would be treated in a dedicated queue. However, we have never had customer complains about poor voice quality (never have dealt with such a huge warehouse) Thanks
... View more
Jul 7 2023
2:08 AM
Thanks for your quick response. Understood, provided I need anyconnect VPN, I must deploy vMX with no Av Zone. Still a couple of doubts related to vMX redundancy in Azure: In case you must deploy vMX in two different AZ Regions, then I think you can't solve the HA using Azure Functions. I think best approach is deploying two standalone vMX hubs, each inside one of the peered Regions. Ok, you have to pay for two meraki licenses. However, you do not have to worry about complex HA scenarios or adding the route server (still do not know how vMX can run BGP against it as I read it required BGPoIPSec) vMX in Region 1 would publish vnets in Region1 and vMX in region2 would inject vnets in Region 2. Inside Azure, UDRs for subnets in Region 1 would route the on-prem prefixes towards vMX in Region 1. UDRs for subnets in Region 2, towards vMX in Region 2. All of this is a simplification, because in real world there is a FW applicance between server vnets and the vMX. So UDRs would point to the FW and FW to the vMX. It should work. In this scenario I am aware subnet UDR for the vMX would require specific routes towards the customer server vnets towards the FW appliance. So AutoVPN decapsulated traffic will be sent to the FW from the vMX. However, I have to study how the vMX will send outgoing traffic to the FW. When you deploy a vMX, Azure provides you with a basic ENI so you automatically get Azure internet access and vMX registers with Meraki cloud. So once registered, I will need to modify it to make control and also AutoVPN and Annyconnect traffic to be sent to the FW (as we do for on-prem Hubs). Azure assigns you a dynamic IP in your vnet and sets Azure vnet-reserved DGw .1 as vMX DGw. I suppose changing vMX subnet UDR to route 0.0.0.0 towards the FW IP would work: Traffic towards vnets would pass the FW, traffic towards internet would also be sent to the FW. And I guess Azure would still apply source nat to internet traffic sourced by the vMX vnet IP. Is my assumption right?
... View more
Jul 6 2023
5:04 AM
Hi, has anyone tested the BGP option against de AZ Route Server? I thought Route Server could only run BGP as BGPoIPSec, I think I've read this somewhere. Same as AWS transit gateway which I think it only can run BGPoGRE. Maybe I'm wrong, because taking a look at the provided link BGP seems to be configure natively in the Meraki dashboard. What if no option for deploying vMX (active and spare) using Av Zones? My customer requires Anyconnect access to the vMX cluster when deployed and I've read it is not compatible with the use of Av Zones. Are you aware of current state of this restriction? Provided it is still in place, I should deploy both vMX with no Av Zone support. Thanks!
... View more
Jun 28 2023
5:06 AM
Hi, then no NSG is required for vMX in Azure. I had seen in other post, https://ccietbd.com/2022/04/20/basic-anyconnect-on-azure-hosted-meraki-vmx that Anyconnect would not work unless you configure inbound rules to allow TCP/443 and UDP/443 for vMX in nic/subnet associated NSG. However, I saw that post this morning, after deploying a vMX in Azure last week without associating any NSG. And Anyconnect worked fine. Maybe Meraki could have changed that behaviour recently. Thanks!
... View more
Nov 4 2022
12:12 AM
Thanks for your response. Yes, I see Meraki has recently added the SP-initiated SAML option that requires the new early access configuration. However, we will still deploy the IDP-initiated unless we could see any advantage using the SP-initiated.
... View more
Nov 3 2022
1:15 AM
3 Kudos
I think I can answer myself: As it is IDP initated model, you first go to your IDP and then redirected to the dashboard only in case you pass your IDP authentication. So no issues here: The customer would go to directly to authenticate against its IDP and our users to our Az AD. Sorry, I just think it deeply once I had opened the topic.
... View more
Nov 3 2022
1:08 AM
Hi, We have a customer Org in a shared management scheme (both customer and our accounts have write privileges). We already had deployed SSO for our corporate users (validating in our Az AD IDP), leaving customer users as local managers in the dashboard. Now customer is requiring SSO too. I've seen you can configure multiple IDPs at Org level. So we will deploy another IDP for the customer. However, I do not know how it works. Both SSO would follow the IDP initiating model. I've seen nothing in the dashboard that could associate each @domain to their own IDP. I've seen nothing in the meraki documentation or community so far. Should I assume each time a user logs in the dashboard it would try to authenticate in first IDP in the list and in case it is not authenticated it will try with the second one? Thanks for your support.
... View more
Sep 18 2018
2:22 AM
2 Kudos
Hi, Sorry for reopen this conversation. IMO, this paragraph in both supplied documents: "In a DC-DC failover design, a spoke site will form VPN tunnels to all VPN hubs that are configured for that site. For subnets that are unique to a particular hub, traffic will be routed directly to that hub so long as tunnels between the spoke and hub are established successfully. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable." for me it means no real active-active is provided in case both hubs have to export the same subnets. OK, you can Split the spokes and configure 50% with hub1 as primary and 50% with hub 2 as primary. Doing so, you won't have the traffic going directly to the desired hub in all cases. It would be great if you could set the hub priority in a subnet basis. This behavior makes me think Meraki solution was deployed with dual-internet solutions in mind and not for hybrid MPLS-Internet. Provided you have hybrid solution, your hub sites (per cost reasons) usually have one Access per "color", not two. So you need hub 1 to also inject all hub 2 subnets (and viceversa) in order to cover a hub's single Access sortage. Usually some of your spokes are single Access... Another thing that makes me think Meraki does not fit well with mpls is the fact all MX wan interfaces need to reach the Meraki cloud. For Internet Access this is not an issue. For MPLS...a Service Provider has to convince his customer to dedicate some Bandwidth from his DC internet Access for your solution's control/management traffic (aggregate for all your mpls sites)... or you have to deploy a dedicated internet Access at your SP Network for this. Regards, Chema.
... View more
Sep 25 2017
6:25 AM
Thanks for your help. Unfortunately, we need the MX's in NAT mode and according to your useful link Meraki states it is not supported when configuring L3 Roaming option on the AP profile: "This configuration is designed for use with an MX in passthrough/concentrator mode, tunneling to an MX in NAT mode is not supported." So we have finally decided to change our design, keeping the MX-600s nodes just as a L2 cluster FW and establishing the VPN tunnels from router to router in a hub and spoke DMVPN solution. This more classical approach ensures scalabitily would not be an issue. We have successfully tested the MX600's as L2 FW cluster at our lab. Thanks again for your help.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 507 | Sep 10 2023 11:34 PM | |
| 604 | Jul 30 2023 11:40 PM | |
| 1162 | Nov 3 2022 1:15 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 406 | |
| 3 | 1162 | |
| 2 | 20319 |
© 2024 Cisco Systems, Inc.
