- Display Name
- Last Active
- No Roles
yes ... that is the route i am working on. I will post back any conclusions
i guess i will need to open ticket with support. I will try your suggestion on the Any Packet Filter. I had similar issue with SIP traffic and ran that through support and what came back was certain traffic is NOT logged and a known issue. I my gut is that will be the answer here. I will look up those case numbers and add…
I have logging turned on for every policy.
i did .. but as i indicated in my original post " policy that should control is UDP-TCP policy Port 0(any), under properties logging is set to "Send Log message"" I would think this would cause this traffic to display / flash through the traffic monitor ..
Why doesn't the initial connection flash thru the traffic monitor?
Yes we have case opened. A second feature of this has been some sip traffic just does NOT show up in the traffic monitor and logging. Makes it very tough to troubleshoot. But a key point is the link monitor induced failover does not compartmentalize the traffic to the failed link in way that the FB behaves the same as…
Ok using a non responsive target partly worked. It does trigger a fail-over but does not behave like physically disconnecting the primary wan cable from the FB. To give a specific example, my sip trunk continues to communicate with the primary wan interface after the link monitor induces fail-over to our secondary wan.…
After 3 calls for various reasons, they renewal team notified me there there is an exception that has been implemented that provides a perpetual license to all AP hardware purchased prior to Sept 1 2018. That seems reasonable to me and consistent with my original posting. I just wish i did not have to go thru multiple…