AS41961 not seen in many networks
Hi, Since November 2006 we announce our 3 new prefixes: 194.60.78.0/24 194.60.204.0/24 194.153.114.0/24 from new AS41961. It seems that somewhere our announcements are blocked probably due to bogon lists. Our ASN is is in AS block allocated by RIPE on 13 April 2006 then somebody can have it still in as-path ACLs. Could you please check your configuration or help us to isolate the problem? -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
Hi Sebastian, SRusek@axit.pl (Sebastian Rusek) wrote:
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
To make it easier for everyone - could you provide hosts in each network that are pingable? Yours, Elmar.
Dnia czwartek 04 stycznia 2007 15:06, napisałeś:
SRusek@axit.pl (Sebastian Rusek) wrote:
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
To make it easier for everyone - could you provide hosts in each network that are pingable?
now pingable addresses are: 194.60.78.254 194.60.204.254 194.153.114.254 They should be accessible via LambdaNET. Routes inside LambdaNET can be diffrent to each address. -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
now pingable addresses are: 194.60.78.254 194.60.204.254 194.153.114.254
They should be accessible via LambdaNET. Routes inside LambdaNET can be diffrent to each address.
Everything looks fine from here (AS 2116), prefixes reachable and addresses pingable. Example traceroute below. Steinar Haug, Nethelp consulting, sthaug@nethelp.no traceroute to 194.60.78.254 (194.60.78.254), 64 hops max, 60 byte packets 1 nethelp-gw (195.1.209.46) 1.190 ms 1.139 ms 1.144 ms 2 gi1-0-6000034.ar4.o-d.no.catchbone.net (81.0.129.174) 5.982 ms 6.819 ms 6.617 ms 3 ge-0-2-3-15.cr1.osls.no.catchbone.net (193.75.3.165) 6.138 ms 5.709 ms 6.145 ms 4 c10G-ge-3-0-0.cr2.osls.no.catchbone.net (81.0.128.54) 5.824 ms 6.041 ms 5.841 ms 5 c2488-so-1-3-0.cr1.mejv.se.catchbone.net (193.75.3.239) 13.195 ms 13.066 ms 13.011 ms 6 ge-0-1-0.br1.stcy.se.catchbone.net (81.0.128.210) 13.321 ms 13.379 ms 19.719 ms 7 netnod-ge-a.sto-1-eth020-15.se.lambdanet.net (194.68.123.141) 13.021 ms 13.050 ms 13.328 ms 8 HAN-7-pos720-0.de.lambdanet.net (81.209.190.17) 34.421 ms 36.609 ms 34.856 ms 9 DUS-1-pos012.de.lambdanet.net (217.71.105.126) 39.065 ms 38.768 ms 38.776 ms 10 217.71.96.66 (217.71.96.66) 41.873 ms 41.597 ms 41.889 ms 11 FRA-2-pos600.de.lambdanet.net (217.71.96.102) 42.342 ms 42.251 ms 42.032 ms 12 194.60.78.254 (194.60.78.254) 42.655 ms 42.673 ms 42.662 ms
Sebastian Rusek wrote:
Dnia czwartek 04 stycznia 2007 15:06, napisałeś:
SRusek@axit.pl (Sebastian Rusek) wrote:
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists. To make it easier for everyone - could you provide hosts in each network that are pingable?
now pingable addresses are: 194.60.78.254 194.60.204.254 194.153.114.254
They should be accessible via LambdaNET. Routes inside LambdaNET can be diffrent to each address.
From one location, things die as soon as they hit AT&T, another location things work perfectly. From AS29979 jcheney@katahdin jcheney $ traceroute 194.60.78.254 traceroute to 194.60.78.254 (194.60.78.254), 30 hops max, 38 byte packets 1 66.231.214.33 (66.231.214.33) 0.689 ms 0.703 ms 0.607 ms 2 208.252.22.1 (208.252.22.1) 7.160 ms 7.948 ms 7.620 ms 3 12.125.39.69 (12.125.39.69) 9.630 ms !H * 10.049 ms !H -- Josh Cheney josh.cheney@gmail.com http://www.joshcheney.com
now pingable addresses are: 194.60.78.254 194.60.204.254 194.153.114.254
From one location, things die as soon as they hit AT&T, another location things work perfectly. I have a couple of networks off AT&T and I am not seeing these routes in my tables. I do see them off other networks, however.
-Don
They are seen here, through Cogent : *> 194.60.78.0 38.101.161.116 4001 0 174 13237 41961 i *> 194.60.204.0 38.101.161.116 4001 0 174 13237 41961 i *> 194.153.114.0 38.101.161.116 4001 0 174 13237 41961 i Regards Marshall On Jan 4, 2007, at 8:57 AM, Sebastian Rusek wrote:
Hi,
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
Our ASN is is in AS block allocated by RIPE on 13 April 2006 then somebody can have it still in as-path ACLs.
Could you please check your configuration or help us to isolate the problem? -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
And aren't seen through gblx. I also think I can't see those prefixes through verizon. Gustavo. Marshall Eubanks wrote:
They are seen here, through Cogent :
*> 194.60.78.0 38.101.161.116 4001 0 174 13237 41961 i *> 194.60.204.0 38.101.161.116 4001 0 174 13237 41961 i *> 194.153.114.0 38.101.161.116 4001 0 174 13237 41961 i
Regards Marshall
On Jan 4, 2007, at 8:57 AM, Sebastian Rusek wrote:
Hi,
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
Our ASN is is in AS block allocated by RIPE on 13 April 2006 then somebody can have it still in as-path ACLs.
Could you please check your configuration or help us to isolate the problem? --Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
Yes, I should have made that clear, not received through Level 3 at AS 16517. (But, Cogent has them.) On Jan 4, 2007, at 11:25 AM, sthaug@nethelp.no wrote:
And aren't seen through gblx. I also think I can't see those prefixes through verizon.
Also not seen via Telia (1299) or Level3 (3356).
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Regards Marshall
Qwest appears not show it (traceroute dies at the first IP in their network) and Cogent and LambdaNET show a jump from 90ms to 170ms between their networks (in two different places depending on IP tracerouted) - but it does go through. -- Jeff Shultz
On Thu, 4 Jan 2007 sthaug@nethelp.no wrote:
And aren't seen through gblx. I also think I can't see those prefixes through verizon.
probably gustavo means verizonbusiness here, and probably vzb-US (as701), it's in 702 though.
Also not seen via Telia (1299) or Level3 (3356).
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Sebastian Rusek wrote:
Hi,
Since November 2006 we announce our 3 new prefixes: [..] Could you please check your configuration or help us to isolate the problem?
You could also check http://www.ris.ripe.net/ and use that tool to determine exactly which networks are not seeing you and then contact those operators to fix their setups. And for people not peering with RIS yet, PEER! (info at the url) Greets, Jeroen
On Thu, 4 Jan 2007, Jeroen Massar wrote:
You could also check http://www.ris.ripe.net/ and use that tool to determine exactly which networks are not seeing you and then contact those operators to fix their setups.
And for people not peering with RIS yet, PEER! (info at the url)
Well, the undocumented fact is that RIS does not accept multi-hop BGP peerings, which may somewhat limit its coverage. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 5 January 2007 08:11:41 +0200, Pekka Savola wrote:
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. -ako
On Fri, Jan 05, 2007 at 09:49:24AM +0100, Alexander Koch wrote:
On Fri, 5 January 2007 08:11:41 +0200, Pekka Savola wrote:
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.
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, -- Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept.
On Fri, 5 Jan 2007, Alexander Koch wrote:
On Fri, 5 January 2007 08:11:41 +0200, Pekka Savola wrote:
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. 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, Jan 05, 2007 at 12:16:07PM +0200, Pekka Savola wrote:
On Fri, 5 Jan 2007, Alexander Koch wrote:
On Fri, 5 January 2007 08:11:41 +0200, Pekka Savola wrote:
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, -- Erik Romijn RIPE NCC jr. software engineer http://www.ripe.net/ Information Services dept.
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
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
"Sebastian" == Sebastian Rusek <SRusek@axit.pl> writes:
Sebastian> Hi, Sebastian> Since November 2006 we announce our 3 new prefixes: Sebastian> 194.60.78.0/24 Sebastian> 194.60.204.0/24 Sebastian> 194.153.114.0/24 Sebastian> from new AS41961. Sebastian> It seems that somewhere our announcements are blocked Sebastian> probably due to bogon lists. I don't think this is anything to do with bogons. I see those routes via Cogent and _only_ via Cogent - none of our other transit providers have them at all. I suspect a problem with your announcements themselves. -- Andrew, Supernews http://www.supernews.com
Not seeing any of the routes, or any routes from AS41961. UUNET, Sprint, and AT&T connectivity. On Thu, January 4, 2007 05:57, Sebastian Rusek wrote:
Hi,
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
Our ASN is is in AS block allocated by RIPE on 13 April 2006 then somebody can have it still in as-path ACLs.
Could you please check your configuration or help us to isolate the problem? -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 WrocÅaw, Poland
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
you may want to use the views from route-views.org and ripe's ris project, as opposed to getting email from the very same folk who contribute to them :). looks to me as if the problem is very near you, perhaps even at your border. randy
not seeing any routes through Level3 or INAP On Jan 4, 2007, at 5:57 AM, Sebastian Rusek wrote:
Hi,
Since November 2006 we announce our 3 new prefixes:
194.60.78.0/24 194.60.204.0/24 194.153.114.0/24
from new AS41961.
It seems that somewhere our announcements are blocked probably due to bogon lists.
Our ASN is is in AS block allocated by RIPE on 13 April 2006 then somebody can have it still in as-path ACLs.
Could you please check your configuration or help us to isolate the problem? -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
On 4 Jan 2007, at 13:57, Sebastian Rusek wrote:
Since November 2006 we announce our 3 new prefixes: 194.60.78.0/24 194.60.204.0/24 194.153.114.0/24 from new AS41961.
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 -- Regards, Andy Davidson Consultant Systems and Network Engineer, Devonshire IT Limited http://www.devonshire.it/ - 0844 704 704 7 - Sheffield, UK
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 :) Thanks everyone for help! :) -- Sebastian Rusek, Phone: +48 71 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wrocław, Poland
participants (20)
-
Alexander Koch -
Andrew - Supernews -
Andy Davidson -
Chris L. Morrow -
David Meyer -
Donald Stahl -
Elijah Savage -
Elmar K. Bins -
Erik Romijn -
Gustavo Rodrigues Ramos -
Jeff Shultz -
Jeremy Hanmer -
Jeroen Massar -
Josh Cheney -
Marshall Eubanks -
Pekka Savola -
Randy Bush -
Rick Ernst -
Sebastian Rusek -
sthaug＠nethelp.no