Another alternative, as a quick fix you can try to turn off H.323 inspection and see whether it solved the issue. Welcome to the world of L7
-pavel On Sat, Aug 14, 2010 at 11:58 PM, Pete Lumbis <[email protected]> wrote: > This could be anything from a non-standard H.323 stack to a bug in ASA code. > > > Closed by inspection is when the h.323 inspection engine that is responsible > for opening the high ports that are negotiated in the h.323 setup as well as > NATing any addresses inside the h.323 packet closes the connection it is > monitoring. Normally if an inspection engine closes down any part of a flow > it will tear don any child flows (that is, flows opened by or opened for > some setup type message). > > It's hard to tell exactly what caused the tear down, but I'd suggest you run > the latest version of code for your ASA train (a number of voice/video > related bugs have been fixed over the years). For more information I believe > there is a "debug h323" command. I'd also suggest doing inside and outside > captures on a circular buffer to try and see what is the last packet to make > it through and if there is something fishy about it. > > Finally you can always call TAC they are pretty good about identifying why > things like this happens, but you will probably need to be able to recreate > the problem somehow so they can collect data. > > Hope this helps. > > -Pete > > On Sat, Aug 14, 2010 at 3:36 PM, Jeff Kell <[email protected]> wrote: > >> I have had several intermittent reports over time from one of our >> distance learning customers concerning network issues during some of >> their classes (appears to be just one classroom, with one particular >> peer location, but I'm still looking to point the finger). >> I'm way over my head with H.323 (do well to spell it)... other that >> setting it up with default inspection. >> >> The classroom is setup on static NAT, and has a "permit ip any any" >> policy on it with the peer addresses, as do our other codecs. >> >> The call was done outbound, and the ASA "associated setup" appears to >> have succeeded: >> >> Original setup 323: >> > Aug 14 08:01:47 ASA %ASA-6-302013: Built outbound TCP connection >> > 100295465 for outside:remote-site/1720 (remote-site/1720) to >> > legacy:inside-codec/5555 (EX-inside-codec/5555) >> >> And associated: >> > Aug 14 08:01:51 %ASA-6-302003: Built H245 connection for faddr >> > inside-codec laddr remote-site/11014 >> > Aug 14 08:01:51 %ASA-6-302003: Built H245 connection for faddr >> > inside-codec laddr remote-site/11014 >> > Aug 14 08:01:52 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2326 >> > Aug 14 08:01:52 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2327 >> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2328 >> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2329 >> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2330 >> > Aug 14 08:01:53 %ASA-6-302004: Pre-allocate H323 UDP backconnection >> > for faddr remote-site to laddr inside-codec/2331 >> >> > Aug 14 08:01:52 %ASA-6-302013: Built outbound TCP connection 100295645 >> > for outside:remote-site/11014 (remote-site/11014) to >> > legacy:inside-codec/5556 (EX-inside-codec/5556) >> >> But about an hour into the call, there was this "odd" sequence of events >> (particularly the "closed by inspection" bit): >> >> > Aug 14 09:02:36 %ASA-6-302014: Teardown TCP connection 100295645 for >> > outside:remote-site/11014 to legacy:inside-codec/5556 duration 1:00:45 >> > bytes 6223 Flow closed by inspection >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295706 for >> > outside:remote-site/2445 to legacy:inside-codec/2331 duration 1:00:40 >> > bytes 94208 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295703 for >> > outside:remote-site/2444 to legacy:inside-codec/2330 duration 1:00:44 >> > bytes 402 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295695 for >> > outside:remote-site/2441 to legacy:inside-codec/2329 duration 1:00:42 >> > bytes 111168 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295693 for >> > outside:remote-site/2440 to legacy:inside-codec/2336 duration 1:00:44 >> > bytes 158138102 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295692 for >> > outside:remote-site/2440 to legacy:inside-codec/2328 duration 1:00:44 >> > bytes 198963714 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295688 for >> > outside:remote-site/2439 to legacy:inside-codec/2327 duration 1:00:41 >> > bytes 112048 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295686 for >> > outside:remote-site/2438 to legacy:inside-codec/2334 duration 1:00:44 >> > bytes 30243540 >> > Aug 14 09:02:36 %ASA-6-302016: Teardown UDP connection 100295685 for >> > outside:remote-site/2438 to legacy:inside-codec/2326 duration 1:00:44 >> > bytes 31335820 >> > Aug 14 09:02:36 %ASA-6-302015: Built inbound UDP connection 100675685 >> > for outside:remote-site/2440 (remote-site/2440) to >> > legacy:inside-codec/2328 (EX-inside-codec/2328) >> > Aug 14 09:02:36 %ASA-6-302015: Built inbound UDP connection 100675686 >> > for outside:remote-site/2438 (remote-site/2438) to >> > legacy:inside-codec/2326 (EX-inside-codec/2326) >> > Aug 14 09:02:36 %ASA-6-302015: Built outbound UDP connection 100675688 >> > for outside:remote-site/2440 (remote-site/2440) to >> > legacy:inside-codec/2336 (EX-inside-codec/2336) >> > Aug 14 09:02:36 %ASA-6-302015: Built outbound UDP connection 100675689 >> > for outside:remote-site/2438 (remote-site/2438) to >> > legacy:inside-codec/2334 (EX-inside-codec/2334) >> >> It appears that the "inspection" closed out the call (and the >> back-channel traffic), while the channels continued to pass data (the >> connections built afterward using the same src/dst ports). The call >> could not however be re-established. >> >> Can anyone explain this "closed by inspection" bit? Is that the "cause" >> of the call termination/interruption, or is it an "effect" of an >> incident on the other end? >> >> Thanks in advance, >> >> Jeff >> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
