Xconnect sobre o L2TPv3 ciente VRF em ASR1K

Transcrição

1 Xconnect sobre o L2TPv3 ciente VRF em ASR1K Índice Introdução Informações de Apoio Caso de teste mim: L2TPv3 Xconnect sobre a rede IP com valores-limite no VRF Caso de teste II: L2TPv3 Xconnect sobre a rede MPLS com valores-limite no VRF Introdução Este original descreve como o roteamento virtual e a transmissão (VRF) podem ser usados quando você configura o protocolo Layer 2 Tunneling Protocol (L2TP)v3 Xconnect sobre a rede IP e de Multiprotocol Label Switching (MPLS). Informações de Apoio O L2TP é o protocolo de tunelamento usado pelos provedores de serviço da Internet (ISP) a fim fornecer o Virtual Private Network (VPN) no espaço do acesso do seletor sobre o Internet. Combina o melhor do protocolo da transmissão da camada 2 de Cisco (L2F) e do Point-to-Point Tunneling Protocol (PPTP) de Microsoft. Os componentes principais do L2TP são o controlador do acesso L2TP (LAC) e o L2TP Network Server (LNS). Controlador do acesso L2TP: O LAC é um servidor de acesso conectado à rede telefônica pública comutada (PSTN). O LAC é o iniciador das chamadas recebidas e o receptor das chamadas feitas. É conectado ao LNS sobre o LAN ou o WAN. L2TP Network Server: O LNS é o servidor de rede para o protcol L2TP onde as sessões de PPP terminam e são autenticadas. O LNS é o iniciador das chamadas feitas e o receptor das chamadas recebidas. L2TPv2 foi projetado levar o tráfego PPP sobre redes IP. O equipamento do acesso de rede (DSL, modem a cabo ou relações de acesso por discagem) aceitou conexões PPP dos assinantes e escavou um túnel as sessões de PPP ao ISP sobre o L2TP. O L2TPv3 da nova versão é projetado levar todo o payload da camada 2 além do que o PPP que era o único payload que foi apoiado pela versão 2. Especificamente, o L2TPv3 define o protocolo L2TP para cargas úteis da camada 2 da escavação de um túnel sobre uma rede central IP com o VPNs de camada 2 do uso. Os benefícios desta característica incluem este: O L2TPv3 simplifica o desenvolvimento dos VPN O L2TPv3 não exige o MPLS

2 O L2TPv3 apoia a camada 2 que escava um túnel sobre o IP para todo o payload Está aqui a configuração de exemplo do pseudowire do L2TPv3: 1. enable 2.terminal configure 3. interface datilografe a /porta do entalhe 4.peer-ip-address xconnect vcidencapsulation l2tpv3pw-classpw-class-name Olhe agora como o L2TPv3 Xconnect se comporta quando o VRF é usado. Está aqui a topologia que é usada para a demonstração em que nós Xconnect somos configurados entre o CPE e o ASR1002 (IP) e o ASR1004 (MPLS) com valores-limite em ASR1000 no VRF (o L2TPv3 ciente VRF não é apoiado na plataforma ASR1000). Caso de teste mim: L2TPv3 Xconnect sobre a rede IP com valores-limite no VRF O PE-1 e PE-2 fazem a rede MPLS para o ISP. O CPE é conectado ao PE-1 sobre o VRF e o ASR1002 é conectado a PE-2 sobre o VRF. ASR1002 igualmente tem o VRF na relação conectada a PE-2. A alcançabilidade do laço de retorno CPE de ASR1002 é através do VRF sobre a interface IP. Configuração no CPE para Xconnect para ASR1002: interface FastEthernet4.2381

3 encapsulation dot1q 2381 xconnect encapsulation l2tpv3 pw-class PSEUDO_CLASS >>>>>>>>>>> Xconnect with ASR1002 pseudowire-class PSEUDO_CLASS encapsulation l2tpv3 interworking vlan protocol l2tpv3 L2TP_CLASS ip local interface Loopback0 ip tos reflect l2tp-class L2TP_CLASS authentication password cisco interface Gigabit0/1 ip address end Interface Loopback0 ip address end ip route >>>>>>>>>>>>>> Default route towards PE-1 Configuração em funcionamento em ASR1002: interface GigabitEthernet0/0/0.906 > Interface connected to PE-2 is in VRF encapsulation dot1q 906 ip vrf forwarding L2TP_VRF ip address interface GigabitEthernet0/0/ encapsulation dot1q 2381

4 xconnect encapsulation l2tpv3 pw-class PSEUDO_CLASS pseudowire-class PSEUDO_CLASS encapsulation l2tpv3 interworking vlan protocol l2tpv3 L2TP_CLASS ip local interface Loopback11 l2tp-class L2TP_CLASS authentication password cisco interface Loopback11 ip vrf forwarding L2TP_VRF > Source is in VRF ip address router bgp 1 address-family ipv4 vrf L2TP_VRF redistribute connected neighbor remote-as 2 > ebgp with PE-2 in VRF neighbor activate neighbor soft-reconfiguration inbound exit-address-family VRF L2TP_VRF: B /32 [20/0] via , 1d > Xconnect end point learned via ebgp in VRF Deixe-nos agora verificar o estado de Xconnect no CPE: CPE #sh xconnect all de

5 UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 DOWN Protocol State: DOWN Remote Circuit State: DOWN Diz o segmento 2 está para baixo, que significa que o trajeto do CPE a ASR1002 está tendo uma edição. Contudo, nós podemos sibilar o valor-limite. Debuga no CPE mostra que esse túnel ao valor-limite está falhado ou não há nenhuma rota ao valor-limite. CPE #sh xconnect all de UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 DOWN Protocol State: DOWN Remote Circuit State: DOWN A questão principal aqui é que o valor-limite é alcançável através do VRF em ASR1002. O valorlimite de Xconnect precisa de estar na tabela de roteamento global para que venha acima. Deixenos agora configurar uma rota para o laço de retorno /32 CPE em apontar global para conectar GigabitEthernet0/0/0.906 que está próprio no VRF.

