Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About etb
etb
Getting noticed
Member since Dec 31, 2019
Aug 7 2024
Community Record
27
Posts
19
Kudos
1
Solution
Badges
Aug 3 2024
12:00 PM
2 Kudos
Interesting to know. I don't suspect that Kapil was wrong/lying, so I assume that there is some kind of mechanism to stop an unwanted stream after not too terribly long. TV channels are going to be significantly lower bandwidth though, so it probably didn't matter nearly as much as these video-over-IP streams which can practically saturate a 1 Gbps link with 1 stream. But when there are 2 different large video-over-IP manufacturers and also community members seeing issues, it would be an awfully unstable limb for me to go out on myself. Extron actually advised against using their products with Meraki switches, whereas Crestron notes that they have some installations but that there can be some suboptimal experiences. So I was hoping that maybe Meraki might say that Extron and Crestron just had suboptimal switch configurations, and actually MS switches are in fact documented and tested as immediately stopping a stream when no longer wanted. Either way, thanks for your input.
... View more
Jul 31 2024
2:54 PM
4 Kudos
Hello, Sorry to necro this old thread - I can start a new thread if desirable. But I basically have the same question regarding whether Meraki MS switches necessarily support a fast/immediate leave. In my particular case, I have a large 3rd party audio/video manufacturer (Extron) saying that they have tested their video-over-IP solution with Meraki switches as recently as this year, and they found Meraki switches to not work with their products due to a lack of support for fast/immediate leave. (The reason fast/immediate leave is so critical for these video-over-IP solutions is that individual video streams can be solidly in excess of 500Mbps. So it can exceed the bandwidth of a 1Gbps port if the first multicast stream is not stopped very quickly when switching to receive a different multicast stream. bcdaus and lukewarms above are referring to a very similar system from Extron's competitor, Crestron. And bcdaus states that their testing seemed to show that the Meraki switch is not successfully conducting fast/immediate leaving.) I've tried googling various combinations of related terms, and all relevant results I find are this thread plus some reddit threads. I've also looked through the Meraki documentation I can find (link) and (link), but I can't seem to find anything definitive about fast/immediate leave. So is there some documentation which officially states that Meraki MS in fact support a mechanism to immediately stop a multicast stream when an IGMP leave message is received?
... View more
Jan 12 2024
4:44 PM
Thanks, Ryan. Yeah, I can be flexible as to exactly how to accomplish things. Automatic load balancing with pinning based on domain would be most ideal, but I could also just pick various NBAR-supported applications and manually assign them to the secondary link (without enabling the automatic round-robin load balancing). My particular application happens to be LogMeIn, and NBAR does list that as supported. But my experience since the "statistical peer-to-peer" stuff (Meraki community thread) has been that the majority of LogMeIn traffic seems to be getting classified as "unknown". So I'll see what I can work out with MX 18.2xx. But if I could get SD-Internet, with support for destination domain, and all included in the Advanced license - well that would be perfect 🙂
... View more
Jan 12 2024
2:57 PM
Okay. That sucks because what I'd like to do won't work, but also because it seems so tantalizingly close to being possible. Since this capability already exists for SD-WAN, does it seem like it would be a halfway-reasonable feature request to make the capability available for internet as well? I don't even really need the ability to monitor the "health" of the link - I just need/want to pin traffic to an interface based on domain (or other traffic classification beyond just IP address and port). EDIT - I think my wish might be getting granted in MX18.2 before I even wished it? But still only with an SD-WAN Plus license. https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/SD-WAN_Internet_Policies_(SD-Internet)#Application_Policy_Configuration
... View more
Jan 12 2024
12:55 PM
Hi and thanks for your response. That seems at least sort of related to what I'm doing, but again I am not actually using any VPN's at all - just 2 plain internet connections. To try to make an easier illustration: let's say that I want to round-robin load balance all regular internet traffic (no VPN's involved at all), except that I always want outbound traffic to meraki.com to use the Primary uplink. Should I be able to pin traffic by domain like that when not using any VPN's?
... View more
Jan 12 2024
12:46 PM
Should it be possible to use the [SD-WAN & traffic shaping -> SD-WAN policies -> VPN traffic -> Uplink selection policy] to pin certain traffic by destination domain to a certain "WAN" link - even if I actually have no VPN's (just 2 regular internet connections)? This may or may not be a dumb question. I have read through documentation and forum posts (some links below), and I'm just not 100% confident. I also set up a little test using my MX68 running 18.107.5, and it's not working to pin traffic by domain when using VPN traffic Uplink selection. So I'm not sure if I have just proven that it doesn't work the way I'm hoping it could, or if I'm just doing something incorrectly with my test configuration. (I can share screenshots of the config if anyone wants, but just didn't to make this post that much longer.) I did read that ICMP doesn't respect the configuration no matter what, so I'm simulating real outbound traffic and running PCAP on each "WAN" interface. I can see that the traffic continues to use the primary link, even though I set an Uplink selection policy to send it out the secondary link. At the heart of the matter, my scenario is that I will have 2 regular internet connections (no VPN) in a new office, and I'd ideally like to load balance traffic between them (whether automatically or hard-configured for certain traffic groups) just to take advantage of the combined bandwidth. But there is outbound traffic to a few domains which I really need to pin to the primary internet connection (unless the primary internet connection goes down), and so the plain round-robin load balancing wouldn't work reliably for that (I can't trust the automatic 60-minute flow pinning to work 100%). I assume that the [SD-WAN & traffic shaping -> Uplink selection -> Flow preferences -> Internet traffic] would theoretically work, but that only seems to allow for IP addresses (not domains). My domains in question use many different blocks of IP addresses, and they could change at any time, so I don't think trying to configure by IP address is feasible. Any other feasible solution is welcome. And apologies if I'm being dense. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Load_Balancing_and_Flow_Preferences https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/SD-WAN_and_Traffic_Shaping https://community.meraki.com/t5/Security-SD-WAN/Load-balancing-question/m-p/101903#M25616
... View more
Jun 26 2023
4:03 PM
By crazy coincidence(?), that event from Fri 6/23 @ 10:09pm EDT (2:09am UTC) was the last one of these logged. I didn't see any of these events in question over the weekend nor today (6/26). So it looks like this is closed out. Thanks, AlexP and community members.
... View more
Jun 23 2023
7:15 PM
I'm not too concerned about the exact timing, but I'm just reporting because you asked. I'm still seeing them as of 10:09pm EDT (2:09am UTC). I'll check again later.
... View more
Jun 21 2023
11:33 AM
2 Kudos
Very interesting - thanks, El-Bandito. I found time to pcap all traffic for a couple minutes and search some of the IP addresses which I'm seeing logged in these IDS events. For the couple which I have found so far, it does appear to be directly related to Microsoft Updates. In both HTTP headers, the user-agent is shown as Microsoft-Delivery-Optimization. In one header, the host is shown as 11.tlu.dl.delivery.mp.microsoft[.]com, and in the other header it is shown as 9.tlu.dl.delivery.mp.microsoft[.]com. One of the IP addresses has a reverse lookup to Edgecast, but if I search that Microsoft host, the IP address which is returned matches the one in the IDS event. The other IP address has a reverse lookup to Highwinds Network Group, but again the Microsoft host resolves to that same IP address. So with those limited results so far, it does seem like IDS is somehow flagging Microsoft Update traffic. In my particular case, the mass of IDS events did happen to start on a Patch Tuesday, though that could be a coincidence.
... View more
Jun 20 2023
12:58 PM
I'm still seeing most (all?) of the sources as what appear to be various content delivery networks (CDN's). My #1 source today is from Edgecast. #2 from today is HWCDN. #8 from today is LLNW. All of the rest of my top 10 from today reverse lookup to Level3. (Akamai was on my top 10 for other days though.)
... View more
Jun 16 2023
5:10 PM
Thanks, @AlexP. Understood regarding NBAR vs Snort. It's a little tough to assume that 5+ different CDN's all started doing something different at the same time though. (It wasn't terribly unusual for us to go a whole 2 weeks with no IDS events, but all of a sudden now we have thousands per day from multiple CDN's.) Or similarly, I really wouldn't know I guess, but it seems unlikely that some application/service which we use leverages 5+ different CDN's such that that application/service would be generating this traffic from multiple CDN's. Not impossible, but it seems more likely something that changed on the Meraki side. I can try to dig into it a little more. Should I be able to see this traffic in a PCAP on my WAN interface, or does IDS block traffic before it would even get captured? My dashboard doesn't seem to offer the ability to inspect packets for this rule.
... View more
Jun 15 2023
5:53 PM
I'm seeing a ton of these IDS rule hits as well. Rule ID 1-16295 "Kaspersky antivirus library heap buffer overflow - without optional fields". Over 6,100 starting around 4:45pm EST on Tues 6/13 (nothing noteworthy before then). I'm guessing that all of the remote sources are CDN's. HWCDN, LLNW, Akamai, Edgecast, and Level 3. 4 of the top 10 have contributed to between 600 and 1000 events each, and others of the top 10 are 80 or fewer events each. We are running firmware MX 18.107, and that has not changed recently. I'm not aware of any other changes in our environment which could be contributing to this. I'm taking a wild guess that maybe something changed with NBAR definitions, and it's causing false-positives? That said, I have no idea what legitimate traffic would be hammering from CDN's what looks like roughly every 4 to 5 minutes per each affected local computer at literally all hours of the day.
... View more
Dec 21 2022
2:19 PM
Thanks Isack2230! Looking at our Traffic Analytics page, I can see that the traffic which used to get classified as Statistical P2P maybe 50% of the time now appears to be getting classified as "Unknown". I actually don't have any Statistical P2P showing up in the past 30 days, although most users use this application every day. In addition to "Unknown", I also have 2 separate rows for "undefined" which I don't recall seeing before. Those 2 "undefined" rows combined would be the 3rd largest single traffic type in our network over the past 30 days, so I'm guessing that they're just some kind of a catch-all for traffic for which NBAR doesn't have any definition. Though I don't know how that differs from the traffic which gets classified as "Unknown". If I click on "undefined" to try to view the clients and hosts, the screen is just blank. But, at least it looks like our legitimate traffic won't get blocked as P2P anymore. When I'm feeling adventurous, I'll try re-enabling the P2P content filtering and L7 firewall rules.
... View more
Oct 19 2022
8:14 AM
1 Kudo
hey, sorry, I think I'd rather not share the case # just because I don't honestly know what info could or could not be gleaned or social engineered with the case #. I'll PM you my Meraki Support Engineer's name though. And yeah, I included permalinks to various posts in this thread for reference in my Support case.
... View more
Oct 19 2022
8:09 AM
not that I want to weaken our case for improved NBAR and related functions 😀, but if you have some firewall rules that you don't want to apply at all in some places, you could probably use group policies.
... View more
Oct 17 2022
8:51 AM
1 Kudo
Thanks, @Isack2230 . For anyone else following, I did upgrade to 16.16.5, but as of now I have not reenabled the L7 firewall rules nor content filtering rules. Based on the traffic analytics page, I can still see our remote access software getting classified as "statistical P2P" maybe about 40% of the time. For a little while it was classified as "encrypted P2P", but for a couple weeks now it has been "statistical P2P". (I am not aware of any changes to the traffic itself, so I'm guessing that the change in classification is a result of changes in NBAR.) I have had a case open with Meraki Support for about a month now, and we have been communicating back and forth. At least based on this forum thread, it seems that Meraki Support has the impression that this issue is resolved. So if others are still seeing it unresolved as well, then you probably want to let Support know.
... View more
Oct 14 2022
7:22 PM
1 Kudo
I just noticed that your firewall rules are configured for /32 subnets (so I believe each rule would be effectively blocking only 1 host address). if you are wanting the rules to apply to each entire subnet, then I'm guessing that you probably want /24.
... View more
Oct 14 2022
7:18 PM
1 Kudo
https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Using_Layer_3_Firewall_Rules Destination: Specifies the destination FQDN, IP address or network address using CIDR notation to match in outbound traffic. "Any" can also be used to specify all networks. Note that, on a network with an MX handling inter-VLAN routing, the IP address of the MX on the destination subnet may still be accessible via ping even if the rule is set to block traffic. This is due to the nature of software routing on the MX and does not pose a security risk; host devices on the destination subnet will still be blocked according to the rule.
... View more
Oct 14 2022
4:27 PM
1 Kudo
I'm not meaning to hijack athan1234's thread, but I stumbled across this thread while researching my own related issue. Is this to say that it is the expected behavior that the MX's Ping Live tool will basically ignore any firewall rules? I have explicit deny rules configured similarly to athan1234, and I can confirm that real clients in one VLAN are successfully blocked from reaching clients in any other VLAN. However, the MX's Ping Live tool can ping any client in any VLAN regardless of which "Source IP Address" I select. For example, although there is an explicit deny firewall rule configured in both directions between VLAN 3 and VLAN 4, the MX Ping Live tool with a "Source IP Address" of VLAN 3 can ping any device in VLAN 4. But again, no real clients in VLANs 3 or 4 can ping each other, so I can see that the firewall rules are working for real clients. I actually started this research because I discovered that any device in any VLAN could reach the management IP address of any other VLAN. For example, any device in VLAN 3 can ping/reach the MX's management IP address for VLAN 4. I found this article seemingly saying that this is expected behavior for AP's, but I am still searching for documentation indicating the expected behavior for MX's. https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/All_VLANs_can_ping_the_Cisco_Meraki_AP's_LAN_Interface
... View more
Aug 25 2022
7:56 AM
1 Kudo
@Dunky thanks, but yes, the very hit-or-miss issues were logged as blocked as statistical p2p, and it stopped within minutes of removing the configured p2p rules. @jrsilvius thank you. i guess i'll continue to hold off on reinstating the p2p rules until the community has more consistently better results.
... View more
Aug 23 2022
10:19 AM
Thanks, AlexP. Are there any fine folks in the community who previously had statistical p2p false positives and who could share their experience after upgrading to 16.16.4 and re-enabling the p2p rules? We are a small company with only 1 MX. Also, the issue seemed to randomly only affect maybe 25% of users, and only sometimes affect them. Although everyone is using the same affected application (LogMeIn) in the same manner, some users were never affected, some users were affected 1 hour but not the next, some users were affected 1 day but not the next, etc. So I cannot think of any way that I could create a reliable testbed to try re-enabling the p2p rules without potentially randomly preventing some users from being able to work.
... View more
Mar 28 2022
8:58 AM
1 Kudo
I found this thread while searching for leads on a new issue that has come up since our MX upgraded from 15.x to 16.16 (and hence NBAR was added). Legitimate LogMeIn remote control traffic started getting blocked intermittently under this same NBAR ID 1889 Statistical Peer to Peer. All of our users are using LogMeIn the same way, but I see logs that only about 25% of them were blocked under this rule. I'm not sure if it's weird or to be expected that these blocks seemed to resolve on their own after like 3 mins to 30 mins. (The users kept trying, and eventually it just worked.) I did find in old NBAR release notes that this rule "Classifies traffic by comparing it to machine-learned clusters", so I'm not sure if the rule adapts in real time, or if the rule just misses some instances sometimes (and so my users were able to connect with LogMeIn on a random instance that NBAR missed). I guess I'm going to give it a few hours to see how things go, and then probably need to remove the content filter for P2P if there are still issues. Though obviously I'd rather not do that.
... View more
Oct 21 2020
8:45 AM
1 Kudo
Please interpret this as a newb-ish reply, especially because I have not been able to physically get my hands on any of our Apple devices due to COVID, so I have had to rely on our users to disable the feature on their own. But my anecdotal experience is that some of them had to disable the feature twice - they described it that the setting somehow did not save the first time. Other users did not seem to have that issue. In addition to that, I think in many cases I saw one final IP conflict alert per device after a user had successfully disabled the feature. I assume that this was caused by the Apple device returning to using its factory MAC after it had been more recently using its randomized MAC. YMMV.
... View more
Jul 1 2020
11:07 AM
2 Kudos
I know that many people have complained about this, and I know the standard response (e.g. as posted above by MerakiGeoff on 12/10/19). But has anyone heard any updates that point toward a true "fix"? As of last night, maybe only about 10% of my Windows 7/8.1/10 clients were showing up as their mDNS names, and the rest were showing (as desired) as their host names. It had been like that for probably about a month since an office-wide extended power outage. Today, it is randomly up to about 50% that are showing as mDNS. There weren't any Windows updates last night, nor anything else I can think of which should have caused a change in behavior. My only other thought was that maybe a Chrome browser update did something weird, but it looks like the stable release of Chrome hasn't been updated in about a week now. I don't want to manually configure all of the host names in the MX, and I don't want to install Apple Bonjour for Windows as a poster above suggested. Is there a proper "fix" in the works, or a better workaround that doesn't require unnecessary software?
... View more
Feb 3 2020
10:35 AM
1 Kudo
I wanted to bypass the splash page for a wired client on an MX as well, and came across this thread. I don't see anything newer, so I submitted a "wish".
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 3665 | Oct 14 2022 7:22 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 4 | 842 | |
| 2 | 742 | |
| 2 | 8338 | |
| 2 | 5607 | |
| 1 | 22829 |
© 2024 Cisco Systems, Inc.
