Verificação RPF RPF Rígida para mVPN
Contents
Introduction
Este documento descreve o recurso RPF (Strict Reverse Path Forwarding) para Multicast sobre VPN (mVPN). Este documento usa um exemplo e a implementação no Cisco IOS® para ilustrar o comportamento.
Informações de Apoio
O RPF implica que a interface de entrada é verificada em direção à origem. Embora a interface seja verificada para determinar se é a correta na direção da origem, ela não é verificada para determinar se é o vizinho RPF correto nessa interface. Em uma interface multiacesso, pode haver mais de um vizinho para o qual você poderia executar RPF. O resultado pode ser que o roteador receba duas vezes o mesmo fluxo multicast naquela interface e encaminhe ambas.
Em redes onde o Protocol Independent Multicast (PIM) é executado na interface multiacesso, isso não é um problema, porque o fluxo multicast duplicado faz com que o mecanismo assert seja executado e um fluxo multicast não será mais recebido. Em alguns casos, o PIM não é executado na árvore de distribuição multicast (MDT), que é uma interface multiacesso. Nesses casos, o BGP (Border Gateway Protocol) é o protocolo de sinalização de sobreposição.
Nos perfis com MDT particionado, mesmo que o PIM seja executado como o protocolo de sobreposição, pode ser impossível ter asserções. Isso ocorre porque uma Borda do provedor de entrada (PE) não se junta ao MDT particionado de outro PE de entrada nos cenários em que há dois ou mais roteadores PE de entrada. Cada roteador de PE de entrada pode encaminhar o fluxo multicast para seu MDT particionado sem que o outro roteador de PE de entrada veja o tráfego multicast. O fato de que dois roteadores PE de saída diferentes unem um MDT para um roteador PE de entrada diferente para o mesmo fluxo multicast é um cenário válido: é chamado de Origem de Anycast. Isso permite que diferentes receptores se juntem ao mesmo fluxo multicast, mas em um caminho diferente no núcleo de Multiprotocol Label Switching (MPLS). Veja na Figura 1 um exemplo de Origem de Anycast.
Figure 1
Há dois roteadores PE de entrada: PE1 e PE2. Há dois roteadores PE de saída: PE3 e PE4. Cada roteador PE de saída tem um roteador PE de entrada diferente como seu vizinho RPF. PE3 tem PE1 como seu vizinho RPF. PE4 tem PE2 como seu vizinho RPF. Os roteadores PE de saída escolhem seu roteador PE de entrada mais próximo como seu vizinho RPF.
O fluxo (S1,G) vai do S1 para o receptor 1 no caminho superior e do S1 para o receptor 2 no caminho inferior. Não há interseção dos dois fluxos sobre os dois caminhos (cada caminho no núcleo MPLS é um MDT particionado diferente).
Se o MDT fosse um MDT padrão - como nos perfis de MDT padrão - isso não funcionaria porque os dois fluxos multicast estariam no mesmo MDT padrão e o mecanismo de asserção seria executado. Se o MDT for um MDT de dados nos perfis de MDT padrão, todos os roteadores de PE de entrada se juntarão ao MDT de dados dos outros roteadores de PE de entrada e, como tal, verão o tráfego multicast um do outro e o mecanismo de asserção será executado novamente. Se o protocolo de sobreposição for BGP, então há a seleção Upstream Multicast Hop (UMH) e somente um roteador Ingress PE é selecionado como o encaminhador, mas isso é por MDT.
Anycast Source é uma das grandes vantagens da execução do MDT particionado.
Problema
A verificação RPF regular confirma que os pacotes chegam ao roteador a partir da interface RPF correta. Não há verificação para confirmar se os pacotes são recebidos do vizinho RPF correto nessa interface.
Consulte a Figura 2. Ele mostra um problema em que o tráfego duplicado é encaminhado persistentemente em um cenário com MDT particionado. Mostra que a verificação RPF regular no caso de MDT particionado não é suficiente para evitar tráfego duplicado.
Figure 2
Há dois receptores. O primeiro receptor é configurado para receber tráfego para (S1,G) e (S2,G). O segundo receptor é configurado para receber tráfego somente para (S2,G). Há o MDT particionado e o BGP é o protocolo de sinalização de sobreposição. Observe que a origem S1 pode ser alcançada via PE1 e PE2. O protocolo da árvore central é o Multipoint Label Distribution Protocol (mLDP).
Cada roteador PE anuncia uma rota mVPN IPv4 BGP tipo 1, que indica que é um candidato a ser a raiz de um MDT particionado.
PE3#show bgp ipv4 mvpn vrf one
BGP table version is 257, local router ID is 10.100.1.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-pah, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:3 (default for vrf one)
*>i [1][1:3][10.100.1.1]/12
10.100.1.1 0 100 0 ?
*>i [1][1:3][10.100.1.2]/12
10.100.1.2 0 100 0 ?
*> [1][1:3][10.100.1.3]/12
0.0.0.0 32768 ?
*>i [1][1:3][10.100.1.4]/12
10.100.1.4 0 100 0 ?
PE3 encontra PE1 como vizinho RPF para S1 após uma pesquisa da rota unicast para S1.
PE3#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:3:10.100.1.6/32, version 16
Paths: (2 available, best #2, table one)
Advertised to update-groups:
5
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
Originator: 10.100.1.2, Cluster list: 10.100.1.5
mpls labels in/out nolabel/20
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
10.100.1.1 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
Originator: 10.100.1.1, Cluster list: 10.100.1.5
mpls labels in/out nolabel/29
rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.1)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE3 seleciona PE1 como o vizinho RPF para (S1,G) e une o MDT Particionado com PE1 como raiz. PE3 seleciona PE2 como o vizinho RPF para (S2,G) e une o MDT Particionado com PE2 como raiz.
PE3#show bgp vpnv4 unicast vrf one 10.100.1.7/32
BGP routing table entry for 1:3:10.100.1.7/32, version 18
Paths: (1 available, best #1, table one)
Advertised to update-groups:
6
Refresh Epoch 2
65002, imported path from 1:2:10.100.1.7/32 (global)
10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
Originator: 10.100.1.2, Cluster list: 10.100.1.5
mpls labels in/out nolabel/29
rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE4 seleciona PE2 como o vizinho RPF para (S1,G) e une o MDT Particionado com PE1 como raiz.
PE4#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:4:10.100.1.6/32, version 138
Paths: (2 available, best #1, table one)
Advertised to update-groups:
2
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
10.100.1.2 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
Originator: 10.100.1.2, Cluster list: 10.100.1.5
mpls labels in/out nolabel/20
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
10.100.1.1 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
Originator: 10.100.1.1, Cluster list: 10.100.1.5
mpls labels in/out nolabel/29
rx pathid: 0, tx pathid: 0
PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Observe que a interface RPF é Lspvif0 para S1 (10.100.1.6) e S2 (10.100.1.7).
PE3 une o MDT particionado de PE2 para (S2,G) e PE4 ao MDT particionado de PE2 para (S1,G). PE1 une o MDT particionado de PE1 para (S1,G). Você pode ver isso pelas rotas mVPN IPv4 BGP tipo 7 recebidas em PE1 e PE2.
PE1#show bgp ipv4 mvpn vrf one
BGP table version is 302, local router ID is 10.100.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf one)
*>i [7][1:1][1][10.100.1.6/32][232.1.1.1/32]/22
10.100.1.3 0 100 0 ?
PE2#show bgp ipv4 mvpn vrf one
BGP table version is 329, local router ID is 10.100.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:2 (default for vrf one)
*>i [7][1:2][1][10.100.1.6/32][232.1.1.1/32]/22
10.100.1.4 0 100 0 ?
*>i [7][1:2][1][10.100.1.7/32][232.1.1.1/32]/22
10.100.1.3 0 100 0 ?
As entradas multicast em PE3 e PE4:
PE3#show ip mroute vrf one 232.1.1.1
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.100.1.7, 232.1.1.1), 21:18:24/00:02:46, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:11:48/00:02:46
(10.100.1.6, 232.1.1.1), 21:18:27/00:03:17, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:11:48/00:03:17
PE4#show ip mroute vrf one 232.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.100.1.6, 232.1.1.1), 20:50:13/00:02:37, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 20:50:13/00:02:37
Isso mostra que PE3 une a árvore ponto a multiponto (P2MP) com raiz em PE1 e também a árvore com raiz em PE2:
PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
LSM ID : A Type: P2MP Uptime : 00:18:40
FEC Root : 10.100.1.1
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
10.100.1.1:0 [Active]
Expires : Never Path Set ID : A
Out Label (U) : None Interface : Ethernet5/0*
Local Label (D): 29 Next Hop : 10.1.5.1
Replication client(s):
MDT (VRF one)
Uptime : 00:18:40 Path Set ID : None
Interface : Lspvif0
LSM ID : B Type: P2MP Uptime : 00:18:40
FEC Root : 10.100.1.2
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
10.100.1.5:0 [Active]
Expires : Never Path Set ID : B
Out Label (U) : None Interface : Ethernet6/0*
Local Label (D): 30 Next Hop : 10.1.3.5
Replication client(s):
MDT (VRF one)
Uptime : 00:18:40 Path Set ID : None
Interface : Lspvif0
Isso mostra que PE4 se une à árvore P2MP com raiz em PE2:
PE4#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
LSM ID : 3 Type: P2MP Uptime : 21:17:06
FEC Root : 10.100.1.2
Opaque decoded : [gid 65536 (0x00010000)]
Opaque value : 01 0004 00010000
Upstream client(s) :
10.100.1.2:0 [Active]
Expires : Never Path Set ID : 3
Out Label (U) : None Interface : Ethernet5/0*
Local Label (D): 29 Next Hop : 10.1.6.2
Replication client(s):
MDT (VRF one)
Uptime : 21:17:06 Path Set ID : None
Interface : Lspvif0
Fluxo S1 e S2 para o Grupo 232.1.1.1 com 10 pps. Você pode ver os fluxos em PE3 e PE4. No entanto, em PE3, você pode ver a taxa para (S1,G) como 20 pps.
PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 232.1.1.1, Source count: 2, Packets forwarded: 1399687, Packets received:
2071455
Source: 10.100.1.7/32, Forwarding: 691517/10/28/2, Other: 691517/0/0
Source: 10.100.1.6/32, Forwarding: 708170/20/28/4, Other: 1379938/671768/0
PE4#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
2 routes using 1246 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 232.1.1.1, Source count: 1, Packets forwarded: 688820, Packets received:
688820
Source: 10.100.1.6/32, Forwarding: 688820/10/28/2, Other: 688820/0/0
PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 9000 bits/sec, 30 packets/sec
Há um fluxo duplicado. Esta duplicação é o resultado da presença de fluxo (S1,G) no MDT Particionado de PE1 e no MDT Particionado de PE2. Este segundo MDT Particionado, do PE2, foi unido por PE3 para obter o fluxo (S2,G). Mas, porque PE4 se juntou ao MDT Particionado de PE2 para obter (S1,G), (S1,G) também está presente no MDT Particionado de PE2. Portanto, o PE3 recebe o fluxo (S1,G) de ambos os MDTs particionados em que se juntou.
PE3 não pode discriminar os pacotes para (S1,G) que recebe de PE1 e PE2. Ambos os fluxos são recebidos na interface RPF correta: Lspvif0.
PE3#show ip multicast vrf one mpls vif
Interface Next-hop Application Ref-Count Table / VRF name Flags
Lspvif0 0.0.0.0 MDT N/A 1 (vrf one) 0x1
Os pacotes podem chegar em diferentes interfaces físicas de entrada em PE3 ou na mesma interface. Em qualquer caso, os pacotes dos diferentes fluxos para (S1,G) chegam com um rótulo MPLS diferente em PE3:
PE3#show mpls forwarding-table vrf one
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
29 [T] No Label [gid 65536 (0x00010000)][V] \
768684 aggregate/one
30 [T] No Label [gid 65536 (0x00010000)][V] \
1535940 aggregate/one
[T] Forwarding through a LSP tunnel.
View additional labelling info with the 'detail' option
Solução
A solução é ter um RPF mais rigoroso. Com RPF estrito, o roteador verifica de que vizinho os pacotes são recebidos na interface RPF. Sem RPF rigoroso, a única verificação é determinar se a interface de entrada é a interface RPF, mas não se os pacotes são recebidos do vizinho RPF correto nessa interface.
Notas para o Cisco IOS
Aqui estão algumas notas importantes sobre RPF com Cisco IOS.
- Quando você altera para/do modo RPF estrito, configure-o antes de configurar o MDT particionado ou limpe o BGP. Se você configurar apenas o comando RPF strict, ele não criará outra interface Lspvif imediatamente.
- RPF restrito não está habilitado por padrão no Cisco IOS.
- Não é suportado ter o comando strict-rpf com perfis de MDT padrão.
Configuração
Você pode configurar RPF estrito em PE3 para o Virtual Routing and Forwarding (VRF).
vrf definition one
rd 1:3
!
address-family ipv4
mdt auto-discovery mldp
mdt strict-rpf interface
mdt partitioned mldp p2mp
mdt overlay use-bgp
route-target export 1:1
route-target import 1:1
exit-address-family
!
As informações de RPF foram alteradas:
PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif1
RPF neighbor: ? (10.100.1.1)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif2
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
O PE3 criou uma interface Lspvif por PE de entrada. A interface Lspvif é criada por PE de entrada, por família de endereços (AF) e por VRF. O RPF para 10.100.1.6 agora aponta para a interface Lspvif1 e o RPF para 10.100.1.7 agora aponta para a interface Lspvif2.
PE3#show ip multicast vrf one mpls vif
Interface Next-hop Application Ref-Count Table / VRF name Flags
Lspvif0 0.0.0.0 MDT N/A 1 (vrf one) 0x1
Lspvif1 10.100.1.1 MDT N/A 1 (vrf one) 0x1
Lspvif2 10.100.1.2 MDT N/A 1 (vrf one) 0x1
Agora, a verificação de RPF para pacotes (S1,G) de PE1 é verificada na interface Lspvif1 de RPF. Esses pacotes vêm com o rótulo 29 do MPLS. A verificação de RPF para pacotes (S2,G) do PE2 é verificada em relação à interface Lspvif2 do RPF. Esses pacotes entram com o rótulo MPLS 30. Os fluxos chegam ao PE3 através de diferentes interfaces de entrada, mas essa também pode ser a mesma interface. No entanto, devido ao fato de que o mLDP nunca usa Penúltimos-saltos-saltos (PHP), sempre há um rótulo MPLS regular em cima dos pacotes multicast. Os pacotes (S1,G) que chegam de PE1 e PE2 estão em dois MDTs particionados diferentes e, portanto, têm um rótulo MPLS diferente. Assim, o PE3 pode diferenciar entre o fluxo (S1,G) que vem do PE1 e o fluxo (S1,G) que vem do PE2. Dessa forma, os pacotes podem ser mantidos separados por PE3 e um RPF pode ser executado em diferentes roteadores PE de entrada.
O banco de dados mLDP em PE3 agora mostra as diferentes interfaces Lspvif por PE de entrada.
PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
LSM ID : C Type: P2MP Uptime : 00:05:58
FEC Root : 10.100.1.1
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
10.100.1.1:0 [Active]
Expires : Never Path Set ID : C
Out Label (U) : None Interface : Ethernet5/0*
Local Label (D): 29 Next Hop : 10.1.5.1
Replication client(s):
MDT (VRF one)
Uptime : 00:05:58 Path Set ID : None
Interface : Lspvif1
LSM ID : D Type: P2MP Uptime : 00:05:58
FEC Root : 10.100.1.2
Opaque decoded : [gid 65536 (0x00010000)]
Opaque length : 4 bytes
Opaque value : 01 0004 00010000
Upstream client(s) :
10.100.1.5:0 [Active]
Expires : Never Path Set ID : D
Out Label (U) : None Interface : Ethernet6/0*
Local Label (D): 30 Next Hop : 10.1.3.5
Replication client(s):
MDT (VRF one)
Uptime : 00:05:58 Path Set ID : None
Interface : Lspvif2
RPF ou RPF por PE de entrada funciona devido ao fato de que os fluxos multicast chegam ao PE de entrada com um rótulo MPLS diferente por PE de entrada:
PE3#show mpls forwarding-table vrf one
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
29 [T] No Label [gid 65536 (0x00010000)][V] \
162708 aggregate/one
30 [T] No Label [gid 65536 (0x00010000)][V] \
162750 aggregate/one
[T] Forwarding through a LSP tunnel.
View additional labelling info with the 'detail' option
A prova de que o RPF rigoroso funciona é que não há mais um fluxo duplicado (S1,G) encaminhado no PE3. O fluxo duplicado ainda chega em PE3, mas é descartado devido à falha de RPF. O contador de falha de RPF está em 676255 e aumenta constantemente a uma taxa de 10 pps.
PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.
IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 232.1.1.1, Source count: 2, Packets forwarded: 1443260, Packets received:
2119515
Source: 10.100.1.7/32, Forwarding: 707523/10/28/2, Other: 707523/0/0
Source: 10.100.1.6/32, Forwarding: 735737/10/28/2, Other: 1411992/676255/0
A taxa de saída em PE3 agora é de 20 pps, que é de 10 pps para cada fluxo (S1,G) e (S2,G):
PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 6000 bits/sec, 20 packets/sec
Conclusão
A verificação RPF estrita deve ser usada para os modelos de implantação mVPN que usam MDT particionado.
As coisas podem parecer funcionar, mesmo que você não configure a verificação RPF estrita para os modelos de implantação mVPN com MDT particionado: os fluxos multicast são entregues aos receptores. No entanto, há a possibilidade de haver tráfego multicast duplicado quando as fontes estão conectadas a vários roteadores de entrada PE. Isso leva a um desperdício de largura de banda na rede e pode afetar adversamente a aplicação multicast nos receptores. Portanto, é necessário configurar a Verificação RPF estrita para os modelos de implantação de mVPN que usam MDT particionado.
Feedback