AS41961 not seen in many networks

Mailman List Mirror (Read Only)
21

Indeed, we do have multi-hop peering sessions on one of our route
collectors (rrc00). That one is specifically used for multi-hop
peerings.
On the other collectors, placed on a specific exchange, we prefer to
only have peers from that exchange, to prevent confusion.

However, we can not accept unlimited numbers of peerings, especially
peerings where we receive a full table, multi-hop or not.
The maximum appears to be around 15 for each collector, depending on the
hardware used for it.

If you think we should have a peering with someone that we don't have
already, perhaps multi-hop, we are interested to know (with an
explanation).

(and we are always interested in any suggestions to improve RIS)

regards,

22

Well, some time ago we opened a ticket to create RIS peering, and it was set up but didn't work, because they didn't realize it'd be multihop (about 3 hops). The peering was cancelled.

Below is the "explanation" (NCC#2005120077 rrc07):

===8<====
Actually we didn't notice immediately the request was meant to be for
multi-hop.

We normally prefer not to configure multi-hop sessions. It would be
preferable for us if you are present at the common IXP location with
the RIS project so that we can establish a session there.

You can check out locations at:
http://www.ripe.net/projects/ris/docs/peering.html

The sessions are now cancelled.
====8<====

This policy was not, AFAIR, available in any public documents.

So I wouldn't be surprised if RIS's coverage was somewhat limited.

23

If you're interested in how Europeans see you..

I have three default-free transit providers and only see you behind two of them, eventually through 'LambdaNet' on both.

-a

24

>>Well, the undocumented fact is that RIS does not accept multi-hop BGP
>>peerings, which may somewhat limit its coverage.
>
>Why then do I have one? They do such things, they indeed do.

Well, some time ago we opened a ticket to create RIS peering, and it
was set up but didn't work, because they didn't realize it'd be
multihop (about 3 hops). The peering was cancelled.

A disclaimer in advance: this was far before my time here.

Part of the explanation is true.
If you are present at one of the IXPs where we are, we prefer to
configure the peering there.
Also, we only configure multi-hop on our exchange-connected RRCs in very
rare cases, as it could confuse people.

RRC00, which is not connected to any exchange, is the dedicated rrc for
multi-hop sessions.

This policy was not, AFAIR, available in any public documents.

Part of it was, but perhaps a bit hidden. I'll clarify it and add it in
a more obvious place.

It was here:
http://www.ripe.net/info/faq/projects/ris.html#18

The RIS FAQ says:

Note: Since the database update capacity is currently limited, we do
not accept any new peers on RRC00. However, do not hesitate to contact
us if you can provide us with data that is complementary to what RRC00
already collects and we'll see what can be done.

So I wouldn't be surprised if RIS's coverage was somewhat limited.

Would anyone? The view of RIS is always limited by the amount of data we
can process and the locations where we are present.
Therefore, we would be very happy to hear ideas about how to improve the
usefulness of the data we collect.
Should we get more full feeds at exchanges (requiring bigger hardware)?
Or more locations? Which locations? Or accept more multi-hop?

regards,

25

Hi.

  We've got resolution. LambdaNet didn't update import/export fields of their
AS in RIPE so this ISPs who make filters based on RIPE database filtered our
announcements.
  LambdaNet corrected this and we should apear soon in ALL Internet :slight_smile:

  Thanks everyone for help! :slight_smile:

26

(and we are always interested in any suggestions to improve RIS)

  Likewise routeviews. Let us know if there are peerings
  folks would like us to pick up.

  --dmm

27

Well, the undocumented fact is that RIS does not accept multi-hop BGP
peerings, which may somewhat limit its coverage.

this is a good thing. as multi-hop bgp is very fragile, measurements
go borkville just when you want them the most.

randy

28

Randy Bush wrote:

Well, the undocumented fact is that RIS does not accept multi-hop BGP
peerings, which may somewhat limit its coverage.

this is a good thing. as multi-hop bgp is very fragile, measurements
go borkville just when you want them the most.

While that is true, it does help in the cases when there is connectivity
between the two BGP speakers in question. For instance GRH would not
have been possible if it was not for multihop-bgp. Indeed when
connectivity breaks, it is useless, but most of the time it works and
then it is great to have.

A better requirement for RIS could be that it would be advised to be
present at an IX and peer there, otherwise offer the option of
multihop-bgp so that people who are not too-well connected can also
contribute to it. The ones present at the IX's are also the ones which
will cause multihop to break when the IX or they themselves go down, the
remote participants are most likely smaller players thus them going down
and going off the system doesn't really hurt a lot, except them.

Greets,
Jeroen