[ SNIP ]
This is not directed at Sean, but please -- as a fomer Cisco
engineering flunky, I can distinguish between marketing fluff
(even when disguised as a 'case study') and real figures, and
the truth is, there are no figures, because there is dismal
adoption of the services. Go figure.
http://www.boston.com/business/technology/articles/2005/12/13/
telecoms_want_their_products_to_travel_on_a_faster_internet/
My commentary is reserved at this point... but, it does make me
shudder.
Before you complain... It did not require a subscription when I
first saw it.
On Dec 13, 2005, at 2:56 PM, Blaine Christian wrote:
http://www.boston.com/business/technology/articles/2005/12/13/
telecoms_want_their_products_to_travel_on_a_faster_internet/
My commentary is reserved
There is a fundamental security dilemma here. Years ago the original
designers of Privacy Enhanced Mail (PEM) had the notion that users
couldn't be trusted, so the idea was that there would be one root
CA and
it would only issue certificates to people who proved who they were.
Software
On Nov 17, 2005, at 12:25 PM, Jeff Rosowski wrote:
Oh, the irony - all I get is:
Linux Journal Is Currently Unavailable Due to a Denial of Service
(DoS) Attack
Sorry for any inconvenience.
I suppose the bells and the cable providers are DOS'ing them grin.
BTW, it is STILL not clear
J
On Nov 16, 2005, at 12:15 AM, Alain Hebert wrote:
Thanks.
( There is more interesting details but I will reserve myself. (; )
We're already working on making contact with the upstreams, but
you're right I forgot about making more specific announcement.
Thanks again.
access the Internet, could it be more clear?
No, because there is no legal defintion of the Internet.
While it is probably impossible to define a full routing table at
any particular point in time. It IS possible to evaluate/understand
whether someone is purposely, or accidentally,
On Nov 14, 2005, at 11:31 AM, Sean Donelan wrote:
On Mon, 14 Nov 2005, Steven M. Bellovin wrote:
In message Pine.GSO.
[EMAIL PROTECTED], Sean Donela
n writes:
On Mon, 14 Nov 2005, Blaine Christian wrote:
We are talking about an infrastructure that does not lend itself
very
well
On Nov 10, 2005, at 5:56 PM, [EMAIL PROTECTED] wrote:
Begin forwarded message:
From: Brett Glass [EMAIL PROTECTED]
Date: November 9, 2005 10:43:40 AM EST
Here's the latest draft of the Internet
regulation bill, dated November 3rd. Note that, like earlier
versions, it subjects all ISPs and
On Nov 11, 2005, at 10:43 AM, Gordon Cook wrote:
thank you Vint.
folks please note Vint's remarks on common carriage. This stuff
gets very complicate very fast and i do not have it all at the tip
of my tongue by any means. Vint did engage with Fred Goldstein,
Andrew Odlyzko, David
On Nov 9, 2005, at 7:49 PM, Christopher L. Morrow wrote:
On Wed, 9 Nov 2005, Robert Kiessling wrote:
Which rule would you suggest for the IXP? The naive connect
only routers wouldn't do of course in nowaday's world of
hybrids.
yick hybrids...
I like watching some of those hybrids boot
On Nov 10, 2005, at 5:56 PM, [EMAIL PROTECTED] wrote:
Begin forwarded message:
From: Brett Glass [EMAIL PROTECTED]
Date: November 9, 2005 10:43:40 AM EST
Here's the latest draft of the Internet
regulation bill, dated November 3rd. Note that, like earlier
versions, it subjects all ISPs and
On Nov 7, 2005, at 8:32 AM, Howard C. Berkowitz wrote:
At 9:44 AM -1000 11/6/05, Randy Bush wrote:
A peer should never announce a route it has already announced
unless
that route is withdrawn.
one of many counterexamples: change in igp will cause change in
med. any attribute
http://www.networkworld.com/news/2005/110405-juniper-cisco-
hacker.html
Cisco, Juniper, or vendor X. We all benefit by having genetic
diversity in our routing/switching systems. I have been bit hard,
as many of us on this thread have been bit, by bugs in vendor
software/hardware. Support
aol/google/content-provider-foo might provide exclusive content for a
higher (or lower) price than to normal folks, it also might be
bitten by
the lose of potential customers that way :( This sounds like a
business
decision not a legislative one, eh?
Connection web site, should Disney
Neat! So you were thinking you would leave the actual route
selection process monolithic and create separate processes per
peer? I have seen folks doing something similar with separate
MBGP routing instances. Had not heard of anyone attempting this
for a global routing table
On Oct 26, 2005, at 12:12 PM, [EMAIL PROTECTED] wrote:
On Wed, 26 Oct 2005 08:53:50 PDT, Alexei Roudnev said:
Anyway, as I said - it is only small, minor engineering question -
how to
forward having 2,000,000 routes. If internet will require such
router - it
will be crearted easily.
Another thing, it would be interesting to hear of any work on
breaking the router code into multiple threads. Being able to
truly take advantage of multiple processors when receiving 2M
updates would be the cats pajamas. Has anyone seen this? I
suppose MBGP could be rather
I did read your comment on BGP lending itself to SMP. Can you
elaborate on where you might have seen this? It has been a
pretty monolithic implementation for as long as I can remember.
In fact, that was why I asked the question, to see if anyone had
actually observed a
As of the last time that I looked at it (admittedly quite awhile
ago), something like 80% of the forwarding table had at least one
hit per minute. This may well have changed given the number of
traffic engineering prefixes that are circulating.
Tony
Yea, but that's just me pinging
Your signaling traffic will be incredibly low compared to your RTP
streams (especially for G.711u). For G.711u if 2Mbps is your peak
think somewhere in the range of 10kbps or so (complete SWAG but I
hope you get the picture).
Use about 100k per call for 711u and it will help make the
Use about 100k per call for 711u and it will help make the numbers
actually around 88.2k.
I did say round you know! Lol... Things like VAD would drop the
numbers even lower for G.711.
nice and round.
If you are trying to calculate busy hour search for
Erlang on your
I am probably telling you what you already know, but for the ones who
don't know it yet:
Secure BGP (S-BGP):
http://www.ir.bbn.com/projects/s-bgp/
http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf
http://www.nwfusion.com/details/6484.html?def
and of course the sister by amongst
so, 'dumb' but not 'invalid'... There might very well be networks (say not
on the internet) where as-paths longer than 100 might be required. Saying:
they are invalid isn't correct. Saying: The use of as-path longer than
100 on today's Internet isn't helpful is correct, or so say you and
Specifically, they have the ability to tickle a legacy cisco bug with AS
path length. This bug was supposedly mitigated in code and I believe my
previous company is still filtering AS path length (UUNET) of 100 or
greater.
A valid AS-Path of greater than 100 has not yet been found (which was
If you folks could take just a minute to answer a question (off list
please).
Do you ever prepend AS's, other than your own or private ones, to your AS
path?
---form---
YES:
NO:
---endform---
formsample
YES:
NO:X
endformsample
http://yuba.stanford.edu/~appenz/pubs/sigcomm-extended.pdf
Anyone care to comment on this paper? I find that it confirms
my beliefs and gut feeling I have had since 2000 or so, and
my real life experiences with L3 switches with just a few ms
of packet buffer.
I believe buffering is
Can someone confirm from another location? Comments from Akamai?
Google appears to be having DNS issues in several places... Luckily my
internal network cache appears to remain viable. I can not resolve google
from home using a more production set of DNS servers nor can a buddy of
mine
Can I use secondary IP addresses and then BGP with these
addresses, this would
be a form of security by obscurity but providing you can
keep the info a
secret thats surely going to do it?
It will depend on your architecture in large part. In some cases there is
absolutely no need to
The other is our new hot topic of security, not sure if
anyone has thought of this yet (or how interesting it is) but
the nature of the bgp attack means that if you can view a BGP
session you can figure things about a peer that would
otherwise be hidden from you in particular the port
The TTL mechanism is just a way to distinguish at low cost
between good for_us traffic and junk. So more of a classifer
than a security layer, though it can be argued both ways.
And even though it does have security in the title, it is
_not_ a panacea for securing bgp or any routing
Hi Pekka,
Spoofing filters (source address is most useful, but a few
protocols being deployed now also require destination address
based filtering) at your border are still best to prevent
external abuse to your
infrastructure?
I agree that spoofing filters help also (perhaps we
However, this says a TTL of 254 will be accepted. Now the
fact that I
can talk to boxes running a slightly older IOS with a TTL of
0 without
any problems suggests to me that emitting packets with a TTL
of 255 on
router A and accepting packets with a TTL of 254 on router B
7 POS1-2.BR2.LAX9.ALTER.NET (204.255.169.137) 13.461 ms
16.557 ms 12.602 ms 8 * 0.so-0-2-0.XL2.LAX9.ALTER.NET
(152.63.114.246) 230.718 ms 245.466 ms 9 *
0.so-0-0-0.TL2.LAX9.ALTER.NET (152.63.115.146) 220.956 ms *
10 0.so-7-0-0.IL2.DCA6.ALTER.NET (152.63.9.221) 261.532 ms
34 matches
Mail list logo
