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
2 weeks ago
Community Record
31
Posts
10
Kudos
3
Solutions
Badges
a month ago
Hi, Finally I got the feature visible after Meraki TAC configured it behind the scenes. Note first time they only configured support for subnet-to-subnet NAT (I checked it worked fine, only natted subnet was present in hub table), when trying to configure Many-to-1 nat, it failed. After contacting again with the TAC engineer both options were available. This is what I saw: I confirm Many-to-1 nat works fine for Spoke2 site (the one not associated to any template). Regarding Spoke1 site, it works too... however, what dashboard reflects is quite strange: First I deassociated spoke1 from its template (selecting config retention). Then I configured Many-to-1 nat for the subnet. It worked fine, hub site learnt the /32 natted and did not see the private /24 prefix. Fine! I reassociated the network spoke1 to the template. As the subnet is configured as unique in the template, spoke1 changed its subnet to a random one. I configured the proper private /24 addressing and... hub learnt the /32 natted IP. However, nor the template nor the spoke1 show this nat anymore. As a summary: For sites not associated to any template, both subnet to subnet (same mask) and Many-to-1 NAT work fine. For sites associated to template, It also works. However, It is difficult to manage as at the end of the day you do not see what is configured. Nat is not shown anywhere in the dashboard, even when you see the natted prefix in AutoVPN neighbor table. I guess in case you need a change in the natted IP/prefix, you would need to deassociate the network from its template, apply the changes and make the association again. IMO NAT over AutoVPN is not as flexible as what a router or dedicated fw can support. We had customers where you need a mix of dynamic and static entries. This kind of corner cases I guess they won't work here.
... View more
Nov 18 2024
7:31 AM
Still not sure regarding this feature can make it work as needed. And there is another ingredient that would add complexity for sure: having affected sites associated to templates. It could be cumbersome. The fact is templates are the base and strength for Meraki deployments. Asking Meraki TAC to enable the feature in a template, once done from their side, the only option I see as available is natting the internal subnet using same mask. No way to configure many to one NAT. I have asked whether it needs something else from their side to make it visible. I still do not have clear whether that translation for AutoVPN traffic could be 1:1 as it indeed can be configured for internet traffic in port fwd designs. I just have seen there is a kind of local override to configure at network level when site is associated to template. However, I'm not sure it would be enough. Any ideas? Thanks!
... View more
Nov 12 2024
7:20 AM
Hi, Thanks for your response. Source could be any private IP from a class B 10.X/16 addressing.
... View more
Nov 11 2024
4:24 AM
Hi, I have a customer with a particular requirement for AutoVPN traffic. Their current network is comprised of remote sites sharing lan addressing so in their current non-sdwan solution the branch routers are running PAT to ensure each site is presented in the network with an unique /32 IP. They have Meraki switches and routers and they are planning to add Meraki MXs to run an SDWAN network. I was happy when discovered meraki allows a hide feature (only Meraki staff can activate) to apply 1:1 or 1:n VPN subnet translation. In my case, 1:n would fit perfectly. However, I just have discovered they have an internal server in each site that has to be reachable from outside (coming from their private network, not from the internet). It made me think in having both a 1:1 and 1:n VPN subnet translation in place on each remote site. The server hosting this application is sharing local lan subnet with all other devices and it is not a dedicated server for this particular application. The document does not reflect whether it is possible to run both 1:1 and 1:n at the same time. In case it were possible, it is not clear the inside address could be present in the 1:1 transalation once it is part of the 1:n translated subnet. Using Site-to-site VPN Translation - Cisco Meraki Documentation If both premises were successfully accepted by remote MX, I guess it could work: Outbound sessions from the internal server (and their responses) could use the 1:1 translation rule. Inbound sessions against the 1:1 "public" IP would be set to the internal server. No other inbound sessions are required. Outbound sessions from all other servers would be srcnatted into the PAT site IP address. I'm going to ask Meraki for activating this feature in our lab. Prior to this, I was wondering whether you have a similar scenario in place. Thanks!
... View more
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
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 1120 | Sep 10 2023 11:34 PM | |
| 1461 | Jul 30 2023 11:40 PM | |
| 2119 | Nov 3 2022 1:15 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 784 | |
| 3 | 2119 | |
| 2 | 24713 |
© 2024 Cisco Systems, Inc.
