Actually its that Verio wont accept networks longer than /21. I have a /22 there.
Thats from Dorian according to this http://info.us.bb.verio.net/routing.html#PeerFilter
That connection is not down.
Alan
-Original Message-
From: Marshall Eubanks [mailto:[EMAIL PROTECTED]]
Sent: Tuesd
On Tue, 16 Jul 2002 19:02:22 -0700
"Alan Sato" <[EMAIL PROTECTED]> wrote:
>
> Im having the same problem. I was told Verio was not accepting connections
> from UUnet.
> C:\>tracert www.webshots.com
>
> Tracing route to www.webshots.com [128.242.104.137]
> over a maximum of 30 hops:
>From me
Im having the same problem. I was told Verio was not accepting connections from UUnet.
C:\>tracert www.webshots.com
Tracing route to www.webshots.com [128.242.104.137]
over a maximum of 30 hops:
116 ms16 ms15 ms 66-243-100-1.focaldata.net [66.243.100.1]
216 ms <10 ms
BH> anyone know what is going on over at uu?
BH>
BH> seeing problems all over...
BH>
BH> > 3 <10 ms <10 ms <10 ms 216.79.187.254
BH> > 4 <10 ms10 ms <10 ms 172.25.57.5
BH> > 5 <10 ms10 ms <10 ms 205.152.37.184
BH> > 6 <10 ms10 ms10 ms 500.POS2-0.GW11.
wow.. what are you trying to get to? This looks like it entered 701 on
hop 6 and exited at hop 8 to some other network which sttms to have some
delivery problems of its own.
--Chris
([EMAIL PROTECTED])
###
## UUNET Technologies, Inc.
anyone know what is going on over at uu?
seeing problems all over...
> 3 <10 ms <10 ms <10 ms 216.79.187.254
> 4 <10 ms10 ms <10 ms 172.25.57.5
> 5 <10 ms10 ms <10 ms 205.152.37.184
> 6 <10 ms10 ms10 ms 500.POS2-0.GW11.ATL5.ALTER.NET
> [157.130.76.97]
It is very messy, but until we get a Supervisor/MSFC/PFC that can police on
egress vlan...
We have two bgp sessions with our provider, one that distributes I2 routes,
and the other, default. Each points to the other end of their respective
/30 subnets on their own vlan on an 802.1q trunk (set
> Is this link in production? We are using a gigabit ethernet to our
> provider. We are limited on our traffic going to Commodity traffic, but
> have free reign on our Internet 2 traffic. We found that we get the best
> results when we shape/police our traffic to stay within our contractual
> li
--On Monday, July 15, 2002 10:48 PM -0400 Alex Rubenstein <[EMAIL PROTECTED]>
wrote:
> I'm trying to troubleshoot a problem with a fractional (311 mbit/second)
> gigabit-ethernet line provided to me by a metro access provider.
> Specifically, it is riding a gig-e port of a 15454.
>
> The behavio
Maybe you don't have the router do the authorization of the prefix.
Maybe it asks another box that says yes, or no. If that box disappears
you have a fallback mechanism (prefix-limit and as-path filter). Of
course you still need vendor buy-in.
I don't think this is realistic, so hold the tomato
Hello,
> I've pretty much always assumed that what a switch
> reported as a status regarding the link of a node was the
> actual status of the line to be the case. However, when I
I think that there is no such thing as "the actual status of the line".
Each end of the cable has a status, either
> I would still contend that the number 1 issue is how you do express
> the policy to the routing code. One could potentially attempt to
> recognise the primary key is a route-map/policy-statement and compile
> it as you suggest. It is an idea that ends up being tossed up in the
> air frequentl
Please excuse the duplicate post (If there is one)
Hello all,
After being tasked to diagnose why a node is reporting
a Half duplex connection I ran across an unusual observation.
I've pretty much always assumed that what a switch
reported as a status regarding the link of a node was the
actua
I may be missing something but..
presumably their rate-limiting involves some form of queuing/buffering..
in which case assuming the ping is the only thing occuring, when the rate hits
the limit it will queue, delay and slow down the echo/reply
and no packets should be lost?
on the other h
In other words..intermittent intergap delay?
At 01:33 AM 7/16/2002 -0400, Vincent J. Bono wrote:
>Since this is being done with the 15454s this is not true rate limiting,
>more its a matter of STS channels being made available for use on the Vlan
>assigned to the two GigE ports.
>
>We hav
Vadim Antonov wrote:
>On Mon, 15 Jul 2002, Pedro R Marques wrote:
>
>
>
>> From a point of view of routing software the major challenge of
>>handling a 256k prefix list is not actually applying it to the
>>received prefixes. The most popular BGP implementations all, to my
>>knowledge, have pre
At 11:13 AM 7/15/2002 -0400, Art Houle wrote:
>We are using QOS to preferentially drop packets that represent
>file-sharing (kazaa, gnutella, etc). This saves us 40Mbps of traffic
>across our multiple congested WAN links. The trick is to mark packets
>meaningfully. Also, the WFQ introduces s
On Mon, 15 Jul 2002, Pedro R Marques wrote:
> From a point of view of routing software the major challenge of
> handling a 256k prefix list is not actually applying it to the
> received prefixes. The most popular BGP implementations all, to my
> knowledge, have prefix filtering algorithms that
: A cisco ping is not bursty, to the extent of hundreds of mb/s. Also, cisco
: ping doesn't offer 4,000 pings/sec.
No, but you can start 6 simultaneous sessions to the router and have 5 of
them pinging the other side of the circuit while looking at the 6th
session to watch for traffic leve
19 matches
Mail list logo
