About KevinJB

Hi All,   Has anyone had problems with CAPWAP AP's separated from the WLC by a PA-220 firewall get stuck in a DISCOVERY OperationState?   >show capwap client rcb AdminState : ADMIN_ENABLED OperationState : DISCOVERY Name : *** SwVer : 8.5.151.0 HwVer : 1.0.0.0 MwarApMgrIp : 10.1.1.2 MwarName : CISCO-LWAPP-CONTROLLER MwarHwVer : 0.0.0.0 Location : *** ApMode : FlexConnect ApSubMode : Not Configured CAPWAP Path MTU : 1421 CAPWAP UDP-Lite : Enabled IP Prefer-mode : IPv4 AP Link DTLS Encryption : OFF AP TCP MSS Adjust : Enabled AP TCP MSS size : 1250 LinkAuditing : disabled Efficient Upgrade State : Disabled Flex Group Name : *** AP Group Name : default-group Cisco Trustsec Config AP Inline Tagging Mode : Disabled AP Sgacl Enforcement : Disabled AP Override Status : Disabled   If I do a clear session all filter source <IP of AP> the AP will shortly come online again so it does appear to be the PA220 that's causing the problem.   >show capwap client rcb AdminState : ADMIN_ENABLED OperationState : UP   Even when the AP is offline I can ping the WLC just fine and interestingly if I add application capwap to the clear session filter it doesn't come back up.   We did create an application-override rule for the capwap traffic but that hasn't helped and since clearing on the capwap session doesn't help and there isn't any other session from that IP I am very confused.   Thanks in advance for any suggestions will also open a TAC case but they seem to take so long to respond these days with COVID and all. Kevin ... View more

Hi All,   I'm trying to get my head around SD-WAN and tunnel monitoring, specifically SD-WAN AutoVPN creates Tunnels with tunnel monitor turned on with a destination IP of the other side of the tunnel and the Tunnel Monitor profile set to sdwan-default. If I then look in Network Profiles -> Monitor  see sdwan-default configured with an action of wait-recover, inverval of 3 seconds and Threshold of 5. If I lookup the help for this page I notice the following:   Action Specify an action to take if the tunnel is not available. If the threshold number of heartbeats is lost, the firewall takes the specified action. • wait-recover —Wait for the tunnel to recover; do not take additional action. Packets will continue to be sent according to the PBF rule. • fail-over —Traffic will fail over to a backup path, if one is available. The firewall uses routing table lookup to determine routing for the duration of this session. In both cases, the firewall tries to negotiate new IPSec keys to accelerate the recovery.   Does this seem counter intuitive to anyone? Or is my understanding just off? The help talks about PBF rules not sdwan but if I try and read between the lines I come up with that wait-recover for an SD-WAN top down traffic distribution profile won't force traffic onto other working tunnels that are higher cost, it will sit there and wait for the top tunnel to recover? So if we want to use other working tunnels we should create a sdwan-default monitor profile and set it's action to fail-over, or alternatively set a SD-WAN policy that has a traffic distribution profile that is not top down but either best path or weighted distribution (not that this is always desirable). Does anyone know why the sdwan-default monitor profile would be set to wait-recover by default, is this just an oversight/bug or do you think most people would want a top down sdwan traffic distribution profile to not fail over onto other link types if the main tunnels were down?   BTW my experience with this is currently with TAC, but I have seen during a failure event traffic for sdwan.902 (tunneled traffic) does not fail over to a lower tunnel in the sdwan.902 list (which contains tunnel.901 through tunnel.906, during failover of which only tunnel.903-906 would be up) and eventually ends up trying to pass across to the INTERNET zone and out to the internet. Clearing the session for this traffic fixes it but I am curious as to if it is the tunnel monitor that is causing it to not failover in the first place or if the traffic trying to follow the default route out to the internet is some other bug and the tunnel monitor is just a red herring.   Thanks, Kevin-John ... View more