|
Home > Archive > alt.certification.cisco > February 2003 > Some latency on the network, and missing pings?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Some latency on the network, and missing pings?
|
|
| looker 2003-02-20, 7:23 pm |
| Hey All,
We are having a small issue with out VOIP network. It seems as though we are
periodically getting network drops when placing a call from the internal
network. We tried tracerouting our internal network, which spans about 6 to
7 physical locations over a VPN created by our back bone provider. When we
traceroute from inside the network, it goes through the normal path then it
seems to produce * * and then timedouts on the router and then through
the network. This only happens periodically, but almost points to a network
lag? I would normally think that ICMP was turned off, but we sometimes see
the router ip. Funny thing is today we did a trace route, and one of the
Router resolved it's outside IP on the inside??
This is very odd, any ideas?
For the most part we are using 1700's with one 2600 in the mix!
Thanks..
| |
| Hansang Bae 2003-02-20, 9:23 pm |
| In article <73f5a.509$Wo6.480@nwrdny03.gnilink.net>, picturelover37
@hotmail.com says...
> Hey All,
>
> We are having a small issue with out VOIP network. It seems as though we are
> periodically getting network drops when placing a call from the internal
> network. We tried tracerouting our internal network, which spans about 6 to
> 7 physical locations over a VPN created by our back bone provider. When we
> traceroute from inside the network, it goes through the normal path then it
> seems to produce * * and then timedouts on the router and then through
> the network. This only happens periodically, but almost points to a network
> lag? I would normally think that ICMP was turned off, but we sometimes see
> the router ip. Funny thing is today we did a trace route, and one of the
> Router resolved it's outside IP on the inside??
> This is very odd, any ideas?
> For the most part we are using 1700's with one 2600 in the mix!
You shouldn't be seeing the outside interface's address unless you had a
transient failure or something (you rode the default GW to your ISP and
it shot it back to you). Doesn't Cisco have a tool to measure latency
for VoIP packets? You can also try pathping if you have Windows 2000.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
******************************
******************************
********
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************
******************************
********
| |
| Bernie 2003-02-20, 9:23 pm |
| On Fri, 21 Feb 2003 01:13:39 GMT, "looker"
<picturelover37@hotmail.com> wrote:
>Hey All,
>
>We are having a small issue with out VOIP network. It seems as though we are
>periodically getting network drops when placing a call from the internal
>network. We tried tracerouting our internal network, which spans about 6 to
>7 physical locations over a VPN created by our back bone provider. When we
>traceroute from inside the network, it goes through the normal path then it
>seems to produce * * and then timedouts on the router and then through
>the network. This only happens periodically, but almost points to a network
>lag? I would normally think that ICMP was turned off, but we sometimes see
>the router ip. Funny thing is today we did a trace route, and one of the
>Router resolved it's outside IP on the inside??
>
>This is very odd, any ideas?
What you really need to do is a VoIP assessment using tools like
NetIQ's Chariot. It is expensive, but without this type of tool, you
are going to be constantly reacting to transient problems. Basically
Chariot is a special traffic generator that you place at various
places in your network to simulate certain numbers of calls. The tool
not only can tell you which conversations had dropped packets, but the
delay, delay variations, and also how those problems affect your MOS
scores etc. You can also run it during different times of the day and
get trending analysis at peak times, etc. Basically there is not much
the took cannot do.
I wouldn't try to tackle troubleshooting weird VoIP problems without
such a tool.
--Bernie
| |
| news.verizon.net 2003-02-21, 2:24 pm |
| 1700 and 1600 routers are not the best equipment to run VOIP. I had the same
problem and I can tell you that 2500 routers with external CSU/DSU units
performed about 40 % better than this routers.
Good luck.
"Bernie" <Bernie@weekend.com> wrote in message
news:26E3C13925B991CF.F666CEAED16CF466.BA4A8602D6CACBBD@lp.airnews.net...
> On Fri, 21 Feb 2003 01:13:39 GMT, "looker"
> <picturelover37@hotmail.com> wrote:
>
> >Hey All,
> >
> >We are having a small issue with out VOIP network. It seems as though we
are
> >periodically getting network drops when placing a call from the internal
> >network. We tried tracerouting our internal network, which spans about 6
to
> >7 physical locations over a VPN created by our back bone provider. When
we
> >traceroute from inside the network, it goes through the normal path then
it
> >seems to produce * * and then timedouts on the router and then through
> >the network. This only happens periodically, but almost points to a
network
> >lag? I would normally think that ICMP was turned off, but we sometimes
see
> >the router ip. Funny thing is today we did a trace route, and one of the
> >Router resolved it's outside IP on the inside??
> >
> >This is very odd, any ideas?
>
> What you really need to do is a VoIP assessment using tools like
> NetIQ's Chariot. It is expensive, but without this type of tool, you
> are going to be constantly reacting to transient problems. Basically
> Chariot is a special traffic generator that you place at various
> places in your network to simulate certain numbers of calls. The tool
> not only can tell you which conversations had dropped packets, but the
> delay, delay variations, and also how those problems affect your MOS
> scores etc. You can also run it during different times of the day and
> get trending analysis at peak times, etc. Basically there is not much
> the took cannot do.
>
> I wouldn't try to tackle troubleshooting weird VoIP problems without
> such a tool.
>
> --Bernie
| |
| looker 2003-02-22, 9:23 am |
| I agree with you. When I saw our backbone network staff install the 1700's I
questioned that, but they are the "pro's". They placed 4 or 5 1700's and one
2600. The connection going into the 2600 seems to be the most problem. It
seems a though going from 1700 to 1700 seems to be fine, but we really can't
test that!
And of course they find nothing!? on their side. We are going into HP
procurves, and cisco catalysts, for the switching. The switches are mainted
by this organizations IT staff (outside).
"news.verizon.net" <garcia.fairbanks@verizon.net> wrote in message
news sv5a.1919$ep5.297@nwrddc02.gnilink.net...
> 1700 and 1600 routers are not the best equipment to run VOIP. I had the
same
> problem and I can tell you that 2500 routers with external CSU/DSU units
> performed about 40 % better than this routers.
>
> Good luck.
>
> "Bernie" <Bernie@weekend.com> wrote in message
> news:26E3C13925B991CF.F666CEAED16CF466.BA4A8602D6CACBBD@lp.airnews.net...
> > On Fri, 21 Feb 2003 01:13:39 GMT, "looker"
> > <picturelover37@hotmail.com> wrote:
> >
> > >Hey All,
> > >
> > >We are having a small issue with out VOIP network. It seems as though
we
> are
> > >periodically getting network drops when placing a call from the
internal
> > >network. We tried tracerouting our internal network, which spans about
6
> to
> > >7 physical locations over a VPN created by our back bone provider. When
> we
> > >traceroute from inside the network, it goes through the normal path
then
> it
> > >seems to produce * * and then timedouts on the router and then
through
> > >the network. This only happens periodically, but almost points to a
> network
> > >lag? I would normally think that ICMP was turned off, but we sometimes
> see
> > >the router ip. Funny thing is today we did a trace route, and one of
the[c
olor=darkred]
> > >Router resolved it's outside IP on the inside??
> > >
> > >This is very odd, any ideas?
> >
> > What you really need to do is a VoIP assessment using tools like
> > NetIQ's Chariot. It is expensive, but without this type of tool, you
> > are going to be constantly reacting to transient problems. Basically
> > Chariot is a special traffic generator that you place at various
> > places in your network to simulate certain numbers of calls. The tool
> > not only can tell you which conversations had dropped packets, but the
> > delay, delay variations, and also how those problems affect your MOS
> > scores etc. You can also run it during different times of the day and
> > get trending analysis at peak times, etc. Basically there is not much
> > the took cannot do.
> >
> > I wouldn't try to tackle troubleshooting weird VoIP problems without
> > such a tool.
> >
> > --Bernie
>
>[/color]
| |
| emailNOSPAM@sover.net 2003-02-24, 12:24 pm |
| I know this may seem like a stupid question but I have not seen it
addressed yet. Have you checked the physical links (packets loss, timing,
traffic, bandwidth spikes...). I have seen problems odd problems over
telco links that do not manifest themselves with regular traffic and only
become apparent with VoIP. Also are you running any routing protocols
over this network?
______________________________
______
Talk is cheap. Supply exceeds Demand.
On Sat, 22 Feb 2003, looker wrote:
>
>
> I agree with you. When I saw our backbone network staff install the 1700's I
> questioned that, but they are the "pro's". They placed 4 or 5 1700's and one
> 2600. The connection going into the 2600 seems to be the most problem. It
> seems a though going from 1700 to 1700 seems to be fine, but we really can't
> test that!
>
> And of course they find nothing!? on their side. We are going into HP
> procurves, and cisco catalysts, for the switching. The switches are mainted
> by this organizations IT staff (outside).
>
>
> "news.verizon.net" <garcia.fairbanks@verizon.net> wrote in message
> newssv5a.1919$ep5.297@nwrddc02.gnilink.net...
> > 1700 and 1600 routers are not the best equipment to run VOIP. I had the
> same
> > problem and I can tell you that 2500 routers with external CSU/DSU units
> > performed about 40 % better than this routers.
> >
> > Good luck.
> >
> > "Bernie" <Bernie@weekend.com> wrote in message
> > news:26E3C13925B991CF.F666CEAED16CF466.BA4A8602D6CACBBD@lp.airnews.net...
> > > On Fri, 21 Feb 2003 01:13:39 GMT, "looker"
> > > <picturelover37@hotmail.com> wrote:
> > >
> > > >Hey All,
> > > >
> > > >We are having a small issue with out VOIP network. It seems as though
> we
> > are
> > > >periodically getting network drops when placing a call from the
> internal
> > > >network. We tried tracerouting our internal network, which spans about
> 6
> > to
> > > >7 physical locations over a VPN created by our back bone provider. When
> > we
> > > >traceroute from inside the network, it goes through the normal path
> then
> > it
> > > >seems to produce * * and then timedouts on the router and then
> through
> > > >the network. This only happens periodically, but almost points to a
> > network
> > > >lag? I would normally think that ICMP was turned off, but we sometimes
> > see
> > > >the router ip. Funny thing is today we did a trace route, and one of
> the
> > > >Router resolved it's outside IP on the inside??
> > > >
> > > >This is very odd, any ideas?
> > >
> > > What you really need to do is a VoIP assessment using tools like
> > > NetIQ's Chariot. It is expensive, but without this type of tool, you
> > > are going to be constantly reacting to transient problems. Basically
> > > Chariot is a special traffic generator that you place at various
> > > places in your network to simulate certain numbers of calls. The tool
> > > not only can tell you which conversations had dropped packets, but the
> > > delay, delay variations, and also how those problems affect your MOS
> > > scores etc. You can also run it during different times of the day and
> > > get trending analysis at peak times, etc. Basically there is not much
> > > the took cannot do.
> > >
> > > I wouldn't try to tackle troubleshooting weird VoIP problems without
> > > such a tool.
> > >
> > > --Bernie
> >
> >
>
>
>
|
|
|
|
|