Inhoud

Inleiding

Achtergrondinformatie

Netwerkdiagram

Theorie

IOS XR-implementatie

Configureren

Configuratievoorbeeld

MPLS traffic engineering op Root-router

Problemen oplossen

Conclusie

Inleiding

Dit document beschrijft hoe de routing kan worden beïnvloed wanneer er een of meer routeswitches (RR’s) in het netwerk zijn geïnstalleerd om een volledig netwerk tussen iBGP-routers te voorkomen.

Achtergrondinformatie

Stap 8 in het BGP best path Selectie algoritme is om de voorkeur te geven aan het pad met de laagste IGP metrieke naar de BGP volgende hop. Dus als alle stappen vóór stap 8 gelijk zijn, kan stap 8 de beslissende factor zijn op wat het beste pad op de RR is. De IGP-kosten van de RR naar de advertentie-iBGP-router worden vervolgens bepaald door de plaatsing van de RR. Standaard geeft de RR alleen de beste route naar de klanten door. Afhankelijk van waar de RR wordt geplaatst, kunnen de IGP kosten aan de advertentierrouter kleiner of groter zijn. Als alle IGP kosten van de paden hetzelfde zijn, zal dit waarschijnlijk uitmonden in het aanbreken van de reclamerouter met de laagste BGP router-ID.

Netwerkdiagram

De routers PE1, PE2 en PE3 adverteren het voorvoegsel 172.16.2.0/24. Als alle IGP kosten van de links gelijk zijn, dan ziet RR het pad van PE1, PE2 en PE3 met een IGP-kosten van 2. Uiteindelijk kiest RR het pad van PE1 als het beste omdat het de lagere BGP-router ID heeft. Dit is stap 11 in het BGP best path Selectie algoritme. Het resultaat is dat alle PE-routers, met inbegrip van PE4, PE1 als de egress PE-router voor het voorvoegsel 172.16.2.0/24 zullen kiezen. Vanuit het standpunt van PE4, is het kortere IGP-pad naar een egress PE-router het pad naar PE3, met een IGP-kosten van 1. De IGP-kosten voor elke andere PE-router zijn 2. Voor veel netwerken is het feit dat het verkeer op de kortst mogelijke manier door het transitnetwerk wordt vervoerd is belangrijk. Dit staat bekend als hot-aardappel routing.

Er is een andere mogelijke reden voor RR om het beste pad uit PE1 te hebben gekozen. Als in het beeld de kosten van het Protocol van de Gateway van het Binnenlandse Zaken (IGP) van de verbinding P2-PE3 10 zijn en alle andere koppelingen nog steeds een IGP-kosten van 1 hebben, dan zou de RR het pad uit PE3 niet als het beste kiezen, zelfs niet als PE3 de laagste BGP-router had.

Als de beheerder van dit netwerk de routing met hot-aardappelen wil hebben, moet er een mechanisme zijn zodat wanneer er RR's in het netwerk zijn, de ingangsrouter nog steeds het pad naar de dichtstbijzijnde graafrouter in het iBGP-netwerk kan leren. Dit kan worden bereikt met de BGP-functie Add Path. Met die functie moeten de R's en de grensrouters echter een recentere code hebben die de functie begrijpt. Met de functie van de BGP Optimal Route Reflectie is dit geen vereiste. Deze eigenschap zal RR in staat stellen om het beste pad naar de ingress BGP grens router te verzenden, gebaseerd op wat volgens RR het beste pad is vanuit het perspectief van de ingesloten BGP-router.

Een andere oplossing die hot-aardappel routing mogelijk maakt wanneer RR's worden ingezet, is de on-line plaatsing van RR's. Deze RR's zijn geen specifieke RR's, die alleen BGP en het IGP uitvoeren. Deze inline RR's bevinden zich in het verzendingspad en worden in het netwerk geplaatst zodat zij hun eigen reeks RR-klanten hebben, zodat zij de beste route naar elke RR-client kunnen weergeven, wat ook de beste route is vanuit het perspectief van die RR-cliënt.

