IPFIX avançado: VRF, next-hop BGP, túneis e DPI no EdgeWarden

Quais campos IPFIX alimentam VRF Visibility, Flow Explorer e Aplicações (DPI), o que cada fabricante exporta de fato e como configurar e conferir.

Além da 5-tupla

Endereços, portas, protocolo e contadores bastam para detectar um ataque volumétrico. Os campos opcionais do IPFIX respondem às perguntas seguintes: qual cliente de L3VPN está sendo atacado, por qual vizinho BGP o ataque entra e se aquela rajada em UDP/53 é consulta legítima ou reflexão. Isso decide onde mitigar e quem avisar.

Este guia mostra quais campos o EdgeWarden lê, em que tela cada um aparece, o que cada fabricante exporta segundo a própria documentação e como ligar esses campos onde o suporte é confirmado.

Pré-requisitos

  • Exportação IPFIX básica funcionando, com o roteador cadastrado em Configurações → Rede → Dispositivos e SNMP ativo. Se ainda não chegou lá, comece pelos guias de Juniper MX, Cisco ou Huawei.
  • Rotas BGP no roteador exportador. Sem a rota, ASN e next-hop chegam zerados. O EdgeWarden completa o ASN pela base ip2asn, mas não tem como inventar o next-hop.
  • Janela de manutenção: nos passos abaixo você altera records e filtros aplicados às interfaces.

Os campos e as telas

Campo IPFIXIEOnde aparece no EdgeWarden
ingressVRFID / egressVRFID234 / 235VRF Visibility e Analisador de Rede
bgpSourceAsNumber / bgpDestinationAsNumber16 / 17Flow Explorer (eixo AS), Análise de AS e Peering Analytics
bgpNextHopIPv4Address / bgpNextHopIPv6Address18 / 63Analisador de Rede, dimensão BGP Next Hop
layer2SegmentId (VNI)351Analisador de Rede, dimensões Tipo Túnel e ID Túnel
dataLinkFrameSection315Aplicações (DPI): TLS SNI, HTTP Host e DNS

Sem o IE 18 ou o 63, o EdgeWarden usa o next-hop IP comum (IE 15 ou 62). Nesse caso o valor é o próximo salto imediato, não o vizinho que anunciou a rota.

Túneis não exigem campo extra. O EdgeWarden classifica VxLAN (UDP 4789), GENEVE (UDP 6081), L2TP (UDP 1701), MPLS-in-UDP (UDP 6635), GRE e IP-in-IP pelo cabeçalho externo de qualquer flow. O IE 351 só acrescenta o VNI; sem ele, o túnel aparece classificado e com ID vazio.

O que cada fabricante exporta

Resumo do que conferimos na documentação oficial. "Não documentado" quer dizer que não encontramos o campo, não que ele com certeza falte na sua versão.

PlataformaVRF (IE 234/235)ASN e next-hop BGPPacket section (IE 315)
Cisco IOS XE (Flexible NetFlow)Sim: match routing vrf input / outputSim: collect routingNão documentado
Cisco IOS XRProvável: confira no cacheSim, no record fixoASR 9000: só até o cabeçalho L4
Juniper MX (inline J-Flow)Não consta no templateSim: IE 16, 17, 18 e 63Sim, por inline monitoring (Junos 19.4R1+)
Huawei NE40E/NE8000Não confirmadoSim: origin-as bgp-nexthopNão documentado
MikroTik RouterOS v7NãoNão; só o campo gatewayNão
  • Cisco IOS XE: a referência de comandos do Flexible NetFlow não traz comando para o IE 315. O collect ipv4 section header exporta o IE 313, que o EdgeWarden ignora quando o registro já traz endereços, e o IE 314 (section payload) não é lido. Por esse caminho não há DPI.
  • Cisco IOS XR: os exemplos de IPFIX da Cisco para o ASR 9000 mostram InputVRFID, OutputVRFID, BGPNextHopV6 e ASN de origem no cache do monitor. Por padrão o record traz o AS de origem; record ipv4 peer-as troca pelo AS vizinho. Mantenha o padrão: o EdgeWarden espera o AS de origem. O IPFIX 315 do ASR 9000 corta o quadro no cabeçalho L4, funciona só na entrada, em linecards de 3ª e 4ª geração, e não pode ser ligado numa interface que já tem monitores IPv4, IPv6 ou MPLS: o EdgeWarden reconstrói a 5-tupla, mas não há carga útil para extrair SNI, Host ou DNS.
  • Huawei: ip netstream export version aceita route-distinguisher apenas no formato 9, não no ipfix, e a documentação não diz em qual campo o valor vai. Para ASN e next-hop, use ip netstream export version ipfix origin-as bgp-nexthop ttl, como no guia Huawei.
  • MikroTik: nenhum campo de /ip traffic-flow ipfix traz VRF, ASN ou next-hop BGP. O gateway é o próximo salto do flow, e o ASN vem da base ip2asn do EdgeWarden.

