Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About ToryDav
ToryDav
Building a reputation
Member since Sep 24, 2019
Apr 26 2024
Community Record
130
Posts
53
Kudos
3
Solutions
Badges
Sep 17 2021
11:40 AM
Just to update this post. I got approval to upgrade this MS390 switch stack firmware. It took a long time to download but once they actually went down it was only about 15 minutes downtime or so. Everything seems ok thus far.
... View more
Sep 17 2021
9:56 AM
Hi @Bruce, Having done the upgrade yourself, would you recommend having someone on-site during the upgrade window? I am not local to the site location. That issue seems to have been fixed in 14.29, but I am a bit nervous. from 14.29 release notes.
... View more
Sep 16 2021
2:30 PM
Deployed my first pair of MS 390 switches! Some strange issues -- VLAN 0 - I see a bunch of clients showing they are on VLAN 0, but I don't really know what this means. For example: Shows it on port 6, but that is configured for VLAN 40. STP ROOT - Although there is only a single stack of two switches, this still concerns me. What is this trying to tell me? Just looking for any experience anyone may have to shed some ideas on what could be causing this weirdness. Also seeing constant port status changes, so I am concerned to know if this STP root message is truly something to be concerned about or a bug. Or is it just an MS390 thing? Thanks, Tory
... View more
Aug 18 2021
10:01 AM
7 Kudos
I recently had the same issue and fixed it by looking at the event log in windows. Windows Start > type Event Viewer Under Applications you will see the RASclient entries and error codes I was seeing error code 720. I made sure my config matched the instructions: https://documentation.meraki.com/MX/Client_VPN/Client_VPN_OS_Configuration (IT DID) What I actually did to fix my issue was head on over to Windows Device Manager > Network Adapters Delete the WAN MINIPORT for IP as well as for L2TP. Then above click the icon to scan for new changes. You will see them return. Deleting the IP Miniport was the only thing that fixed this for me after I checked configuration, enabled firewall rules and looked at both logs in Meraki and Windows. Hope it helps! Tory Let's connect on linkedin!
... View more
Aug 17 2021
7:43 AM
1 Kudo
Uninstalling WAN MINIPORT IP under windows device manager just did the trick for me.
... View more
Aug 6 2021
6:16 AM
Hi! I'm looking for some clarification on this question: If I have an MX with 2 WANs set to load-balance and configure my port forwarding to use "BOTH" uplinks, would this essentially make my ports exposed on both public IPs of each wan? I don't need the port forwarding to work on both IPs at the same time, but I am just curious to know, in this configuration, would it? Thanks, Tory
... View more
Labels:
- Labels:
-
Other
Aug 2 2021
6:31 PM
Hello ! I have a design question regarding a port forward and a multi-wan set-up using Meraki MX. Lets say I have an MX with a triple WAN set-up. Below shows the proposed idea. With port forwarding, It looks like I may only be able to configure dual WAN port forwarding, see the below example: My confusion lies within the complexity of the port forwarding. With the two devices above is this even possible when configuring the port forwarding onto the MX? It seems pretty straight-forward for two WANs, but since WAN 2 port on the MX will connect to the CP E300 router, it will actually be given a private IP, the E300 router will be the gateway which then connects to the WAN 2 + Cellular. In this scenario, how can I ensure the port forwarding works regardless of whether we have failed over from WAN 1 onto WAN 2 or LTE?
... View more
Jul 1 2021
4:25 PM
Jul 1 2021
4:24 PM
@DarrenOC @Bruce Likely it will be MS 390's The top and bottom spread is just how I chose to do it, it's a stack so really I could put one link on each switch. Logically all one switch. Also Bruce thanks for the tips. I will aggregate the links and spread those links out better. Makes perfect sense, not sure why that got past me on this one.
... View more
Jul 1 2021
2:16 PM
2 Kudos
Cartoon floating head Tory has arrived!
... View more
Jul 1 2021
2:05 PM
2 Kudos
Hello! I would love some feedback on the following designs. Looking for ways to improve the technical design and check for correctness. 2x MX in H/A (WAN NOT SHOWN) (LAYER 1 CABLE DIAGRAM) Layer 2 Diagram LAYER 3 DIAGRAM For the Layer 3 diagram, I've debated with putting the layer 3 gateways on the MX but I would prefer to have a true core as well where the gateways and DHCP reside on the MDF switch stack instead with Layer 2 trunks to the IDFs. Thus I would create a transit VLAN X with a /30 for each MX for connectivity between the core and both MX. Thoughts? Constructive feedback? Thanks, Tory
... View more
May 20 2021
3:37 PM
2 Kudos
All, The MX swap went flawlessly. We stood up the MX100 in parallel, put a static IP on it within the local status page and cut over the uplink. I did have to reboot the MX 100 as it didn't reach the dashboard right away. Once it came online all the configuration applied from before, with the exception of the site-to-site VPN. We simply turned on the site-to-site VPN and didn't need to reconfigure it in any way. Our 1:1 NAT didn't work, but rebooting the upstream router cleared its tables and restored connectivity to the webserver behind the NAT. To troubleshoot this I took a PCAP and watched the TCP SYN from my public IP address hit three times and then saw the fast retransmission occur, but we never received any SYN/ACK. Looking at the source and destination MAC addresses, I could see the packet source from the CISCO router upstream, destined for the old MX port 1 MAC address. Rebooted the cache upstream. Thanks, Tory H. Davenport
... View more
Apr 29 2021
8:32 AM
4 Kudos
Thanks! I will use the cold swap method and prior to cutting make sure I go through the caveats for proper preparation. I'm comfortable configuring Meraki features. I am really posting this for the logic of the cut. So in this instance I should be able to use the following task list: 1. Backup current MX configuration just in case, including local status page and dashboard. 2. Remove the MX 80 from the network. 3. Add the MX 100 to the new network. Allow the MX to boot and upgrade firmware. Add any local parameters from the local status page. 4. Validate that all the configuration carried over and re-configure the features that may or may not have.
... View more
Apr 29 2021
7:30 AM
Hi everyone, I need to migrate MX 80 to MX 100 single device, no H/A. We want to stand the MX 100 up in parallel with the MX 80, configure the MX 100 and then cut the cables. Problem is, I don't think this is going to work. If the MX 80 and MX 100 are stood up in the same network, I can't configure them independatly can I? Otherwise what would be the best way to migrate seamlessly. We do have a cutover window, but I'd like to avoid taking the MX 80 down and out of the network and adding the MX 100 manually because I know I'll have to reconfigure it on the spot. The other route I am considering is using the API. Thoughts?
... View more
Feb 23 2021
3:51 PM
Thanks @PhilipDAth I was thinking about that too. They are set-up like the diagram now. STP is blocking where it should be with the redundancy between the MX and the 355's, but that is good point. The 355's are stacked. I can advise them to remove two links like you mention to reduce potential STP issues from occurring, but so far so good. I was concerned about using the public IPs on the WAN switches. Any concern there beyond locking down the local status pages on those devices? Not a huge fan of public IP's on the WAN switches for management personally.
... View more
Feb 23 2021
12:55 PM
Does this design seem copacetic? Right or wrong? I know these are not ideal for breakout switches.
... View more
Feb 10 2021
11:38 AM
@BrandonS Meraki MX is not in play. It is an ASA 5516-X managed through FMC. Single WAN, 50 up and down just got upgraded to 200 Meg or will be soon -- > Spectrum I will find out about IDS/IPS, I didn't see any static NAT.
... View more
Feb 10 2021
10:56 AM
Hey @BrandonS Thanks taking a few minutes to talk through it all with me. The phones are new, they set-up Ring Central and put Polycom's in place. Polycom VVX 250, 350, 450 and Polycom Trio 8800. They have been having these issues since October and I'm just recently getting involved. Problems include: Random reboots One-way audio Calls drop Poor Quality We are addressing QoS and Bandwidth concerns for the audio issues, but I am looking at the ports to see why they might be rebooting. Nothing really sticks out other than the LoopGuard config.
... View more
Feb 10 2021
6:53 AM
Hello, I've stumbled across a problem where client states phones are rebooting randomly and I am seeing duplex changes and disconnects on the connection health bar for those ports. Event log doesn't reveal much to me aside from STP changes from designated to disabled on some of those ports, which I've seen before even on ports with no STP enhancements configured. STP doesn't show any of them in the blocking state. After looking at port configuration I noticed that STP LOOPGUARD is applied to almost all of their access ports, and to be clear these are for workstation/phone pair with VLAN and Voice VLAN configured. This is a red flag to me - - but I thought I would get your perspective and buy-in on the idea that this is likely misconfiguration and it is contributing to the issues they are having. Why would someone put loop guard on these ports? That is for uplink ports.
... View more
Feb 2 2021
11:14 AM
Hi, I am investigating MAC address flapping in my event logs. I see Meraki event log reporting flaps on my switchports across a bunch of switches in this environment. The thing is, these are either on uplink ports or access point ports. Am I correct to say this is normal behavior? Searching the a MAC address from one of these flaps reveals a client visible to both wired and wireless equipment. There is also non-Meraki equipment at play in the switching environment (older cisco catalyst). SO, to me, if the client is roaming, then the mac address could be learned on on multiple switches. Which is why I am seeing them on AP ports and uplinks. And the client tracking by MAC address could be at play here with the non-Meraki switches (which do have MR's off of some of them). Any other thoughts that could be causing this?
... View more
Jan 22 2021
9:15 AM
Hello! I have a questions to see if anyone can help me look at the pros and cons of this scenario: I have 2x MS 250's in H/A, down steam in the distribution there is 2X MS 355's stacked. Then for the access layer there are 3x MS 250s stacked. Can someone describe the pros/cons of having the L3 gateway on the MS stack vs the MX ? I really want to put a transit VLAN between the MX and MS pair for management and then put all my layer 3 gateways on the MS 355's. I do see those are "access" switches in the documentation, but that's neither here nor there. Thoughts?
... View more
Jan 13 2021
8:14 AM
@ww Okay, I think I'm following. So I am interpreting the rule wrong the document says inbound .. https://documentation.meraki.com/General_Administration/Other_Topics/Upstream_Firewall_Rules_for_Cloud_Connectivity so not inbound from the outside zone but inbound from the network the AP MGMT is on, destined for those 172 addresses. So the addressing under destination IP (172.19.0.25/32 and 172.25.0.25/32) are just examples then? I would put Source ip = Meraki MR Management IP Destination = RADUIS server Thanks for your help in advice.
... View more
Jan 13 2021
7:28 AM
Would someone be able to explain to me what this rule is doing? Control traffic? The customer has internal RADIUS so my understanding is that the firewall should allow RADIUS east/west though zones but this is inbound, and to seemingly private IP addressing. Tory
... View more
- « Previous
- Next »
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 4464 | Feb 5 2023 5:41 AM | |
| 2627 | Mar 28 2022 3:09 PM | |
| 4043 | May 20 2021 3:37 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 7 | 10806 | |
| 4 | 4432 | |
| 3 | 2138 | |
| 2 | 5702 | |
| 2 | 9162 |
© 2024 Cisco Systems, Inc.