Zoals in deze afbeelding wordt getoond, worden de R's in het netwerk geplaatst zodat ze een kleine reeks naburige RR-clients kunnen gebruiken. Vanwege het netwerkontwerp ontvangen de RR-klanten de beste paden die vanuit hun oogpunt de beste paden zijn, vanuit de RR's, zodat er een hottomatenrouting in het netwerk kan zijn.

Theorie

BGP-optimale routereflectie wordt beschreven in IETF-conceptIntra-ietf-idr-bgp-optimale reflectie.

De BGP-oplossing voor optimale routereflectie stelt de RR in staat een specifiek beste pad naar een specifieke BGP-grensrouter te verzenden. RR kan ervoor kiezen een ander beste pad naar verschillende BGP-grensrouters of een set grensrouters te verzenden. De grensrouters moeten RR-clients van de RR zijn. Het doel is dat elke inkomende BGP-grensrouter een andere uitgang of een grotere BGP-router voor hetzelfde voorvoegsel kan hebben. Als de ingress border-router het verkeer altijd naar de gesloten AS-exit-router kan doorsturen, dan maakt dit de routing van hot-aardappelen mogelijk.

Het probleem is dat de RR normaal slechts het zelfde beste pad naar elke BGP grensrouter verstuurt, wat de routing van hot-aardappelen voorkomt. Om dit op te lossen, hebt u de RR nodig om verschillende beste paden voor hetzelfde voorvoegsel te kunnen berekenen afhankelijk van de ingress BGP-grensrouter. De beste padberekening op de RR wordt uitgevoerd op basis van de positie van de ingress BGP-grensrouter, vandaar dat de RR de BGP-best path-berekening uitvoert vanuit het perspectief van de ingangsrouter. De RR die dit alleen kan doen, is de RR die het volledige beeld van de topologie van het netwerk heeft vanuit het IGP-perspectief waar de RR- en ingress-grensrouter(s) zich bevinden. Om aan dit vereiste te zijn voldaan, moet IGP een verbinding-staat routingprotocol zijn.

In dat geval kan RR een berekening van het Kortste Pad Eerste (SPF) met de ingress grens router als wortel van de boom uitvoeren en de kosten voor elke andere router berekenen. Op deze manier zullen de kosten van de ingress border-router naar alle andere routers bekend zijn. Deze speciale SPF-berekening met een andere router als wortel, wordt aangeduid als Omgekeerde SPF (rSPF). Dit kan alleen worden gedaan als de RR alle BGP-paden van alle BGP-grensrouters leert. Er zouden evenveel afzonderlijke fondsen kunnen worden opgericht als er RR-cliënten zijn. Hierdoor wordt de CPU-lading enigszins verhoogd op de RR.

De oplossing maakt het mogelijk dat de best path-berekening wordt gebaseerd op het BGP best path-Selectie algoritme, waardoor de RR het beste pad plukt vanuit het perspectief van de ingress border-router naar het pad wordt verstuurd. Dit betekent dat het beste pad wordt gekozen op basis van de kortste IGP-kosten voor de BGP volgende hop. De oplossing maakt het ook mogelijk om de beste route te kiezen op basis van een of ander geconfigureerd beleid. De ingress border-routers kunnen hun beste paden kiezen op basis van een of ander ingesteld beleid, en niet op basis van de laagste IGP-kosten. De oplossing staat de RR toe om de optimale routereflectie op de IGP kosten (plaats op het netwerk) of op een of ander gevormd beleid, of beiden te implementeren. Als beide worden ingezet, dan wordt het beleid eerst toegepast en dan zal de op IGP gebaseerde optimale routereflectie op de resterende paden voorkomen.

IOS XR-implementatie

