Mailing List Archive

All,

>Paul A Vixie writes:
>
> > The organizations that export/import routes via the route servers may find:
> >
> > 1) the routers have fewer configured peers therefore resulting
> > in less load on the routers
> > 2) the route servers have route flap dampening implemented thereby
> > insulating the peer from a high number of routing updates
> > 3) the route servers do the routing computations which results
> > in freeing significant amounts of processing time on the peer routers
> > 4) a reduction in the time and energy (people resources) needed to
> > establish new peering relationships
> >
> > --Elise
>
> I, as an example of an "organization" as described above, have found these
> things to be true. The startup transient is high -- all those this-objects
> and that-objects. But once it's up and running, adding route relationships
> is much easier using the route server than by adding BGP sessions.
>
> Of course, I don't do anything complicated. I understand that Sean and
> others have found that they need to do things with their route import and
> export rules that the route servers don't have a way of expressing. Perhaps
> if I were running a net as large as Sean's I would have his troubles.
>

Some providers have indicated that the route servers would better
serve their needs if: 1) the RSs implemented only a subset of the
policy expressed in the IRR and 2) the RSs could do proxy aggregation.
The configurations of the RSs support both of those requirements
now. The policy language does not yet support this in a "standard"
fashion, but that is being addressed in the RPS working group.

The RA has implemented requirements that providers have when a
provider communicates what is needed. I can't find any messages
from Sean indicating what he would like to express but can't.
The RA team is always willing to work with providers to meet
their needs.

--Elise

At 2:12 PM 4/30/96, Matt Zimmerman wrote:
>...
>Setting aside the technological barriers to such an arrangement, an
>optimal configuration would be one in which all routing entities peer with
>one another at all available locations, so as to provide the shortest path
>between routing communities.

I believe that the optimal configuration would actually involve only
one routing entity and no peering at all. I'm pleased that instead
we've implemented a model which (while not optimal) allows for a
growing Internet service provider industry. Solutions which are
optimal under one constraint tend to degenerate in the real world.

Shortest-exit routing and equivalent distributed peering is used to
avoid settlements for transit costs. If there's a strong demand
for dissimiliar peering, then it's likely to appear with settlements.

/John

On Tue, 30 Apr 1996, Randy Bush wrote:

> peerage, like sex these years, has a great potential for the transmission
> of disease. so one is very careful about with whom one peers. the route
> servers are more like a bath house, you're excahnging bodily fluids with
> every and any body.

Interesting analogy...but not quite accurate. RS-based peering would be
more like...a routing orgy among a group of peers, where a central entity
organizes the bodily routing fluids and directs them, according to
prearranged policy, to the appropriate indirect peers. It breaks down
there...:-)

Your statement implies that, when peering via an RA route server, one is
required to accept (and advertise) any and all routes. This is wholly
untrue. The RS's use policy information from the RADB to do routing
calculations, resulting in a centralized routing model rather than a
distributed one. Yes, it makes policy decisions for you...but based on
your own policy indications.

> some exchanges have multi-lats. how many are actually used by the bigger
> players and how many are ignored in favor of multiple bi-lats?

I don't know of very many exchanges that have MLPA's, but at the Ameritech
(Chicago) NAP...

-----

Date: 29 Apr 96 08:21:16 -0500
From: MARK.A.CNOTA@x400gw.ameritech.com
To: nathan@netrail.net
Cc: nap-info@aads.net
Subject: Multi-Lateral Peering Agreement

Nathan,

Below is the current list of MLPA participants.

Mark Cnota
AADS Operations - Chicago


Alpha-Net
AGIS
Argonne Nat. Laboratory
Concentric Research
Hyperspace Networks
ISI/Merit (Routing Arbiter)
NAP.NET
Network 99
Netcom On-Line
Univ. of Chicago
One Call Communications

// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]

On Tue, 30 Apr 1996, John Curran wrote:

> At 2:12 PM 4/30/96, Matt Zimmerman wrote:
> >...
> >Setting aside the technological barriers to such an arrangement, an
> >optimal configuration would be one in which all routing entities peer with
> >one another at all available locations, so as to provide the shortest path
> >between routing communities.
> I believe that the optimal configuration would actually involve only
> one routing entity and no peering at all. I'm pleased that instead
> we've implemented a model which (while not optimal) allows for a
> growing Internet service provider industry. Solutions which are
> optimal under one constraint tend to degenerate in the real world.

