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

[Bernd Spiess]

> Austausch heißt, wir erfahren auch Deine Settings? :-)

Gerne ... ich kann aber nur dafür sprechen wie ich es früher bei 39912 gehalten habe :-)
Andi kann ja gerne updaten wenn er Dinge dort jetzt anders handhabt :-)

> 1)
> Maxpref wird, denke ich, jeder einsetzen?

Maxpref war immer gesetzt - bei allen peerings und bei allen BGP Kundenconfigs
Bei kleinen IXP´s typischerweise auf ca. 50 oder 100 - bei großen wie DE-CIX typischerweise auf ca. 3000 - 
Pro Session dann halt individuell höhere Werte wenn benötigt... (aber nie ohne Maxpref)

(Bei Kunden waren statische ACL´s zusätzlich gesetzt - d.h. doppelt abgesichert - )

> 2)
> 
> Bogon Filter (10.x / 192.168.x / .) hat vermutlich auch jeder?
> 
> ( full list: siehe http://www.team-cymru.org/bogon-dotted-decimal.html
> => verwendet ihr die volle Liste?)

war anfangs nicht aktiv - wurde dann nachgezogen weil es viele peers gibt, die das irrtümlich mitschicken - sollte man aus meiner Sicht
an allen Stellen rausfiltern - außer natürlich wenn eh per ACL nur die positiven durchlässt ... dann hat es sich natürlich erledigt ...

> 3)
> 
> Wie verwendet ihr filtering von: "do not accept if originate packet ip 
> is from ourselves"?

"
Also hier haben wir derzeit keine Filter. Wir selbst haben BCP38-Filter an allen unseren Teilnehmeranschlüssen und hoffen somit mit Recht behaupten zu können, hier "clean" zu sein. Natürlich könnten Pakete von außen kommen. Hier ist ein bissl schwer, wer "ourselves" ist, denn wir haben einige Multihomed-Teilnehmer, wo also auch legitimer Traffic mit "unseren" Source-IPs von außen hereinkommen könnte.
"

Ja BCP38 ... deshalb hab ich gefragt ... bei kleinen Netzen ist es vermutlich gut  - bei großen Transitnetzen scheiterst wohl genau daran, dass einfach zuviele Prefixe im Spiel sind um das an den Edges auch zu filtern...

> 4)
> 
> AS path filter ja/nein?

"(seit ca. 10 Jahren) nicht mehr. Wir hatten das mal als unsere Router noch nicht die full-routing-table beherrschen konnten."

War bei uns auch so - anfangs ja - danach aber aufgehört damit ...

> 5)
> 
> Gerade auf Nanog liste gesehen: DSCP flags auf 0 reset um zu 
> verhindern,
> 
> dass traffic von peering prefixes ungewollt interne EF queue´s / . 
> ansteuert.
> 
> machen das alle?

"Macht unsere Platform automatisch, da wir kein Trust gesetzt haben."

War damals bei 39912 kein Thema - wir hatten keine DSCP Verwendung im Core - 
Ist aber ein interessanter Punkt, den ich vorher nicht am Radar hatte... daher auch die Frage...

> 6)
> 
> Statische acl pro peering wird wohl niemand machen? Wer verwendet 
> dynamische Acl´s auf Basis RADB/Ripe und wie sind die Erfahrungen hiermit?

"Wir bauen primär Prefixlisten für jene Peers, die wenig (ca. <300) Prefixe announcen.
Das geschieht automatisch aus der RIPE-DB mit rtconfig (v4 + v6). 
Die Erfahrungen damit sind gut, allerdings funktnioniert es in unserer Implementierung nur mit RIPE-DB-Objects."

Bei 39912 war es statisch bzw. gab es eine ACL Freischaltung nur dann, wenn der manuell überprüfte RADB korrekt vorhanden war - 
viel Arbeit aber sinnvoll und notwendig - Bei meinen jetzigen Kunden ist es interessant - vereinzelt kommen 
Netze mit bis zu 50% RADB Fehler daher ... Die werden dann natürlich bei den Routeservern rausgefiltert und
demzufolge ist es viel Arbeit, die auf Fehlerfreiheit hinzubewegen... 
Da verschenkt man viel echten Traffic=Umsatz wenn man sich nicht darum kümmert ...

> 7)
> 
> set metric auf 0 an den Borders auf gelernte Prefixe oder übernehmt 
> ihr alles
> 
> was Euer gegenüber bzgl. den med´s eingestellt hat?

"Wir setzen unsere eigenen Meds."

Detto bei 39912 - dort wurde an allen Übergängen (Transit und Peering) alles auf eigene definierte Werte gesetzt...

> 8)
> 
> Bgp community tagging (sofern benötigt), ist denke ich klar .

"Die Frage verstehe ich nicht ganz, aber ja, wir taggen unsere gelernten Routen mit communities, um "weiter hinten" 
noch zu wissen, wo sie herkamen. Und ja, outgoing setzen wir natürlich auch dort communities, wo wir irgendeine Info mitgeben wollen."

Ja, genau so war die Frage gemeint ... Detto bei 39912

> 9)
> 
> Fremde bgp community tags alle per default löschen oder lässt Ihr die 
> einfach?

"Wir löschen sie nicht. Ist aber eine gute Frage und mich würde hier auch feedback von anderen freuen."

Wurde nur vereinzelt gelöscht um quasi zu einer Regel zu kommen ob löschen oder lassen ...
Wäre hier auch an anderen Meinungen interessiert...

> 10)
> 
> 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 - 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 ... :-)

> 11)
> 
> Default route filtern (no-na)

"Ha, erwischt. Bei den maxpref-peers haben wir einen derartigen Filter nicht. Das wäre vielleicht eine gute Idee, neben den RFC1918 auch gleich die Default-Route wegzuhauen."

Ja ... bei 39912 brutal überall gefiltert - gegen Kunden, gegen Peerings - quasi in jeder BGP config war das ein Fixpunkt ...

> 12)
> 
> Was fehlt hier sonst noch?

12) Ist IPv4 und IPv6 kongruent konfiguriert?

"Bei uns ja, wir versuchen Announcements und Metriken für beide Protokolle so gleich wie möglich abzubilden. D.h. dort wo es die Gerätefamilie zulässt, haben wir auch die gleichen Route-Policies für
IPv4 und IPv6."

Confirm ... bei 39912 seit vielen vielen Jahre so praktiziert und auch bei jeder peering session so eingefordert wenn verfügbar ...


13) Wenn noch kein IPv6 - warum, bzw. was ist das Hindernis?


Das würde mich auch interessieren :-) 
Wenn jemand Core Beispielconfigs braucht, einfach in der Gruppe melden ... Sind zum Austeilen versandbereit ... :-)


"Bitte, ich bin auf weitere gespannt!"

me too...

lG Bernd (gesprochen aus Sicht des früher verantworteten 39912)