Re: Telnet over WAN latency troubleshooting

Actually there is 'real' documentation. It just doesn't include
information on how to find out line quality information, at least from
the telnet/menu interface. I got info on getting to the CLI, and even
found a usable CLI manual (a royal pain since its not reachable by a
link; you have to do just the right search).

Unfortunately even the CLI manual doesn't provide any way to access
line quality information; only statistics. I can see receive and
transmit errors, but no SNR or noise levels, etc.

The web interface manual does list the info, but I can't get to the
modem via a browser, at least at this time, since that access is
restricted to traffic coming in over the LAN interface. There's
conflicting info about the availability of web interfaces depending on
model and firmware revisions; the 8.5 firmware guide has nothing to say
about a web interface, and the CLI guide only tells you how to turn it
on or off.

I tried Lynx from the Alpha at the central site and got a useless XML
dump. We do not allow the intersite tunnels to route beyond the remote
LAN, and I don't get to change that even for testing, so I can't use a
browser from my own site. Best I can do will be to see if I can walk
someone at the central site through connecting from a peecee, if it
works at all; the remotes don't have peecees or other usable hosts.

Today I connected to each modem, generated a traceroute from that modem
to the LAN side of the modem at each remote site to ID the intervening
routers, then performed long ping tests, both short and long packets,
to each router in turn. The ISP has two jumps between each location
(so its modem - ISP router - ISP router - modem).

Despite continued latency complaints from the users, I had fairly clean
runs. Only one test, from the central site modem to its first hop
router, had 5% packet loss over 300 packets. All preceding and
subsequent tests were clean or only 1 packet lost per 300 tested.
Remote modem to each router in turn heading to the central location
also ran clean or at most 1 packet lost out of 300. But then LAN to
LAN tests also ran cleaner than normal today for some reason, even
though the latency did not go away.

We're having a netguy look at some traces to see if he can id any
problems; I don't have time. We're also seeing if we can get a peecee
to a remote site to telnet to the system, bypassing the decserver on
the off chance there's a problem with it.

Such fun...

Rich

.

Relevant Pages

  • RE: Intrusion Prevention requirements document
    ... The tools consider one interface as "client" and other ... Packet 1 is first sent out on client interface. ... > my previous company was Blade Software where I developed IDS Informer ... Up to 75% of cyber attacks are launched on shopping carts, ...
    (Pen-Test)
  • AS5400 configuration help
    ... just like to configure for modem access, but when I dial into it I get ... controller E1 7/0 ... interface FastEthernet0/0 ... dialer rotary-group 1 ...
    (comp.dcom.sys.cisco)
  • Re: Pix 515 VLAN NAT0 issues
    ... that ACL will be exempt from NAT. ... the packet at the time the PIX receives the packet. ... ACL applied to an inside interface would have the internal IPs as ... accepted as having a translation and satisfying the security policies. ...
    (comp.dcom.sys.cisco)
  • Re: ACTS Problem with Internal Modem
    ... 3com modem, ... Listening on interface #0 wildcard, ... acts: setup ATB1&C0&D2E0L1M1Q0V1 ... fd 4 time 3421861511.761957 timecode 2 AT ...
    (comp.protocols.time.ntp)
  • RE: Intrusion Prevention requirements document
    ... The tools consider one interface as "client" and other ... Packet 1 is first sent out on client interface. ... > The product uses two network cards and so the library of over 700 ... > my previous company was Blade Software where I developed IDS Informer ...
    (Focus-IDS)