PLNOG19 - Konrad Kulikowski - Segment Routing – okiem praktykaPROIDEA
W swojej prezentację przedstawię wady i zalety segment routingu oraz jak konfigurować go w sieci Brown Field we współpracy z LDP. Poruszę również temat: włączania TI-LFA, który zapewnia protekcję 100% prefixów bez względu na topologię sieci, uruchamiania serwera PCE i zestawiania sesji BGP-LS do PCE (Path Computation Element), konfiguracji tunneli SR z trasami definiowanymi explicit, dynamic, PCE, jak również Disjoint Node/Path/Srlg czy Metryki IGP/TE oraz przedstawię nowatorską technologię ODN (On Demand NextHop), a na koniec opowiem o nowym podejściu do definiowania tuneli SR tzw POLICY. Prezentacja będzie oparta na przykładach konfiguracji w systemach IOS XR i XE.
PLNOG14: Nowości w protokole BGP, optymalizacja routingu na brzegu sieci - Łu...PROIDEA
Łukasz Bromirski - Cisco Systems
Language: Polish
Nowości w protokole BGP i optymalizacja routingu BGP na brzegu sieci
Zarejestruj się na kolejną edycję PLNOG: krakow.plnog.pl
PLNOG16: IP/MPLS for Fixed and Mobile Convergence, Kevin WangPROIDEA
This document discusses IP/MPLS and MPLS-TP solutions from Raisecom for fixed and mobile network convergence. It introduces the iTN8800 platform and iTN200 and RAX700 series CPE devices, which support IP/MPLS, MPLS-TP and carrier Ethernet technologies. The document also outlines their applications such as business service access, mobile backhaul, legacy network migration and interworking IP/MPLS with MPLS-TP networks.
PLNOG16: DDOS SOLUTIONS – CUSTOMER POINT OF VIEW, Piotr WojciechowskiPROIDEA
This document provides an overview of DDoS solutions from a customer perspective. It discusses different types of DDoS attacks and the need for multiple protection tools. It describes two common deployment models for scrubbing centers: DNS redirection and BGP. AlwaysOn protection is generally better than on-demand AlwaysAvailable protection. While scrubbing services can mitigate large attacks, they are not a complete solution and other measures are needed to deal with initial attack waves. Preparation including a response team and plan can help organizations effectively respond to DDoS attacks.
PLNOG19 - Konrad Kulikowski - Segment Routing – okiem praktykaPROIDEA
W swojej prezentację przedstawię wady i zalety segment routingu oraz jak konfigurować go w sieci Brown Field we współpracy z LDP. Poruszę również temat: włączania TI-LFA, który zapewnia protekcję 100% prefixów bez względu na topologię sieci, uruchamiania serwera PCE i zestawiania sesji BGP-LS do PCE (Path Computation Element), konfiguracji tunneli SR z trasami definiowanymi explicit, dynamic, PCE, jak również Disjoint Node/Path/Srlg czy Metryki IGP/TE oraz przedstawię nowatorską technologię ODN (On Demand NextHop), a na koniec opowiem o nowym podejściu do definiowania tuneli SR tzw POLICY. Prezentacja będzie oparta na przykładach konfiguracji w systemach IOS XR i XE.
PLNOG14: Nowości w protokole BGP, optymalizacja routingu na brzegu sieci - Łu...PROIDEA
Łukasz Bromirski - Cisco Systems
Language: Polish
Nowości w protokole BGP i optymalizacja routingu BGP na brzegu sieci
Zarejestruj się na kolejną edycję PLNOG: krakow.plnog.pl
PLNOG16: IP/MPLS for Fixed and Mobile Convergence, Kevin WangPROIDEA
This document discusses IP/MPLS and MPLS-TP solutions from Raisecom for fixed and mobile network convergence. It introduces the iTN8800 platform and iTN200 and RAX700 series CPE devices, which support IP/MPLS, MPLS-TP and carrier Ethernet technologies. The document also outlines their applications such as business service access, mobile backhaul, legacy network migration and interworking IP/MPLS with MPLS-TP networks.
PLNOG16: DDOS SOLUTIONS – CUSTOMER POINT OF VIEW, Piotr WojciechowskiPROIDEA
This document provides an overview of DDoS solutions from a customer perspective. It discusses different types of DDoS attacks and the need for multiple protection tools. It describes two common deployment models for scrubbing centers: DNS redirection and BGP. AlwaysOn protection is generally better than on-demand AlwaysAvailable protection. While scrubbing services can mitigate large attacks, they are not a complete solution and other measures are needed to deal with initial attack waves. Preparation including a response team and plan can help organizations effectively respond to DDoS attacks.
PLNOG15: BGP New Advanced Features - Piotr WojciechowskiPROIDEA
This document provides an overview of new advanced BGP features including BGP Graceful Shutdown, BGP Additional Paths, support for multiple sourced paths per redistributed route, BGP Accumulated IGP Metric, and BGP FlowSpec. It describes each feature, how it works, and its configuration. The presenter is a senior network engineer and CCIE with experience designing networks and leading a large Cisco community.
PLNOG15: Is there something less complicated than connecting two LAN networks...PROIDEA
The document discusses connecting virtual and physical infrastructure through virtual networking technologies like VXLAN. It describes how VXLAN uses encapsulation to transport layer 2 frames over a layer 3 network and provides logical network isolation through a VXLAN Network Identifier. It also summarizes options for bridging between virtual and physical networks through x86-based or hardware VTEPs and how they can be used to integrate non-virtualized workloads. OVSDB integration is also described as a way for hardware VTEPs to connect to logical networks without requiring multicast in the underlay.
PLNOG16: Ochrona AntiDDoS, lokalnie oraz w chmurze, Paweł WachełkaPROIDEA
The document discusses Huawei's hybrid anti-DDoS solution, including on-premise and cloud-based mitigation capabilities. It provides an overview of common DDoS attack types and sources, describes how to simulate attacks, and shows test results of stresser tools. The solution uses detection centers, cleaning centers, and a management center. It also leverages Huawei's global network of cloud-based scrubbing centers and partnerships to provide cloud mitigation services.
PLNOG16: Milion użytkowników IPv6 na polskim rynku mobilnym, Tomasz KossutPROIDEA
Orange Poland has over 1 million customers using IPv6-only mobile connections. They have implemented an IPv6-only solution for smartphones and mobile devices using CLAT, PLAT, DNS, and NAT64 to allow access to IPv4 content. Stats show growing usage of native IPv6 flows, especially for Google and Facebook services which account for about 60% of total traffic. Analysis of DNS data found the top domains were mostly Google, Facebook, and YouTube, showing these companies' dominance on the internet. The document discusses ensuring good IPv6 connectivity and latency to major sites to avoid issues.
PLNOG16: VXLAN Gateway, efektywny sposób połączenia świata wirtualnego z fizy...PROIDEA
The document discusses VXLAN gateways and how they connect virtual and physical networks. It provides details on Juniper QFX5100 VXLAN gateways and their integration with NSX, including how they dynamically learn virtual networks via OVSDB, handle multidestination traffic, and store MAC address tables. The document also shows configurations and statuses when viewing the integration through NSX and Network Director management tools.
PLNOG16: Public IX is the tip of the Internet Iceberg. The 9:1 PNI rule, Mart...PROIDEA
The document discusses key considerations for peering planning and implementation. It recommends having a blend of transit, public peering, and private peering according to traffic volumes. Specifically, it suggests planning for 20%+ annual traffic growth, including peering as part of the IP traffic growth strategy, understanding the benefits of campus peering over distributed peering models, and expecting private peering traffic to outgrow public peering traffic over the long run. The document uses Equinix as an example, highlighting their large ecosystem of networks that can help lower IP transit costs and support robust public and private peering options.
PLNOG15 :DDOS Attacks & Collateral Damage. Can we avoid it? Asraf AliMarta Pacyga
This document discusses DDoS attacks, including the types of attacks, their impact on victims, and best practices for network operators. It covers TCP exhaustion attacks, volumetric attacks, reflective amplification attacks that exploit protocols like DNS and NTP, and application layer attacks. These attacks can directly impact content providers and indirectly impact service providers and cloud providers. The document recommends network operators deploy anti-spoofing, scan for and mitigate abusable services, and utilize carrier DDoS protection services to help prevent collateral damage from attacks.
PLNOG16: Usługi w sieciach operatorskich, Marcin AronowskiPROIDEA
This document discusses network services in carrier networks. It begins with an agenda for a 168 slide, 40 minute presentation on multiservice IP next-generation networks (NGN). It then discusses concepts like quality of service (QoS), multicasting, and TCP performance in the context of modern networking technologies like HTTP/2, over-the-top services, and 100 gigabit Ethernet. The rest of the document provides details on implementing QoS, guidelines for QoS for video, the history and uses of multicasting, and fundamentals of multicast addressing.
PLNOG16: Bezpieczeństwo w sieci operatora, Sebastian PasternackiPROIDEA
The document discusses network security training that includes an exercise on responding to threats and mitigating distributed denial-of-service (DDoS) attacks, as well as configuring security tools like Control Plane Policing (CoPP) and remote triggered black hole (RTBH) routing.
PLNOG19 - Jakub Słociński - Wieloprocesorowa platforma x86 a wydajny routing ...PROIDEA
W trakcie wykładu poruszony zostanie temat użycia platform serwerowych na potrzeby wydajnego routingu pakietów. Mocne i słabe strony zastosowania architektury jedno- czy wieloprocesorowej pod kątem konfiguracji sieciowej, jej wypływ na wydajność oraz skalowalność rozwiązania.
Prezentacja dotycząca wydajnego przetwarzania ruchu IP na PC wygłoszona podczas IT Conference na WAT (http://itacademicday.azurewebsites.net/), listopad 2015.
(Polish only) Talk regarding effective IP traffic processing on x86 platforms, given at IT Academic Day / Military University of Technology in Warsaw, November 2015.
PLNOG 13: Piotr Okupski: Implementation of Wanguard software as a protection ...PROIDEA
Piotr Okupski – technical director at the Association of Cable Television “TV-SAT 364″ in Lodz. A graduate of the University of Łódź, Faculty Informatics and Econometrics,MA in Computer Science and Econometrics. He started his work at ATMAN as NOC operator. He has over 11 years of experience as administrator of Linux systems, 9 years experience in network equipment – Cisco and Juniper. Since 2008 involved heavily in the network, STB and headend aspects of digital television (IPTV).
Topic of Presentation: Implementation of Wanguard software as a protection against DDOS attacks
Language: Polish
Abstract: The presentation will be about one of the cheapest commercial solutions to protect against DDOS attacks – Wanguard (http://www.andrisoft.com/software/wanguard). I will present the implementation of Remotely Triggered Blackhole Filtering (RTBF) using the BGP protocol with an example of BGP policy for Juniper MX. In addition to the overall system configuration examples I will also describe the important points like Linux tuning that are necessary to achieve high system performance at minimum cost. The presentation is directed to small and medium-sized operators.
Radosław Ziemba: GPON or xWDM as technology for connecting business subscribesPROIDEA
Radosław Ziemba – Manager in the Network Device Department in Elmat since 2009. His main interest lies in the areas of FTTH and xPON networks, optical transmission and IPTV. He is also responsible for trainings and deployment of G-EPON/GPON equipment for customer in Europe.
Topic of Presentation: GPON or xWDM as technology for connecting business subscribes
Language: Polish
Abstract: Which FTTH technology is ready for business subscribers? In these presentation we would like answer on this question by comparing technology like GPON, P2P/AON, CWDM or there mix to needs coming from SMB clients. We will as well underline aspect of CAPEX, OPEX as well as like satisfaction of end customer demands from offered services.
PLNOG 13: Radosław Ziemba: GPON or xWDM as technology for connecting business...PROIDEA
Radosław Ziemba – Manager in the Network Device Department in Elmat since 2009. His main interest lies in the areas of FTTH and xPON networks, optical transmission and IPTV. He is also responsible for trainings and deployment of G-EPON/GPON equipment for customer in Europe.
Topic of Presentation: GPON or xWDM as technology for connecting business subscribes
Language: Polish
Abstract: Which FTTH technology is ready for business subscribers? In these presentation we would like answer on this question by comparing technology like GPON, P2P/AON, CWDM or there mix to needs coming from SMB clients. We will as well underline aspect of CAPEX, OPEX as well as like satisfaction of end customer demands from offered services.
7. 7
• iBGP wymaga połączeń w pełnej siatce
• Łącznie – n*(n-1)/2 sesji iBGP
• Dwa rozwiązania:
Route Reflectory
Konfederacje
0
2000
4000
6000
8000
10000
12000
0 50 100 150 200
Sesje
Sąsiedzi
8. 8
• RR to speaker iBGP który odbija trasy nauczone przez
speakerów iBGP do innych – nazywanych klientami RR
• Pełna siatka zamienia się w topologię hub & spoke
• RR jest hubem
R1 R2 R3 R1 R2 R3
LUB
router bgp 65002
neighbor R1 route-reflector-client
neighbor R2 route-reflector-client
neighbor R3 route-reflector-client
router bgp 65002
no bgp client-to-client reflection
neighbor R1 route-reflector-client
neighbor R2 route-reflector-client
neighbor R3 route-reflector-client
Klienci RR są połączeni
Klienci RR są
“normalnymi”
speakerami iBGP
RR RR
RR
Odbijanie tras
klient<>klient można
wyłączyć
9. 9
RR & klient RR
RR
iBGP
eBGP
Prefiks od sąsiada eBGP
RR wysyłą prefiks do
klientów i nie-klientów (oraz
innych sąsiadów eBGP)
Prefiks od klienta RR
RR odbija prefiks do
klientów i wysyłą go do nie-
klientów (w tym innych
sąsiadów eBGP)
Prefiks od nie-klienta
RR odbija prefiks do
klientów (oraz innych
sąsiadów eBGP)
10. 10
RR a reszta topologii
10
R1 R2 R4R3
nie-klienci
klienci
R5
Dowolny router może
mieć zapiętą sesję
eBGP
klaster klaster
AS 100AS 101
RR RR
iBGP
eBGP
11. 11
• Więcej RR = większa redundancja
Ale i więcejkonfiguracji,więcejsesji, więcej pamięci
• Ogólnie przyjęty i spotykany w sieciach model:
2 RR dla każdejusługi(lub zestawu usług)
Np.:
2 RR dla IPv4
2 RR dla VPNv4
2 RR dla IPv6
...
13. 13
• Tam gdzie wymagana jest redundancja ale w skali – stosuje się
klastry (z dwoma RR per klaster)
• Klaster = RR i jego klienci
R1 R2 R4R3
R5
RR RR RR RR
Klient może mieć sesjęz RR z różnychklastrów
Pełna siatkapomiędzy
RRami i jego nie-klientami
powinna być ograniczona
14. 14
• RR1 ma tylko 1 ścieżkę dla prefiksów od RRC2
RR1 i RR2 mają ten sam Cluster-ID
• Jeśli jeden z linków od RR do jego klienta padnie
iBGP nadalstoi – sesja zapięta między loopbackami
• Jeśli zastosowalibyśmy różne Cluster-ID
RR1 przechowuje ścieżkę z RR2
…co kosztuje więcejpamięcii trochę CPU
...ale może utrzymać dziękitemu trasę zapasową
• “To jak mam robić”?
Różne cluster-ID
Trochę dodatkowego obciążenia na RR, widoczność zapasowychtras
Ten sam cluster-ID
Mniejszeobciążenie, tylkojedna, najlepsza trasa
RRC1 RRC2
RR1 RR2
15. 15
• RR1 i RR2 mają różne cluster-ID
RRC1 RRC2
RR1 RR2
AS Path: {65000}
AS Path: {65000}
AS Path: {65000}
Originator-ID: RRC1
Cluster-List: {RR1}
AS Path: {65000}
Originator-ID: RRC1
Cluster-List: {RR1, RR2}
Wykryta pętla
16. 16
• Łańcuch RRów tak aby zachować pełną
siatkę pomiędzy RRami a ich nie-klientami w
miarę ograniczoną
• Grupa RRów staje się klientam innych RRów
• Topologia iBGP powinna podążać za
topologią fizyczną*
• Ilość warstw (tier) w zasadzie
nie ma ograniczeń
Tier 1
Tier 2
Tier 3
RR & RR client
RR
18. 18
• ProtokółBGP4 specyfikuje wybóri propagację jednejnajlepszejścieżkidla
każdego prefiksu
• W przypadku użycia RRów,tylko najlepszazostaniewysłanaz RR do
speakerów BRP
„Multipath” nie rozwiązuje tego problemu
• Takie zachowanie prowadzido wielu ograniczeń– w szczególnościzwiązanych
z redundancją
NH: PE1, P: Z
NH: PE2, P: Z
P:Z
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2
P: Z
Path 1: NH: PE1, best
NH: PE1, P: Z
Wyjściowy PE nie uczy sie drugiej
ścieżki
CE1
PE1
PE2
RR PE3 CE2
19. 19
• Konwergencja
BGP Fast Convergence (2 i więcejścieżek w lokalnejbazie BGP)
BGP PIC Edge (2 i więcejścieżek gotowych w warstwie forwardingu)
• Rozkładanie ruchu na wiele ścieżek
ECMP
• Umożliwienie routingu wg. schematu „gorącego kartofla”
W domyślnejkonfiguracjiroutery brzegowe mogą nie znać najlepszejścieżki
• Zapobieganie oscylacjom
Lokalna trasa zapasowazapewnia lokalnąmożliwość podjęcia obsługiruchu
bez czekania/opierania się o iBGP
Zapobiegamy oscylacjitras powstających gdy trasy porównywane są
pomiędzyróżnymiMEDami– tam gdzie RR lub konfederacjaukrywa część
tras (jako nie najlepszych)
19
20. 20
• Unikalne RD w MPLS VPN
• BGP Best External
• BGP Add-Path
• BGP shadow RR / session
• BGP Optimal Route Reflection
Co mamy do dyspozycji?
20
21. 21
• Unikalny RD dla VRFów à unikalne NLRI VPNv4/v6
• RR wykonuje algorytm najlepszej ścieżki dla dwóch różnych adresów
• Rekomendowane rozwiązanie dla MPLS-VPN
Z
NH:PE2, P:Z/RD2
NH:PE3, P:Z/RD3
NH:PE2, P:Z/RD2
NH:PE3, P:Z/RD3
VRF blue
Prefix Z
via PE2
via PE3
PE1
RR
PE2
PE3
22. 22
• Przy wykorzystaniu tej funkcji PE2 nadal rozgłosi do PE1 (lub RR)
swoją trasę mimo gorszych atrybutów (których potencjalnie nauczy się
od PE3)
• PE1 i PE3 mają po dwie ścieżki
Prefix Z
Via PE2, LP 100
Via PE3, LP 200
Z
NH:PE3, P:Z
LP 200
NH:PE2, P:Z
LP100
PE2
PE3
PE1
23. 23
csr1000v(config-router)# address-family ipv4 unicast vrf test1
csr1000v(config-router-af)# bgp advertise-best-external
csr1000v# show vrf test1 detail
VRF test1 (VRF Id = 1); default RD 400:1; default VPNID <not set>
Interfaces:
Se4/0
Address family ipv4 (Table ID = 1 (0x1)):
Export VPN route-target communities
RT:100:1 RT:200:1 RT:300:1
RT:400:1
Import VPN route-target communities
RT:100:1 RT:200:1 RT:300:1
RT:400:1
No import route-map
No export route-map
VRF label distribution protocol: not configured
VRF label allocation mode: per-prefix
Prefix protection with additional path enabled
Address family ipv6 not active.
24. 24
csr1000v(config-router)# address-family ipv4 unicast vrf test1
csr1000v(config-router-af)# bgp advertise-best-external
csr1000v# show ip route vrf test1 repair-paths
Routing Table: vpn1
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
[…]
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.1.1.0/24 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
B 10.1.1.1/32 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.1.2.0/24 is directly connected, Ethernet0/0
L 10.1.2.2/32 is directly connected, Ethernet0/0
B 10.1.6.0/24 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
25. 25
• Add-Path rozgłosi od 2 do X dodatkowych ścieżek
• Oczywiście router odbierający ścieżki (RR, PE) musi obsługiwać to
rozszerzenie (capability) na etapie zestawiania sesji BGP
NH:PE2, P:Z AP 1
NH:PE2, P:Z
Prefix Z
via PE2
via PE3NH:PE3, P:Z AP 2
NH:PE3, P:Z
Z
https://tools.ietf.org/html/draft-ietf-idr-add-paths-10*
router bgp 1
address-family ipv4
bgp additional-paths select best 2
bgp additional-paths send
neighbor PE1 advertise additional-paths best 2
router bgp 1
address-family ipv4
bgp additional-paths receive
bgp additional-paths install
PE1
RR
PE2
PE3
26. 26
• Draft IETF definiuje parę różnych rodzajówAdd-x-Path:
Add-n-path:RR wykonaobliczenia dla wszystkich tras i wyśle N najlepszych
do PE
Przykładowezastosowanie: trasa główna + N tras zapasowych
Add-all-path:RR wykona obliczenietylko dla pierwszejścieżki,ale i tak
wyśle kompletdo PE
Przykładowezastosowanie: routing ‘hot potato’ mimo obecności RR, ECMP load-
balancing w DC
Add-all-multipath+backup:RR wykona obliczenie dla najlepszejścieżki,
wyśle wszystkie trasyo tym samym koszcie i dodatkowo jedną zapasową do
PE
Przykadowezastosowanie: ECMP load-balancing w DC
27. 27
router bgp 1
address-family vpnv4
additional-paths install backup ! stare polecenie
additional-paths advertise
additional-paths receive
additional-paths selection route-policy BGPAddPathX
Konfiguracja przykładowa
route-policy BGPAddPath1
if community matches-any (1:1) then
set path-selection backup 1 install
elseif destination in (10.1.0.0/16, 10.2.0.0/16) then
set path-selection backup 1 advertise install
endif
route-policy BGPAddPath2
set path-selection all advertise
route-policy BGPAddPath3
set path-selection multipath advertise
Przykładowe polityki RPL
28. 28
• Proste wdrożenie – jeden dodatkowy RR na klaster
• RR2 rozgłasza drugą najlepszą ścieżkę, inną niż ta, którą
rozgłasza RR1
NH: PE1, P: Z
NH: PE2, P: Z
P:Z
NH: PE2, P: Z
shadow RR
router bgp 1
address-family ipv4
bgp additional-paths select backup
neighbor 10.100.1.3 advertise diverse-path backup
RR1
PE1
PE2
CE1
PE3
CE2
RR2
P: Z
Path 1: NH: PE1
Path 2: NH: PE2
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2, 2nd best
NH: PE1, P: Z
29. 29
RR(config-router-af)# bgp bestpath igp-metric ignore
shadow RR
RR i Shadow RR są w tej samej lokalizacji (z
punktu widzenia topologii sieci – ten sam
koszt dla IGP do prefiksu
Nie trzeba wyłączyć sprawdzania
metryki IGP
RR i Shadow RR znajdują się w różnych
lokalizacjach
Note: trzeba wyłączyć sprawdzenie metryki
IGP – oba RR liczą tą samą metrykę (i
shadow RR nie wybierze przez przypadek
tej samej ścieżki)
(wszystkie linki mają ten sam koszt dla IGP)
ten sam dystans (IGP)
P
RR1
RR2
PE1
PE2
P:Z
shadow RR
PE1
P
RR1
RR2PE2
P:Z
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2, 2nd best
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2
P: Z
Path 1: NH: PE1, 2nd best
Path 2: NH: PE2, best
RR2 advertises
same path as RR1 !
30. 30
• Proste wdrożenie – wymaga kodu z różnymi ścieżkami tylko na RR
Sesje zapinane są z różnychadresów loopback
Druga sesjarozgłaszainną ścieżkę
NH: PE1, P: Z
NH: PE2, P: Z
CE1
P:Z
NH: PE1, P: Z
NH: PE2, P: Z
PE1
PE2
CE1 CE2RR PE3
P: Z
Path 1: NH: PE1, best
Path 2: NH: PE2, 2nd best
Uwaga: druga sesja z RR do klienta RR (PE3) ma
skonfigurowane polecenie diverse-path tak aby rozgłosić
drugą ścieżkę jako najlepszą
P: Z
Path 1: NH: PE1
Path 2: NH: PE2
31. 31
• W tradycyjnym routingu BGP o wyborze najlepszej ścieżki do prefiksu
przez RR decyduje koszt IGP do rozgłaszającego go PE
RR preferuje PE bliższe kosztem PE dalszych od siebie (w rozumieniu kosztu
IGP)
• Umieszczenie RR w jednym miejscu topologii pomaga, ale wraz z
popularyzacją wirtualnych RR i narzędzi do ich automatycznego
“ustawiania” problem rośnie
“one są wszędzie!”
• BGP ORR pomaga rozwiązać problem routingu wg. koncepcji “gorącego
ziemniaka” wszędzie tam, gdzie topologia IGP nie podąża za
umiejscowieniem wszystkich RR
34. 34
• Trzy sposoby:
AddPath (już omówione)
ORR z punktu widzenia RR (opcja #2)
ORR wspomagane przez klienta RR (opcja #3)
• To nadal draft:
https://tools.ietf.org/id/draft-ietf-idr-bgp-optimal-route-reflection-10.txt
35. 35
• RR wykonuje przeliczenie SPF wielokrotnie – raz dla każdego klastra
lub klienta RR
Wynik przechowywany jest w osobnej bazie RIB
• Modyfikujemy mechanizm wyboru najlepszej ścieżki – dodając do
algorytmu najlepszą ścieżkę per klaster/klienta RR
• Rozgłoszenie BGP zawiera najlepszą ścieżkę dla tego klastra/klienta
RR
• Zaleta:
Zmiany dotyczątylkoRR, nie zmieniamy konfiguracji/oprogramowaniana klientach RR
• Wada
Istotna zmiana mechanizmu wyboru ścieżki
Nowy moduł obsługi wielokrotnego przeliczaniaSPF
37. 37
• RR pobiera metrykę IGP od klienta RR za pomocą:
NH SAFI (draft-varlashkin-bgp-nh-cost-02) lub
BGP-LS (draft-ietf-idr-ls-distribution-03)
• Ponownie – RR przechowuje metryki IGP do klientów RR w osobnej
tablicy RIB
• Modyfikujemy mechanizm wyboru najlepszej ścieżki – dodając do
algorytmu najlepszą ścieżkę per klaster/klienta RR
• Rozgłoszenie BGP zawiera najlepszą ścieżkę dla tego klastra/klienta
RR
• Zalety:
RR nie musi wielokrotnie uruchamiać algorytmuSPF
• Wady:
Wymaga zmian po stronieklientów RR (…ale może to implementacja programowa?)
Ten sposób działania może mieć negatywny wpływ na czas konwergencji
39. 39
• Dedykowana funkcjonalność dla serwerów tras (nie RR!)
• Każda grupa klientów zostaje zamknięta w “kontekście”
• Upraszcza znakomicie konfiguracje typu:
“temu klientowidajemy ISP1 i ISP2, a temu tylko ISP3”
• Jeden z autorów draftu jest dzisiaj z nami J
https://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-08
https://tools.ietf.org/html/draft-ietf-grow-ix-bgp-route-server-operations-05
44. 44
• Wiele prywatnychASN
• Jednolityka polityka
przydziału podsieci IP oraz
VLANów
• Wykorzystane wiele
rozszerzeń BGP:
AS_PATH multipath relax
Allow AS in
Fast eBGP fall-over
Remove Private-AS
https://www.nanog.org/meetings/nanog55/presentations/Monday/Lapukhov.pdf
45. 45
WAN
• ISIS służy do zbudowania
matrycy dla DC
• MP-BGP służy do rozgłaszania
adresów hostów i podsieci
wewnątrz matrycy oraz sieci
zewnętrznych
…ale także np. IP multicastu
• MP-BGP zoptymalizowane do
szybkiego rozgłaszania setek
tysięcy prefiksów
MP-BGP
RR RR
http://www.cisco.com/c/en/us/solutions/collateral/data-center-
virtualization/application-centric-infrastructure/guide-c07-733236.html
46. 46
PLNOG 0x0F, Kraków, 28.09.2015
(prezentację sponsoruje RFC 4271 i 4456)
Łukasz Bromirski
CCIE #15929,CCDE #2012::17
Cisco Systems Polska