[atnog] Frage zu peering handling (setting/filtering)

[Wilfried Woeber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Servus!

On 2015-05-14 16:34, Bernd Spiess wrote:
> Hallo Wilfried
> 
> Danke für deinen Input ...
> 
>>>> Filter auf alles was kleiner ist als /24
>>>
>>> "nein."
>>>
>>> Aha ... interessant - bei 39912 wurde generell alles darauf gefiltert 
>>> ... die mit /25 und kleiner haben die Empfehlung bekommen, das Netz 
>>> zurückzugeben und auf mindestens /24 zu wechseln
>>
>> Also *ds* find' ich spannend, denn das hat dann systematisch Adressblöcke
>> unerreichbar gemacht, die per RIPE Policy kein /24 oder größer bekommen haben...
>>
> 
> Eigentlich nicht - per default route waren die ja immer erreichbar ...
> Es war nur eine Policyentscheidung in der Full Table nichts kleineres
> als /24 mitzunehmen ...

Ah. OK. Die Konfig.-Kombination mit "full" table und Default hab ich noch nie im Kopf gehabt!

> D.h. ausgeschlossen vom Routing: Nein
> Ausgeschlossen von kurzen Peering Wegen: Ja

I see.

>> Wie hat sich so ein "Wechsel" abgespielt - durch "belügen" des RIPE NCC?
> 
> Nein ... nur der Hinweis, dass wir vermutlich nicht die einzigen sind, die auf kleiner
> als /24 filtern und somit einfach längere Wege in Kauf zu nehmen sind... 
> was dann jeder einzelne mit der Info macht, ist dann ja seine Sache ...

OK. Ich muss das noch einmal durchdenken, aber das riecht nach einer (sicher
nicht häufigen aber doch) potenziellen Quelle von Loops?

> Mein persönlicher Tip hier war: bevor mit /25 PI arbeitest - nimm lieber
> PA vom ISP der dann aggregiert ja mit grösser /25 unterwegs ist...

Dem würde ich mich auch anschließen!

>>> - Sowas wurde bei 39912 nur per default Route via Transit Carrier 
>>> erledigt - in den Peerings haben wir sowas kleines nicht angenommen ...
>>> Vor allem deshalb weil es auch verhindert, dass komplette interne iBGP 
>>> Netzstrukturen, die per Error mitannounced werden, übernommen werden 
>>> ... schlimm genug wenn man die ganzen /24 more specifics abbekommt ... 
>>> :-)
>>
>> Das ist ja eine *ganz* andere Baustelle. Für mich klingt das Bestrafung der
>> Unschuldigen, weil wir die
>> (jahrelang!!) Schuldigen nicht in den Griff bekommen?
>>
> 
> Ja - wenn man das so sehen will: korrekt
> ... wenn es keinen Wettbewerb an Defragmentierung gegeben hätte,
> d.h. all diejenigen die z.B. /19 in 32 x /24 zerteilt haben - und es heute
> noch immer tun ...

Das wäre ja jetzt vmtl. einen eigenen Thread wert,
aber ich habe nie verstanden, wie die ISP Community jahrelang ihre "Sorgen"
gegen jede Quelle von ein paar zusätzlichen Routen artikuliert hat (zB im
Zusammenhang mit IPv6), aber gleichzeitig über Jahre(!) das substanzielle(!)
Einsparungs-Potenzial durch Aggregierung / Filtern der Deaggregierung ignoriert hat.

> wären die Überlegungen an Filterübungen gar
> nicht erst aufgekommen ... Das Problem wer damals ein massives Thema
> wie die BGP full Table in Richtung 256.000 Routen gegangen ist und somit
> viele Router an das Hardware-Chip-Limit gekommen sind ... Heute hingegen wäre das
> wiederum egal weil die Router eh darauf eingestellt sind ...
> (aus der Zeit stammt diese Config die sich halt dann länger gehalten hat...)

Ja, nix hält solange wie ein Provisorium :-)

>> Übrigens, in der (näheren) Zukunft könnte das Thema wiederkommen, wenn im
>> Zuge des Adresshandels Blöcke kleiner als /24 den Beutzer wechseln?
> 
> 
> Ich würde jedem abraten /25 oder kleiner zu kaufen ...

Ich auch,

> wieso sollte ich mir Probleme kaufen :-)

aber wenn ich nur ein paar Adressen brauche und dann gleich 256 kaufen soll?
Hängt natürlich vom Preis und den "deep pockets" ab?

> vielleicht bin aber ich ja der Einzige der das so sieht?.... Daher auch die
> Frage danach ...
> 
> lG aus Kärnten nach Amsterdam ... 

LG,
Wilfried

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVVMKvAAoJEPMGt0I/M2zS0q4QAICzNscOSxV0hlNFAatoLvD0
DzbFPtLxn1MwVml9gbVAIedqFXPuDiEHYjh/CQDUeaufVXuLr9j7lvDjXE1rh4l7
R+UFORqVJcl61ketQgyaGoF7ZW3BUiznlngugXFozFM40vkczuVJv639JqRs+u1E
z4O2gfVofs7FR6pDXR7Mms9I43PvnIHgq25mzUPJer2jqLqr9b5HJp8/66fJ3GQM
sq8aAg0OMN82fwErZvyu059BFYaVIXhjl8d8/14cvyKNb/8ZLpGYeSWGulszVxoE
ZN5Has3e+C5bn5vK4yU9DSrnllf5u+Zgy3Xp++BDzyzN4NJLWt1rnesovH+IKw//
Ywcuu8dJggHpyte+T8Lc7JGn69ztVifaccFelvCPlioHHNY8GMP0UJGcPJPM7mO3
MopoVJLwuPz5fZL8uRbYqUfk8LUvXZEXpwykQJRrB6JeGI0xzRf6ukCkYzjlQvWK
n0tbGGxEP16nxjQpaP+A2oB+l/Qzxk96Rfo66QkxKkbCdWrhCfnU+anTk5Kv0jv/
A3qL4ovyUtOHY9j8KvyUoX3fZM/bqaiknLTRzguuQ0U3NUZ3/bFUCMJki7cOQLsG
A9CJoX0WFfXVuEgPmitfuyVETRjdsR0jwbrQmULhfc/UW3nI5GpGlieP1ujFTSXJ
HotLausDYeJaXgNrghjk
=Ebj3
-----END PGP SIGNATURE-----