For varying values of "optimal". :-) In terms of decision-making, you
can't beat centralized routing...if a single entity knows all there is to
know about current state of the Internet topology, it can make optimal
decisions. But a distributed system is far more reliable, and more
flexible in terms of growth. My "optimal" was slightly more oriented
toward the current state of affairs than was yours. ;-)

> Shortest-exit routing and equivalent distributed peering is used to
> avoid settlements for transit costs. If there's a strong demand
> for dissimiliar peering, then it's likely to appear with settlements.

I, for one, would see this as a far more equitable solution than an SKA
arrangement where peering arrangements are subject to strict policy-based
discrimination.

If I were to peer with Sprint at MAE-East (and MAE-east only), relying on
their network to backhaul traffic across the nation, it could be seen as
fair for me to compensate them financially, if only as an interim measure
until a true peering arrangement is feasible.

// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]

At 10:49 AM 4/30/96 -0400, you wrote:

> Unrestricted peering policy would accelerate rolling of the
> snowball, and lead to the collapse of an interconnect. In order
> for Internet to survive, this snowball effect got to stop.

... or the hardware has to be manufactured to support it. /Some day/ there
are going to be 500 companies at the interconnects, and they are /all/ going
to be important players, or that is at least a likely scenario. Will this
be next year? No. Unrestricted peering policies are gone, the internet is
not what it once was. "There was a day when anyone could peer with
anyone..." Yeah, there was also a day when the backbone was uucp serial
links, I don't hear you mourning that. (generic you, not specific) The
internet has frown. There are some things which can be done on a handshake
and a smile, a global network isn't one of them. Heck, if all I needed was
a connection to the MAE to get global routing, I'd run a ds-3 to my house
and be done with it (its only about 3 miles from my house to MAE East, maybe
5).

>
>(2) There is no connectivity gain for a national provider to peer
> with a single-attached organizaiton as all these organizations have
> transit providers that are present at multiple interconnects.

This is a chicken and egg scenario. If CompanyX could get to everywhere
without buying a link to an upstream as well as their connection to the MAE,
well, then they wouldn't buy the connection to the upstream provider. The
real point should be that losing connectivity to all whopping X,000 of their
customers where X is between 1 and 9 is really not all that big a deal,
netwise.

>
>(3) There is a huge investment involved to build a national backbone.
> Many providers currently do "hot-potato" routing (closed-exit)
> because of this cost. Peering with a single-attached organization
> would require much more backbone investment as traffic to this
> organization needs to be carried across the backbone, while the
> cost for this single-attached organization would be small (one
> DS3 to an interconnect).

This is somewhat of a paper tiger. This singly homed is also not nearly so
likely to generate as much traffic as some of the larger backbones, and you
are only carrying /your customers'/ traffic to them. One way or another, so
long as you are peering and not transiting, any packets that cross your
network are for the good of /your customers/. Please keep that in mind, but
I digress...

>
>Regarding the RS (I have many friends there, and they have done many
>good work), let me echo the fundamental issues that Steve Heimlich
>has pointed out, would you rather have your peering policy enforced by
>yourself or by a third party? Would you rather develop a dependency
>on a third party (which may not be there a few years down the road)
>to deliver the critical service or depend on yourself?

