On Fri, 15 Oct 2004, Paul Vixie wrote:
... tell the hotel to put the room in your name and you can call them
and give them a credit card number. as-of: Fri Oct 15 18:11:14 GMT 2004.
at "Fri, 15 Oct 2004 14:20:30 -0400", patrick gilmore got this room.
next time, though, i ought to get a couple of
On Fri, 15 Oct 2004, Paul Vixie wrote:
>
> > > > > And what do you do with a BGP customer which sends you traffic
> > > > > from prefixes he doesn't want to announce to you? There are such
> > > > > customers. Fail filter ACL?
> > > >
> > > > This has been my question with uRPF from the beginni
> > > > And what do you do with a BGP customer which sends you traffic
> > > > from prefixes he doesn't want to announce to you? There are such
> > > > customers. Fail filter ACL?
> > >
> > > This has been my question with uRPF from the beginning. You can
> > > solve this on for some networks, bu
> ... tell the hotel to put the room in your name and you can call them
> and give them a credit card number. as-of: Fri Oct 15 18:11:14 GMT 2004.
at "Fri, 15 Oct 2004 14:20:30 -0400", patrick gilmore got this room.
next time, though, i ought to get a couple of extra rooms and then auction
them
tcptrace with xplot or jplot could help you out debuging this issue.
http://jarok.cs.ohiou.edu/software/tcptrace/useful.html
_sergei
On Fri, 15 Oct 2004 10:11:36 -0700, Alexei Roudnev <[EMAIL PROTECTED]> wrote:
>
> CAR does not work like a regular link; no way. It works like a link with 0
> b
On Fri, 15 Oct 2004, Paul Vixie wrote:
>
> > > And what do you do with a BGP customer which sends you traffic from
> > > prefixes he doesn't want to announce to you? There are such customers.
> > > Fail filter ACL?
> >
> > This has been my question with uRPF from the beginning. You can solve thi
Hi all. I am Dan Ellis, CTO of PenTeleData. We are a regional ISP/communications
company owned by 7 cable and telephone companies, responsible for 150k+ broadband
subscribers and associated IP infrastructures. Like many MSO's, we are looking at
rolling out a large (300-500+ AP) distributed
Good day,
As many of you know, I am a network engineer at the University of
Wisconsin, Madison. We are currently in the preliminary planning stages
of our next generation campus network and would like to get some ideas
on what the "real world" is actively doing to focus in on the
appropriate te
i got the room just before the deadline, it's in the nanog/arin hotel,
but i'm not going to make it to DC after all. first come first served;
if you wanted to be in the conference hotel but missed the deadline, i
can tell the hotel to put the room in your name and you can call them
and give them
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]
If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.
Routing Table Report 04:00 +10GMT Sat 16 Oct, 2004
CAR does not work like a regular link; no way. It works like a link with 0
buffer size.
Problem is that CAR drops packets which override bandwidth, do not query
them (and do not prioritize them), so it use TCP adaptation to the packet
drop, not to the delay/rtt. This thing works fine with drop l
--On 15 October 2004 12:31 -0400 Andy Dills <[EMAIL PROTECTED]> wrote:
If the desire is to provide a simulated circuit with "x" bandwidth, CAR
does a great job, IFF you correctly size the burst: 1.5x/8 for the normal
burst, 3x/8 for the max burst.
The aggregate rate of the transfer is "x" in all t
On Fri, 15 Oct 2004, Alex Bligh wrote:
> I can support what Iljisch said.
>
> In a former life I ran extensive tests on the effect of CAR on TCP (no
> longer have the data to publish, but it's out there), and it's "just plain
> broken" - if your purpose is to simulate a lower amount of bandwidth
--On 15 October 2004 11:46 -0400 Andy Dills <[EMAIL PROTECTED]> wrote:
Hmm...I'd have to disagree. Are you perhaps assuming a certain threshold
(>100mbps, for instance)?
I use rate limiting for some of my customers, and when correctly
configured (you _must_ use the right burst sizes), you will get
> > And what do you do with a BGP customer which sends you traffic from
> > prefixes he doesn't want to announce to you? There are such customers.
> > Fail filter ACL?
>
> This has been my question with uRPF from the beginning. You can solve this
> on for some networks, but it doesn't scale very
On Fri, 15 Oct 2004, Iljitsch van Beijnum wrote:
> However, the cause can also be rate limiting. Rate limiting is deadly
> for TCP performance so it shouldn't be used on TCP traffic.
Hmm...I'd have to disagree. Are you perhaps assuming a certain threshold
(>100mbps, for instance)?
I use rate li
I'd like to review any methods by which operators are currently
exchanging e.164 telephony route information between VoIP systems
(excluding SS7.) In the last ~1 year, I have not heard of any
significant changes in the manner in which routes are exchanged; the
typical method still seems to be
For those that have added your PGP key to the keyring at biglumber,
thank you. If you have not yet submitted your key, please do so,
and know that you can safely ignore the remainder of this message.
At NANOG 32 we will be trying out a new, hopefully greatly improved
method for signing keys for
On Oct 15, 2004, at 14:24 Uhr, Alex Bligh wrote:
I can't remember what the tool is now, but there used to be a tool
which
worked like ping but sent a udp stream at a given rate per second and
told
you about packet drops,
iperf? (works for both, tcp and udp)
Regards, Marc
--
Marc Binderberger
Alex Bligh wrote:
--On 15 October 2004 13:33 +0200 Iljitsch van Beijnum
<[EMAIL PROTECTED]> wrote:
However, the cause can also be rate limiting. Rate limiting is deadly
for
TCP performance so it shouldn't be used on TCP traffic.
Add "unless appropriate shaping is performed prior to the rate-li
Stephen J. Wilcox wrote:
On Thu, 14 Oct 2004, Joe Maimon wrote:
Sabri Berisha wrote:
On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote:
With the risk of stating the obvious I would say that normally, PMTUD
should do the trick.
On todays internet everything is more relia
I've used QCheck (freeware) for testing response time, TCP and UDP
performance, and packet loss. Works well. You need to install the enpoint on
the target machine. Check out:
http://www.ixiacom.com/products/performance_applications/pa_display.php?skey
=pa_q_check
-Mike McSpedon
Arrow Global Data
--On 15 October 2004 13:33 +0200 Iljitsch van Beijnum <[EMAIL PROTECTED]>
wrote:
However, the cause can also be rate limiting. Rate limiting is deadly for
TCP performance so it shouldn't be used on TCP traffic.
Add "unless appropriate shaping is performed prior to the rate-limiting
with the para
This report has been generated at Fri Oct 15 21:44:38 2004 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table Hist
On Fri, 15 Oct 2004, Joe Shen wrote:
>
> Hi,
>
> the network path is:
>
>
> |-(ADSL)\
> customer/ --Edge_router---...---Japan
> Server
> \-(100Methernet)-/
>
>
> So, from edge_router to Japan server the path is
> identical.
>
> Yes. But, for ftp TCP contr
On 15-okt-04, at 12:04, Joe Shen wrote:
Your explanation on TCP behavior seems reasonable, but
why TCP over fast access line express so much packet
loss than slow access line ? Do WindowsXP/Win2k
determine its startup sending window according to
access speed or path MTU ?
I don't think there is muc
>
> It's generally a bad idea to turn of ethernet
> autonegotiation unless
> the equipment at the other side doesn't support it.
>
Yes, we've checked the configuration, both access
router interface and customer's ethernet interface are
forced to be (100Mbsp, full duplex). And, there is no
CRC
On Thu, Oct 14, 2004 at 06:05:06PM +0200, Mikael Abrahamsson wrote:
>
> On Thu, 14 Oct 2004, Sabri Berisha wrote:
>
> > for the lack of knowledge of the end-user administrators or webmasters.
>
> ... or vendors of equipment that these people use. There are plenty of
> vendors out there who mak
Hi Joe,
"divide et impera" :-)
Put a (FTP-)server in _your_ network to get an idea if the problem is
with the edge device (or somewhere in your network) or on the WAN to
Japan.
The PING may not tell you much about short-term queue problems in a
device. As Mikael Abrahamsson wrote use a sniffer
On 15-okt-04, at 10:14, Joe Shen wrote:
The
measuring is scheduled 20packet per 20seconds, we also
ping each hop address along the path to server. The
result shows there is no packet loss along from
monitoring computer to customer site, but packet loss
increase at a special hop along the path to se
Hi,
the network path is:
|-(ADSL)\
customer/ --Edge_router---...---Japan
Server
\-(100Methernet)-/
So, from edge_router to Japan server the path is
identical.
>
> There is something wrong with both scenarios.
>
> A 5 Mbyte file is 40 megabits. W
31 matches
Mail list logo