De IOS-XR implementatie staat tot drie basisknooppunten voor de rSPF berekening toe. Als u veel RR-klanten in één update-groep hebt, is er geen behoefte aan één rSPF-berekening per RR-client als die RR-klanten hetzelfde beleid en/of dezelfde IGP-kosten hebben voor de verschillende BGP-grensrouters. Dit laatste betekent doorgaans dat de RR-cliënten medegevestigd zijn (waarschijnlijk in dezelfde POP zijn). Als dat het geval is, hoeft u niet elke RR-client als wortel te configureren. De IOS-XR implementatie staat toe om drie, de primaire, de secundaire en de tertiaire wortel, per reeks van RR cliënten, voor overtollige doeleinden te vormen. Om de BGP ORR optie op een RR-client van toepassing te laten zijn, moet die RR-client zo zijn geconfigureerd dat hij deel uitmaakt van een ORR-beleidsgroep.

De BGP ORR optie is per adresfamilie ingeschakeld.

Er is een link-statenprotocol vereist. Het kan OSPF of IS-IS zijn.

IOS XR implementeert alleen de BGP ORR optie op basis van de IGP-kosten voor de BGP volgende hop en niet op basis van een of ander ingesteld beleid.

De BGP-peers met hetzelfde outbound-beleid worden in dezelfde update-groep geplaatst. Dit is meestal het geval voor iBGP op de RR. Wanneer de optie BGP of R is ingeschakeld, worden de peers uit verschillende ORR-groepen in verschillende update groepen geplaatst. Dit is logisch, omdat de updates die vanuit de RR naar de RR-cliënten in verschillende BGP-ORR-groepen worden gestuurd anders zullen zijn, omdat de BGP-beste route anders is.

Het resultaat van de rSPF-berekeningen wordt opgeslagen in een database.

ORRSPF is de nieuwe component in IOS-XR die voor de BGP ORR optie nodig is. ORRSPF zorgt voor:

1. Het verzamelen van de verbinding-staat informatie en het onderhouden van het Link-State gegevensbestand

2. RSVP's uitvoeren en de NBP's onderhouden per beleidsgroep

3. De prefixes van de SPT naar het RIB downloaden met de volgende parameters

De database krijgt de link-state informatie direct van de link-staat IGP of van BGP-LS.

De rSPF-berekeningen resulteren in een topologie die het kortste pad van de RR-client naar een andere router in het gebied/niveau toont.

De routes die van elke router in de topologie hangen worden opgeslagen in een speciale RIB tabel voor het ORR groepsbeleid en per AFI/SAFI. Deze tabel wordt gemaakt door RSI. De tabel wordt bevolkt door de routes die door de SPF's worden berekend met de primaire wortel als de wortel. Als de primaire wortel niet beschikbaar wordt, dan is de secundaire wortel de wortel en bevolkt de routes in de ORR RIB tabel. Hetzelfde geldt voor de tertiaire wortel.

Configureren

De minimale configuratie was nodig:

1. ORR moet worden ingeschakeld voor de adresfamilie van BGP, voor specifieke groepen van BGP-buren

2. Voor elke groep BGP-buren moet minimaal één wortel worden geconfigureerd. Optioneel kan een secundaire en tertiaire wortel worden ingesteld.

3. De herverdeling van de ORR-routes van het IGP naar het BGP moet mogelijk worden gemaakt.

Configuratievoorbeeld

Zoals in het eerste beeld wordt getoond, is RR een IOS-XR router met de BGP ORR optie.

Alle andere routers voeren IOS uit. Deze routers hebben geen BGP ORR-functie.

PE1, PE2, en PE3 adverteren het voorvoegsel 172.16.2.0/24 in AFI/SAFI 1/1 (IPv4-éénvoud). RR ligt even dicht bij PE1 en PE2 dan bij PE3. De IGP kosten van alle links zijn 1. Het beste pad voor dit voorvoegsel is die met R1 als volgende-hop vanwege de laagste BGP router-ID.

RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0/24 bestpath-compare

BGP routing table entry for 172.16.2.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 34          34

Last Modified: Mar  7 20:29:48.156 for 11:36:44