6 ip route GigabitEthernet0/0/ S /32 [1/0] via , GigabitEthernet0/0/0.906 Uma vez que a rota estática do manequim é configurada, Xconnect vem acima. Você pode igualmente apontá-lo ao null0. Esta é uma ação alternativa para deixar o roteador acreditar que o valor-limite é alcançável através não do VRF global e está usado apenas para o plano do controle. O tráfego plano real dos dados será através do VRF somente. Estão aqui os resultados do sibilo com e sem o VRF: ip route GigabitEthernet0/0/ S Estado de Xconnect no CPE: /32 [1/0] via , GigabitEthernet0/0/0.906 CPE #sh xconnect all de UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 UP Protocol State: UP Remote Circuit State: UP Caso de teste II: L2TPv3 Xconnect sobre a rede MPLS com valores-limite no VRF

7 O PE-1, PE-2 e PE-3 fazem a rede MPLS para o ISP com o PE-2 que atua como o refletor de rota (RR). O CPE é conectado ao PE-1 sobre o VRF e o ASR1004 é conectado a PE-2 com o MPLS permitido na relação. ASR1004 igualmente tem o VRF em que se supõe para receber as rotas do VPNv4 do PE-1 através do RR. A alcançabilidade do looback CPE de ASR1004 é através do VRF sobre a relação MPLS. Configuração no CPE para Xconnect para ASR1004: CPE #sh xconnect all de UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 UP Protocol State: UP Remote Circuit State: UP

8 Configuração em ASR1004: CPE #sh xconnect all de UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 UP Protocol State: UP Remote Circuit State: UP Entrada da rota para o ponto final de Xconnect: ASR1004#sh ip rou vrf L2TP_VRF via VRF > Xconnect End Point also learned Routing Table: L2TP_VRF Routing entry for /32 Known via "bgp 2", distance 200, metric 0, type internal Last update from d17h ago Routing Descriptor Blocks: * (default), from , 6d17h ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 18 MPLS Flags: MPLS Required We observed that Segment 2 was continuously flapping on both ends. ASR1004#sh xc all de

9 DN pri ac Gi0/0/1:2380(Eth VLAN) UP l2tp :2380 DN >>>>>>>>>>>>>> Interworking: vlan Session ID: Tunnel ID: Protocol State: DOWN Remote Circuit State: DOWN ASR1004#sh xc all de UP pri ac Gi0/0/1:2380(Eth VLAN) UP l2tp 1.1.1,1:2380 UP >>>>>>>>>>>>>>>> Interworking: vlan Session ID: Tunnel ID: Protocol State: UP Remote Circuit State: UP Logs do CPE: CPE#sh xconnect all de DN pri ac Fa4.2380:2380(Eth VLAN) UP l2tp :2380 DN à Flapping with ASR1004 Interworking: vlan Session ID:

10 Tunnel ID: Protocol State: DOWN Remote Circuit State: DOWN pw-class: PSEUDO_CLASS UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 UP à Stable with ASR1002 Protocol State: UP Remote Circuit State: UP pw-class: PSEUDO_CLASS CPE#sh l2tp session L2TP Session Information Total tunnels 2 sessions 2 LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit , Fa4.2380:2380 est 00:00:03 0 > Flapping with ASR , Fa4.2381:2381 est 15:37:06 0 > Stable with ASR1002 Você não pode configurar uma rota estática neste caso porque a relação da saída é interface ativada MPLS. Como uma ação alternativa, há um loop de duas relações entre si e configurado no VRF com o outro em global. Configurou então uma rota estática em apontar global para a relação VRF, com este Xconnect tornou-se estável. CPE#sh xconnect all de DN pri ac Fa4.2380:2380(Eth VLAN) UP l2tp :2380 DN à

11 Flapping with ASR1004 Interworking: vlan Session ID: Tunnel ID: Protocol State: DOWN Remote Circuit State: DOWN pw-class: PSEUDO_CLASS UP pri ac Fa4.2381:2381(Eth VLAN) UP l2tp :2381 UP à Stable with ASR1002 Protocol State: UP Remote Circuit State: UP pw-class: PSEUDO_CLASS CPE#sh l2tp session L2TP Session Information Total tunnels 2 sessions 2 LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit , Fa4.2380:2380 est 00:00:03 0 > Flapping with ASR , Fa4.2381:2381 est 15:37:06 0 > Stable with ASR1002 O total da informação de sessão de L2TP escava um túnel 2 sessões 2: LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit , Fa4.2380:2380 est 00:20: , Fa4.2381:2381 est 15:37:06 0 O fluxo de tráfego é considerado como em caso de ASR1004: Quando o tráfego vem do CPE em ASR1004, vem na relação Gi0/0/1 MPLS e obtém comutado diretamente à porta de acesso Gi0/0/0. Quando o tráfego vem da porta de acesso Gi0/0/0, toma o trajeto dado laços de Gi0/0/0 - > Gi0/0/2 - > Gi0/0/3 - > Gi0/0/1. A questão principal com esta ação alternativa é para a utilização QFP na plataforma ASR1000

12 como o processamento do pacote é feito duas vezes: LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit , Fa4.2380:2380 est 00:20: , Fa4.2381:2381 est 15:37:06 0 Este comportamento é documentado no erro Doc: CSCvi42964