Meraki

RaphaelL · ‎Mar 2 2023

Hi , I think this is expected : if they are currently active, as seen below in Figure 1. The activity threshold for a client is one minute. If a client does not pass traffic for longer than one minute, then the client will no longer be considered active. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Clients_Usage_Page_Overview#Clients_Overview

RaphaelL · ‎Mar 2 2023

Have you tried to configure a simple content filtering policy on the dashboard , then retreived the rule via a GET ?https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-content-filtering Looking at the documentation , it seems that the output for categories is different from what you are using. It 'should' include the category name. https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-content-filtering-categories

RaphaelL · ‎Mar 2 2023

I was right ! The IP source address spoofing protection is expected to block traffic from a device when it see's a source IP that does not match a known configured VLAN/subnet. In this case, the client device is sending DHCP discovers with a source IP address of 169.254.x.x instead of the expected 0.0.0.0. A client should not be sourcing the DHCP discover using the APIPA address, as that goes against the standard set forth in RFC 2131: "DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0." So it is an expected behavior ! I will have to investigate why our HVAC windows machines are suddenly doing that.

RaphaelL · ‎Mar 1 2023

Hi , Clients must generate some kind of traffic to be listed in the network-wide clients page. There used to be a documentation page about that , but I can't find it. It used to state that it must send 'web traffic' or something like that. Intra-vlan traffic wasn't enough to map the client. The ARP table however is essential. It should always be valid and containing the clients of that broadcast domain. Edit : I was typing this while @Brash had already found the documentation. 🙂 I'm a slow typer haha

RaphaelL · ‎Mar 1 2023

You should 'make a wish' to push support to ''create'' a 'Disable automatic firmware updates' feature 🤔 I wish that feature existed 😕

RaphaelL · ‎Mar 1 2023

MXs do not support LACP.

RaphaelL · ‎Feb 28 2023

Hi , I think it is this one : https://developer.cisco.com/meraki/api-latest/#!update-network-appliance-settings { "clientTrackingMethod": "MAC address", "deploymentMode": "routed", "dynamicDns": { "prefix": "test", "enabled": true } }

RaphaelL · ‎Feb 28 2023

Hi , According to the documentation : https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Organization_Menu/Organization_Change_Log It is not specified but the changelog ( either via the API or the dashboard ) has a payload lenght of a maximum 4096 chars. Eg : This means, if you have multiple L3 firewall rules and you modify them , the changelog will not report the complete change and only a part of it ( the first 4096 chars of that change ). Not sure if it is the expected behavior , but I think it should be documented as a limitation if so. Thanks ,

RaphaelL · ‎Feb 27 2023

Do you have more info ( or a thread ) about this issue ? Is it only affecting Z Series ?

RaphaelL · ‎Feb 24 2023

hehe no worries ! I myself missed some too 😛

RaphaelL · ‎Feb 24 2023

Still listed in the known issues , no ? : Wireless clients may experience degraded performance for HTTP and HTTPS traffic when content filtering is enabled.

RaphaelL · ‎Feb 24 2023

Huge update ! Kinda suprised not seeing these changes ported to MX17

RaphaelL · ‎Feb 22 2023

100% with you there ! Do you have a way to test the transfer when the appliance is less utilized ? Let's say during the week-end or the night ?

RaphaelL · ‎Feb 22 2023

In that case , that might be related to CPU usage. CPU must be spiking above 85% in that 1 minute window. The stats are tracked every minute if I'm not mistaken.

RaphaelL · ‎Feb 22 2023

Hi , You would probably need to take a packet capture and see how TCP is handling / reacting. Look for TCP zero and/or TCP window full. Do you see any packetloss on that link ? Have you configured traffic shapping with the configured WAN speed ?

RaphaelL · ‎Feb 21 2023

Yes. This setup is currently working for all clients and all sites. Sorry for the confusion. I will edit the first post.

RaphaelL · ‎Feb 21 2023

DHCP is over the S2S VPN. This is a spoke.

RaphaelL · ‎Feb 21 2023

Wait. Shouldn't DHCP discover packets be sourced with 0.0.0.0 ? I might have to read the RFC again DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. https://www.rfc-editor.org/rfc/rfc2131 Well I think I found the issue. Thoses machines are sourcing their DHCP discover with an IP different from 0.0.0.0. Meraki support will confirm that. I will keep you guys updated.

RaphaelL · ‎Feb 21 2023

Same topology as the documentation. MX receives the DHCP discover , but drops it.

RaphaelL · ‎Feb 21 2023

Hi , We are running MXs in NAT mode under the 15.44 code ( yeah I know. ) On some sites we have machines that have issues getting IP from DHCP. We can see the MX dropping thoses packets with the event log : Documentation states : Special exceptions are made for DHCP discover messages and for traffic used to synchronize information between MXs in a NAT warm spare configuration. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/IP_Source_Address_Spoofing_Protection Has anyone ever encountered issues with RPF ? We have 1000++ networks , I'm pretty sure that I can find couple other examples. Yes upgrading to MX17 or MX18 is planned , but I don't see any mention of that behavior in the patch notes. EDIT : This is a branch. The MX is configured to relay DHCP packets to a DHCP server in our DC over the S2S VPN. Setup is working fine for 99.9999% of our clients/workstation except some which seems to be sourcing the requests with an IP different from 0.0.0.0 as per the RFC. Thanks ,

RaphaelL · ‎Feb 21 2023

Well you will have to take a packet capture to identify if the DHCP server is really receiving the requests and responding.

RaphaelL · ‎Feb 20 2023

100% agree with you ! 2 ports on 10K is nothing serious ! 🙂 Glad to have this issue fixed !

RaphaelL · ‎Feb 20 2023

Yes ! Update was made to my case. It looks fixed. But I have 2 ports that are showing way larger values than the rest : {"portId":"31","enabled":true,"status":"Disconnected","isUplink":false,"errors":["Port disconnected"],"warnings":[],"speed":"","duplex":"","usageInKb":{"total":948292,"sent":899714,"recv":48578},"lldp":{"systemName":"","systemDescription":"","portId":"","chassisId":"","portDescription":"eth0","systemCapabilities":"S-VLAN Component of a VLAN Bridge"},"clientCount":1,"powerUsageInWh":3368.2,"trafficInKbps":{"total":89.9,"sent":85.3,"recv":4.6},"securePort":{"enabled":false,"active":false,"authenticationStatus":"Disabled","configOverrides":{}}} Rest is around 100-300 , 2 ports reporting 3XXX.

RaphaelL · ‎Feb 17 2023

That behavior is only true if Radius testing is enabled. Which is not by default.

RaphaelL · ‎Feb 16 2023

You can configure a port mirroring : https://documentation.meraki.com/MS/Monitoring_and_Reporting/Packet_Captures_and_Port_Mirroring_on_the_MS_Switch That way you could capture all trafic from a port ( ap port ) to a different destination port. You could run wireshark on that destination port and capture all traffic. Not sure if that answers your question.

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges