Onderwerp: Zelfde AS, andere transit.

(Lijkt me het meest on-topic hier, zo niet doe dan x-post en f'up naar de
juiste groep)

Bij toeval kwam ik er net achter dat HCCNet (AS20689) voor twee
verschillende IP-blocks andere transit heeft, of beter gezegd bij één
block ontbreken er.

Als ik bijv. in de RIPE-whois kijk en een whois op het AS doe zie ik dat
ze volledige routes van AS1136 (KPN Telecom) en AS3356 (Level3) 'krijgen'.
Verder is er private peering met Abovenet. Dit geld inderdaad voor het
block. 62.251.0.0/17 maar niet voor 80.100.0.0/15, voorbeeld van een
traceroute vanaf Level3 in Amsterdam:

Naar een adres in de 62.251.0.0/17 range
: 1 ge-7-0.ipcolo2.Amsterdam1.Level3.net (213.244.165.8) 0 msec
: ge-10-1.ipcolo2.Amsterdam1.Level3.net (213.244.165.68) 4 msec
: ge-11-1.ipcolo2.Amsterdam1.Level3.net (213.244.165.84) 0 msec
: 2 212.72.45.66 0 msec 4 msec
: 3 * * *
:etc..

Naar een IP in de 80.100.0.0/15 range:

: 1 acr1-so-3-0-0.Amsterdamamx.savvis.net (208.174.49.1) 0 msec 0 msec
: 2 kpn.Amsterdamamx.savvis.net (208.174.49.46) 0 msec 0 msec
: 3 asd-pbw-ias-ar13.nl.kpn.net (195.190.227.154) 4 msec 4 msec 4 msec
: 4 ge1-2.gw1.hccnet.nl (62.251.0.206) 4 msec 0 msec
: 5 fia-300.kpn.hccnet.nl (62.251.0.193) 4 msec 0 msec
: 6 195.190.249.35 8 msec 4 msec 4 msec

Die laatste gaat dus via Savvis naar KPN en zo naar HCCNet, terwijl HCCNet
een directe verbinding met Level3 heeft. Een verschil van 2 AS'es dus. En
zo gaat het bij verbindingen van en naar andere transitprovider op zo'n
80.100/15 adres ook vaak slechter, omdat het verkeer niet via Level3 gaat.
En daarmee gaat het idd beter.

Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben hetzelfde
AS, en ik dacht dat dit soort dingen alleen per AS geregeld konden worden.
Daarnaast welke reden zou HCCNet hebben om het ene deel van haar klanten
wel via beide transitproviders te laten 'surfen' maar een ander deel niet?

Of is dit gewoon een flinke misconfiguratie en zou dit niet zo moeten
zijn?

--
EP
Rockstars, is there anything they don't know? (Homer Simpson)
cp: Air - Alpha Beta Gaga

On 09 Nov 2004 13:45:22 GMT, "EL PIÑO" <elpino@postmaster.co.uk>
wrote:


>Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben hetzelfde
>AS, en ik dacht dat dit soort dingen alleen per AS geregeld konden worden.
>Daarnaast welke reden zou HCCNet hebben om het ene deel van haar klanten
>wel via beide transitproviders te laten 'surfen' maar een ander deel niet?

Er zijn meerdere mogelijkheden hiervoor. meeste logische is ( mij ooit
overkomen ) vergeten een subnet bij het NOC van AboveNet aan te
melden, aangezien zij met handmatige prefix filters werken. Een andere
mogelijkheid is dat het 80.100.0.0/15 subnet om voor reden dan ook een
AS prepend heeft gekregen van HCC, hierdoor wordt het ASpath langer en
zal er voor de kortste route gekozen worden ( KPN? ), het kan ook zijn
dat ze op deze manier traffic load ballancing toepassen.
en zo zijn er nog een aantal mogelijkheden te bedenken.

>Of is dit gewoon een flinke misconfiguratie en zou dit niet zo moeten
>zijn?

Kan, hoeft dus niet

Maurice

On 09 Nov 2004 13:45:22 GMT, "EL PIÑO" <elpino@postmaster.co.uk> wrote:

>Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben hetzelfde
>AS, en ik dacht dat dit soort dingen alleen per AS geregeld konden worden.
>Daarnaast welke reden zou HCCNet hebben om het ene deel van haar klanten
>wel via beide transitproviders te laten 'surfen' maar een ander deel niet?

Je kunt aparte route-entries opnemen waarbij je bepaalde delen
afsplitst. Ik kan een provider met zijn main-facility op een andere
aansluiting dan de ADSL-aansluitingen. De IP adressen van het ADSL
netwerk vallen binnen hetzelfde AS, maar worden op een andere IX naar
Internet gekoppeld.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente

I've checked it, Maurice Sienema really wrote this:

>>Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben
>>hetzelfde AS, en ik dacht dat dit soort dingen alleen per AS geregeld
>>konden worden. Daarnaast welke reden zou HCCNet hebben om het ene deel
>>van haar klanten wel via beide transitproviders te laten 'surfen' maar
>>een ander deel niet?
>
> Er zijn meerdere mogelijkheden hiervoor. meeste logische is ( mij ooit
> overkomen ) vergeten een subnet bij het NOC van AboveNet aan te
> melden, aangezien zij met handmatige prefix filters werken.

Oké, dat zou het voor de private peering met Abovenet moeten verklaren,
maar voor Level3 niet. Of zij zouden met hetzelfde systeem moeten werken,
dat weet ik niet. Het zou wel erg slordig zijn in dat geval, want volgens
mij hebben ze dat block al een jaar of 2.

> Een andere
> mogelijkheid is dat het 80.100.0.0/15 subnet om voor reden dan ook een
> AS prepend heeft gekregen van HCC, hierdoor wordt het ASpath langer en
> zal er voor de kortste route gekozen worden ( KPN? ),

Lijkt me sterk eerlijk gezegd, ik zie sowieso niet in welk direct nut het
zou hebben. Daarnaast zou er wel flink geprepend (minstens met 2) moeten
worden om een directe verbinding te omzeilen, bovendien zou Level3
waarschijnlijk wel de prioriteit zetten op een directe verbinding dus dat
die daar sowieso langs zou gaan.

> het kan ook zijn
> dat ze op deze manier traffic load ballancing toepassen.
> en zo zijn er nog een aantal mogelijkheden te bedenken.

Wederom zie ik het daar het nut niet van in, waarom zou je een deel van je
klanten anders behandelen dan de rest, want dat is het in principe wel.
Goed, het block is 4 keer zo groot, maar daar kun je dan beter aan denken
bij het inkopen van je transit lijkt mij.

Misschien heeft iemand hier een ingang bij HCCNet waar hij/zij dat aan kan
vragen? De helpdesk heeft de technische kennis van een gekke koe, dus daar
kom je iig niet ver mee (sowieso niet lijkt me) :-)

--
EP
Rockstars, is there anything they don't know? (Homer Simpson)
cp: Faithless - Mass Destruction (Single Mix)

I've checked it, Peter Peters really wrote this:

>>Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben
>>hetzelfde AS, en ik dacht dat dit soort dingen alleen per AS geregeld
>>konden worden. Daarnaast welke reden zou HCCNet hebben om het ene deel
>>van haar klanten wel via beide transitproviders te laten 'surfen' maar
>>een ander deel niet?
>
> Je kunt aparte route-entries opnemen waarbij je bepaalde delen
> afsplitst. Ik kan een provider met zijn main-facility op een andere
> aansluiting dan de ADSL-aansluitingen. De IP adressen van het ADSL
> netwerk vallen binnen hetzelfde AS, maar worden op een andere IX naar
> Internet gekoppeld.

Oké, dat is inmiddels duidelijk. Maar het gaat hier niet om bijv. de
routers/mainservers en de klanten die gescheiden worden, maar simpelweg om
twee ranges. Als dat eerste gebeurde (dus in principe zoals jij noemt) dan
zou ik de logica er nog van in kunnen zien.

--
EP
If(tagline = 'funny') steal(); else next message();
cp: Golden Earring - Radar Love

On 09 Nov 2004 15:14:12 GMT, "EL PIÑO" <elpino@postmaster.co.uk>
wrote:

>Misschien heeft iemand hier een ingang bij HCCNet waar hij/zij dat aan kan
>vragen? De helpdesk heeft de technische kennis van een gekke koe, dus daar
>kom je iig niet ver mee (sowieso niet lijkt me) :-)

Ik heb even in de BGP tabel gekeken van een router van ons, krijgt ook
transit van Level3, en daar zie ik inderdaad een prepend van AS20689
via KPN lopen.

80.100.0.0/15 *[BGP/170] 2w5d 00:57:43, MED 100, localpref 80
AS path: 24587 20689 I
> to 195.69.144.218 via ge-0/2/0.100
[BGP/170] 1w0d 06:09:11, MED 100, localpref 70
AS path: 6461 20689 I
> to 62.4.95.245 via ge-0/3/0.102
[BGP/170] 2w1d 10:12:41, MED 100, localpref 70
AS path: 3356 3561 1136 1136 20689 I
> to 213.244.164.121 via ge-0/2/0.101