Passo 1: VRF, ASN e next-hop BGP no Cisco IOS XE

Acrescente os campos aos records do guia Cisco. A Cisco exige tirar o monitor de todas as interfaces antes de alterar o record; depois, reaplique. O exemplo mostra uma interface: repita a remoção e a reaplicação em cada interface onde o monitor está.

IOS XE: campos de VRF e BGP nos records
interface GigabitEthernet0/0/1
 no ip flow monitor EW-MON-V4 sampler EW-SAMP input
 no ipv6 flow monitor EW-MON-V6 sampler EW-SAMP input
!
flow record EW-REC-V4
 match routing vrf input
 collect routing source as 4-octet
 collect routing destination as 4-octet
 collect routing next-hop address ipv4 bgp
!
flow record EW-REC-V6
 collect routing source as 4-octet
 collect routing destination as 4-octet
 collect routing next-hop address ipv6 bgp
!
interface GigabitEthernet0/0/1
 ip flow monitor EW-MON-V4 sampler EW-SAMP input
 ipv6 flow monitor EW-MON-V6 sampler EW-SAMP input
  • 4-octet exporta o ASN em 4 bytes; sem ele, o campo tem 2 bytes e não comporta ASNs de 32 bits. Não use peer: ele troca o AS de origem pelo AS vizinho e o exporta em outros campos (IE 128/129), que o EdgeWarden não lê.
  • match routing vrf output existe desde o IOS XE 3.8S, mas exige monitor output. Somado ao input, o mesmo pacote é contado duas vezes. Prefira só a VRF de entrada.
  • O exemplo de VRF da Cisco usa um record IPv4. Se a sua plataforma aceitar, acrescente match routing vrf input também ao EW-REC-V6. Se recusar alguma linha, remova só ela e confira os campos com show flow record.

Passo 2: next-hop BGP preciso no Juniper MX

O template IPFIX do MX já traz ASN e next-hop BGP (IE 16, 17, 18 e 63). Quando o destino tem vários caminhos, porém, o next-hop IP (IE 15) e a interface de saída (IE 14) mostram o primeiro caminho da tabela de encaminhamento, e no IPv6 vêm zerados, até você ligar o nexthop-learning. O next-hop BGP tem o mesmo problema com tráfego balanceado entre vários peers BGP: o MX informa o primeiro da lista. A partir do Junos 24.2R1, nos MX240, MX480, MX960, MX2010 e MX2020, o multi-bgp-path informa o vizinho correto, e ele depende do nexthop-learning.

Junos: aprendizado de next-hop e multi-bgp-path
set services flow-monitoring version-ipfix template ew-ipv4 nexthop-learning enable
set services flow-monitoring version-ipfix template ew-ipv6 nexthop-learning enable
set services flow-monitoring version-ipfix template ew-ipv4 multi-bgp-path
set services flow-monitoring version-ipfix template ew-ipv6 multi-bgp-path
commit check
commit confirmed 10
commit

Em versões anteriores ao 24.2R1 ou em outros modelos, omita as duas linhas de multi-bgp-path e confira o suporte no Feature Explorer da Juniper. Para IPv6, a Juniper também pede ipv6-extended-attrib na tabela de flows da FPC; a hierarquia aparece de forma diferente em páginas da própria documentação, então confira na sua versão. Com o recurso ligado, o fragmentIdentification (IE 54) passa a valer 0.

Passo 3: packet section para DPI no Juniper MX

O inline monitoring (MX com MPC a partir do Junos 19.4R1; MPC10E e MPC11E a partir do 20.4R1) exporta o pacote amostrado no IE 315, recortado a partir do cabeçalho Ethernet: até 126 bytes no Junos OS, até 256 no Junos OS Evolved. O exemplo amostra só DNS, em que o nome consultado costuma caber no recorte, e HTTP, em que o Host só cabe quando a linha de requisição é curta. Ele cobre IPv4; para IPv6, repita os termos num filtro family inet6.

