Configurazione Del Meccanismo Di Controllo Del Traffico PfRv2 Con Routing Statico E Basato Su Policy
Sommario
Introduzione
In questo documento viene descritto come PfRv2 (Performance Routing) controlla il traffico in base alla decisione sulla policy PfRv2. In questo documento viene descritto l'utilizzo di route statiche e di routing basato su criteri in PfRv2.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza di base di Performance Routing (PfR).
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Configurazione
PfRv2 consente a un amministratore di rete di configurare i criteri e di instradare di conseguenza il traffico in base al risultato dei criteri PfRv2. Il protocollo PfRv2 controlla il traffico in varie modalità e dipende dal protocollo tramite il quale viene appresa la route padre per il prefisso di destinazione. PfRv2 è in grado di modificare il RIB (Routing Information Base) modificando i protocolli di routing, inserendo route statiche o tramite routing dinamico basato su policy.
- Se la route padre viene appresa tramite BGP, PfRv2 può modificare dinamicamente le route utilizzando attributi quali le preferenze locali.
- Se la route padre viene appresa tramite EIGRP, PfRv2 può inserire una nuova route nella tabella della topologia EIGRP.
- Se la route padre viene appresa tramite una route statica, PfR2 inserisce una route più specifica (migliore) sul router di confine selezionato PfR (BR).
- Se la route padre non viene appresa tramite nessuno dei tre meccanismi precedenti, PfRv2 utilizza il routing basato su criteri (PBR) per eseguire il push del traffico sulla route selezionata.
In questo articolo viene descritto l'utilizzo di PfRv2 con route statiche (quando la route padre è tramite route statica) e PBR (quando la route padre in RIB è tramite RIP, OSPF, ISIS e così via) per controllare il traffico.
Esempio di rete
Questo documento farebbe riferimento alla seguente immagine come topologia di esempio per il resto del documento.
Dispositivi mostrati nel diagramma:
R1- Server, avvio del traffico.
R3- Router master PfR.
R4 & R5- PfR Border Router
I client collegati a R9 e R10 sono dispositivi che ricevono il traffico dal server R1.
Configurazioni
In questo scenario verranno configurati due elenchi di informazioni, uno per il traffico di applicazioni (APPLICATION-LEARN-LIST) e dati (DATA-LEARN-LIST). In questo scenario viene utilizzato un elenco di prefissi per definire il traffico. L'elenco degli accessi può essere usato anche per definire il tipo di traffico, ad esempio TCP, UDP, ICMP, ecc. DSCP e TOS possono essere utilizzati anche per definire il traffico.
key chain pfr
key 0
key-string cisco
pfr master
policy-rules PFR
!
border 10.4.4.4 key-chain pfr
interface Tunnel0 internal
interface Ethernet1/0 external
interface Ethernet1/2 internal
link-group MPLS
!
border 10.5.5.5 key-chain pfr
interface Tunnel0 internal
interface Ethernet1/3 internal
interface Ethernet1/0 external
link-group INET
!
learn
traffic-class filter access-list DENY-ALL
list seq 10 refname APPLICATION-LEARN-LIST //Learn-list for application traffic
traffic-class prefix-list APPLICATION
throughput
list seq 20 refname DATA-LEARN-LIST //Learn-list for data traffic
traffic-class prefix-list DATA
throughput
!
!
pfr-map PFR 10
match pfr learn list APPLICATION-LEARN-LIST
set periodic 90
set delay threshold 25
set mode monitor active
set active-probe echo 10.20.21.1
set probe frequency 5
set link-group MPLS fallback INET
!
pfr-map PFR 20
match pfr learn list DATA-LEARN-LIST
set periodic 90
set delay threshold 25
set mode monitor active
set resolve delay priority 1 variance 10
set active-probe echo 10.30.31.1
set probe frequency 5
set link-group INET fallback MPLS
ip prefix-list DATA
seq 5 permit 10.30.0.0/24
ip prefix-list APPLICATION
seq 5 permit 10.20.0.0/24
Verifica
Caso 1: il percorso padre viene appreso tramite un percorso statico su router di confine
In questo scenario, il traffico scorre verso le destinazioni 10.20.20.1 e 10.30.30.1. Di seguito viene riportato l'aspetto della route padre in R4 e R5.
R4#show ip route
--output suppressed--
S 10.20.0.0/16 [1/0] via 10.0.68.8
S 10.30.0.0/16 [1/0] via 10.0.68.8
R5#show ip route
--output suppressed--
S 10.20.0.0/16 [1/0] via 10.0.57.7
S 10.30.0.0/16 [1/0] via 10.0.57.7
Quando il traffico fluisce, PfRv2 apprende i prefissi e il traffico cade nello stato INPOLICY, come mostrato di seguito nell'output.
R3#show pfr master traffic-class
OER Prefix Statistics:
--output suppressed--
DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos ActLLos
--------------------------------------------------------------------------------
10.20.20.0/24 N N N N N N
INPOLICY 31 10.4.4.4 Et1/0 STATIC
N N N N N N N N
1 2 0 0 N N N N
10.30.30.0/24 N N N N N N
INPOLICY 30 10.5.5.5 Et1/0 STATIC
N N N N N N N N
4 2 0 0 N N N N
Come si può vedere di seguito, il router R4 (10.4.4.4) ha iniettato una route 10.20.20.0/24 più specifica. Questa route generata automaticamente è contrassegnata con un valore di tag di 5000. Questo percorso migliore e più specifico rende R4 migliore BR per il traffico in uscita per 10.20.20.0/24.
R4#show pfr border routes static
Flags: C - Controlled by oer, X - Path is excluded from control,
E - The control is exact, N - The control is non-exact
Flags Network Parent Tag
CE 10.20.20.0/24 10.20.0.0/16 5000
XN 10.30.30.0/24
R4#show ip route 10.20.20.0 255.255.255.0
Routing entry for 10.20.20.0/24
Known via "static", distance 1, metric 0
Tag 5000
Redistributing via ospf 100
Routing Descriptor Blocks:
* 10.0.46.6, via Ethernet1/0
Route metric is 0, traffic share count is 1
Route tag 5000
Analogamente, un comportamento simile può essere osservato in R5 e inietta una route più specifica 10.30.30.0/24, che ha anche un tag di 5000. Ciò rende R5 un candidato adatto per indirizzare il traffico per 10.30.30.0/24. In questo modo PfRv2 preferisce instradare il traffico come mostrato in "show pfr master traffic-class".
R5#show pfr border routes static
Flags: C - Controlled by oer, X - Path is excluded from control,
E - The control is exact, N - The control is non-exact
Flags Network Parent Tag
XN 10.20.20.0/24
CE 10.30.30.0/24 10.30.0.0/16 5000
R5#show ip route 10.30.30.0 255.255.255.0
Routing entry for 10.30.30.0/24
Known via "static", distance 1, metric 0
Tag 5000
Redistributing via ospf 100
Routing Descriptor Blocks:
* 10.0.57.7, via Ethernet1/0
Route metric is 0, traffic share count is 1
Route tag 5000
Nel caso in cui vi siano più router di confine (come in questo caso), queste route statiche generate automaticamente devono essere ridistribuite manualmente nell'IGP in modo che possano raggiungere altri router di confine e indirizzare il traffico in base al percorso più specifico generato dalla scheda di routing selezionata.
Caso 2: la route padre viene appresa tramite OSPF
Tutte le route padre che non vengono apprese tramite BGP, EIGRP o route statica vengono controllate tramite PBR (Policy Based Routing). PfRv2 consente di immettere una mappa dinamica degli accessi e un elenco degli accessi per controllare il traffico. Di seguito viene illustrato l'aspetto della route padre OSPF su R4 e R5.
R4#show ip route
--output suppressed--
O E2 10.20.0.0/16 [110/20] via 10.0.46.6, 02:16:35, Ethernet1/0
O E2 10.30.0.0/16 [110/20] via 10.0.46.6, 02:16:35, Ethernet1/0
R5#show ip route
--output suppressed--
O E2 10.20.0.0/16 [110/20] via 10.0.57.7, 02:18:20, Ethernet1/0
O E2 10.30.0.0/16 [110/20] via 10.0.57.7, 02:18:20, Ethernet1/0
Quando PfRv2 deve modificare il flusso del traffico tramite il routing basato su policy, richiede un'interfaccia direttamente connessa tra i BR. Questo collegamento con connessione diretta potrebbe essere una connessione fisica o un tunnel GRE. Questo tunnel deve essere creato e configurato manualmente come interfaccia interna nella definizione del bordo PfRv2.
R4
interface tunnel 0 // Defining GRE tunnel for policy routing of traffic.
ip add 10.0.45.4
tunnel source 10.0.24.4
tunnel destination 10.0.25.5
R5
interface tunnel 0
ip add 10.0.45.5
tunnel source 10.0.25.5
tunnel destination 10.0.24.4
border 10.4.4.4 key-chain pfr
interface Tunnel0 internal // Packets would be policy routed to selected BR using this Tunnel.
interface Ethernet1/0 external
interface Ethernet1/2 internal
link-group MPLS
!
border 10.5.5.5 key-chain pfr
interface Tunnel0 internal // Packets would be policy routed to selected BR using this Tunnel.
interface Ethernet1/3 internal
interface Ethernet1/0 external
link-group INET
R3#show pfr master traffic-class
OER Prefix Statistics:
--output suppressed--
DstPrefix Appl_ID Dscp Prot SrcPort DstPort SrcPrefix
Flags State Time CurrBR CurrI/F Protocol
PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos EBw IBw
ActSDly ActLDly ActSUn ActLUn ActSJit ActPMOS ActSLos ActLLos
--------------------------------------------------------------------------------
10.20.20.0/24 N N N N N N
INPOLICY @8 10.4.4.4 Et1/0 RIB-PBR
N N N N N N N N
2 1 0 0 N N N N
10.30.30.0/24 N N N N N N
INPOLICY 82 10.5.5.5 Et1/0 RIB-PBR
N N N N N N N N
1 1 0 0 N N N N
In base ai criteri definiti dal protocollo PfRv2, viene fornito il miglior router di uscita (BR) per 10.20.20.0/24 e 10.30.30.0/24. Ad esempio, nel caso in cui il traffico destinato alla versione 10.20.20.0/24 arrivi alla versione R5 (10.5.5.5), che non è la BR selezionata, viene automaticamente iniettata una mappa del percorso e un elenco degli accessi dinamici per instradare il traffico alla versione R4 del router di uscita (10.4.4.4) selezionata. I pacchetti vengono instradati attraverso l'interfaccia del tunnel definita in precedenza.
R5#show route-map dynamic
route-map OER_INTERNAL_RMAP, permit, sequence 0, identifier 436207617
Match clauses:
ip address (access-lists): oer#1
Set clauses:
ip next-hop 10.0.45.4
interface Tunnel0 // Tunnel is used to PBR traffic to R4.
Policy routing matches: 314076 packets, 16960104 bytes
R5#show ip access-lists dynamic
Extended IP access list oer#1
1073741823 permit ip any 10.20.20.0 0.0.0.255 (315125 matches)
2147483647 deny ip any any (314955 matches)
Feedback