Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Adam2104
Community Record
101
Posts
52
Kudos
1
Solution
Badges
@cmr wrote: The other thing to be aware of is radio power levels, smaller devices often cannot raise their power level above ~17dBm so to ensure that the AP can hear them when they can hear the AP you should keep maximum power restricted to this or below. This. I've had really good luck with balancing the AP transmit level to the approximate level of my wireless devices. I run 15dbm on my MR42s and devices roam just fine from device to device. I'd work on surveying the AP power levels and coverage before bothering with 802.11r.
... View more
802.11r is unsafe when paired with WPA2 PSK (pre-shared-key). WPA2 Enterprise is safe to use with 802.11r, at least that's my understanding.
... View more
Jun 16 2020
2:20 PM
I have two Xboxes (Xboxen?) here. I did a port forward for each Xbox and the NAT test comes back as open. One is hard wired, an Xbox One X, and it' works fine. The other Xbox is an OG Xbox that uses wireless. Neither Xbox has any problem staying connected while playing games. The OG Xbox on wireless seems to have problems where it is no longer connected to Xbox Live when waking the system from sleep. I'm not sure what's up with that and I haven't spent any time debugging it. A reboot of the Xbox gets it back online. I have a full stack here, 3x MR42, 3x MS120-8, and 1x MX67. ISP is Google Fiber. What problems are you seeing?
... View more
May 23 2020
6:05 PM
Unfortunately, bug/defects like this are resolved in priority order. A bug that's 24 months old that is affecting one person will take a back seat to one that's brand new but is affecting dozens. That's just how it works, good, bad, or whatever. It works like this everywhere.
... View more
May 23 2020
12:37 PM
1 Kudo
I’m sad to say that a fix for this is probably not going to arrive any time soon. The amount of people doing DHCP relay to an MX has to be very, very low. These devices are targeted at a very specific customer-set and people doing DHCP relay to the MX itself are not likely to be very common. If this issue is a show-stopper in your environment just toss a dhcp-pool on the switch that’s doing you’re DHCP helper and call it a day.
... View more
May 22 2020
1:50 PM
3 Kudos
It's explained here: https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Applying_Policies_by_Device_Type#Client_Identification
... View more
May 20 2020
9:31 AM
I'm sorry, but I don't understand this statement: "Seeing it on my syslog server without any way to determine which rule it came from is not acceptable to us or our clients." It says, in the syslog message, which pattern it came from. Sure, it doesn't say "Rule 15", but it does give you enough information to determine what rule it is from. It's not ideal, but the information is available to you.
... View more
May 20 2020
7:35 AM
1 Kudo
Well, you could make that argument about anything it does. There's no way for you to get into the MX to see the actual ruleset that's configured. If that's a requirement for your environment you may want to consider a different product/solution that offers you that level of control / visibility. Regarding your rules not generating hits. Are you saying in the Dashboard? If so, I've found those counters to not be real-time. The logging option on the rule is your best bet. However, I assume that is probably rate-limited to avoid causing a DoS on your own equipment by trying to log too much info too fast. Even regular big Cisco IOS/IOS-XE routers have a logging rate and queue limit.
... View more
May 20 2020
7:26 AM
Does anyone have a list of all the support-enabled features you can have enabled via a case with Meraki? Personally I have the following enabled: 2.4ghz-only SSIDs Disable MX flow_start and flow_stop syslog messages Firewall objects Inbound L3 firewall rules Disable wifi mesh Some of these items caused me to spend many cycles trying to figure out what was wrong, or, how to do what I wanted. It'd be nice if there was a list of all the things support can enable for you so you don't end up spending time trying to figure it out.
... View more
May 20 2020
7:21 AM
Agreed, it doesn't tell you "rule 25 generated this log". You're going to have to determine that from the rest of the message contents. For example: 1589984219.325305969 mx67 flows src=192.168.1.82 dst=192.168.40.254 mac=AA:BB:CC:DD:EE:FF protocol=tcp sport=46928 dport=853 pattern: deny tcp && (dst port 53 || dst port 853) Specifically, you need to look at the pattern. This will match what you've configured in your rules. The one from the above example is a Deny rule that blocks all TCP traffic to destination ports 53 and 853. Presumably you don't have several duplicate rules with the same matching criteria.
... View more
May 20 2020
6:59 AM
3 Kudos
The only way to see what firewall rules are getting hit is to configure a syslog server (Network Wide ---> General) and turn on the "flows" option. After that check the syslog checkbox in the firewall rule. Sadly, there's no other way to do it. To figure out which rule is generating the syslog message you need to look at the pattern show in the syslog message itself, it should match whatever you configured on the rule.
... View more
May 19 2020
9:59 AM
Has anyone played with the no NAT functionality in MX 15? I'm playing with a few different topologies and currently I want to run without the MX doing NAT. The topology is: Internet --- Firepower 1010 --- MX67 --- Clients I want the Firepower 1010 to see the real IP addresses of the clients. The Firepower will also handle all NAT duties to/from the Internet. All my clients and services are behind the MX67, there's only a small /30 between the MX and the Firepower. Thus, I need to poke holes in the firewall of the MX to allow for incoming services to work. Previously, with NAT mode, I'd just configure the port forwarding rule on the Firewall page and everything works. However, once the NAT exceptions are enabled the port forwards don't work (as expected), thus I need to poke a hole in the Inbound firewall to allow the traffic to hit the relevant ports on the relevant IP addresses. However, there is no inbound firewall configuration options available. The only thing I see in the Dashboard are the regular outbound firewall rules. The only way I can get the inbound firewall rules to appear is by using passthrough mode, but that has other limitations I'd prefer to avoid. Am I missing something basic? It seems like no NAT needs to expose inbound firewall rule configurations. Otherwise, it's impossible to host any services behind the MX.
... View more
May 12 2020
1:49 PM
1 Kudo
This started working with both api keys late yesterday. I haven't changed anything on my end, it simply started working. I'm not sure what changed but it's good to go now.
... View more
May 11 2020
1:51 PM
I'd agree, if the server was sending a 302 back, but it isn't, it's sending a 404.
... View more
May 11 2020
9:42 AM
I'm just starting to play around with the API. My user has full access to the org and also the network I'm playing with. I'm just tinkering for now making API requests via curl on the command line of my Mac. If I make the request against "api.meraki.com" I get a 404 and no data is returned. If I change it to the shard I'm on "n###.meraki.com" I get a 200 OK and the data I'm expecting. So, from this I assume my API key is valid. Why doesn't the request work on api.meraki.com, but does when I point it at the specific shard? Works: curl -X GET \
--url 'https://n456.meraki.com/api/v0/organizations' \
-H 'X-Cisco-Meraki-API-Key: foo'\
-H 'Accept: application/json' Doesn't work: curl -v -X GET \
--url 'https://api.meraki.com/api/v0/organizations' \
-H 'X-Cisco-Meraki-API-Key: foo'\
-H 'Accept: application/json'
... View more
Labels:
- Labels:
-
Dashboard API
May 8 2020
6:54 PM
I believe this is an Apple-enforced restriction on the newer versions of iOS. See here: https://arstechnica.com/gadgets/2015/06/apple-to-require-6-digit-passcodes-on-newer-iphones-ipads-under-ios-9/
... View more
May 8 2020
6:50 PM
1 Kudo
Anyway you can test without the MX in place? Or perhaps plug directly into the circuit and test it that way? If it’s consistently 20 then something is misconfigured somewhere. My bet is on the circuit itself.
... View more
May 4 2020
5:08 PM
Just to follow up on this I decided to keep the MX67 in place. The FP1010, while faster and more capable in most areas seems to be particularly fragile, both in the FTD software for the FP1010 and the management center software.
... View more
Apr 30 2020
7:20 AM
2 Kudos
Replying to my own thread here. I think I figured out the difference. The ARP requests from the MX are unicast ARP requests, not standard broadcast ARP requests. Proxy-ARP on the MR42 seems to only handle broadcast ARP requests, not client-status unicast ARP requests. In this case, it technically isn't wasting airtime because it isn't having to broadcast ARP to all connected clients. I'd still prefer if the MR replied to it on behalf of the clients given that the MX sends an ARP request every 15 seconds.
... View more
Apr 29 2020
5:33 PM
MR access points are supposed to use proxy-arp to respond to ARP requests on behalf of connected clients. However, I've noticed that my MR42s are NOT proxy-arp responding to ARP requests from my MX67. Specifically, an ARP requests from the MX67 are forwarded to the end client, needlessly wasting airtime. Given that the MX67 ARPs for all connected clients every 15 seconds this is generating a lot of ARP requests over the air. Is anyone else seeing the same thing? There's basically two scenarios: Scenario 1: MX sends client-status ARP request for a host connected behind MR42. The MR42 receives this ARP request and forwards it to the end client in question. The client responds and the MR forwards this response to the MX. This is wasting airtime. Scenario 2: Another host on the network sends an ARP request for the same host connected behind MR42. The MR42 receives this ARP request and immediately responds (proxy-arp) without forwarding it to the end client, as expected. This saves airtime. My MX is on 14.50. The MR42 is on 26.7. This happens with numerous clients and doesn't appear to be client-specific. Running Wireshark on a 2018 Macbook Pro 15'' shows the ARP requests from the MX, but no ARP requests from any other devices. Interestingly, this only happens on ARP requests from the MX. If I swap the MX for my Cisco Firepower1010, configured with the same LAN IPs, etc, the MR correctly sends proxy-arp responses.
... View more
Apr 25 2020
5:04 AM
@DarrenOC Well, not really, the question wasn't "which hardware is better?" it was about traffic analytics and the impact of removing the MX.
... View more
Apr 25 2020
4:20 AM
@DarrenOC Sadly, just up'ing the spec of the MX isn't really viable. The only MX that meets/exceeds the performance of the Firepower1010 is the MX100 which has a list price of $4995, without a license. The Firepower1010, without a license, lists for $1195. It also has a proper VPN client, IPv6 support, two PoE+ ports, a much smaller footprint, no fan, etc. I'm extremely familiar with Cisco's firewall line, so the configuration differences aren't really a concern.
... View more
Apr 24 2020
10:48 AM
I was hoping I could get some input into what I might loose from a traffic analytics perspective if I remove the MX from my full stack environment. Right now I have an MX67, several MS120-8 switches, and a few MR42 APs. I'm considering dumping the MX67 for a Firepower1010 for the increased performance and IPv6 capabilities. If I remove the MX67, will I be missing out on some traffic analytics? Or, will the MS and MRs fill in the gaps?
... View more
Apr 19 2020
9:31 AM
What IP address do the PCs get when they're directly connected to the 881? I suspect the addressees being given by the 881 overlap with the addresses on the inside of the MX and thus it is not accepting the address.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 9928 | Jun 14 2019 5:17 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 6204 | |
| 5 | 1813 | |
| 5 | 30868 | |
| 4 | 9928 | |
| 3 | 2666 |
© 2024 Cisco Systems, Inc.
