On Mon, 25 Mar 2002, Pistone, Mike wrote:
I was curious if anybody would share what they consider to be average or
acceptable transatlantic ping response times over a T1.
I know there are tons of variables here, but I am looking for ballpark
figures.
Assume that utilization on the circuit
On Sun, 7 Apr 2002, Richard A Steenbergen wrote:
Layer 3 devices usually do a form a load balancing called equal cost
forwarding. If you have two routes to a single prefix (say you have two
physical links), and both have the same routing cost, packets may be
load balanced across those
On Mon, 22 Apr 2002, Mark Radabaugh wrote:
www.on-the-i.com has four channels that multicast music. I prefer
channel 2 but that's just me :-)
Yes, but how do I get those multicast packets to flow over my network? It
seems the Mbone has dropped of the face of the net and everyone still
doing
.
Iljitsch van Beijnum
On Thu, 2 May 2002, Avleen Vig wrote:
Basically, it works like this: when you identify the target of the attack,
you have traffic for those target addresses rerouted to a filter box.
This filter box then contains source address based filters to get rid of
the attacking traffic.
Two
On Thu, 2 May 2002, LeBlanc, Jason wrote:
There are some limitations as to where uRPF works, SONET only on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I
think) regardless of interface type. Impact should be minimal, as it simply
does a lookup in the CEF
On Thu, 2 May 2002, Christopher L. Morrow wrote:
Congrats on re-inventing the wheel :( This is what
mazuu/arbor/wanwall(riverhead now?) all do... this is also the way
CenterTrack(tm robert stone) was kind of supposed to work.
Thanks for the kind works.
Just to be clear: I'm not working on
On Thu, 2 May 2002, Richard A Steenbergen wrote:
RPF works by matching the source address of the packet against the CEF
table, in addition to the normal match against the destination address.
There are multiple modes of operation, ranging from is there a route
for the source address to the
apps set the source to the group address as well.
Iljitsch van Beijnum
On Sun, 5 May 2002, Christopher L. Morrow wrote:
like with single homed customers. The only time when those sets of
prefixes is NOT the same is for a backup connection. But if a connection
Not always the case, customer behaviour can not be accurately modeled.
I was hoping someone
A bunch of us are thinking about multihoming solutions for IPv6. For this
purpose, it is useful to know a bit more about how actual networks (rather
than the ones existing only as ASCII drawings) interconnect. So:
- What are the 12 - 18 most important interconnect locations in the world?
MAE
On Mon, 26 Aug 2002, Greg A. Woods wrote:
As a user, I pay my ISP to forward IP packets. If there happen to be TCP
segments in those packets, that's something between me and the person the
packet is addressed to, whether the destination port of those TCP segments
is 25 or something
On Mon, 26 Aug 2002, Greg A. Woods wrote:
Well, you might be able to pay your ISP for that kind of service, but
not all ISPs need supply such service and certainly not many users
really _need_ such a level of service.
So now I have to justify the kind of services I want to use?
On Tue, 27 Aug 2002, Marshall Eubanks wrote:
Since it so easy for a host (relative to ipv4) to have multiple ip
addresses, I like what Microsoft has done. If told by a router, a Win
XP box will assign itself a global unicast address using EUI-64. It
will also create a global unicast
On Tue, 27 Aug 2002, Kurtis Lindqvist wrote:
censored fears abuse as a hardware ID wired into the ipv6 protocol can
be used to determine the manufacturer, make and model number, and value
of the hardware equipment being used by the end user.
...uhm, and? What is the real difference with
hoping to avoid the mess that is IPv4), but I
think we're getting closer to a solution.
Iljitsch van Beijnum
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
I would definately not recommend route reflection or a confederation in a
network with such a small number of BGP routers:
In spirit of the above, I suggest you also do not have maintenance window,
forget about re-checking configs, enable to
|no|always|Counter]
that's how you turn that stupid feature off, it is annoying IMHO and
quite useless as
Why is it stupid, annoying and useless?
Iljitsch van Beijnum
time values with us?
Iljitsch van Beijnum
address for route from other AS points to. Since this can't be a loopback
address and you typically don't run an IGP on subnets between border
routers in your AS and a remote AS, you need to either set next-hop-self
on all IBGP sessions or redistribute connected in your IGP.
Iljitsch van Beijnum
On Tue, 3 Sep 2002, Frank Scalzo wrote:
Since when is BGP a bug-free protocol? Let's not forget the BGP best
path selection algorithm itself is broken
Actually, the RFC says the route selection algorithm is a local matter, so
if it's broken on your network, then strictly speaking, it's your
what I'm talking about, but network
192.0.2.0/24 is no good?
If it doesn't do anything else, at least IPv6 will get rid of this
problem.
Iljitsch van Beijnum
the rules we use here.
Iljitsch van Beijnum
On Fri, 6 Sep 2002, Joe Abley wrote:
Actually, I would assume it to be the other way around: if you only
communicate with people who are active in the field who are aware of
all the new tricks, how are you going to learn about obsolete stuff?
I think there is often a directed graph of
On Mon, 9 Sep 2002, Hank Nussbacher wrote:
The spamming is usually done (but not only) from an Internet cafe where the
spammer inserts a spammer CD and blasts away at open mail relays. When
SMTP is blocked for that IP, they switch to HTTP and send the spam via MSN,
Yahoo, Hotmail,
On Mon, 9 Sep 2002, Hank Nussbacher wrote:
Looking for automatic off-the-shelf solution. Not something that requires
a NOC to constantly update a Cisco ACL.
Correct me if I'm wrong, but the web (ok, most of it) has been running on
TCP port 80 for quite a while now. So if you limit outgoing
On Mon, 9 Sep 2002, Al Rowland wrote:
Final comment on this subject (I promise) :)
How many (more) protocols are we willing to cripple in the name of
fighting spam?
Obviously the crippled protocol here is SMTP, because it allows pretty
much everything. As a rule, I'm against solving
On Tue, 10 Sep 2002, Brad Knowles wrote:
Brad No, the traffic budget is on upstream traffic, not
Brad downstream. Stream content all you want, but don't try to
Brad generate too much upstream traffic or you get your bandwidth
Brad severely curtailed.
[The
On Mon, 9 Sep 2002, Marshall Eubanks wrote:
Ok, suppose someone can touch type. The world record is something like 600
key presses per minute, which is 10 41-byte TCP packets per second ~= 4
kbps.
When I go to Internet cafe's (I like Global Gossip), I connect my Ti-book
to the local
On Tue, 10 Sep 2002 [EMAIL PROTECTED] wrote:
It is more trouble than its worth. SPAM is not a technical problem. It is a
social problem. Using technical methods is not going to solve the problem.
There are two saying that come to mind:
You can't solve social problems with technical
On Tue, 10 Sep 2002 [EMAIL PROTECTED] wrote:
We don't even have to throw out SMTP - there's STARTTLS, AUTH, PGP, and
so on. The problem is that we don't know how to do a PKI that will
scale (note that the current SSL certificate scheme isn't sufficient, as
it usually does a really poor job
On Wed, 11 Sep 2002, Jared Mauch wrote:
There are a lot of things one can do:
1) enable wep
2) rotate wep keys
3) authenticate by mac-address
4) restrict dhcp to known mac-addresses
5) force utilization of vpn/ipsec client
Suddenly laying down UTP
On Fri, 13 Sep 2002, Stephen J. Wilcox wrote:
At what point does one build redundancy into the network.
No, it doesnt necessarily use IX's, in the event of there being no peered path
across an IX traffic will flow from the originator to their upstream
tier1 over a private transit link,
On Wed, 18 Sep 2002, Steven M. Bellovin wrote:
See http://www.whitehouse.gov/pcipb/
Wow, we should all start using out of band management. Anyone think it is
feasible to do management of an IP network exclusively out of band?
And BGP should be more secure. What is the problem we should be
On Wed, 18 Sep 2002, Jared Mauch wrote:
And BGP should be more secure. What is the problem we should be trying to
fix here? There is a Secure BGP draft:
http://www.ir.bbn.com/projects/sbgp/draft-clynn-s-bgp-protocol-00a.txt
I think the problem that people are attempting to address
On Fri, 20 Sep 2002, David Diaz wrote:
The hop count question is interesting. Is the consensus that it's
mostly a customer service issue, where latency isnt affected but
customer perception is? Or is it a real latency issue as more
routers take a few CPU cycles to make a routing decision.
On Fri, 20 Sep 2002, Petri Helenius wrote:
Under the best possible circumstances, most of the extra delay is due to
the fact that routers do store and forward forwarding, so you have to
wait for the last bit of the packet to come in before you can start
sending the first bit over the
as well, and use TCP MD5
password protection on all BGP sessions. That's something we can all do
before the month is out and it will actually make the net more secure
without breaking anything.
Iljitsch van Beijnum
On Sun, 22 Sep 2002, Richard A Steenbergen wrote:
On Sun, Sep 22, 2002 at 01:11:07PM +0200, Iljitsch van Beijnum wrote:
There are also people ssh'ing to personal and corporate machines from
the terminal room where the root password is given out or easily
available.
Are you saying
On Sun, 22 Sep 2002, John M. Brown wrote:
a prudent user does not ssh _from_ a machine they don't control or
prudent users don't get hacked.
Really? Care to list the bulletproof hardware and software these god-like
creatures use, rather than the bug-ridden stuff we lesser folk have to
make
On Fri, 27 Sep 2002, Stephen J. Wilcox wrote:
When designing an all IP network requiring mostly Ethernet interfaces, the
logical conclusion is to specify layer 3 switches (instead of routers). The
cost per port and functionality requirements make a layer 3 switch the
perfect choice.
On Fri, 27 Sep 2002, Richard A Steenbergen wrote:
On Fri, Sep 27, 2002 at 11:28:39AM +0200, Iljitsch van Beijnum wrote:
Core routers typically don't do any filtering and the BGP setup (if any)
is straightforward, so switch-like routers are good here.
May god have mercy on your core
On Thu, 3 Oct 2002, Marshall Eubanks wrote:
Where are they diverting it to, the Moon (1.5 light seconds away) ?
Really - I have seen some multisecond latencies on network links we were
testing, and I always wondered how these could come to be.
Good question. Cisco routers use a default
On Fri, 4 Oct 2002, Petri Helenius wrote:
Vendor C sells packet memory up to 256M each way for a line card. Whether
this makes any sense depends obviously on your interfaces.
Hm, even at 10 Gbps 256M would add up to a delay of something like 200 ms.
I doubt this is something customers like.
On Fri, 4 Oct 2002, Petri Helenius wrote:
Kind of an arms race between the routers and the hosts to see which can
buffer more data.
You usually end up with 64k window with modern systems anyway. Hardly
anything uses window scaling bits actively.
I also see ~17k a lot. I guess most
On Fri, 4 Oct 2002, Sean Donelan wrote:
Should the Service Provider version of routing software include the
redistribute bgp command? Other than CCIE labs, I haven't seen a
real-world use for redistributing the BGP route table into any IGP.
I don't think it's the business of anyone outside
On Sat, 5 Oct 2002, Rafi Sadowsky wrote:
IvB Obviously some packet loss and jitter are normal. But how much is
IvB normal? Even at a few tenths of a percent packet loss hurts TCP
IvB performance. The only way to keep jitter really low without dropping large
IvB numbers of packets is to
On Mon, 7 Oct 2002, David Luyer wrote:
But not allowing BGP - IGP - BGP might be a good one. On the other hand,
someone who is determined to screw up could do BGP - IGP on one router
and IGP - BGP on another.
I've seen that done. And usefully.
But it's just too dangerous.
Any
On Tue, 8 Oct 2002, Chris Wedgwood wrote:
FWIW, almost nobody filters rfc1918 packets outbound and a good
percentage of ISP customers bleed these something terrible
Actually, that's a good thing. This makes it trivial to detect which peers
aren't doing egress filtering. If people just
On Tue, 8 Oct 2002, Kelly J. Cooper wrote:
Also, egress filtering is NOT easy,
I don't care. And it doesn't have to be egress filtering as such,
filtering packets you receive from your customers will work just as well.
Plus, lots of attacks these days are mixing spoofed and legit traffic,
On Tue, 8 Oct 2002, Joe Abley wrote:
Also, egress filtering is NOT easy,
What is difficult about dropping packets sourced from RFC1918 addresses
before they leave your network?
But what's the point?
That's like complaining that the door isn't locked while the house has no
walls.
On Tue, 8 Oct 2002, Joe Abley wrote:
What is difficult about dropping packets sourced from RFC1918
addresses before they leave your network?
But what's the point?
Politeness, I guess. Seems rude to send traffic to peers when you
absolutely know that the source address is inaccurate.
There are two separate issues:
1. Making sure packets with falsified source addresses don't leave your
network
This can be done by having customer-specific filters on all
customer-facing interfaces. (And on interfaces connecting to any type of
hosts in case those are compromised.) Or use the
On Tue, 8 Oct 2002, John M. Brown wrote:
It seems to reason that if people started filtering RFC-1918 on
their edge, we would see a noticable amount of traffic go away.
Simulation models I've been running show that an average of 12 to 18 percent
of a providers traffic would disappear if
On Tue, 8 Oct 2002, John M. Brown wrote:
Why is it hard to believe that a large amount of RFC-1918 sourced
traffic is floating around the net?
Because if 20% of all people generate this crap (which is a huge number)
it must be 90% of their traffic to get at 18%. How can someone generate so
On Tue, 8 Oct 2002 [EMAIL PROTECTED] wrote:
Because if 20% of all people generate this crap (which is a huge number)
it must be 90% of their traffic to get at 18%. How can someone generate so
much useless traffic and keep doing it, too?
How much you want to bet that *all* the internal
On Wed, 9 Oct 2002, Stephen J. Wilcox wrote:
On a related issue (pMTU) I recently discovered that using a link with MTU
1500 breaks a massive chunk of the net - specifically mail and webservers who
block all inbound icmp.. the servers assume 1500, send out the packets with DF
set, they hit
On Thu, 10 Oct 2002, Richard A Steenbergen wrote:
Even Windows 2000+ includes blackhole detection which will eventually
remove the DF bit if packets aren't getting through and ICMP messages
aren't coming back, something many unixes lack.
Wow, now I'm impressed. And what about the 1999 other
the traffic stats at
http://www.ams-ix.net/hugegraph.html Usually, incoming and outgoing
traffic is the same. But during this problem, much more traffic went out
than came in.
Iljitsch van Beijnum
On Wed, 23 Oct 2002, Greg Pendergrass wrote:
There has been a lot about what did not happen yesterday, but how about some
details about what did happen? Was it a ping flood, syn-flood, smurf, or
some combination of types? Were the zombie machines windows, linux, or both?
Some of the root
On Wed, 23 Oct 2002, Neil J. McRae wrote:
There seem to be large scale problems at the AMS-IX. BGP sessions with
peers keep oscillating. Since their own addresses keep jumping all
over the place, it is not possible to reach anyone over the AMS-IX
tech list.
I have disabled all AMS-IX
On Wed, 23 Oct 2002, Neil J. McRae wrote:
Did you try calling them?!
No. I have enough confidence in the AMS-IX staff to trust they'll notice
problems without me having to tell them about it.
So why send an email here?
To advise other network operators of the problem, so they could
everyone who is present there looks in to doing the same.
Iljitsch van Beijnum
On Sat, 25 Jan 2003, Doug Barton wrote:
Anyone want to get involved in some sort of real time chat (like IRC) to
disuss strategies? We're seeing some pretty big traffic, and related
problems in multiple colo's world wide.
What's to discuss? If you put something like
access-list 150 deny udp
On Sat, 25 Jan 2003, Mikael Abrahamsson wrote:
Does it really have to be this time everytime something happens and it
actually would be nice to get the information out quickly?
In this case there may be a causal relationship between the two. Being a
mailing list server can't be a fun job when
On Sat, 25 Jan 2003, Christopher L. Morrow wrote:
wants to log for a while and then counts hits against the cache until it
only for identical packets... so source A:123 - Dest B:80 x50 packets
gets logged 'once'. One log for the first packet and update logs at 5 min
intervals (which
On Sat, 25 Jan 2003, K. Scott Bethke wrote:
Keep in mind that these problems aren't from 'well behaved' hosts, and
'well behaved' hosts normally listen to ECN/tcp-window/Red/WRED
classic DoS attack scenario. :(
I understand the evils, but are we really at the mercy of situations like
Sean Donelan wrote:
Many different companies were hit hard by the Slammer worm, some with
better than average reputations for security awareness. They bought
finest firewalls, they had two-factor biometric locks on their data
centers, they installed anti-virus software, they paid for SAS70
On Tue, 28 Jan 2003, Scott Francis wrote:
I'm still looking for a copy of the presentation, but I was able to find a
slightly older rant he wrote that contains many of the same points:
http://www.bsdatwork.com/reviews.php?op=showcontentid=2
Good reading, even if it's not very much practical
On Wed, 29 Jan 2003 [EMAIL PROTECTED] wrote:
Does anybody know how/if I can force cisco router to consider ospf route
(I'll consider other igp protocol if its possible) from particular source
to be prefereble over connected and locally-entered static routes. This is
needed for failover
On Fri, 31 Jan 2003, Jack Bates wrote:
If a proper rulebased system were implemented, wouldn't this account for the
issues? For example, implementation of an increase is only allowed by peer E
if the traffic has been a gradual increase and X throughput has been met for
T amount of time. Peer
On Wed, 12 Feb 2003, David Wilburn wrote:
Let's assume that I have a large-ish network with multiple connections
to the Internet and ambiguous routing (meaning that a packet might come
in one gateway and the response packet might leave through a different
gateway).
We usually call this
point is that you'd be able to go from New York to
London over Tokio if the direct line is congested.
--
Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: Feb 14, 14:12:15)
On Sun, 16 Feb 2003, Scott Granados wrote:
Can someone give me a good pointer as to places to start learning more about
ipv6?
You could try a book or two. Or if you're not afraid of RFCs: reading
2460, 2373, 2374, 2461 and 2462 should give you a good start. After that
you're ready to start
On Mon, 17 Feb 2003, Steve Feldman wrote:
through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels
over the public Internet.
Maybe a stupid question... why would you need GRE tunneling while IPsec
has a tunnel mode of its own?
On Tue, 18 Feb 2003, Petri Helenius wrote:
Maybe a stupid question... why would you need GRE tunneling while IPsec
has a tunnel mode of its own?
Probably because a major router vendor, despite of repeated customer requests,
declined to implement routing across such tunnel mode.
So if the
On Tue, 18 Feb 2003, Stephen Sprunk wrote:
In fact, a method to encrypt small parcels of data efficiently is
well-known for decades. It is called stream cypher (surprise).
Besides LFSR-based and other stream cyphers, any block cypher
can be used in this mode. Its application to RTP is
On Thu, 20 Feb 2003, William Allen Simpson wrote:
Worse, it only takes 1 infected host to re-infect the entire net in
about 10 minutes. So, the entire 'net has to cooperate, or we'll see
continual re-infection.
Only if people didn't fix their servers. And if they didn't, this
reverse denial
On Thu, 20 Feb 2003, Joshua Smith wrote:
Only if people didn't fix their servers. And if they didn't, this
reverse denial of service attack is a good reminder.
what was that one worm from a year or two ago that was eliminated from the
net, oh yeah, code red..if they didn't fix
On Fri, 21 Feb 2003, William Allen Simpson wrote:
I've been pretty disappointed with some of the responses on this issue.
:-)
I'm of the technical opinion that everyone will need to filter outgoing
1434 udp forever.
Forget it. That's a port used for legitimate traffic. Besides, filtering
On Thu, 27 Feb 2003, Tim Rand wrote:
I have searched the archives but have not found an answer to my question - is there
any danger in using excessively high TTL values with ebgp-multihop?For example,
neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed,
if we can't determine if routes are good or bad? If you
reject the routes you break a lot of connecitvity. If you don't, nobody
will bother jumping through all the hoops to make their route
authenticity verifiable. I really don't envy the first operator to
deploy (S-|so)BGP...
--
Iljitsch van Beijnum
On Sun, 2 Mar 2003, Avi Freedman wrote:
In article [EMAIL PROTECTED] The Great Sean wrote:
^^
: I'll be stupid, and ask some questions I've always wondered about.
: Why should routes learned by eBGP have a higher priority than
On maandag, maa 3, 2003, at 16:44 Europe/Amsterdam,
[EMAIL PROTECTED] wrote:
tool in the generic sense. too many things that depend on
LDAP for proper functioning -will- make LDAP a tempting
target.
So not functioning properly is preferable to depending on a tempting
On maandag, maa 3, 2003, at 17:30 Europe/Amsterdam,
[EMAIL PROTECTED] wrote:
So not functioning properly is preferable to depending on a tempting
target for proper functioning?
what is not functioning properly?
Determining who is authorized to announce a certain block of IP address
space.
On maandag, maa 3, 2003, at 18:41 Europe/Amsterdam,
[EMAIL PROTECTED] wrote:
what is not functioning properly?
Determining who is authorized to announce a certain block of IP
address
space.
no protocol is going to help with this problem. its a
social engineering issue, not a
On dinsdag, maa 4, 2003, at 10:26 Europe/Amsterdam,
[EMAIL PROTECTED] wrote:
How would you feel about ARIN being the root of a registry hierarchy
that
works similar to the DNS? In that case, ARIN would not necessarily hold
the route information, they would just be at the top of the search
On Fri, 7 Mar 2003, Dave Israel wrote:
Yeah. Give me a million dollars, plus fiber from here to anywhere,
and let me muck with the TCP algorithm, and I can move a gig-e worth
of traffic, too.
Doing the 923 Mbps for one stream may be non-trivial (heck, even doing
110 MB per second sustained
On Sat, 8 Mar 2003, Cottrell, Les wrote:
We used a stock TCP (Linux kernel TCP). We did however, use jumbo
frames (9000Byte MTUs).
What kind of difference did you see as opposed to standard 1500 byte
packets? I did some testing once and things actually ran slightly faster
with 1500 byte
On Sat, 8 Mar 2003, Joe St Sauver wrote:
you will see that for bulk TCP flows, the median throughput is still only
2.3Mbps. 95th%-ile is only ~9Mbps. That's really not all that great,
throughput wise, IMHO.
Strange. Why is that? RFC 1323 is widely implemented, although not
widely enabled
-compatible
adoption of jumboframes a possibility. (Maybe retrofit ND into v4 while
we're at it.)
Iljitsch van Beijnum
On Mon, 10 Mar 2003, Richard A Steenbergen wrote:
On the receive size, the socket buffers must be large enough to
accommodate all the data received between application read()'s,
That's not true. It's perfectly acceptable for TCP to stall when the
receiving application fails to read
On Mon, 10 Mar 2003, Todd A. Blank wrote:
I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post. This approach punishes the clueless instead
of the people that already know
On Tue, 11 Mar 2003, Jack Bates wrote:
Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be
On Tue, 11 Mar 2003, Peter Galbavy wrote:
If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router
correctly, he can actually refuse to accept advertisements from other
sessions that are longer versions of prefixes received through this session.
How???
On Wed, 12 Mar 2003 [EMAIL PROTECTED] wrote:
I'm sure a lot of people have the same problem as we are having... Our
NOC and Server Equipment is located in No Cell Phone signal zone of our
building (It's amazing what metal walls, Server Racks and HVAC Systems
will do to Cellphone Signals). I
On Wed, 12 Mar 2003, Jack Bates wrote:
traffic going to them. My router shows the last BGP peer reset about that
time, so this could be me sending the global table. His bandwidth then drops
to 0 for almost exactly 30 minutes (MRTG isn't an exactly graph). My guess
(authoratative answer) was
On Wed, 12 Mar 2003, Randy Bush wrote:
You need at least three flaps to trigger dampening.
i guess you really need to look at that pdf.
You are right, it is depressing. However, I don't see how the penalty
multiplication could happen here, you need a few hops in between for
that.
On Wed, 12 Mar 2003, Danny McPherson wrote:
Dampening is done on the eBGP router where the route enters the AS, and,
unless I'm mistaken, per route/path and not per prefix. So the flapping
that ISP A sees from ISP B is a completely seperate thing from the
flapping that ISP A sees from
1 - 100 of 522 matches
Mail list logo
