Configurar o recurso de otimização TCP no Cisco IOS® Roteadores cEdge XE SD-WAN
Contents
Introdução
Este documento descreve o recurso de otimização do Transmission Control Protocol (TCP) nos roteadores SD-WAN Cisco IOS® XE, que foi introduzido na versão 16.12 em agosto de 2019. Os tópicos abordados são pré-requisitos, descrição do problema, solução, as diferenças nos algoritmos de otimização TCP entre Viptela OS (vEdge) e XE SD-WAN (cEdge), configuração, verificação e lista de documentos relacionados.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
As informações neste documento são baseadas no Cisco IOS® XE SD-WAN.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Problema
A alta latência em um link de WAN entre dois lados de SD-WAN causa mau desempenho do aplicativo. Você tem tráfego TCP crítico, que deve ser otimizado.
Solução
Ao usar o recurso Otimização de TCP, você melhora a taxa de transferência média de TCP para fluxos TCP críticos entre dois sites SD-WAN.
Observe a visão geral e as diferenças entre a otimização de TCP em cEdge Bottleneck Bandwidth and Round-trip (BBR) e vEdge (CUBIC)
O algoritmo de tempo de propagação BBR rápido é usado na implementação XE SD-WAN (no cEdge).
O Viptela OS (vEdge) tem um algoritmo diferente e mais antigo, chamado CUBIC.
O CUBIC leva em consideração principalmente a perda de pacotes e é amplamente implementado em diferentes sistemas operacionais clientes. Windows, Linux, MacOS, Android já têm CUBIC integrado. Em alguns casos, quando você tem clientes antigos executando a pilha TCP sem CUBIC, a ativação da otimização TCP no vEdge traz melhorias. Um dos exemplos, em que a otimização CUBIC de TCP do vEdge se beneficiou, está em submarinos que usam hosts clientes antigos e links de WAN que sofrem atrasos/quedas significativas. Observe que somente o vEdge 1000 e o vEdge 2000 suportam TCP CUBIC.
O BBR se concentra principalmente no tempo de ida e volta e na latência. Não em perda de pacotes. Se você enviar pacotes do oeste dos EUA para a costa leste ou até mesmo para a Europa através da internet pública, na maioria dos casos você não vê nenhuma perda de pacotes. Às vezes, a Internet pública é boa demais em termos de perda de pacotes. Mas o que você vê é atraso/latência. E esse problema é abordado pela BBR, que foi desenvolvida pela Google em 2016.
Resumindo, a BBR modela a rede e examina cada confirmação (ACK) e atualiza a largura de banda máxima (BW) e o tempo mínimo de ida e volta (RTT). Em seguida, o envio de controle é baseado no modelo: sonda para largura de banda máxima e RTT mínimo, ritmo próximo à estimativa de largura de banda e mantenha a operação perto do produto de atraso de largura de banda (BDP). O objetivo principal é garantir alto throughput com uma fila de gargalo pequena.
Este slide de Mark Claypool mostra a área onde o CUBIC opera:
A BBR opera em um lugar melhor, que é mostrado neste slide também de Mark Claypool:
Se você quiser ler mais sobre o algoritmo BBR, você pode encontrar várias publicações sobre BBR vinculadas na parte superior da página inicial da lista de discussão bbr-dev Aqui.
Em resumo:
| Plataforma e algoritmo |
Parâmetro de entrada de chave | Caso de uso |
| Borda (XE SD-WAN): BBR | RTT/Latência | Tráfego TCP crítico entre dois sites SD-WAN |
| vEdge (Viptela OS): CUBICP | Perda de pacote | Clientes antigos sem otimização TCP |
Plataformas XE SD-WAN suportadas
No XE SD-WAN SW versão 16.12.1d, essas plataformas cEdge suportam TCP Otimization BBR:
- ISR4331
- ISR4351
- CSR1000v com 8 vCPU e mín. 8 GB de RAM
Caveats
- Atualmente, não há suporte para todas as plataformas com menos de 8 GB de RAM.
- Atualmente, não há suporte para todas as plataformas com 4 ou menos núcleos de dados.
- A Otimização de TCP não suporta MTU 2000.
- No momento, não há suporte para tráfego IPv6.
- Não há suporte para a otimização do tráfego DIA para um servidor BBR de terceiros. Você precisa ter roteadores cEdge SD-WAN em ambos os lados.
- No cenário do data center atualmente, somente um nó de serviço (SN) é suportado por um nó de controle (CN).
- O caso de uso combinado com segurança (contêiner UTD) e otimização TCP no mesmo dispositivo não é suportado na versão 16.12. A partir da versão 17.2, o caso de uso combinado é suportado. A ordem de operação é TCP Opt primeiro, depois Security. O pacote será direcionado para o contêiner de otimização de TCP e, em seguida, o serviço será encadeado (sem segundo punt) para o contêiner de segurança UTD. A otimização de TCP é feita para o fluxo completo, não para os primeiros bytes. Se o UTD cair, a conexão completa será descartada.
Esta tabela resume as advertências por versão e sublinha as plataformas de hardware suportadas:
| Cenários |
Casos de uso |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
Comentários |
| Filial para Internet |
DIA |
No |
Yes |
Yes |
Yes |
Em 16.12.1, o AppQoE FIA não está habilitado na interface de Internet |
| SAAS |
No |
Yes |
Yes |
Yes |
Em 16.12.1, o AppQoE FIA não está habilitado na interface de Internet |
|
| Filial para DC |
Roteador de borda única |
No |
No |
No |
Yes |
Necessidade de oferecer suporte a vários SNs |
| Vários roteadores de borda |
No |
No |
No |
Yes |
Precisa de simetria de fluxo ou sincronização de fluxo Appnav. 16.12.1 não ensaiado com |
|
| Vários SNs |
No |
No |
No |
Yes |
Aprimoramento do vManage para aceitar vários IPs SN |
|
| De filial para filial |
Rede de malha completa (Spoke-to-Spoke) |
Yes |
Yes |
Yes |
Yes |
|
| Hub e spoke (Spoke-Hub-Spoke) |
No |
Yes |
Yes |
Yes |
||
| Suporte a BBR |
TCP Opt com BBR |
Parcial | Parcial |
Completo |
Completo |
|
| Plataformas |
Plataformas com suporte |
Somente 4300 e CSR |
Todos, exceto ISR1100 |
Todos |
Todos |
Configurar
Um conceito de SN e CN é usado para a otimização de TCP:
- SN é um daemon, que é responsável pela otimização real dos fluxos TCP.
- O CN é conhecido como AppNav Controller e é responsável pela seleção de tráfego e pelo transporte de/para o SN.
SN e CN podem ser executados no mesmo roteador ou separados como nós diferentes.
Há dois casos de uso principais:
- Caso de uso de filial com SN e CN sendo executados no mesmo roteador ISR4k.
- Caso de uso do data center, em que o CN é executado no ASR1k e o SN é executado em um roteador virtual CSR1000v separado.
Os dois casos de uso são descritos nesta seção.
Caso de uso 1. Configurar a otimização TCP em uma filial (todas em uma borda)
Esta imagem mostra a arquitetura interna geral para uma única opção independente em uma filial:
Etapa 1. Para configurar a otimização TCP, você precisa criar um modelo de recurso para a otimização TCP no vManage. Navegue até Configuration > Templates > Feature Templates > Other Templates > AppQoE como mostrado na imagem.
Etapa 2. Adicione o modelo de recurso AppQoE ao modelo de dispositivo apropriado em Modelos Adicionais:
Esta é a visualização CLI da configuração do modelo:
service-insertion service-node-group appqoe SNG-APPQOE
service-node 192.3.3.2
!
service-insertion appnav-controller-group appqoe ACG-APPQOE
appnav-controller 192.3.3.1
!
service-insertion service-context appqoe/1
appnav-controller-group ACG-APPQOE
service-node-group SNG-APPQOE
vrf global
enable
! !
interface VirtualPortGroup2
ip address 192.3.3.1 255.255.255.0
no mop enabled
no mop sysid
service-insertion appqoe
!
Etapa 3. Criar uma política de dados centralizada com a definição do tráfego TCP interessante para otimização.
Como um exemplo; essa política de dados corresponde ao prefixo IP 10.0.0.0/8, que inclui endereços de origem e destino e permite a otimização de TCP para ele:
Esta é a visualização da CLI da Política vSmart:
policy
data-policy _vpn-list-vpn1_TCPOpt_1758410684
vpn-list vpn-list-vpn1
sequence 1
match
destination-ip 10.0.0.0/8
!
action accept
tcp-optimization
!
!
default-action accept
!
lists
site-list TCPOpt-sites
site-id 211
site-id 212
!
vpn-list vpn-list-vpn1
vpn 1
!
!
!
apply-policy
site-list TCPOpt-sites
data-policy _vpn-list-vpn1_TCPOpt_1758410684 all
!
!
Caso de uso 2. Configurar a otimização TCP no data center com um SN externo
A principal diferença para o caso de uso de filial é a separação física de SN e CN. No caso de uso de filial all-in-one, a conectividade é feita dentro do mesmo roteador usando a Virtual Port Group Interface. No caso de uso do data center, há um túnel encapsulado de GRE do AppNav entre o ASR1k atuando como CN e o CSR1k externo sendo executado como SN. Não há necessidade de um link dedicado ou conexão cruzada entre CN e SN externo, o alcance IP simples é suficiente.
Há um túnel AppNav (GRE) por SN. Para uso futuro, onde vários SNs são suportados, recomenda-se usar a sub-rede /28 para a rede entre CN e SN.
Duas NICs são recomendadas em um CSR1k atuando como SN. A segunda NIC para o controlador SD-WAN é necessária se o SN tiver que ser configurado/gerenciado pelo vManage. Se o SN for configurado/gerenciado manualmente, a 2ª NIC será opcional.
Esta imagem mostra o Data Center ASR1k sendo executado como CN e o CSR1kv como Nó de Serviço SN :
A topologia do caso de uso do data center com ASR1k e CSR1k externo é mostrada aqui:
Este modelo de recurso AppQoE mostra o ASR1k configurado como Controlador:
CSR1k configurado como nó de serviço externo é mostrado aqui:
Caso de failover
Failover no caso de uso do data center com CSR1k atuando como SN, em caso de falha CSR1k externa:
- As sessões TCP que já existem são perdidas porque a sessão TCP no SN é encerrada.
- Novas sessões TCP são enviadas ao destino final, mas o tráfego TCP não é otimizado (desvio).
- Sem blackholing para tráfego interessante em caso de falha de SN.
A detecção de failover é baseada na pulsação do AppNav, que é de 1 pulsação por segundo. Após 3 ou 4 erros, o túnel é declarado inativo.
O failover no caso de uso da filial é semelhante - em caso de falha de SN, o tráfego é enviado diretamente ao destino sem ser otimizado.
Verificar
Use esta seção para confirmar se a sua configuração funciona corretamente.
Verifique a otimização de TCP na CLI com o uso deste comando da CLI e veja o resumo dos fluxos otimizados:
BR11-CSR1k#show plat hardware qfp active feature sdwan datapath appqoe summary TCPOPT summary ---------------- optimized flows : 2 expired flows : 6033 matched flows : 0 divert pkts : 0 bypass pkts : 0 drop pkts : 0 inject pkts : 20959382 error pkts : 88
BR11-CSR1k#
Esta saída fornece informações detalhadas sobre fluxos otimizados:
BR11-CSR1k#show platform hardware qfp active flow fos-to-print all
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
GLOBAL CFT ~ Max Flows:2000000 Buckets Num:4000000
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Filtering parameters:
IP1 : ANY
Port1 : ANY
IP2 : ANY
Port2 : ANY
Vrf id : ANY
Application: ANY
TC id: ANY
DST Interface id: ANY
L3 protocol : IPV4/IPV6
L4 protocol : TCP/UDP/ICMP/ICMPV6
Flow type : ANY
Output parameters:
Print CFT internal data ? No
Only print summary ? No
Asymmetric : ANY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
keyID: SrcIP SrcPort DstIP DstPort L3-Protocol L4-Protocol vrfID
==================================================================
key #0: 192.168.25.254 26113 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26113 IPv4 TCP 3
==================================================================
key #0: 192.168.25.254 26173 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26173 IPv4 TCP 3
==================================================================
key #0: 10.212.1.10 52255 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52255 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 1, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 1, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
key #0: 10.212.1.10 52254 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52254 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 158, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 243, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Number of flows that passed filter: 4
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FLOWS DUMP DONE.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BR11-CSR1k#
Troubleshooting
O seguinte CLI ajudará a identificar problemas com um fluxo TCP específico.
Todos os exemplos foram tirados da imagem SD-WAN 17.2.1 do IOS XE em execução no ISR4431.
- Descubra a ID do VRF (que não é igual ao nome do VRF). Nesse caso, vemos na saída abaixo, que o VPN de serviço (VRF) 1 tem o VRF Id 2:
AppQoE_R2#show vrf detail
VRF 1 (VRF Id = 2); default RD 1:1; default VPNID <not set>
New CLI format, supports multiple address-families
Flags: 0x180C
Interfaces:
Gi0/0/3
…
- Descubra o ID de fluxo apropriado para o cliente na vpn de serviço - vemos aqui 4 fluxos diferentes entre dois clientes Windows usando o compartilhamento SMB pela porta TCP 445:
AppQoE_R2#show sdwan appqoe flow vpn-id 2 client-ip 192.168.200.50
Optimized Flows
---------------
T:TCP, S:SSL, U:UTD
Flow ID VPN Source IP:Port Destination IP:Port Service
15731593842 2 192.168.200.50:49741 192.168.100.50:445 T
17364128987 2 192.168.200.50:49742 192.168.100.50:445 T
25184244867 2 192.168.200.50:49743 192.168.100.50:445 T
28305760200 2 192.168.200.50:49744 192.168.100.50:445 T
AppQoE_R2#
- Consulte estatísticas de TCP Opt para obter o fluxo apropriado:
AppQoE_R2#show sdwan appqoe flow flow-id 15731593842
VPN: 2 APP: 0 [Client 192.168.200.50:49741 - Server 192.168.100.50:445]
TCP stats
---------
Client Bytes Received : 14114
Client Bytes Sent : 23342
Server Bytes Received : 23342
Server Bytes Sent : 14114
TCP Client Rx Pause : 0x0
TCP Server Rx Pause : 0x0
TCP Client Tx Pause : 0x0
TCP Server Tx Pause : 0x0
Client Flow Pause State : 0x0
Server Flow Pause State : 0x0
TCP Flow Bytes Consumed : 0
TCP Client Close Done : 0x0
TCP Server Close Done : 0x0
TCP Client FIN Rcvd : 0x0
TCP Server FIN Rcvd : 0x0
TCP Client RST Rcvd : 0x0
TCP Server RST Rcvd : 0x0
TCP FIN/RST Sent : 0x0
Flow Cleanup State : 0x0
TCP Flow Events
1. time:2196.550604 :: Event:TCPPROXY_EVT_FLOW_CREATED
2. time:2196.550655 :: Event:TCPPROXY_EVT_SYNCACHE_ADDED
3. time:2196.552366 :: Event:TCPPROXY_EVT_ACCEPT_DONE
4. time:2196.552665 :: Event:TCPPROXY_EVT_CONNECT_START
5. time:2196.554325 :: Event:TCPPROXY_EVT_CONNECT_DONE
6. time:2196.554370 :: Event:TCPPROXY_EVT_DATA_ENABLED_SUCCESS
AppQoE_R2#
- Veja também estatísticas de TCP Opt genéricas, que também mostram 4 fluxos otimizados:
AppQoE_R2#show tcpproxy statistics
==========================================================
TCP Proxy Statistics
==========================================================
Total Connections : 6
Max Concurrent Connections : 4
Flow Entries Created : 6
Flow Entries Deleted : 2
Current Flow Entries : 4
Current Connections : 4
Connections In Progress : 0
Failed Connections : 0
SYNCACHE Added : 6
SYNCACHE Not Added:NAT entry null : 0
SYNCACHE Not Added:Mrkd for Cleanup : 0
SYN purge enqueued : 0
SYN purge enqueue failed : 0
Other cleanup enqueued : 0
Other cleanup enqueue failed : 0
Stack Cleanup enqueued : 0
Stack Cleanup enqueue failed : 0
Proxy Cleanup enqueued : 2
Proxy Cleanup enqueue failed : 0
Cleanup Req watcher called : 135003
Total Flow Entries pending cleanup : 0
Total Cleanup done : 2
Num stack cb with null ctx : 0
Vpath Cleanup from nmrx-thread : 0
Vpath Cleanup from ev-thread : 2
Failed Conn already accepted conn : 0
SSL Init Failure : 0
Max Queue Length Work : 1
Current Queue Length Work : 0
Max Queue Length ISM : 0
Current Queue Length ISM : 0
Max Queue Length SC : 0
Current Queue Length SC : 0
Total Tx Enq Ign due to Conn Close : 0
Current Rx epoll : 8
Current Tx epoll : 0
Paused by TCP Tx Full : 0
Resumed by TCP Tx below threshold : 0
Paused by TCP Buffer Consumed : 0
Resumed by TCP Buffer Released : 0
SSL Pause Done : 0
SSL Resume Done : 0
SNORT Pause Done : 0
SNORT Resume Done : 0
EV SSL Pause Process : 0
EV SNORT Pause Process : 0
EV SSL/SNORT Resume Process : 0
Socket Pause Done : 0
Socket Resume Done : 0
SSL Pause Called : 0
SSL Resume Called : 0
Async Events Sent : 0
Async Events Processed : 0
Tx Async Events Sent : 369
Tx Async Events Recvd : 369
Tx Async Events Processed : 369
Failed Send : 0
TCP SSL Reset Initiated : 0
TCP SNORT Reset Initiated : 0
TCP FIN Received from clnt/svr : 0
TCP Reset Received from clnt/svr : 2
SSL FIN Received -> SC : 0
SSL Reset Received -> SC : 0
SC FIN Received -> SSL : 0
SC Reset Received -> SSL : 0
SSL FIN Received -> TCP : 0
SSL Reset Received -> TCP : 0
TCP FIN Processed : 0
TCP FIN Ignored FD Already Closed : 0
TCP Reset Processed : 4
SVC Reset Processed : 0
Flow Cleaned with Client Data : 0
Flow Cleaned with Server Data : 0
Buffers dropped in Tx socket close : 0
TCP 4k Allocated Buffers : 369
TCP 16k Allocated Buffers : 0
TCP 32k Allocated Buffers : 0
TCP 128k Allocated Buffers : 0
TCP Freed Buffers : 369
SSL Allocated Buffers : 0
SSL Freed Buffers : 0
TCP Received Buffers : 365
TCP to SSL Enqueued Buffers : 0
SSL to SVC Enqueued Buffers : 0
SVC to SSL Enqueued Buffers : 0
SSL to TCP Enqueued Buffers : 0
TCP Buffers Sent : 365
TCP Failed Buffers Allocations : 0
TCP Failed 16k Buffers Allocations : 0
TCP Failed 32k Buffers Allocations : 0
TCP Failed 128k Buffers Allocations : 0
SSL Failed Buffers Allocations : 0
Rx Sock Bytes Read < 512 : 335
Rx Sock Bytes Read < 1024 : 25
Rx Sock Bytes Read < 2048 : 5
Rx Sock Bytes Read < 4096 : 0
SSL Server Init : 0
Flows Dropped-Snort Gbl Health Yellow : 0
Flows Dropped-Snort Inst Health Yellow : 0
Flows Dropped-WCAPI Channel Health Yellow : 0
Total WCAPI snd flow create svc chain failed : 0
Total WCAPI send data svc chain failed : 0
Total WCAPI send close svc chain failed : 0
Total Tx Enqueue Failed : 0
Total Cleanup Flow Msg Add to wk_q Failed : 0
Total Cleanup Flow Msg Added to wk_q : 0
Total Cleanup Flow Msg Rcvd in wk_q : 0
Total Cleanup Flow Ignored, Already Done : 0
Total Cleanup SSL Msg Add to wk_q Failed : 0
Total UHI mmap : 24012
Total UHI munmap : 389
Total Enable Rx Enqueued : 0
Total Enable Rx Called : 0
Total Enable Rx Process Done : 0
Total Enable Rx Enqueue Failed : 0
Total Enable Rx Process Failed : 0
Total Enable Rx socket on Client Stack Close : 0
Total Enable Rx socket on Server Stack Close : 0
AppQoE_R2#
Usando o TCPOpt com outros recursos AppQoE/UTD a partir de 17.2
Na versão 16.12, o principal caso de uso para o TCPOpt é Filial a Filial. Há um redirecionamento separado para o Proxy TCP e um redirecionamento separado para o contêiner UTD em 16.12, é por isso que o TCP Opt não funciona junto com a Segurança em 16.12
Em 17.2, um caminho de política centralizado é implementado, o que detectará a necessidade de TCP Opt e Security.
Os pacotes liberados serão redirecionados para o plano de serviço (punted) apenas uma vez.
Diferentes opções de fluxo são possíveis começando do 17.2:
- Somente TCP Opt
- Somente UTD
- TCP Opt -> UTD
- TCP Opt -> Proxy SSL -> UTD
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
29-Jan-2020 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)