80.100.0.0/15 *[BGP/170] 2w5d 00:57:43, MED 100, localpref 80
AS path: 24587 20689 I
> to 195.69.144.218 via ge-0/2/0.100
[BGP/170] 1w0d 06:09:11, MED 100, localpref 70
AS path: 6461 20689 I
> to 62.4.95.245 via ge-0/3/0.102
[BGP/170] 2w1d 10:12:41, MED 100, localpref 70
AS path: 3356 3561 1136 1136 20689 I
> to 213.244.164.121 via ge-0/2/0.101

Vanaf een router die transit krijgt van AboveNet ( en KPN maar dan
AS286), zie ik die prepend niet.

62.251.0.0/17 *[BGP/160] 16w0d 12:31:04, MED 10, localpref 100
AS path: 20689 I
> to 195.69.144.60 via ge-0/1/0.0
[BGP/160] 6w4d 02:09:25, MED 83, localpref 100
AS path: 6461 20689 I
> to 81.17.32.37 via ge-0/2/0.0
[BGP/160] 06:32:57, localpref 100
AS path: 286 1136 1136 20689 I
> to 134.222.97.165 via ge-0/3/0.16
[BGP/170] 4d 10:20:31, localpref 100
AS path: 6453 3356 20689 20689 I
> to 80.231.82.49 via ge-0/3/0.19

80.100.0.0/15 *[BGP/160] 16w0d 12:32:59, MED 10, localpref 100
AS path: 20689 I
> to 195.69.144.60 via ge-0/1/0.0
[BGP/160] 6w4d 02:11:20, MED 83, localpref 100
AS path: 6461 20689 I
> to 81.17.32.37 via ge-0/2/0.0
[BGP/160] 06:34:52, localpref 100
AS path: 286 1136 1136 20689 I
> to 134.222.97.165 via ge-0/3/0.16
[BGP/170] 07:22:15, localpref 100
AS path: 6453 1136 1136 20689 I
> to 80.231.82.49 via ge-0/3/0.19

Maurice

On 09 Nov 2004 15:22:15 GMT, "EL PIÑO" <elpino@postmaster.co.uk> wrote:

>I've checked it, Peter Peters really wrote this:
>
>>>Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben
>>>hetzelfde AS, en ik dacht dat dit soort dingen alleen per AS geregeld
>>>konden worden. Daarnaast welke reden zou HCCNet hebben om het ene deel
>>>van haar klanten wel via beide transitproviders te laten 'surfen' maar
>>>een ander deel niet?
>>
>> Je kunt aparte route-entries opnemen waarbij je bepaalde delen
>> afsplitst. Ik kan een provider met zijn main-facility op een andere
>> aansluiting dan de ADSL-aansluitingen. De IP adressen van het ADSL
>> netwerk vallen binnen hetzelfde AS, maar worden op een andere IX naar
>> Internet gekoppeld.
>
>Oké, dat is inmiddels duidelijk. Maar het gaat hier niet om bijv. de
>routers/mainservers en de klanten die gescheiden worden, maar simpelweg om
>twee ranges. Als dat eerste gebeurde (dus in principe zoals jij noemt) dan
>zou ik de logica er nog van in kunnen zien.

Als ik even kijk naar de hostnamen van de verschillende ranges, lijkt de
ene binnen dsl.hccnet.nl te zitten en de andere binnen dsl.mxposure.nl.
Dus netwerktechnisch kunnen dit best twee hele verschillende netwerken
zijn. Die toevallig binnen 1 AS zijn ondergebracht.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente

I've checked it, Peter Peters really wrote this:

>>> Je kunt aparte route-entries opnemen waarbij je bepaalde delen
>>> afsplitst. Ik kan een provider met zijn main-facility op een andere
>>> aansluiting dan de ADSL-aansluitingen. De IP adressen van het ADSL
>>> netwerk vallen binnen hetzelfde AS, maar worden op een andere IX naar
>>> Internet gekoppeld.
>>Oké, dat is inmiddels duidelijk. Maar het gaat hier niet om bijv. de
>>routers/mainservers en de klanten die gescheiden worden, maar simpelweg
>>om twee ranges. Als dat eerste gebeurde (dus in principe zoals jij
>>noemt) dan zou ik de logica er nog van in kunnen zien.
>
> Als ik even kijk naar de hostnamen van de verschillende ranges, lijkt de
> ene binnen dsl.hccnet.nl te zitten en de andere binnen dsl.mxposure.nl.
> Dus netwerktechnisch kunnen dit best twee hele verschillende netwerken
> zijn. Die toevallig binnen 1 AS zijn ondergebracht.