As a representative of Erol's I can say that I would want to directly peer
with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing
one or two routes I would likely be better serverd as hearing through the RA
until which time as I have lots of free processor/memory/everything else on
my router doing the peering, at which point I would be more than willing to
peer with anyone who I could be assured was technically competent.
(Basical;ly I am not /dependant/ on getting to a lot of those smaller sites,
so I don't very much care if I lose them somehow).

>
>-- Enke (speaking only for myself)
>
>
>

Justin Newton * You have to change just to stay
Internet Architect * caught up.
Erol's Internet Services *

On Tue, 30 Apr 1996, Justin W. Newton wrote:

> This is a chicken and egg scenario. If CompanyX could get to everywhere
> without buying a link to an upstream as well as their connection to the MAE,
> well, then they wouldn't buy the connection to the upstream provider. The
> real point should be that losing connectivity to all whopping X,000 of their
> customers where X is between 1 and 9 is really not all that big a deal,
> netwise.

Not true. It is a VERY big deal if too many blocks of X,000 sites are not
globally reachable because it would destroy the image of the Internet as a
single cohesive network aka "the Net" withe the emphasis on the word
"the". And I think peering agreements based on a handshake will always be
viable in the global Internet. It's not like other businesses. The net is
"real-time" in your face stuff that customers expect to be working on a
7/24 basis. There isn't any room for weasel words and slimy dealings.

Remember that there are folks like Bob Metcalfe who would dearly love to
see the global Internet to move to a settlements based system in which
every byte is charged a fee for transport because that would involve
installing the infrastructure that would make micro-money transactions
possible. See his current InfoWorld column
http://www.infoworld.com/pageone/opinions/metcalfe.htm which I found
incredibly vituperative. This man clearly has a grudge against one or more
Internet operators.

I don't believe it is in anyone's best interests, not even Metcalfe's or
3COM's, to have the huge recordkeeping and billing bureaucracy that would
be needed to do micromoney, even though I could personally earn a lot of
money by selling my written works that way. In the long run we are better
off pushing the network infrastructure into the noise that we don't even
care about paying for on a daily basis like your basic phone service or
the roads and highways infrastructure.

If we want to get to that point, we need to help along the small players
all we can. Sometimes it involves "tough love" like Sprint's route
filters, sometimes it is just sharing information on lists like this and
the IETF lists or at meetings like NANOG or IETF.

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

On Tue, 30 Apr 1996, Justin W. Newton wrote:

> > Unrestricted peering policy would accelerate rolling of the
> > snowball, and lead to the collapse of an interconnect. In order
> > for Internet to survive, this snowball effect got to stop.
> ... or the hardware has to be manufactured to support it. /Some day/ there

If the current trend continues, IXP's may start seeing exponential growth
curves, especially as more of them emerge. I can't think of very many
hardware manufacturers that have been able to keep up with that kind of
demand for better equipment. Hardware can be designed and built to meet
demands on performance, sometimes even on cost. Growth is much more
difficult to account for.

> are going to be 500 companies at the interconnects, and they are /all/ going
> to be important players, or that is at least a likely scenario. Will this
> be next year? No. Unrestricted peering policies are gone, the internet is
> not what it once was. "There was a day when anyone could peer with
> anyone..." Yeah, there was also a day when the backbone was uucp serial
> links, I don't hear you mourning that. (generic you, not specific) The
> internet has frown. There are some things which can be done on a handshake
> and a smile, a global network isn't one of them.

Dunno about you, but I don't recall a day of unrestricted peering. There
may not have been lawyerized, codified policies you see now, but you still
had to convince NSP X that you knew what you were doing. Said policies
are allegedly attempting the same thing, but that's another thread.

> Heck, if all I needed was a connection to the MAE to get global routing,
> I'd run a ds-3 to my house and be done with it (its only about 3 miles
> from my house to MAE East, maybe 5).

Hmm...how many PC's and workstations do you have at home to fill a DS3
with? ;-)

> >(2) There is no connectivity gain for a national provider to peer
> > with a single-attached organizaiton as all these organizations have
> > transit providers that are present at multiple interconnects.
> This is a chicken and egg scenario. If CompanyX could get to everywhere
> without buying a link to an upstream as well as their connection to the MAE,
> well, then they wouldn't buy the connection to the upstream provider. The
> real point should be that losing connectivity to all whopping X,000 of their
> customers where X is between 1 and 9 is really not all that big a deal,
> netwise.

Not a big deal to whom? It certainly is to those customers, and to
CompanyX. And probably to a percentage of the rest of the net.population,
who now can't get to Joe's Whiz-Bang homepage. And who's making a
decision on whether they have connectivity?

(or what does this have to do with chickens and eggs?)

> >(3) There is a huge investment involved to build a national backbone.
> > Many providers currently do "hot-potato" routing (closed-exit)
> > because of this cost. Peering with a single-attached organization
> > would require much more backbone investment as traffic to this
> > organization needs to be carried across the backbone, while the
> > cost for this single-attached organization would be small (one
> > DS3 to an interconnect).
> This is somewhat of a paper tiger. This singly homed is also not nearly so
> likely to generate as much traffic as some of the larger backbones, and you
> are only carrying /your customers'/ traffic to them. One way or another, so
> long as you are peering and not transiting, any packets that cross your
> network are for the good of /your customers/. Please keep that in mind, but
> I digress...

