| 123456789101112131415161718192021222324252627282930 |
- ---
- format: markdown
- title: bird mit unterschiedlichen Hin- und Rückrouten
- toc: no
- categories: Treffen
- ...
- # Problembeschreibung
- FFDO announced das Netz 193.43.221.0/24 sowohl auf dem hypervisor01 wie auch auf dem blech02. Das führt dazu, dass Datenpakete verschiedene Routen vom Client blech02 zu einem Server und zurück haben können. [1], [2]
- Z.B. wird ein Datenpaket vom Client blech02 mit einer MTU 1500 und dem df-bit (don't fragment) an fastly (AS-54113) gesendet. Das Antwort-Datenpaket vom Server wird aber an hypervisor01 geschickt. Von dort muss es über einen Bird-Tunnel an blech02 weitergeleitet werden, dafür muss die MTU verringert werden.
- Der Client hypervisor01/koerne antwortet mit einer TCP/MSS clamping Nachricht an den entfernten Server, damit dieser seine MTU verringert. Wenn der entfernte Server das aber nicht macht, aus welchen Gründen auch immer, wird das Antwortpaket verworfen.
- pMTUd vom Client aus kann keine Lösung sein, da nicht von vornherein bekannt ist, welche Route der Server für die Antwort auswählt.
- Lösung
-
- Pakete vom Client blech02 werden nicht über das Gast-AS-50873 (myloc) an den Server fastly AS-54113 gesendet, sondern über den ffdo-Switch 193.43.221.243, dann 193.43.221.166(koerne). Damit ist die MTU vom Client hypervisor01/koerne zum Server fastly für beide Richtungen gleich.
- Das wird festgelegt durch einen Eintrag in bird.conf auf blech02/duesseldorf in den Zeilen 146-148:
- root@duesseldorf:/etc/bird # diff bird.conf.ok bird.conf
- 145a146,148
- > # deb.debian.org -> fastly => pMTUd broken:-(
- > if bgp_path.last = 54113
- > then gw = 193.43.220.166;
- Die Frage ist nun, was passiert, wenn fastly sich mal entschließen sollte, die Antwort-Pakete an AS-50873 zu senden...?
- [1] https://de.wikipedia.org/wiki/Maximum_Segment_Size
- [2] https://de.wikipedia.org/wiki/Path_MTU_Discovery
|