Nee, in zowel de 80.100 als de 62.251-range zitten adressen van het HCCNet
domein, in 80.100/15 alleen MXPosure dacht ik. Een vriendin van me heeft
namelijk HCCNet in de 80.100.0.0/15 range, terwijl een andere kennis
precies hetzelfde heeft in de 62.251-range.. Maar door het stukje wat
Maurice postte is het wel wat duidelijker.

--
EP
If(tagline = 'funny') steal(); else next message();
cp: Groove Armada - My Friend

EL PIÑO (elpino@postmaster.co.uk) wrote:
> (Lijkt me het meest on-topic hier, zo niet doe dan x-post en f'up naar de
> juiste groep)
>
> Bij toeval kwam ik er net achter dat HCCNet (AS20689) voor twee
> verschillende IP-blocks andere transit heeft, of beter gezegd bij één
> block ontbreken er.
>
> Als ik bijv. in de RIPE-whois kijk en een whois op het AS doe zie ik dat
> ze volledige routes van AS1136 (KPN Telecom) en AS3356 (Level3) 'krijgen'.
> Verder is er private peering met Abovenet. Dit geld inderdaad voor het
> block. 62.251.0.0/17 maar niet voor 80.100.0.0/15, voorbeeld van een
> traceroute vanaf Level3 in Amsterdam:

Je kunt er op die manier niet zomaar achter komen hoe de transit
werkt. Het is best mogelijk dat er wel een BGP route loopt over
beide transits, maar dat bij de ene transit een AS prepend gedaan
wordt op de announce van het ene block, en bij de andere transit
op die van het andere block. Daardoor lijkt de BGP route langer
en zal de route via de andere transit optimaler (korter) lijken.

Op die manier kun je een soort van loadbalancing doen, maar toch
een fallback hebben als een transit wegvalt.

Nadeel is wel dat je in principe geen redundantie hebt. In deze
setup is het goed mogelijk dat het totale externe verkeer groter
wordt dan wat 1 transit aankan.

level3 heeft geloof ik wel een looking glass, en KPN misschien
ook wel. Dan kun je vanaf daar eens kijken hoe de routes lopen.

> Die laatste gaat dus via Savvis naar KPN en zo naar HCCNet, terwijl HCCNet
> een directe verbinding met Level3 heeft. Een verschil van 2 AS'es dus. En
> zo gaat het bij verbindingen van en naar andere transitprovider op zo'n
> 80.100/15 adres ook vaak slechter, omdat het verkeer niet via Level3 gaat.
> En daarmee gaat het idd beter.

Hmmm, zouden ze dan twee ASsen prependen op het pad?

> Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben hetzelfde
> AS, en ik dacht dat dit soort dingen alleen per AS geregeld konden worden.

Nee, het kan dus per IP block.

--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Please note that my From: field is spamtrapped.

I've checked it, Erik Hensema really wrote this:

> Je kunt er op die manier niet zomaar achter komen hoe de transit
> werkt.

Daar was ik me bewust van.

> level3 heeft geloof ik wel een looking glass, en KPN misschien
> ook wel. Dan kun je vanaf daar eens kijken hoe de routes lopen.

Level3 heeft een looking-glass, daarvandaan komen de traces die ik postte.
KPN heeft ook een lg idd, te vinden op
<http://netcollect.kpn.net/looking-glass/index.phtml>.

>> Die laatste gaat dus via Savvis naar KPN en zo naar HCCNet, terwijl
>> HCCNet een directe verbinding met Level3 heeft. Een verschil van 2
>> AS'es dus. En zo gaat het bij verbindingen van en naar andere
>> transitprovider op zo'n 80.100/15 adres ook vaak slechter, omdat het
>> verkeer niet via Level3 gaat. En daarmee gaat het idd beter.
>
> Hmmm, zouden ze dan twee ASsen prependen op het pad?

Dat lijkt er dus wel op.

>> Wat ik me afvraag is dus: Hoe kan dit ueberhaupt? Beiden hebben
>> hetzelfde AS, en ik dacht dat dit soort dingen alleen per AS geregeld
>> konden worden.
>
> Nee, het kan dus per IP block.

Weer wat geleerd :-)

Blijf ik met de vraag zitten waarom men het doet maar ze zullen er iig wel
goede redenen voor hebben.

--
EP
Rockstars, is there anything they don't know? (Homer Simpson)

On 09 Nov 2004 19:58:42 GMT, "EL PIÑO" <elpino@isvervelend.be> wrote:


>
>Blijf ik met de vraag zitten waarom men het doet maar ze zullen er iig wel
>goede redenen voor hebben.

Ik kan me er een financiele reden voor bedenken, bijvoorbeeld: ze
hebben aan Level3 een bandbreedte commitment afgegeven tegen een
bepaalde prijs, Maar KPN is goedkoper ( tuurlijk want HCCnet is een
dochter ) ze hebben dus maar 1 prepend toegevoegd om toch bij die
commitment in de buurt te blijven.
In dit geval blijft het vreemd omdat KPN ( AS1136 ) zichzelf ook een
keer prepend in het ASpath naar HCCnet.

Maurice

In this age, <elpino@postmaster.co.uk> wrote:

> Naar een adres in de 62.251.0.0/17 range

ik zie 'm:
62.251.0.0/17 *[BGP/170] 16w1d 06:19:20, MED 10, localpref 110
AS path: 20689 I
AS path: 6461 20689 I
AS path: 2529 20689 I

En nu een interessante:

route-views.oregon-ix.net>show ip bgp 62.251.0.0/17
BGP routing table entry for 62.251.0.0/17, version 10902295
Paths: (50 available, best #47, table Default-IP-Routing-Table)

286 1136 1136 20689
Community: 286:12 286:146 286:147 286:201 286:202 286:286 286:3809 1136:2 1136:9 1136:10

6461 20689
Community: 6461:5997

3333 20689
193.0.0.56 from 193.0.0.56 (193.0.0.56)
Origin IGP, localpref 100, valid, external, best

> Naar een IP in de 80.100.0.0/15 range:

80.100.0.0/15 *[BGP/170] 16w1d 06:19:27, MED 10, localpref 110
AS path: 20689 I
AS path: 6461 20689 I
AS path: 2529 20689 I

286 1136 1136 20689
Community: 286:12 286:146 286:147 286:201 286:202 286:286 286:3809 1136:2 1136:9 1136:10

route-views.oregon-ix.net>show ip bgp 80.100.0.0/15 | inc 6461
6461 20689
Community: 6461:5997

3333 20689
193.0.0.56 from 193.0.0.56 (193.0.0.56)
Origin IGP, localpref 100, valid, external, best


Let op de communities:

remarks: | 286:12 Prepend 286 twice to European peer
remarks: | 286:3000 + countrycode Country where route is received
remarks: | countrycode E.164 international dial prefix


AS1136 heeft z'n communities niet in de RIPEdb.. Da's wel jammer. Maar
wat we hier zien is dus dat *iemand* liever niet heeft dat het verkeer
in Europa via AS286 gaat..

--
Sabri Berisha, SAB666-RIPE - I route, therefore you are
http://www.cluecentral.net - http://www.virt-ix.net

I've checked it, Maurice Sienema really wrote this:

>>Blijf ik met de vraag zitten waarom men het doet maar ze zullen er iig
>>wel goede redenen voor hebben.
>
> Ik kan me er een financiele reden voor bedenken, bijvoorbeeld: ze
> hebben aan Level3 een bandbreedte commitment afgegeven tegen een
> bepaalde prijs, Maar KPN is goedkoper ( tuurlijk want HCCnet is een
> dochter ) ze hebben dus maar 1 prepend toegevoegd om toch bij die
> commitment in de buurt te blijven.

Oké, dat zou logisch zijn. Maar aangezien ze dat block al een behoorlijke
tijd hebben zou ik denken: het wordt toch tijd voor een nieuwe
overeenkomst daarover. Overigens is HCCNet geen KPN-dochter hoor, ze
hebben meer te maken met InterNLNet bijvoorbeeld.

> In dit geval blijft het vreemd omdat KPN ( AS1136 ) zichzelf ook een
> keer prepend in het ASpath naar HCCnet.

Dat ook..

--
EP
Rockstars, is there anything they don't know? (Homer Simpson)

On 10 Nov 2004 11:46:40 GMT, "EL PIÑO" <elpino@isvervelend.be> wrote:

>Overigens is HCCNet geen KPN-dochter hoor, ze
>hebben meer te maken met InterNLNet bijvoorbeeld.

HCCnet (b)lijkt van CAS internet te zijn.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente

I've checked it, Peter Peters really wrote this:

>>Overigens is HCCNet geen KPN-dochter hoor, ze
>>hebben meer te maken met InterNLNet bijvoorbeeld.
>
> HCCnet (b)lijkt van CAS internet te zijn.

Ack.

--
EP
If(tagline = 'funny') steal(); else next message();
cp: The Vandals - Soccer Mom