Actually, you're very much on-topic, and this is true; however,
closest-exit/hot-potato routing depends on asymmetric division of traffic
to share load between peers. The one who ends up backhauling the traffic
is the one with the bicoastal DS3 backbone, with none of the load shared
by the single-homed peer. Were the single-homed peer not single-homed,
the large peer could hand off the "potato" much closer to its source.

[RS peering]
> As a representative of Erol's I can say that I would want to directly peer
> with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing
> one or two routes I would likely be better serverd as hearing through the RA
> until which time as I have lots of free processor/memory/everything else on
> my router doing the peering, at which point I would be more than willing to
> peer with anyone who I could be assured was technically competent.
> (Basical;ly I am not /dependant/ on getting to a lot of those smaller sites,
> so I don't very much care if I lose them somehow).

This is a risky attitude. Simply because those sites are smaller than you
doesn't mean you can force them down by refusing to peer. You do have a
relatively large dialup customer base, but explaining to your customers
exactly why they can't get to <interesting route> from your service, but
can from GrumbleSmurf down the road, can be tricky when you burn bridges.
I'd place more emphasis on the "technically competent" aspect of your
policy than the "I don't much need your routes anyhow" motivation.

// Matt Zimmerman Chief of System Management NetRail, Inc.
// mdz@netrail.net sales@netrail.net
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]

In message <199604301728.KAA02799@victory.InterNex.Net>, Rob Gutierrez writes:
> >
> > There is no possibility for blackholing packets. Blackholing means
> > advertising a route and then not delivering the packet.
>
> I'm afraid that I did run into a situation where the route was advertised
> and the packet was blackholed.
>
> I started to peer with AS-2882 at the PB NAP, and I accepted routes
> from it for another ISP (no finger pointing today -- sorry). Well, the
> ISP didn't have the VC map config'd in their router, and that route
> became preferred after a glitch somewhere in their network. Well, since
> the med's were the same in the routes we were sending to them, they
> preferred the PB NAP route after their glitch. Needless to say, not
> a happy situation. Then, of course, there was yet another ISP we were
> waiting for their router to be config'd, etc.


This problem is inherent to misconfigured PVC based switched services
and third party routes, not router servers per se. Similar stories
can be heard regarding the CIX SMDS that do not involve a router
server or on frame relay setups.

Curtis

> > (2) Could anyone share opinions/facts regarding why organizations may or
> > may not exchange routes via the Route Servers rather than direct peering
> > relationships at the NAPs?
>
> I know of no case where an organization "may not" exchange routes
> with the Route Servers.

I do, AS1800..


--Peter

> I had thought that these two NSF projects were to work together
> ...

Yep. -s

Stephen Wolff Business Development
Cisco Systems 703.397.5615


- - - - - - - - - - - - - - - - -

At 07:45 PM 4/30/96 -0400, you wrote:

>> Heck, if all I needed was a connection to the MAE to get global routing,
>> I'd run a ds-3 to my house and be done with it (its only about 3 miles
>> from my house to MAE East, maybe 5).
>
>Hmm...how many PC's and workstations do you have at home to fill a DS3
>with? ;-)

Well, it'd be good for IOS code downloads ;)

>
>> >(2) There is no connectivity gain for a national provider to peer
>> > with a single-attached organizaiton as all these organizations have
>> > transit providers that are present at multiple interconnects.
>> This is a chicken and egg scenario. If CompanyX could get to everywhere
>> without buying a link to an upstream as well as their connection to the MAE,
>> well, then they wouldn't buy the connection to the upstream provider. The
>> real point should be that losing connectivity to all whopping X,000 of their
>> customers where X is between 1 and 9 is really not all that big a deal,
>> netwise.
>
>Not a big deal to whom? It certainly is to those customers, and to
>CompanyX. And probably to a percentage of the rest of the net.population,
>who now can't get to Joe's Whiz-Bang homepage. And who's making a
>decision on whether they have connectivity?
>
>(or what does this have to do with chickens and eggs?)

