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 DennisS
Community Record
16
Posts
2
Kudos
1
Solution
Badges
No, guests are simply provided pre-printed credentials for the captive portal which is more than adequate. The challenge is managing corporate user WIFI experience against compliance requirements, because of this, we'll likely continue using ISE.
... View more
We're looking to manage corporate employee & guest (captive portal) WIFI access. We're doing this today via ISE a) it's kludgy and b) we may be moving away from ISE altogether. Corporate users are simply looking for the "hotel" experience where they connect, enter a userid & password and they're in.
... View more
Hi, As the subject states, are there limitations/pitfalls to using Meraki Cloud Authentication to manage SSID access? User credential mgmt. looks forward but curious: Are there limitation on the number of credentials that can be created? There doesn't seem to be a way to perform a bulk add? Is there a Marketplace app that's better? Thanks
... View more
Nov 8 2022
6:57 AM
Hi DouggieFresh, How's this solution been working for you ever since it was deployed? You mentioned you needed to create a separate network for the MX84. Is that because you have different MX models in your existing network already and Meraki won't allow you to add a non-compatible model? We're going to run into the same issue. The network will have a pair of MX95 in HA mode with a primary & backup MPLS uplink to our data centers. The challenge is, how do we accommodate an internet circuit for local internet egress...
... View more
Oct 16 2022
9:01 AM
2 Kudos
That's not possible to control from the spoke side... That's the conclusion I'm coming to. The minute a unique prefix is advertised from one DC, spokes could end up taking the backup hub connection. And because our DCs exchange routes, DC "return" traffic prefers the spoke's primary AutoVPN connection due to MX prepending. Not a big deal right now since our DCs are the only egress points for internet traffic (did I mention this is a SDWAN MPLS deployment) so we simply advertise the default route to branch offices. Later on when we setup local internet egress, we'll need to advertise the same RFC1918 prefixes to spokes and let the DC COREs forward traffic accordingly. It's not idea since we'd prefer branch traffic to go directly to the respective DC but I don't see an alternative setup.
... View more
Oct 16 2022
7:43 AM
We stumbled upon asymmetry while testing failover scenarios.
... View more
Oct 16 2022
7:42 AM
Our DC concentrator is setup the way you described except route advertisements are conducted from our COREs. eBGP between CORE & firewall eBGP between firewall & MX As expected, the backup DC concentrator prepends the branch/spoke prefix "towards" the DCs properly. The problem is from the spoke end. How can I prevent a spoke from taking the backup AutoVPN connection if it learns a more specific prefix from it.
... View more
Oct 16 2022
6:14 AM
Hi Allesandro, The only configuration we can control from the spoke side is hub priority, the nearest DC is the primary. What we're seeing is what's explained in the DC-DC Deployment guide In a dual- or multi-datacenter configuration, identical subnets are advertised from each datacenter with a VPN concentrator mode MX... For subnets that are unique to a particular hub, traffic will be routed directly to that hub. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable. What would be idea is, spoke MX's exclusively select the highest priority hub except during an outage. Additional background... our Security Team would like to deploy an internal firewall between our DC CORE switches & MX concentrator. Firewalls will drop asymmetric traffic.
... View more
Oct 15 2022
5:21 PM
We have East & Midwest data centers. The DC are linked together with P2P circuits and we're running BGP between them for dynamic routing. Branch office MXs have AutoVPN tunnels to each DC Primary AutoVPN is the nearest DC & backup is the farther DC DC MXs advertise a default 0.0.0.0 route to each branch office If a Midwest branch needs to access a East DC resource, traffic flow is symmetric: Branch primary AutoVPN tunnel => Midwest DC Midwest DC => P2P => East DC Return Traffic East DC resource => P2P => Midwest DC Midwest MX AutoVPN tunnel to branch We encounter asymmetric routing when we advertise a specific prefix from one DC. For example, we advertise 10.1.1.0/24 prefix only from East DC MX. Same Midwest branch needs to access a 10.1.1.x East DC resource, traffic flow is asymmetric: branch backup AutoVPN tunnel => East DC Return Traffic East DC 10.1.1.x resource => P2P => Midwest DC Midwest MX AutoVPN tunnel to branch Is it possible to setup the backup AutoVPN solely as a backup connection should the primary tunnel go down? Would source based default routing be a possible solution? https://documentation.meraki.com/MX/Networks_and_Routing/Source_Based_Default_Routing#:~:text=Source%2DBased%20Default%20Routing%20is,a%20device%20on%20the%20LAN
... View more
I upgraded 2 & 3 stacks all together without issue. My hunch is, as the number of member switches increase the greater the likelihood a member switches doesn't recover quick causing other(s) to not come up cleanly.
... View more
Our largest stacks have 5 member switches operating in layer-2 mode. The first and last switch members have an uplink to our traditional Catalyst switches e.g. SWI-1 (uplink discarding) SWI-2 SWI-3 SWI-4 SWI-5 (uplink forwarding) 1st upgrade, scheduled the whole stack to be upgraded at the same time, 2 member switches needed to be power cycled 2nd upgrade, I staggered the switch upgrades: 1&2; 3&4 then 5; 1 member switch needed to be power cycled 3rd upgrade, I shutdown the discarding uplink connection then staggered the switch upgrades: 1&2; 3&4 then 5; the whole stack needed to be power cycled The next attempt, I'll stagger each switch individually. Are others finding the same inconsistent results? This becomes an issue for offices without IT presence.
... View more
Mar 26 2022
10:59 AM
Thanks for the suggestion but it didn't make any difference on the PC. We also dropped the MTU on the MS350 stack, same results. We hopped on a Web-ex with Meraki support and it appears the MX67 isn't forwarding the TLSv1.2 negotiation between the client & Citrix front end server (sits behind an F5). What's odd is, there are other TLSv1 & v1.2 convs from various devices that are working fine. Meraki is reviewing logs and we're waiting for next steps to try.
... View more
Mar 25 2022
8:51 AM
We're currently testing SDWAN connectivity across our MPLS WAN. At our branch location we have our MPLS circuit terminating into a MX67 MX67 connects to a downstream MS350 stack At our data center, a MX84 pair sits behind our traditional Cisco routers running in concentrator mode AutoVPN tunnel is established between MXs; connectivity is across our MPLS so no firewalls to traverse From a PC at the branch location I run Citrix Workspace then select a published app. It sits there thinking for 2-3sec then does nothing. Tried this several times. We took a packet capture from the MS350... TCP handshake between the PC & Citrix server is good, client starts TLSv1.2 connection, keeps retrying until the Citrix server resets the connection. We rolled everything back to traditional MPLS and performed a packet capture... client starts the TLSv1.2 connections followed by the Client Key Exchange and so on until the published app. opens. Anyone run into this before? Thanks
... View more
Mar 14 2022
5:59 PM
This sounds similar to what I'm trying to test between our data center & a branch location. DATA CENTER We plan to deploy a pair of MX87 in HA Concentrator mode All branch office internet traffic back hauls to the data center across a pair of MPLS backbones BRANCH SITE Dual MPLS circuits terminating to dedicated traditional Cisco routers The plan is to deploy MX routers to replace the traditional routers I'm testing with a MX67 at the branch site. I setup ports 1 & 2 as internet connections & assigned each port the IP address of each CE router I disconnected the MPLS circuit from each routers and plugged them into ports 1 & 2 The MX67 never connected to the dashboard If I understand your solution correctly, I should... Configure ports 1 & 2 as LAN access ports Assign each to a unique Vlan then plug each circuit into ports 1 & 2 Ports 3 - 5 can be setup to connect to downstream switches The CE addresses are advertised into the respective carrier backbones via BGP so no additional static routing should be necessary...
... View more
Mar 2 2022
7:01 AM
Hi Bruce, Makes perfect sense and confirms my findings based on my preliminary evaluation work with MX equipment. Thank you
... View more
Mar 1 2022
9:11 AM
Our overall SDWAN architecture won't be finalized for several months. In the meantime, can our traditional ISR routers be replaced with MXs? Southbound (LAN) connectivity to MS/Catalyst switches should be straightforward, it's the northbound dynamic WAN advertisements is what I'm not sure about. The MPLS routers establish BGP adjacencies with the carrier PE to advertise local prefixes. Assuming the carrier has no problem supporting OSPF will the MX advertise local prefixes to the carrier PE? My concern is, they'll only advertise AutoVPN prefixes.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 1298 | Oct 16 2022 9:01 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 1298 |
© 2024 Cisco Systems, Inc.