Paths: (3 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Local, (Received from a RR-client)

10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 34

best of local AS, Overall best

Path #2: Received by speaker 0

Not advertised to any peer

Local, (Received from a RR-client)

10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 6, version 33

Higher router ID than best path (path #1)

Path #3: Received by speaker 0

ORR bestpath for update-groups (with more than one peer):

0.1

Local, (Received from a RR-client)

10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 7, version 34

Higher IGP metric than best path (path #1)

PE4 krijgt het pad met PE1 als volgende-hop. Er is dus geen 'hot-chips'-routing voor PE4.

Als u een routering van hete aardappelen op PE4 wilt hebben, dan voor de voorfixes die worden geadverteerd met PE1, PE2 en PE3 (bijvoorbeeld het voorvoegsel 172.16.2.0/24), dan moet PE1 PE3 als exitpunt hebben. Dit betekent dat de weg naar PE4 de weg moet zijn met PE3 als volgende-hop. We kunnen de RR de route laten sturen met volgende-hop-PE3 naar PE4 met deze ORR-configuratie.

router ospf 1

distribute bgp-ls

area 0

interface Loopback0

!

interface GigabitEthernet0/0/0/0

network point-to-point

!

!

!

router bgp 1

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group 10.100.1.4

!

address-family vpnv4 unicast

!

neighbor 10.100.1.1

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.2

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.3

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.4

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group

route-reflector-client

!

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

!

Als IGP IS-IS is:

router isis 1

net 49.0001.0000.0000.0008.00

distribute bgp-ls

address-family ipv4 unicast

metric-style wide

!

interface Loopback0

address-family ipv4 unicast

!

!

interface GigabitEthernet0/0/0/0

address-family ipv4 unicast

!

!

!

Opmerking: De verbindingsstaat van de adresfamilie hoeft niet globaal of onder de BGP-buurman(en) te worden geconfigureerd.

MPLS traffic engineering op Root-router

RR moet het geconfigureerde worteladres in de IGP-database vinden om het rSPF uit te voeren. In ISIS, is de router-ID aanwezig in de ISIS database. Voor OSPF is er geen router-ID aanwezig in de OSPF LSA-apparaten. De oplossing is om de wortelrouters te laten adverteren met de MPLS-router-ID (Multi Protocol Label Switching) die het geconfigureerde worteladres op de RR aansluit.

Voor OSPF hebben de basisrouters extra configuratie nodig om BGP ORR-werk te maken. Er is een minimale MPLS TE-configuratie nodig op elke basisrouter om deze MPLS TE-router-ID te kunnen adverteren. De nauwkeurige minimale reeks commando's is afhankelijk van het besturingssysteem van de root router. De MPLS TE-configuratie op de root router moet de minimale configuratie voor MPLS TE hebben ingeschakeld, zodat OSPF de MPLS TE-router-ID adverteert in een ondoorzichtig gebied LSA (type 10).

Zodra RR een ondoorzichtig gebied LSA met MPLS TE router-ID heeft die het geconfigureerde adres van de wortelrouter aansluit, kan rSPF lopen en kan BGP op RR de optimale route adverteren.

De minimale configuratie nodig voor OSPF op de root router als deze een IOS-router is:

!

interface GigabitEthernet0/2

ip address 10.1.34.4 255.255.255.0

ip ospf network point-to-point

mpls traffic-eng tunnels

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

router-id 10.200.1.155

network 10.0.0.0 0.255.255.255 area 0

!

Let op:

- MPLS TE is ingeschakeld in het specifieke OSPF-gebied

- De MPLS TE-router-ID wordt ingesteld door het geconfigureerde basisadres van de RR aan te passen

- MPLS TE is ingesteld op ten minste één interface

- RSVP-TE hoeft niet te zijn geconfigureerd

- er hoeft geen MPLS TE zijn ingesteld op een andere router in het gebied

De minimale configuratie nodig voor OSPF op de root router als deze een IOS-XR router is:

!

router ospf 1

router-id 5.6.7.8

area 0

mpls traffic-eng

interface Loopback0

!

interface GigabitEthernet0/0/0/0

network point-to-point

!

!

mpls traffic-eng router-id 10.100.1.11

!

mpls traffic-eng

!

Als de bovenstaande configuratie op de root router is geïnstalleerd, dan moet RR de MPLS TE router-ID in de OSPF-database hebben.

RP/0/0/CPU0:RR#show ospf 1 database

OSPF Router with ID (10.100.1.99) (Process ID 1)

Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

10.1.12.1       10.1.12.1       1297        0x8000002b 0x006145 3

10.100.1.2      10.100.1.2      646         0x80000025 0x00fb6f 7

10.100.1.3      10.100.1.3      1693        0x80000031 0x003ba9 5

10.100.1.99     10.100.1.99     623         0x8000001e 0x00ade1 3

10.200.1.155    10.200.1.155    28          0x80000002 0x009b2e 5

Type-10 Opaque Link Area Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Opaque ID

1.0.0.0         10.200.1.155    34          0x80000001 0x00a1ad        0

1.0.0.3         10.200.1.155    34          0x80000001 0x0057ff        3

RP/0/0/CPU0:RR#show ospf 1 database opaque-area adv-router 10.200.1.155

OSPF Router with ID (10.100.1.99) (Process ID 1)

Type-10 Opaque Link Area Link States (Area 0)

LS age: 184

Options: (No TOS-capability, DC)

LS Type: Opaque Area Link

Link State ID: 1.0.0.0

Opaque Type: 1

Opaque ID: 0

Advertising Router: 10.200.1.155

LS Seq Number: 80000001

Checksum: 0xa1ad

Length: 28

MPLS TE router ID : 10.100.1.4

Number of Links : 0

LS age: 184

Options: (No TOS-capability, DC)

LS Type: Opaque Area Link

Link State ID: 1.0.0.3

Opaque Type: 1

Opaque ID: 3

Advertising Router: 10.200.1.155

LS Seq Number: 80000001

Checksum: 0x57ff

Length: 132

Link connected to Point-to-Point network

Link ID : 10.100.1.3      (all bandwidths in bytes/sec)

Interface Address : 10.1.34.4

Neighbor Address : 10.1.34.3

Admin Metric : 1

Maximum bandwidth : 125000000

Maximum reservable bandwidth global: 0

Number of Priority : 8

Priority 0 :                    0  Priority 1 :                    0

Priority 2 :                    0  Priority 3 :                    0

Priority 4 :                    0  Priority 5 :                    0

Priority 6 :                    0  Priority 7 :                    0

Affinity Bit : 0

IGP Metric : 1

Number of Links : 1

Merk op dat de MPLS TE router-ID (10.100.1.4) en de OSPF router-ID verschillend zijn.

PE4 heeft PE3 als volgende-hop voor het prefix (met de juiste IGP metriek aan de volgende-hop):

PE4#show bgp ipv4 unicast 172.16.2.0

BGP routing table entry for 172.16.2.0/24, version 37

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.3 (metric 2) from 10.100.1.8 (10.100.1.8)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.3, Cluster list: 10.100.1.8

rx pathid: 0, tx pathid: 0x0

PE5 heeft nog steeds PE1 als volgende hop voor het prefix (met de juiste IGP metriek aan de volgende hop):

PE5#show bgp ipv4 unicast 172.16.2.0/24

BGP routing table entry for 172.16.2.0/24, version 13

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.1 (metric 3) from 10.100.1.8 (10.100.1.8)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.1, Cluster list: 10.100.1.8

rx pathid: 0, tx pathid: 0x0

Problemen oplossen

Controleer het voorvoegsel in de RR:

RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0

BGP routing table entry for 172.16.2.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 19          19

Last Modified: Mar  7 16:41:20.156 for 03:07:40

Paths: (3 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Local, (Received from a RR-client)

10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 14

Path #2: Received by speaker 0

Not advertised to any peer

Local, (Received from a RR-client)

10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 4, version 14

Path #3: Received by speaker 0

ORR bestpath for update-groups (with more than one peer):

0.1

Local, (Received from a RR-client)

10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 5, version 19

Merk op dat add-path is toegevoegd aan de andere niet-best paden, zodat ze ook kunnen worden geadverteerd, naast het beste pad. De add path optie wordt niet gebruikt tussen de RR en zijn klanten: de paden worden niet geadverteerd met een pad-identificator.

Controleer of de route(s) (nog steeds) aan de specifieke BGP-buren wordt/worden geadverteerd.

Naar het buurland PE4 is de volgende hop PE3 voor het voorvoegsel 172.16.2.0/24:

RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.4 advertised-routes

Network            Next Hop        From            AS Path

172.16.1.0/24      10.100.1.5      10.100.1.5      i

172.16.2.0/24      10.100.1.3      10.100.1.3      i

Processed 2 prefixes, 2 paths

Naar het buurland PE5 is de volgende-hop PE1 voor het voorvoegsel 172.16.2.0/24:

RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.5 advertised-routes

Network            Next Hop        From            AS Path

172.16.1.0/24      10.100.1.8      10.100.1.5      i

172.16.2.0/24      10.100.1.1      10.100.1.1      i

Het buurland 10.100.1.4 bevindt zich in zijn eigen actualiteitengroep vanwege het bestaande ORR-beleid:

RP/0/0/CPU0:RR#show bgp ipv4 unicast update-group

Update group for IPv4 Unicast, index 0.1:

Attributes:

Neighbor sessions are IPv4

Internal

Common admin

First neighbor AS: 1

Send communities

Send GSHUT community if originated

Send extended communities

Route Reflector Client

ORR root (configured): ipv4-orr-group; Index: 0

4-byte AS capable

Non-labeled address-family capable

Send AIGP

Send multicast attributes

Minimum advertisement interval: 0 secs

Update group desynchronized: 0

Sub-groups merged: 0

Number of refresh subgroups: 0

Messages formatted: 8, replicated: 8

All neighbors are assigned to sub-group(s)

Neighbors in sub-group: 0.1, Filter-Groups num:1

Neighbors in filter-group: 0.3(RT num: 0)

10.100.1.4

Update group for IPv4 Unicast, index 0.3:

Attributes:

Neighbor sessions are IPv4

Internal

Common admin

First neighbor AS: 1

Send communities

Send GSHUT community if originated

Send extended communities

Route Reflector Client

4-byte AS capable

Non-labeled address-family capable

Send AIGP

Send multicast attributes

Minimum advertisement interval: 0 secs

Update group desynchronized: 0

Sub-groups merged: 1

Number of refresh subgroups: 0

Messages formatted: 12, replicated: 42

All neighbors are assigned to sub-group(s)

Neighbors in sub-group: 0.3, Filter-Groups num:1

Neighbors in filter-group: 0.1(RT num: 0)

10.100.1.1                10.100.1.2                10.100.1.3                10.100.1.5

De opdracht van de database show of rspf toont de ORR-groep en de wortel(s);

RP/0/0/CPU0:RR#show orrspf database

ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL

Actual Root: 10.100.1.4

Number of mapping entries: 1

Dezelfde opdracht met het sleutelwoord biedt de kosten van de wortel van de rSPF aan elke andere router/prefix in hetzelfde OSPF-gebied:

RP/0/0/CPU0:RR#show orrspf database detail

ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL

Actual Root: 10.100.1.4

Prefix                                        Cost

10.100.1.6                                    2

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    2

10.100.1.4                                    0

10.100.1.5                                    3

10.100.1.7                                    3

10.100.1.8                                    4

Number of mapping entries: 9

De tabel-id werd toegewezen door RSI voor de ORR-groep en voor AFI/SAFI:

RP/0/0/CPU0:RR#show rsi table-id 0xe0000012

TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000

Refcnt=1

VRF Index=4 TCM Index=1

Flags=0x0 LST Flags=(0x0) NULL

RP/0/0/CPU0:RR#show rib tables

Codes: N - Prefix Limit Notified, F - Forward Referenced

D - Table Deleted, C - Table Reached Convergence

VRF/Table              SAFI  Table ID     PrfxLmt   PrfxCnt TblVersion  N F D C

default/default        uni   0xe0000000   5000000        22        128  N N N Y

**nVSatellite/default  uni   0xe0000010   5000000         2          4  N N N Y

default/ipv4-orr-grou  uni   0xe0000012   5000000         9         27  N N N Y

default/default        multi 0xe0100000   5000000         0          0  N N N Y

De kosten van de wortel (R4/10.100.1.4) van het rSPF aan elkaar router zijn dezelfde als de kosten die worden gezien bij tonen van IP route ospf op PE4:

PE4#show ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

a - application route

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 20 subnets, 2 masks

O        10.100.1.1/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.2/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.3/32 [110/2] via 10.1.8.3, 4d06h, GigabitEthernet0/2

O        10.100.1.5/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.6/32 [110/2] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.7/32 [110/3] via 10.1.8.3, 4d06h, GigabitEthernet0/2

[110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.8/32 [110/4] via 10.1.8.3, 4d05h, GigabitEthernet0/2

[110/4] via 10.1.7.6, 4d05h, GigabitEthernet0/1

RIB voor de BGP ORR-groep:

RP/0/0/CPU0:RR#show route afi-all safi-all topology ipv4-orr-group

IPv4 Unicast Topology ipv4-orr-group:

-------------------------------------

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP

A - access/subscriber, a - Application route

M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

o    10.100.1.1/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.2/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.3/32 [255/2] via 0.0.0.0, 00:04:53, Unknown

o    10.100.1.4/32 [255/0] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.5/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.6/32 [255/2] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.7/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.8/32 [255/4] via 0.0.0.0, 14:14:52, Unknown

RP/0/0/CPU0:RR#show rsi table name ipv4-orr-group

VR=default:

TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000

Refcnt=1

VRF Index=4 TCM Index=1

Flags=0x0 LST Flags=(0x0) NULL

De opdracht van de buur van Bgp toont als de peer een ORR wortel is:

RP/0/0/CPU0:RR#show bgp neighbor 10.100.1.4

BGP neighbor is 10.100.1.4

Remote AS 1, local AS 1, internal link

Remote router ID 10.100.1.4

Cluster ID 10.100.1.8

BGP state = Established, up for 01:17:41

NSR State: None

Last read 00:00:52, Last read before reset 01:18:30

Hold time is 180, keepalive interval is 60 seconds

Configured hold time: 180, keepalive: 60, min acceptable hold time: 3

Last write 00:00:34, attempted 19, written 19

Second last write 00:01:34, attempted 19, written 19

Last write before reset 01:17:43, attempted 19, written 19

Second last write before reset 01:18:43, attempted 19, written 19

Last write pulse rcvd  Mar  8 10:20:13.779 last full not set pulse count 12091

Last write pulse rcvd before reset 01:17:42

Socket not armed for io, armed for read, armed for write

Last write thread event before reset 01:17:42, second last 01:17:42

Last KA expiry before reset 01:17:43, second last 01:18:43

Last KA error before reset 00:00:00, KA not sent 00:00:00

Last KA start before reset 01:17:43, second last 01:18:43

Precedence: internet

Non-stop routing is enabled

Multi-protocol capability received

Neighbor capabilities:

Route refresh: advertised (old + new) and received (old + new)

4-byte AS: advertised and received

Address family IPv4 Unicast: advertised and received

Received 6322 messages, 0 notifications, 0 in queue

Sent 5782 messages, 4 notifications, 0 in queue

Minimum time between advertisement runs is 0 secs

Inbound message logging enabled, 3 messages buffered

Outbound message logging enabled, 3 messages buffered

For Address Family: IPv4 Unicast

BGP neighbor version 41

Update group: 0.1 Filter-group: 0.1  No Refresh request being processed

Route-Reflector Client

ORR root (configured): ipv4-orr-group; Index: 0

Route refresh request: received 0, sent 0

0 accepted prefixes, 0 are bestpaths

Cumulative no. of prefixes denied: 0.

Prefix advertised 2, suppressed 0, withdrawn 0

Maximum prefixes allowed 1048576

Threshold for warning message 75%, restart interval 0 min

AIGP is enabled

An EoR was received during read-only mode

Last ack version 41, Last synced ack version 0

Outstanding version objects: current 0, max 2

Additional-paths operation: None

Send Multicast Attributes

Advertise VPNv4 routes enabled with  option

Advertise VPNv6 routes is enabled with Local with stitching-RT option

Connections established 6; dropped 5

Local host: 10.100.1.8, Local port: 25176, IF Handle: 0x00000000

Foreign host: 10.100.1.4, Foreign port: 179

Last reset 01:17:42, due to User clear requested (CEASE notification sent - administrative reset)

Time since last notification sent to neighbor: 01:17:42

Error Code: administrative reset

Notification data sent:

None

Zoals in deze afbeelding wordt getoond, zijn er meerdere RR-clients ingesteld

Er is een reeks RR-cliënten verbonden met PE3 en een andere reeks verbonden met P1. Elke RR-client in elke set is even ver verwijderd als elke uitgaande BGP-grensrouter.

router bgp 1

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1 10.100.1.4 10.100.1.209 10.100.1.210

optimal-route-reflection ipv4-orr-group-2 10.100.1.5 10.100.1.106 10.100.1.107

!

…

neighbor 10.100.1.4

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.106

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.107

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.108

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.209

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

neighbor 10.100.1.210

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1   route-reflector-client

!

!

neighbor 10.100.1.211

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

!

De orspf-database voor beide groepen:

RP/0/0/CPU0:RR#show orrspf database detail

ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210

Actual Root: 10.100.1.4

Prefix                                        Cost

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    2

10.100.1.4                                    0

10.100.1.5                                    3

10.100.1.6                                    2

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  3

10.100.1.107                                  3

10.100.1.108                                  3

10.100.1.209                                  3

10.100.1.210                                  3

10.100.1.211                                  3

ORR policy: ipv4-orr-group-2, IPv4, RIB tableid: 0xe0000013

Configured root: primary: 10.100.1.5, secondary: 10.100.1.106, tertiary: 10.100.1.107

Actual Root: 10.100.1.5

Prefix                                        Cost

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    4

10.100.1.4                                    3

10.100.1.5                                    0

10.100.1.6                                    2

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  3

10.100.1.107                                  3

10.100.1.108                                  3

10.100.1.209                                  5

10.100.1.210                                  5

10.100.1.211                                  5

Number of mapping entries: 30

Als voor een groep de primaire wortel omlaag of onbereikbaar is, zal de secundaire wortel de eigenlijke gebruikte wortel zijn. In dit voorbeeld is de primaire wortel van groep ipv4-of-groep-1 onbereikbaar. De secundaire wortel werd de echte wortel:

RP/0/0/CPU0:RR#show orrspf database ipv4-orr-group-1

ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210

Actual Root: 10.100.1.209

Prefix                                        Cost

10.100.1.1                                    4

10.100.1.2                                    5

10.100.1.3                                    2

10.100.1.5                                    5

10.100.1.6                                    4

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  5

10.100.1.107                                  5

10.100.1.108                                  5

10.100.1.209                                  0

10.100.1.210                                  3

10.100.1.211                                  3

Number of mapping entries: 14

Conclusie

BGP Optimal Route Reflectie (ORR) is een functie die hot-aardappelen routing in een iBGP-netwerk toestaat wanneer er routereflectors aanwezig zijn, zonder dat er nieuwere besturingssysteemsoftware op de grensrouters nodig is. De voorwaarde is dat IGP een link-staat routingprotocol is.