Its no big deal to BigBackboneDude. That /seems/ to be the attitude that
some of the larger backbone providers take, and I am not sure that I
completely blame them. I.e. Is it worth this level of effort both for me
and for my routers to add connectivity to this level of hosts? If the
number of hosts is large it obviously is. If it is small it may not be.
The problem is deciding where that line is.


>[RS peering]
>> As a representative of Erol's I can say that I would want to directly peer
>> with MCI. Sprint, ANS, UUnet and a few others, all of the people annoucing
>> one or two routes I would likely be better serverd as hearing through the RA
>> until which time as I have lots of free processor/memory/everything else on
>> my router doing the peering, at which point I would be more than willing to
>> peer with anyone who I could be assured was technically competent.
>> (Basical;ly I am not /dependant/ on getting to a lot of those smaller sites,
>> so I don't very much care if I lose them somehow).
>
>This is a risky attitude. Simply because those sites are smaller than you
>doesn't mean you can force them down by refusing to peer. You do have a
>relatively large dialup customer base, but explaining to your customers
>exactly why they can't get to <interesting route> from your service, but
>can from GrumbleSmurf down the road, can be tricky when you burn bridges.
>I'd place more emphasis on the "technically competent" aspect of your
>policy than the "I don't much need your routes anyhow" motivation.

You're misreading what I am saying, hopefully not intentionally. What I am
saying is that Sprint, MCI et al are large snugh that they are absolutely
critical that they work 100% of the time, or as close to 100% of the time as
is possible. If the route server hiccups, or they start implementing wierd
policies that cause me to lose connectivity to those people for /any/ amount
of time I am in deep kimshee. If the route server screws up and decides I
can no longer talk to JustinsTinyISP, I have a little time to ditch the
route server and set up a private peering session with JustinsSmallISP
before it becomes a critical issue. It is not that I don't want to hear the
routes for that provider it is simply that it may not be worth the resources
both on the router and in human manpower to setup a private peering session
with them. The routers do have limits you know. There is no "I don't much
need your routes anyhow" motivation anywhere.


Justin Newton * You have to change just to stay
Internet Architect * caught up.
Erol's Internet Services *

- - - - - - - - - - - - - - - - -

From: Andrew Partan <asp@partan.com>

Luckily this sort of breakage does not happen very often.
Unluckily, if it does break, if can be really hard to diagnose.

Especially in the presence of a TelCo-supplied level 2 switching
fabric like Frame Relay, SMDS, or ATM.

Erik E. Fair apple!fair fair@apple.com
- - - - - - - - - - - - - - - - -

> There is one thing that the RS can't do.
>
> If A & B are doing 3rd party peering via the RS, the fact that the
> A/RS peering is up & working and that the B/RS peering is up &
> working unfortunately does not tell you if A & B can exchange
> packets.
>
> If A & B are peering directly, then the fact that the peering is
> up also tells you that they can exchange packets.
>
> Luckily this sort of breakage does not happen very often.
> Unluckily, if it does break, if can be really hard to diagnose.
> --asp@partan.com (Andrew Partan)

It has happened at least a few times in the past month at MAE-East (islands of
disconnectivity), of course.

Avi

- - - - - - - - - - - - - - - - -

>There is one thing that the RS can't do.
>
>If A & B are doing 3rd party peering via the RS, the fact that the
>A/RS peering is up & working and that the B/RS peering is up &
>working unfortunately does not tell you if A & B can exchange
>packets.

>If A & B are peering directly, then the fact that the peering is
>up also tells you that they can exchange packets.
>
>Luckily this sort of breakage does not happen very often.
>Unluckily, if it does break, if can be really hard to diagnose.

This could happen at a non-broadcast media NAP such as ATM nap when the
PVCs between RS-A & RS-B are up but the PVC between A-B is down. But it's
less likely to happen on a broadcast media NAP.

It'd be ideal that the RS is injected with some intellegence to detect the
fact that A can no long talk to B directly and thus stop passing routes between
A & B. This will avoid the problem. But as you pointed out, it rarely
happens so it may not worth the effort.


By the way, if we flip this example around a bit: if A & B peer with the RS
in addition to peer directly with each other and the bgp session between A & B
broke for some reason and the connection is still there (i.e. they do not have
bgp session but still can exchange packets), A & B would benifit from the
RS.

--Jessica
(speaking for myself)
- - - - - - - - - - - - - - - - -

Jessica Yu <jyy@ans.net> writes

* This could happen at a non-broadcast media NAP such as ATM nap when the
* PVCs between RS-A & RS-B are up but the PVC between A-B is down. But it's
* less likely to happen on a broadcast media NAP.
*
* It'd be ideal that the RS is injected with some intellegence to detect the
* fact that A can no long talk to B directly and thus stop passing routes betw
* een
* A & B. This will avoid the problem. But as you pointed out, it rarely
* happens so it may not worth the effort.

But the question is whether there will be more NBMA type NAPs in the
future. Point to MultiPoint for BGP, I like it ;-)

