Hi, Wie-O-wie: Router A en router B hebben een eBGP sessie met elkaar. A announcet routes aan B. Wie plakt dan het ASN van A voor het as-path? A (de zendende kant) of B (de ontvangende kant)? -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 2003-09-22 at 16:39, Alex Bik wrote:
Router A en router B hebben een eBGP sessie met elkaar. A announcet routes aan B. Wie plakt dan het ASN van A voor het as-path? A (de zendende kant) of B (de ontvangende kant)?
rfc1771, in sectie 5.1.2: b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system, then the advertising speaker shall update the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system shall prepend its own AS number as the last element of the sequence (put it in the leftmost position). het antwoord is dus A (de zendende kant). of heb ik vals gespeeld door in de rfc te kijken? vraag me af wat een gemiddelde bgp implementatie doet waarbij een as_path binnenkomt dat niet begint met het AS van de peer. - ruud -- ruud de rooij | bgphints - internet routing news, hints and tips ruud at ruud.org | http://bgphints.ruud.org/
On Mon, 22 Sep 2003, ruud de rooij wrote:
het antwoord is dus A (de zendende kant). of heb ik vals gespeeld door in de rfc te kijken?
Nee hoor :)
vraag me af wat een gemiddelde bgp implementatie doet waarbij een as_path binnenkomt dat niet begint met het AS van de peer.
Precies. De reden dat ik het vroeg, is dat DE-CIX een routeserver heeft, waar je blijkbaar tegen kunt zeggen dat hij z'n eigen AS 'hidden' moet maken. Het ding doet ongeveer hetzelfde als openpeering, routes die hij leert aan z'n peers announcen zonder next-hop self, zodat je niet perse met alle aanwezigen een sessie op hoeft te zetten. Op zich is het aardig bedacht om het ASN van het ding hidden te kunnen maken, maar dus wel RFC ignorant. Het zou me ook niet verbazen als niet alle routers dat 'slikken', zoals je zelf ook al aangeeft. Waarschijnlijk hebben de mannen dus een gehackte versie van Zebra draaien. De MAC adressen wijzen op kaartjes van "PFU Limited" en "Supermicro". PC's dus. Als ik een bgpd was zou ik de prefixen die niet met het peer-as beginnen droppen en heel hard mekkeren in m'n log :) -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 22 Sep 2003, Alex Bik wrote:
De reden dat ik het vroeg, is dat DE-CIX een routeserver heeft, waar je blijkbaar tegen kunt zeggen dat hij z'n eigen AS 'hidden' moet maken.
Waarschijnlijk hebben de mannen dus een gehackte versie van Zebra draaien. De MAC adressen wijzen op kaartjes van "PFU Limited" en "Supermicro". PC's dus. Als ik een bgpd was zou ik de prefixen die niet met het peer-as beginnen droppen en heel hard mekkeren in m'n log :)
Hmm, ik denk toch niet dat dat waar is. Heel simpel gezien kan je dat ook gewoon met een Juniper doen (en $router_vendor waarschijnlijk ook). Sloop de next-hop self uit je export statements en klaar is kees. Dat zal trouwens niet het geval zijn met routes die je zelf originate. En als extra zal de peer (kant B) een directe verbinding (indirecte route lijkt me niet handig) moeten hebben met hetzelfde LAN als waar jij je routes vandaan haalt (wat dus zo is bij dat DECIX verhaal). -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/
On Mon, 2003-09-22 at 17:13, ProServe - Peter Batenburg wrote:
On Mon, 22 Sep 2003, Alex Bik wrote:
De reden dat ik het vroeg, is dat DE-CIX een routeserver heeft, waar je blijkbaar tegen kunt zeggen dat hij z'n eigen AS 'hidden' moet maken.
Waarschijnlijk hebben de mannen dus een gehackte versie van Zebra draaien. De MAC adressen wijzen op kaartjes van "PFU Limited" en "Supermicro". PC's dus.
zoals jeroen ook al zei, standaard zebra inderdaad, zie ook bijvoorbeeld http://marc.theaimsgroup.com/?l=zebra&m=106275688728595
Als ik een bgpd was zou ik de prefixen die niet met het peer-as beginnen droppen en heel hard mekkeren in m'n log :)
voor C-dozen moet je dat blijkbaar instellen met "bgp enforce-first-as": http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid...
Hmm, ik denk toch niet dat dat waar is. Heel simpel gezien kan je dat ook gewoon met een Juniper doen (en $router_vendor waarschijnlijk ook). Sloop de next-hop self uit je export statements en klaar is kees.
volgens mij wordt nog steeds dan z'n eigen AS toegevoegd als eerste element van het ge-exporteerde as-pad. next-hop self past volgens mij alleen het IP van de route aan (maar ik ben geen juniper expert). - ruud -- ruud de rooij | bgphints - internet routing news, hints and tips ruud at ruud.org | http://bgphints.ruud.org/
On maandag, sep 22, 2003, at 23:40 Europe/Amsterdam, ruud de rooij wrote:
On Mon, 2003-09-22 at 17:13, ProServe - Peter Batenburg wrote:
On Mon, 22 Sep 2003, Alex Bik wrote:
De reden dat ik het vroeg, is dat DE-CIX een routeserver heeft, waar je blijkbaar tegen kunt zeggen dat hij z'n eigen AS 'hidden' moet maken.
Da's een standaard feature van route servers, was al zo met de aloude IRRd van Merit indertijd
Waarschijnlijk hebben de mannen dus een gehackte versie van Zebra draaien. De MAC adressen wijzen op kaartjes van "PFU Limited" en "Supermicro". PC's dus. zoals jeroen ook al zei, standaard zebra inderdaad, zie ook bijvoorbeeld http://marc.theaimsgroup.com/?l=zebra&m=106275688728595
Correct
Als ik een bgpd was zou ik de prefixen die niet met het peer-as beginnen droppen en heel hard mekkeren in m'n log :) voor C-dozen moet je dat blijkbaar instellen met "bgp enforce-first-as": http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/ products_feature_guide09186a008015ce53.html
Klopt ook. De enige checks die IOS zo ongeveer doet is of het ASN wel 16 bits is en of niet z'n eigen ASN in het path staat.
Hmm, ik denk toch niet dat dat waar is. Heel simpel gezien kan je dat ook gewoon met een Juniper doen (en $router_vendor waarschijnlijk ook). Sloop de next-hop self uit je export statements en klaar is kees. volgens mij wordt nog steeds dan z'n eigen AS toegevoegd als eerste element van het ge-exporteerde as-pad. next-hop self past volgens mij alleen het IP van de route aan (maar ik ben geen juniper expert).
Correct (over next-hop-self :). Behalve misschien `local-as' weet ik van geen knob in JunOS om het invoegen van het eigen ASN in announcements te onderdrukken, en voor een route server is local-as niet bepaald van toepassing. -- Niels. --
On Mon, 22 Sep 2003, ruud de rooij wrote:
zoals jeroen ook al zei, standaard zebra inderdaad, zie ook bijvoorbeeld http://marc.theaimsgroup.com/?l=zebra&m=106275688728595
Voordat we nu hier allemaal een voor een gaan roepen dat het allemaal standaard is en dat zebra het kan en $router waarschijnlijk ook: Nee. Het gaat _niet_ om het niet zetten van jezelf als next-hop, maar om het weglaten van je eigen AS nummer. Als je een route leert van A en annoucet aan B zonder next-hop self, zal het IP verkeer van B rechtstreeks naar A gaan en omgekeerd (in het geval van een shared medium), maar zie je wel je eigen AS in het pad. Waar het hier om gaat is het weglaten van die extra AS hop. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Tue, 23 Sep 2003, Alex Bik wrote:
On Mon, 22 Sep 2003, ruud de rooij wrote:
zoals jeroen ook al zei, standaard zebra inderdaad, zie ook bijvoorbeeld http://marc.theaimsgroup.com/?l=zebra&m=106275688728595
Voordat we nu hier allemaal een voor een gaan roepen dat het allemaal standaard is en dat zebra het kan en $router waarschijnlijk ook: Nee.
Het gaat _niet_ om het niet zetten van jezelf als next-hop, maar om het weglaten van je eigen AS nummer. Als je een route leert van A en annoucet aan B zonder next-hop self, zal het IP verkeer van B rechtstreeks naar A gaan en omgekeerd (in het geval van een shared medium), maar zie je wel je eigen AS in het pad. Waar het hier om gaat is het weglaten van die extra AS hop.
DE-CIX gebruikt Zebos, een commerciele implementatie van Zebra, voor meer informatie, zie http://www.ipinfusion.com. Hun manuals staan achter slot en grendel, dus of het weglaten van dat AS standaard door hen wordt gesupport is me niet helemaal duidelijk. Frans
On Tue, 23 Sep 2003, Frans ter Borg wrote:
DE-CIX gebruikt Zebos, een commerciele implementatie van Zebra, voor meer informatie, zie http://www.ipinfusion.com.
Hun manuals staan achter slot en grendel, dus of het weglaten van dat AS standaard door hen wordt gesupport is me niet helemaal duidelijk.
Maar: Mis ik nou wat, of breekt dat de RFC? -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Mon, 22 Sep 2003, ProServe - Peter Batenburg wrote:
Hmm, ik denk toch niet dat dat waar is. Heel simpel gezien kan je dat ook gewoon met een Juniper doen (en $router_vendor waarschijnlijk ook). Sloop de next-hop self uit je export statements en klaar is kees.
Dat klopt niet wat je hier zegt. Als je geen next-hop self zet gaat het IP verkeer wel rechtstreeks van je ene peer naar de andere, maar staat nog steeds jouw AS nummer in het as-path! -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
-----BEGIN PGP SIGNED MESSAGE----- Alex Bik wrote: <SNIP>
De reden dat ik het vroeg, is dat DE-CIX een routeserver heeft, waar je blijkbaar tegen kunt zeggen dat hij z'n eigen AS 'hidden' moet maken.
<SNIP>
Waarschijnlijk hebben de mannen dus een gehackte versie van Zebra draaien. De MAC adressen wijzen op kaartjes van "PFU Limited" en "Supermicro". PC's dus.
Nope, niet eens gehackt, standaard zebra snapt dat ook. Er is een standaard 'routeserver' optie en je kan natuurlijk zebra's "bgp multiple instance" optie gebruiken. Check btw http://lists.quagga.net/pipermail/quagga-users/2003-August/000266.html en match dan die naam uit de From line met wellicht een nu bekend persoon van je :) Overigens snappen cisco'tjes het ook enzo, maar je kan wat meer omgein uithalen, vooral zelf code er in proppen, met zebra doosjes, wat denk ik toch wel een van de redenen is dat ze het oa bij RIS, Routeviews en nog een stapel projecten (mijn GRH ding inclusief) gebruiken. Het scaled alleen niet super en volgens die leuke presentatie op RIPE zitten er ook nog wel wat missertjes in, maar it's good enough(tm). Success @ DE-CIX btw :) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP29mZCmqKFIzPnwjEQIF4wCfS/+Csu1Xp6YrbvrLvjFpSlj6vwYAn1K0 PWJiti8F9lZMbSuoleFR1oJS =uEyY -----END PGP SIGNATURE-----
On Mon, 22 Sep 2003, Jeroen Massar wrote:
Nope, niet eens gehackt, standaard zebra snapt dat ook. Er is een standaard 'routeserver' optie en je kan natuurlijk zebra's "bgp multiple instance" optie gebruiken.
Check btw http://lists.quagga.net/pipermail/quagga-users/2003-August/000266.html en match dan die naam uit de From line met wellicht een nu bekend persoon van je :)
Toch gaat dat volgens mij over iets anders dan het weglaten van je eigen AS in het as-path. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
On Tue, Sep 23, 2003 at 08:01:05AM +0200 Alex Bik(alex at bit.nl) wrote:
On Mon, 22 Sep 2003, Jeroen Massar wrote:
Nope, niet eens gehackt, standaard zebra snapt dat ook. Er is een standaard 'routeserver' optie en je kan natuurlijk zebra's "bgp multiple instance" optie gebruiken.
Check btw http://lists.quagga.net/pipermail/quagga-users/2003-August/000266.html en match dan die naam uit de From line met wellicht een nu bekend persoon van je :)
Toch gaat dat volgens mij over iets anders dan het weglaten van je eigen AS in het as-path.
het gaat volgens mij om de combinatie van de twee (as-path en next-hop) en volgens de rfc is het in ieder geval niet illegaal om de next-hop te veranderen naar iets buiten het common subnet. (rfc1771 - 5.1.3 NEXT_HOP) en ik denk dat voor route-servers het principe van optie a geld mbt as-path, omdat ze qua ip in het zelfde as zitten. (rfc1771 - 5.1.2 AS_PATH) just my EUR 0.02 :-) -- Tycho Eggen (Unix|Network|Social) Engineer tycho at e-dude.org +31 6 41 824 855 Linux is like a wigwam; No Windows, no Gates, and Apache inside!
On Tue, 23 Sep 2003, Tycho Eggen wrote:
het gaat volgens mij om de combinatie van de twee (as-path en next-hop) en volgens de rfc is het in ieder geval niet illegaal om de next-hop te veranderen naar iets buiten het common subnet. (rfc1771 - 5.1.3 NEXT_HOP)
Het veranderen van je next-hop is - uiteraard - gewoon toegestaan. Dat was ook niet waar het om ging.
en ik denk dat voor route-servers het principe van optie a geld mbt as-path, omdat ze qua ip in het zelfde as zitten. (rfc1771 - 5.1.2 AS_PATH)
Wat was optie A ook al weer? :) Er is nog wel een andere RFC die interessant is in dit verband: http://www.rtfm.nl/rfc/rfc1863.txt -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
Hoi,
Router A en router B hebben een eBGP sessie met elkaar. A announcet routes aan B. Wie plakt dan het ASN van A voor het as-path? A (de zendende kant) of B (de ontvangende kant)?
Het is voor een route-server of MLPA-router op een exchange erg handig als je next-hop-self kan en mag uitzetten, omdat je eigenlijk alleen maar het uitwisselen van routes voor iedereen makkelijk wilt maken, en niemand er behoeft aan heeft dat het payload verkeer ook via jou loopt. Je wilt niet zichtbaar zijn in een traceroute. Omdat het payload verkeer niet door je heen loopt zou je eigenlijk ook jouw AS nummer niet in het pad willen zien: het maakt immers het AS path 1 hop langer en dus minder aantrekkelijk. Dan kan het zijn dat deelnemers onnodig verkeer via een transit ontvangen (sturen kun je met localpref nog fixen) of ze moeten op hun transits hun AS path kunstmatig verlengen. De wens is om het AS van de route-server weg te halen is dus heel logisch en zinvol. Als het van de RFC niet zou mogen, moeten we dan de praktijk aanpassen of de RFC? Op dit moment is het AS van Open Peering (AS20562) voor MLPA deelnemers overigens wel zichtbaar. Het uitfilteren is op de Foundry NetIron die wegebruiken ook wat lastiger dan in Zebra. We hebben next-hop-self wel uit staan. Groeten, Jan. -- Jan Hoogenboom jan at openpeering.nl Open Peering Initiative http://www.openpeering.nl +31 (0)70 363 16 61
On Tue, 23 Sep 2003, Jan Hoogenboom wrote:
Het is voor een route-server of MLPA-router op een exchange erg handig als je next-hop-self kan en mag uitzetten, omdat je eigenlijk alleen maar het uitwisselen van routes voor iedereen makkelijk wilt maken, en niemand er behoeft aan heeft dat het payload verkeer ook via jou loopt. Je wilt niet zichtbaar zijn in een traceroute.
Uiteraard. Ik begrijp alleen niet zo goed waarom er steeds over next-hop self gesproken wordt, want ik heb al helemaal aan het begin van deze thread aangegeven dat het daar _niet_ om ging.
Omdat het payload verkeer niet door je heen loopt zou je eigenlijk ook jouw AS nummer niet in het pad willen zien: het maakt immers het AS path 1 hop langer en dus minder aantrekkelijk. Dan kan het zijn dat deelnemers onnodig verkeer via een transit ontvangen (sturen kun je met localpref nog fixen) of ze moeten op hun transits hun AS path kunstmatig verlengen. De wens is om het AS van de route-server weg te halen is dus heel logisch en zinvol.
Maar wel gevaarlijk, in verband met routing loops. Vooral als je meerdere route-servers hebt.
Als het van de RFC niet zou mogen, moeten we dan de praktijk aanpassen of de RFC?
Zie RFC1863. -- Met vriendelijke groet, Alex Bik, BIT BV AB2298-RIPE
participants (8)
-
alex＠bit.nl -
frans＠quanza.net -
jan＠openpeering.nl -
jeroen＠unfix.org -
niels.bakker＠ams-ix.net -
peter＠proserve.nl -
ruud＠ruud.org -
tycho＠e-dude.org