Junos: inline monitoring de DNS e HTTP
set services inline-monitoring template ew-im-tpl template-refresh-rate 60
set services inline-monitoring template ew-im-tpl option-template-refresh-rate 60
set services inline-monitoring template ew-im-tpl observation-domain-id 2
set services inline-monitoring instance ew-im template-name ew-im-tpl
set services inline-monitoring instance ew-im maximum-clip-length 126
set services inline-monitoring instance ew-im collector ew-col source-address 198.51.100.1
set services inline-monitoring instance ew-im collector ew-col destination-address 192.0.2.10
set services inline-monitoring instance ew-im collector ew-col destination-port 2055
set services inline-monitoring instance ew-im collector ew-col sampling-rate 1000
set firewall family inet filter EW-IM term dns from protocol udp
set firewall family inet filter EW-IM term dns from port 53
set firewall family inet filter EW-IM term dns then inline-monitoring-instance ew-im
set firewall family inet filter EW-IM term dns then accept
set firewall family inet filter EW-IM term http from protocol tcp
set firewall family inet filter EW-IM term http from destination-port 80
set firewall family inet filter EW-IM term http then inline-monitoring-instance ew-im
set firewall family inet filter EW-IM term http then accept
set firewall family inet filter EW-IM term resto then accept
set interfaces xe-0/0/0 unit 0 family inet filter input EW-IM
commit check
commit confirmed 10
commit
  • O termo resto é obrigatório: sem ele, o descarte implícito do filtro derruba todo o resto do tráfego. Se a interface já tem filtro de entrada, acrescente os termos a ele em vez de trocar.
  • No Junos OS a taxa é por coletor, e a Juniper a anuncia no option data record (IE 34). O EdgeWarden guarda a taxa por exportador e domínio de observação. O observation-domain-id define só o byte mais significativo do domínio (os outros três são gerados pelo roteador); um valor próprio, como o 2 do exemplo, ajuda a manter a taxa do inline monitoring separada da do J-Flow.
  • O SNI do TLS costuma ficar além de 126 bytes. Com 256 bytes nem sempre cabe. Para SNI de verdade, use o Packet Sensor ou sFlow com cabeçalho amostrado maior que os 128 bytes padrão, se o equipamento permitir.

Os pacotes que o inline J-Flow já amostra voltam a ser contados pelo inline monitoring. O EdgeWarden não sabe que os dois registros descrevem o mesmo pacote, e o volume de DNS e HTTP daquele roteador sobe. Mantenha o filtro estreito e confira o quadro Fluxo × SNMP nas interfaces na tela Análise do instante.

Conferência no roteador

IOS XE: record e cache com VRF e BGP
show flow record EW-REC-V4
show flow monitor name EW-MON-V4 cache format record
Junos: estatísticas do inline monitoring
show services inline-monitoring statistics fpc-slot 0

No cache do IOS XE, os flows de interfaces em VRF devem mostrar a VRF de entrada e o next-hop BGP preenchidos. No Junos, os contadores do comando devem crescer a cada execução.

Conferência no EdgeWarden

  1. Em 1 a 2 minutos depois da mudança, abra a tela Flows e filtre pelo exportador 198.51.100.1.
  2. No Analisador de Rede, agrupe por VRF Ingress, BGP Next Hop e Tipo Túnel. Valor zero ou vazio em tudo indica campo ausente no template.
  3. Em VRF Visibility, cadastre cada ID numérico com nome, RD e cliente. A tela separa o tráfego por instância.
  4. Em Aplicações (DPI), a coluna Tipo mostra TLS SNI, HTTP ou DNS quando a identificação veio do pacote. DNS Cache indica DNS passivo.
  5. Se o packet section chegou, o log registra a linha "IPFIX inline monitoring detectado". Acompanhe com journalctl -u flowspec-core -f.

Armadilhas comuns

  • Template antigo no coletor: os campos novos só são decodificados depois que o template novo chega ao coletor. Template refresh curto encurta a espera.
  • Interface de saída em outra VRF no MX: segundo a Juniper, máscara de destino, AS de destino, next-hop IP (IE 15) e interface de saída vêm zerados.
  • ASN zerado sem tabela completa: o Flow Explorer e a Análise de AS ficam vazios até a base ip2asn ser importada.
  • Filtro do inline monitoring pegando IPFIX: a Juniper avisa que amostrar o próprio tráfego IPFIX cria um laço. Não inclua a porta 2055 nos termos.
  • Cota da licença: um source-address diferente para o inline monitoring vira outro exportador e ocupa outra vaga.

Packet section carrega pedaços reais de pacotes de clientes, inclusive nomes consultados. Restrinja a 2055/UDP aos IPs dos roteadores e trate esses dados conforme a sua política de privacidade.

Próximos passos

Se nenhum flow chegar, siga o checklist Nenhum flow aparece no EdgeWarden?. Para comparar com o sFlow, que carrega o cabeçalho bruto, veja NetFlow v5, v9, IPFIX ou sFlow?. Para a configuração base, veja os guias de Juniper MX, Cisco, Huawei e MikroTik. Revise portas e buffers no guia de instalação e veja em Recursos como esses campos entram na detecção.

Artigos relacionados

Todos os artigos

Quer ver esses flows no EdgeWarden?

Peça uma demonstração com a exportação da sua própria rede, ou siga o guia de instalação para subir o coletor.