-Marten
- - - - - - - - - - - - - - - - -

At 10:48 AM 5/2/96 -0400, Marten Terpstra wrote:

>
>But the question is whether there will be more NBMA type NAPs in the
>future. Point to MultiPoint for BGP, I like it ;-)
>

Marten, you are one sick puppy. ;-)

- paul


- - - - - - - - - - - - - - - - -

Actually, only changes to the RADB and ANS DB will be
caught by _every_ 4 hr update; the other databases (RIPE,
MCI DB, CA*Net DB) are currently obtained 1x/day (usually
in the morning, Brian Renaud says). Work re: synchronization
and distribution of IRR data is, as they say, ongoing.


Steve Richardson/Merit

>From nanog-owner@merit.edu Tue Apr 30 13:16:30 1996
>Message-Id: <199604301712.KAA03518@lint.cisco.com>
>X-Sender: pferguso@lint.cisco.com
>Date: Tue, 30 Apr 1996 13:13:36 -0400
>To: Cengiz Alaettinoglu <cengiz@isi.edu>
>From: Paul Ferguson <pferguso@cisco.com>
>Subject: Re: Peering Policies and Route Servers
>Cc: Ali Marashi <amarashi@interglobe.com>, bmanning@isi.edu, nanog@merit.edu
>Sender: owner-nanog@merit.edu

>At 10:12 AM 4/30/96 -0700, Cengiz Alaettinoglu wrote:
>
>>
>>Route Servers are dynamic, they process upto 6000 routing updates a
>>minute (see http://compute.merit.edu/stats/mae-east/instability).
>>
>>Route Servers are reconfigured with up to date policy 6 times a day,
>>i.e. every four hours. Hence, a brand new route registered in IRR may
>>not be announced by the route servers to the NSPs whose policies are
>>prefix based for up to at most 4 hours. I think this is what you are
>>referring to.
>>
>
>Cengiz, thanks for the clarification.
>
>- paul

- - - - - - - - - - - - - - - - -

At 04:11 PM 5/2/96 -0400, Steven J. Richardson wrote:

>Actually, only changes to the RADB and ANS DB will be
>caught by _every_ 4 hr update; the other databases (RIPE,
>MCI DB, CA*Net DB) are currently obtained 1x/day (usually
>in the morning, Brian Renaud says). Work re: synchronization
>and distribution of IRR data is, as they say, ongoing.
>
>
>Steve Richardson/Merit
>

Steve, thanks for verifying my previous point. :-)

- paul

- - - - - - - - - - - - - - - - -

In message <199605020457.AAA00182@home.partan.com>, Andrew Partan writes:
> > The RA has implemented requirements that providers have when a
> > provider communicates what is needed. I can't find any messages
> > from Sean indicating what he would like to express but can't.
> > The RA team is always willing to work with providers to meet
> > their needs.
>
> There is one thing that the RS can't do.
>
> If A & B are doing 3rd party peering via the RS, the fact that the
> A/RS peering is up & working and that the B/RS peering is up &
> working unfortunately does not tell you if A & B can exchange
> packets.
>
> If A & B are peering directly, then the fact that the peering is
> up also tells you that they can exchange packets.
>
> Luckily this sort of breakage does not happen very often.
> Unluckily, if it does break, if can be really hard to diagnose.
> --asp@partan.com (Andrew Partan)


Just because you don't BGP peer doesn't mean you should monitor
reachability to your third party peers. The BGP mib is handy, but
this is nothing a ping test can't detect. Too bad there is no LQM on
broadcast media.

Curtis
- - - - - - - - - - - - - - - - -