sch-einesystem | Blog
| ||
|
|
|
|
|
|
 | |
| [0] |
20220508-1100-0-1.jpg |
 | |
| [1] |
20220508-1100-0-2.jpg |
 | |
| [2] |
20220508-1100-0-3.jpg |
| Ich bin seit mehreren Tagen daran an meinem außerhalb der EU aber im Ripe Gebiet Peering BGP – Communities zu implemenentieren damit Asien/Osteuropa Traffic dort also vor Ort ankommt und hingeleietet wird udnncih so sher zu den Peers in (Zentral-)europa innerhalb der EU. Das ist mit einem einzelen Prefix und AS das an unter-schiedliche geografisch hunderte/tausende Kilometer voneinander enfernr liegenden Orten nicht ganz einfach. Jeder Provider tagt andere Commuty Attribute an seine Routen, es sit nicht ersichtlich welches Prefix regional in welches land gehört aber so ist das im Backbone nunmal die PI-IPv4-Space Providernetze die nachher den PA-IPv4 Space routen, also die endkudnenenetze, sind ja von der Natur her schon länderübergeifend. Anhand eines AS Handles kann man (Ausnahme Telia oder UUnet) nämlich nur sehr schlecht feststellen wo man Traffi am besten anlandet, insbesondre wenn Provider an meheren Orten gleichzeitg präsent sind. Idealerwise sollte das so us-sehen das der Traffic aus asien im Asien am gegografsich nächstliegenden Peerr abgsendet/entgegengenommen wird Also im Süd/Osten und der nach Amerika an eienm Peer im Nordwesten. Also mit Präferenz, beim Ausfall eiens Peerings sollen natürlich die verbleibenden Peers den Traffic des ausgefallnen übernehmen. Miets kann man nur Communities taggen wie: D*CIX eingehend prependen (schlechtere Priorität) woebi man dann auch korrespondierend eingehend den BGP Feed des Peers
anpassen sollte damit die AS-Pfand anzhal Routesdistanz eigehend und augehend gelich ist. Das Bedute man muß dan anch AS Pfad udn am besten noch den eingehenden Communiyt Tgas suchen udn shcuen daß man bei dem BGP Full Table Feed den der Upstream anliefert dann entsprechend für diese Routen ebeenfalls noch ein AS Pfad prependet wird. Damit die Route hin udn zurück gleich lang bleibt und Traffic auf dem gelh weg rasugeht wie er reienkommt. Verifcht kann amn sichd as so vortellen daß die Pakte die UPS anliefert cuh von UPS abgeholt werden, dei die DHLS liefrt auch bei DHL aufgegeben werden, die bei Hermeis ... usw., so läuft das in einem (flächenmäßig) großen EDV Netz auch bei ausfallsicherem Roting. Was man aslo vemridne muß st das Pakte die per UPS annkommen per DHL zurück ge-schickt werden, etea wiel beim Emfänger der DHL Shop näher ist als der UPS Shop, umgekehrt wie beim Absnder Wo dann im realen Leben in der analogen Welt zusätz-lich Kosten entstehenw enn man nicht zurückversendet auf dem gleichen Wge wie hin, das ksote inder EDV auch zusätzlich, nämlch “round trip time”,Laufzeit, ist der eingehende Weg sagen wir 100ms shcnell und der aus-gehende 200 ms dann wird darsu ne paketlaufzeit von 150 Ms, also shclchter als es sien könntew enn der optimal Weg genommenwird. Daduch snstht dann Jitter, also Störungen etwa in Reltimeandnwendugwn wie der VoIP Sprachqualität wenn man Pech hat. Und um das zu optimieren mußte ich dann ertsmalmeien looking glass scirptee auf vodermann bringen cnhdem ich letzte woche ja schon scripts für dei glue record monitoring geschichte (die sach mit der Domain) geschrieben habe. Laso viel viel arbiet woe man von andern abhängig ist, in deren Looking Glass schauen muß ob AS path Preepnds und Communitys auch wiklich so ankommen und wirken wie man das will. Multihomed/multipath routing udn das balncen der Laod ist ne wisscaft für sich. Das ist nicht so einfacht wie das MLPPP Büdneln mehere ISDN Kanäle. | |