Randy Bush wrote:
how do i debug?
athstats
cool!
# athstats -i ath0
21 data frames received
54431data frames transmit
3tx frames with an alternate rate
104704 long on-chip tx retries
22469tx failed 'cuz too many retries
54M current transmit rate
35362tx manage
how do i debug?
athstats
cool!
# athstats -i ath0
21 data frames received
54431data frames transmit
3tx frames with an alternate rate
104704 long on-chip tx retries
22469tx failed 'cuz too many retries
54M current transmit rate
35362tx management frames
3
I'm playing with 6.3-RC1 on a test box to see what breaks for us, and
so far only one thing seems wrong...
If I do:
# route add 1.2.3.4/32 2.3.4.5 -sendpipe 131072
add net 1.2.3.4: gateway 2.3.4.5
It seems to work okay, but the "sendpipe" option doesn't seem to have
any effect:
# route
Bjoern A. Zeeb wrote:
I'd go with something number+space+text as that going to least likely
break existing scripts (unless they match on line end;).
Another thing I am worried about is the output getting more likely 80
chars which is a bit of a pain.
Drop 'prefixlen' and use / instead:
Julian Elischer wrote:
Andre Oppermann wrote:
People with the ultimate need for speed have to maintain their own
trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford
to cut some more corners anyway.
We are trying to get away from that. We are trying to get more BACK
from th
Vadim Goncharov wrote:
Compare it with a scheme where for EVERY forwarded packet, there is a
need for DOUBLE lookup - after a routing one, do another in L2 table.
ARP lookups will generally use a cheap hash once split. What's the problem?
The PATRICIA lookups are more expensive, to be sure. Do
Andre Oppermann wrote:
People with the ultimate need for speed have to maintain their own
trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford
to cut some more corners anyway.
We are trying to get away from that. We are trying to get more BACK
from those companies.
___
At Sat, 5 Jan 2008 12:52:53 +0100,
Michael Tuexen <[EMAIL PROTECTED]> wrote:
> aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
> the site-local stuff be removed?
RFC3879 only deprecates site-local *unicast* addresses; the notion of
"site-local" is still valid for multicast a
On Tue, 8 Jan 2008, Rui Paulo wrote:
At Sat, 05 Jan 2008 11:17:35 +,
Bruce M. Simpson wrote:
Crist J. Clark wrote:
Anyone up for adding text to the scopeid field in the ifconfig(8)
output for IPv6 addresses? Other OSes do. To avoid too much
disruption to the current format, the text is ap
Li, Qing wrote:
To remove an ARP entry for host A.B.C.D in L2 table of form
(A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)
routing lookup for host A.B.C.D and modify a one pointer in
it's rtentry to NULL or remove rtentry (if it's selected to
be implemented as cloned). Thus
At Sat, 05 Jan 2008 11:17:35 +,
Bruce M. Simpson wrote:
>
> Crist J. Clark wrote:
> > Anyone up for adding text to the scopeid field in the ifconfig(8)
> > output for IPv6 addresses? Other OSes do. To avoid too much
> > disruption to the current format, the text is appended after the
> > curre
Randy Bush wrote:
just for giggles i un-hacked the mtus and ran for an hour with no
one using the wireless
soek0.psg.com:/root# netstat -i
NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll
vr01500 00:00:24:c8:b3:2819022 016015 0 0
vr1
>
> Why a full walk, why such a dumb way?
>
Correct, we don't do a full walk.
>
> To remove an ARP entry for host A.B.C.D in L2 table of form
> (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)
> routing lookup for host A.B.C.D and modify a one pointer in
> it's rtentry
>
> Surely, routing table should contain a cached pointer to an
> entry in L2 table (ARP in case of Ethernet), to not do double
> lookups. But still separate those tables...
>
The routing table contains only the interface route, from this
interface route the L2 table is accessed for on ne
07.01.08 @ 03:41 Andre Oppermann wrote:
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limite
15 matches
Mail list logo
