(Mão na massa) Vimos no post anterior as opções de marcações. Agora vamos ver como fazer e usar as marcações para dar tratamento diferenciado para o tráfego. Classification O primeiro passo é fazer a classificação (identificação) do tráfego, e para isso usamos o class-map. No Cisco IOS usamos o MQC (composto por class-map, policy-map e service-policy) para configurar o QoS. Como citado anteriormente, podemos especificar uma ACL ou olhar diretamente no pacote para fazer a classificação. Exemplo de classificação usando class-map, onde identificaremos os seguintes tráfegos: Tráfego que der match na ACL ipv6SSH (TCP porta 22) Tráfego Telnet com marcação CS6 Tráfego ICMP e ICMPv6 QoS#conf t QoS(config)#ipv6 access-list ipv6SSH QoS(config-ipv6-acl)# permit tcp any any eq 22 QoS(config-ipv6-acl)# permit tcp any eq 22 any QoS(config-ipv6-acl)#exit QoS(config)# QoS(config)#class-map match-all CLASSSSH QoS(config-cmap)# match access-group name ipv6SSH QoS(config-cmap)#class-map match-all CLASSTELNET QoS(config-cmap)# match protocol telnet QoS(config-cmap)# match dscp cs6 QoS(config-cmap)#class-map match-any CLASSICMP QoS(config-cmap)# match protocol icmp QoS(config-cmap)# match protocol ipv6-icmp QoS(config-cmap)#end QoS# Note que temos dois tipos de class-map: match-all (padrão) e match-any. Quando temos a opção match-all, apenas se o pacote atender todas as especificações ele será selecionado. No caso do match-any, como usado no class-map CLASSICMP, se o tráfego atender pelo menos um dos requisições ele já e classificado. Ou seja, se for icmp ou icmpv6 ele será classificado pelo CLASSICMP, enquanto que para ser classificado pelo CLASSTELNET o pacote precisar ser telnet e ter a marcação CS6. Também é importante ressaltar que apesar de não ter sido configurado, temos a class-default, onde os demais pacotes serão enquadrados. Marking Agora que fizemos a classificação do nosso tráfego, precisamos tomar uma ação, e fazemos isso usando o comando policy-map. As ações podem ser marcar o pacote, definir banda, escolher o tipo de fila, shape/policing,…. Mas por enquanto vamos fazer apenas a marcação. Configurando o Policy-Map para: Marcar o tráfego SSH com CS6 Marcar o ICMP com EF Todo o resto com DSCP 0 QoS#conf t QoS(config)#policy-map MARCA QoS(config-pmap)# class CLASSSSH QoS(config-pmap-c)# set dscp cs6 QoS(config-pmap-c)# class CLASSICMP QoS(config-pmap-c)# set dscp ef QoS(config-pmap-c)# class CLASSTELNET QoS(config-pmap-c)# class class-default QoS(config-pmap-c)# set dscp default QoS(config-pmap-c)#end QoS# Observe que inserimos a class CLASSTELNET mas não tomamos nenhuma ação (marcação). Neste caso o tráfego vai passar sem ser alterado. Vamos associar nosso policy-map à interface (no sentido inbound) e verificar a configuração. QoS#conf t QoS(config)#int et0/0 QoS(config-if)#service-policy input MARCA QoS(config-if)#end QoS# QoS#show policy-map interface et0/0 Ethernet0/0 Service-policy input: MARCA Class-map: CLASSSSH (match-all) 11941 packets, 922918 bytes 30 second offered rate 0000 bps, drop rate 0000 bps Match: access-group name ipv6SSH QoS Set dscp cs6 Packets marked 11941 Class-map: CLASSICMP (match-any) 4039 packets, 4059374 bytes 30 second offered rate 0000 bps, drop rate 0000 bps Match: protocol icmp 0 packets, 0 bytes 30 second rate 0 bps Match: protocol ipv6-icmp 4039 packets, 4059374 bytes 30 second rate 0 bps QoS Set dscp ef Packets marked 4039 Class-map: CLASSTELNET (match-all) 2665 packets, 197384 bytes 30 second offered rate 0000 bps Match: protocol telnet Match: dscp cs6 (48) Class-map: class-default (match-any) 4 packets, 304 bytes 30 second offered rate 0000 bps, drop rate 0000 bps Match: any QoS Set dscp default Packets marked 4 QoS# Idealmente a marcação é feita o mais perto possível da origem do tráfego (normalmente por um switch). Após a marcação os demais elementos da rede ficam encarregados de garantir o mesmo tratamento para o tráfego com a mesma marcação. Também pode acontecer do dispositivo final (um telefone IP, por exemplo) fazer a marcação nos seus pacotes, mas é importante tomar medidas para evitar que alguém passe a enviar tráfego marcado e assim ser tratado com prioritário (um usuário poderia fazer com que sua máquina envie tráfego com marcação EF, e os roteadores passariam a priorizar este tráfego). Assim a melhor opção é configurar a marcação nos switches, onde você define que tráfego receberá qual marcação (ou confiar apenas na marcação que vier de dispositivos confiáveis). Congestion Management O gerenciamento de congestionamento permite determinarmos a ordem em que pacotes são enviados por uma interface com base nas prioridades atribuídas a esses pacotes, e envolve a criação de filas, atribuição de pacotes a essas filas e agendamento para transmissão. Resumindo… classificamos, marcamos e agora vamos dar o tratamento diferenciado com base na marcação. Considera-se congestionamento quando as filas em hardware estão cheias Por padrão, quando configuramos uma classe ela trabalha no modo FIFO – First In First Out. Ou seja, primeiro pacote que entra é o primeiro que sai, sendo que cada classe está sujeita ao limite de velocidade especificado para o momento de congestionamento. Podemos no entanto mudar o tipo de fila para WFQ – Weighted Fair Queueing (ou CBWFQ- Class Based Weighted Fair Queueing já que estamos usando o modelo de configuração usando classes). O CBWFQ associa um peso (a conta leva em consideração o IPP) para cada flow, e os flows com pesos menores são encaminhados primeiro. Vamos criar outro policy-map, onde: ICMP deverá ter 128 Kbps, e ser colocado na fila prioritária (LLC) SSH deverá ter 10% da banda Telnet deverá ter 20% da banda Configurar a class-default para usar WFQ QoS#conf t QoS(config)#policy-map QUEUES QoS(config-pmap)# class CLASSICMP QoS(config-pmap-c)# priority 128 QoS(config-pmap-c)# class CLASSSSH QoS(config-pmap-c)# bandwidth percent 10 QoS(config-pmap-c)# class CLASSTELNET QoS(config-pmap-c)# bandwidth percent 20 QoS(config-pmap-c)# class class-default QoS(config-pmap-c)# fair-queue QoS(config-pmap-c)#end QoS# Importante notar que: quando colocamos bandwidth percent estamos reservando uma porcentagem com base no comando bandwitdth que foi aplicado na interface, e não na velocidade da porta (neste exemplo a interface et0/1 do roteador QoS foi configurada com o comando bandwitdh 256 Bkps). Se primeiro configuramos as classes com o comando bandwidth e depois mudamos o bandwidth na interface, as políticas não são atualizadas. Se não houver nenhuma configuração de bandwidth na interface, é considerado o valor real/físico. Podemos especificar o valor em Kbps (ao invés de percent) quando usamos
QoS – Quality of Service (Parte 1)
(É uma bagunça) QoS – Quality of Service é uma das partes mais complexas de redes (pelo menos pra mim). A configuração requer dezenas de comandos, e temos várias ferramentas, conceitos e mecanismos que devemos usar em conjunto. Além disso nem sempre é fácil fazer o dimensionamento da solução (quais os tipos de tráfego? quais marcações? quanto de banda? o que é prioritário? Usar Shape/Policing? E por ai vai…). Minha ideia neste post (e nos próximos) é mostrar/separar as principais ferramentas e “siglas” utilizadas quando falamos de QoS. Nesta série de posts estarei considerando apenas o modelo DiffServ, que é o mais comumente utilizado. Neste modelo o tratamento do tráfego é feito individualmente a cada “salto” (PHB – Per-Hop Behaviors). Campos e Marcações Para darmos tratamento diferenciado os pacote precisam ser identificados. Podemos fazer isso usando uma access-list onde especificamos endereços (origem e/ou destino) e portas (origem e/ou destino), ou olhar diretamente no cabeçalho (camada 2 ou 3) do pacote, procurando pelos campos/marcações abaixo: ToS – Type of Service: Campo, com 8 bits, no cabeçalho IP (camada 3). IPP – IP Precedence: Os três primeiros 3 bits (da esquerda para direita) do ToS formam um “subcampo” chamado IP Precedence. Neste campo é que podemos fazer a marcação do pacote (temos 8 opções). DS – Differentiated Services: Posteriormente foi criado o padrão DiffService, que redefiniu o campo ToS, que passou a ser chamado DS. DSCP – Differentiated Services Code Point: Com o padrão DiffSercive o campo IPP (que existia no ToS) passou de 3 para 6 bits e foi renomeado para DSCP. CS – Class Selector: Com a mudança de ToS para DS, passamos a ter dois padrões, e o CS veio para criar uma forma de acomodar ambos. Lembre-se que o ToS tinha o campo IPP (3 primeiros bits) e o DS agora tem o campo DSCP (6 primeiros bits). Com o CS podemos identificar/marcar os 3 primeiros bits do campo DSCP de forma que equipamentos que conhecem apenas o ToS podem ainda tratar o tráfego como desejado. AF – Assured Forwarding: O AF é outra padronização para marcação do campo DSCP. No AF temos 4 classes e 3 níveis de probabilidade de drop (totalizando 12 possíveis marcações). O AF tem o formado AFxy, onde o “x” representa a “prioridade” (quanto maior, mais prioritário) e o “y” representa a possibilidade de drop (quanto maior, mais chance de ser dropado). EF – Expedited Forwarding: Marcação que deve ser feita no tráfego mais importante. Esta marcação (DSCP recomendado: 101110) junto com outras funcionalidades pode criar reserva de banda com garantia de prioridade. Este conceito veio do modelo IntServ, que garante a banda para o tráfego de maneira fim a fim (diferente do conceito do DiffServ, que é PHB). CoS – Class of Service: No cabeçalho de camada 2 (ethernet) temos o campo Tag, e os três primeiros bits deste campo são usados para a marcação. MPLS Experimental: Campo (3 bits) no cabeçalho MPLS dedicados para a marcação dos pacotes. Filas Após o pacote ser marcado, precisamos separá-los em filas (veremos isso no próximo post). Temos filas em hardware e em software. As filas em hardware usam FIFO (First In First Out) e este comportamento não pode ser mudado. Já as filas em software são muito flexíveis, e nos permitem varias opções de configuração. Assim sendo, a opção que nos resta é trabalhar as filas em software, onde podemos criá-las (até 64), escolher o tamanho, decidir quais pacotes vão para cada fila e qual o tratamento será dado. Para isso (criar e configurar as filas em software) usamos o CBWFQ – Class Based Weighted Fair Queuing e o LLQ – Low Latency Queuing (ambos são configurados através do MQC – Modular Quality of Service Command Line Interface). De acordo com a configuração realizada os pacotes são colocados nas respectivas filas em software, e posteriormente são encaminhamos para as filas em hardware para enfim serem encaminhados. Abaixo um gráfico do CiscoLive! com as recomendações de marcações e tratamento para cada tipo de tráfego. Referências: CCIE Routing and Switching v5.0, Volume 2 Campus QoS Design Simplified QoS: DiffServ for Quality of Service Overview Até a próxima.
High Density WiFi, Co-Channel Interference e Cisco RX-SOP
(E o foco?) A regra mais básica de um projeto WiFi é: Não utilize o mesmo canal em access-points que estão próximos. Contudo, como temos apenas 3 canais (1, 6, 11) que não se sobrepõe em 2.4 GHz, quando temos mais de 3 access-points acabamos tendo a reutilização de canais. Se estes access-points estiverem próximos, teremos a Co-Channel Interference (CCI). Como o WiFi usa um meio de transmissão compartilhado (o ar), quando um dispositivo está transmitindo outro no mesmo canal não deve transmitir, ou ocorreriam colisões e retransmissões. O controle de quando transmitir ou não é feito pelo CCA – Clear Channel Assessment, que verifica se o meio está disponível (se não escuta nada com potência maior do que –85 dBm). Isso é bem comum em ambientes de alta densidade, mas também também acontece em ambientes normais, afinal podemos ter access-points vizinhos, que não estão sob nossa gerência, usando os mesmos canais, ou canais adjacentes. Com dois access-points usando o mesmo canal, temos menos espectro disponível (já que apenas um pode transmitir por vez), diminuindo consideravelmente a performance da rede. Uma opção para amenizar o problema seria diminuir a potência de transmissão dos access-points, diminuindo também a área de cobertura. Outra opção, é aumentar o bitrate mínimo permitido para conexão. Podemos configurar o access-point para permitir conexão apenas de dispositivos que suportem ao menos 18 Mbps. Nesta opção também estamos diminuindo a área de cobertura, já que para suportar esta taxa de transmissão mínima o dispositivo precisa estar mais próximo do AP, mas pelo menos ganhamos em desempenho. Apesar de estar ilustrando o funcionamento em uma WLC Cisco, todos estes conceitos são aplicáveis aos demais fabricantes, desde que permitam acesso a estas configurações. Mas é importante notar que só teremos ganhos com estas configurações se a interferência estiver sendo causada por access-points que temos acesso (do que adiantaria diminuir a potência de transmissão do seu AP, se ele continua ouvindo o AP do vizinho?). Cisco RX-SOP Ai que entra o RX-SOP. O Receiver Start of Packet Detection Threshold (RX-SOP) instrui o access-point à ignorar pacotes “ouvido” a partir de certa potência (habilita um filtro no recebimento). De uma forma bem simples, configuramos o access-point para ouvir menos. Com a necessidade de cobrir áreas com muitos usuários por metro quadrado (auditório, salas de aula, estádios), normalmente utilizando muitos access-points, a Cisco se viu obrigada a criar funcionalidades que pudessem ajudar nestes casos (aliás deu até um nome para este conjunto de funcionalidades e conceitos: HDX – High Density Experience). E o RX-SOP é uma desta funcionalidade! O RX-SOP foi disponibilizado na interface gráfica a partir da versão 8.0, mas antes já era possível configurá-lo pela linha de comando. O AP passa a “ouvir” menos interferências, mas também não ouvirá os dispositivos mais distantes. Talvez por receio de má utilização a Cisco tenha demorado para deixar esta opção visível na interface gráfica. O RX-SOP permite 4 opções de configuração: High, Medium, Low e Auto. Veja na tabela abaixo os limites para cada opção. Quando configuramos o threshold como “High”, o AP passa a ignorar transmissões percebidas abaixo de –76 bBm em 5 GHz e –79 dBm em 2.4 GHz (funciona da mesma forma com os demais valores). Ou seja, habilitando o RX-SOP não teríamos problema de Co-Channel Interference no exemplo abaixo, e ambos access-points poderiam transmitir ao mesmo tempo. Todos os frames recebidos com RSSI mais fraco do que o configurado no RX-SOP são classificados como frames não-WiFi e não são decodificados pelo AP (são tratados como interferência não WiFi e detectados como ruído). Os access-points 1552, 1570, 1600, 1700, 2600, 2700, 3500, 3600 e 3700 suportam o RX-SOP (não achei informação, mas acredito que os modelos 1800, 2800 e 3800 também suportem). Mais informações: What Is Co-Channel Interference and Why Is It Important in High-Density WLANs? High Density Experience (HDX) Deployment Guide Até a próxima.
BGP Origin Path Attribute e Next Hop Self
(Mais uma semana começando…) Aproveitando o gancho do post anterior (e a topologia e a configuração…), vamos falar do Origin Path Attribute e do Next Hop Self. O Origin Path Attribute (um dos atributos que os anúncios BGP carregam), sinaliza como a rota foi inserida na tabela BGP originalmente. Podemos ver os códigos do Origin Path Attribute (“i”, “*” e “?”) quando inserimos o comando show ip bgp. IGP (i): Indica que a rota foi inserida no BGP originalmente através através dos comando network, neighbor default-originate ou aggregate-address (em alguns casos; veja abaixo). EGP (e): Indica que a rota foi inserida pelo Exterior Gateway Protocol, protocolo anterior ao BGP e já não utilizado. Note que não há relação entre EGP e eBGP. Incomplete (?): Sinaliza que a rota foi inserida no BGP através dos comandos redistribute, default-information originate ou aggregate-address (em alguns casos; veja abaixo). Quando usamos o comando aggregate-address para a sumarização manual, dependendo de como fazemos a configuração, a rota terá Origin Path Attribute “i” ou “?”. Se o as-set não for utilizado, a rota sumarizada terá o código “i”. Se o as-set for utilizado, tanto a rota sumarizada quanto as rotas componentes (que fazem parte da rota sumarizada), terão o código “i”. Se a opção as-set for utilizada, mas existir ao menos uma rota componente com código “?”, a rota agregada terá o Origin Code “?”. A coluna Patch mostra como a rota foi inserida no BGP inicialmente. R2#sh ip bgp BGP table version is 38, local router ID is 10.1.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 *>i 0.0.0.0 10.1.1.1 0 100 0 i *>i 4.4.4.4/32 10.1.1.1 0 100 0 ? * i 10.1.1.0/24 10.1.1.1 0 100 0 ? *> 0.0.0.0 0 32768 ? *>i 10.10.0.0/24 10.1.1.1 0 100 0 ? *>i 172.16.0.0/24 10.1.1.1 0 100 0 ? R2# Rota default anunciada por R1, usando a opção neighbor default-originate (veja post anterior). R2#sh ip bgp 0.0.0.0 BGP routing table entry for 0.0.0.0/0, version 27 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 Local 10.1.1.1 from 10.1.1.1 (172.16.0.1) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0 R2# Rota para 4.4.4.4 anunciada por R1, usando o comando redistribute static (veja poste anterior). R2#sh ip bgp 4.4.4.4 BGP routing table entry for 4.4.4.4/32, version 20 Paths: (1 available, best #1, table default) Not advertised to any peer Refresh Epoch 1 Local 10.1.1.1 from 10.1.1.1 (172.16.0.1) Origin incomplete, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0 R2# E por que isso importa? O BGP tem um longo processo para a escolha da melhor rota, e um dos passos para a escolha pode ser avaliar o Origin PA, sendo que uma rota (NLRI – Network Layer Reachability Information) com Origin PA IGP é preferida à uma rota EGP, que por sua vez é preferida a uma rota incomplete (?). Next Hop Self No post anterior tínhamos R1 e R2 no mesmo AS (10), enquanto R3 estava em um AS diferente (30). E na configuração do BGP no R1, tínhamos o comando neighbor 10.1.1.2 next-hop-self. R1#sh run | sec router router ospf 40 router bgp 10 bgp log-neighbor-changes redistribute connected redistribute static neighbor 10.1.1.2 remote-as 10 neighbor 10.1.1.2 next-hop-self neighbor 10.1.1.2 default-originate neighbor 10.10.0.2 remote-as 30 R1# Quando um roteador envia updates para um peer eBGP (roteador em outro AS), o NEXT_HOP Path Attribute é alterado para o IP do roteador que está fazendo o anúncio. Ou seja, no nosso exemplo, todos os updates que R3 recebe de R1 vem com o NEXT HOP 10.10.0.1 (IP utilizado por R1 para enviar os updates). R3#sh ip bgp BGP table version is 7, local router ID is 10.10.0.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 *> 3.3.3.3/32 0.0.0.0 0 32768 ? *> 4.4.4.4/32 10.10.0.1 0 0 10 ? *> 10.1.1.0/24 10.10.0.1 0 0 10 ? *> 10.10.0.0/24 0.0.0.0 0 32768 ? * 10.10.0.1 0 0 10 ? *> 172.16.0.0/24 10.10.0.1 0 0 10 ? R3# No entanto, quando R1 envia os updates para R2 (estão no mesmo AS) o NEXT HOP informado por padrão é o IP do último roteador eBGP por onde o anúncio passou. Com isso as rotas anunciadas por R3 chegariam ao R2 com o IP do R3, o que pode causar problemas no roteamento (se não houver uma rota para o NEXT HOP a rota não pode ser considerada best, ou ainda pode ser necessário a verificação recursiva, que causa aumento no consumo da CPU). Com o comando next-hop-self em R1: R2#sh ip bgp BGP table version is 8, local router ID is 10.1.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 *>i 0.0.0.0 10.1.1.1 0 100 0 i *>i 3.3.3.3/32 10.1.1.1 0 100 0 30 ? *>i 4.4.4.4/32 10.1.1.1 0 100 0 ? *> 10.1.1.0/24 0.0.0.0 0 32768 ? * i 10.1.1.1 0 100 0 ? *>i 10.10.0.0/24 10.1.1.1 0 100 0
Rota default no BGP
(Até a parte fácil é difícil) Existem três formas de adicionar uma rota default na tabela BGP. Vamos usar a topologia e as configurações abaixo, como ponto de partida, e mostrar estas opções. R1: interface Ethernet0/0ip address 10.1.1.1 255.255.255.0!interface Ethernet0/1ip address 10.10.0.1 255.255.255.0!interface Ethernet0/2ip address 172.16.0.1 255.255.255.0!router bgp 10redistribute connectedredistribute staticneighbor 10.1.1.2 remote-as 10neighbor 10.1.1.2 next-hop-selfneighbor 10.10.0.2 remote-as 30!ip route 0.0.0.0 0.0.0.0 172.16.0.2ip route 4.4.4.4 255.255.255.255 172.16.0.2 R2: interface Ethernet0/0ip address 10.1.1.2 255.255.255.0! router bgp 10redistribute connectedneighbor 10.1.1.1 remote-as 10 R3: interface Ethernet0/1ip address 10.10.0.2 255.255.255.0!router bgp 30redistribute connectedneighbor 10.10.0.1 remote-as 10 R4: interface Loopback4ip address 4.4.4.4 255.255.255.255!interface Loopback200ip address 200.1.1.1 255.255.255.255!interface Ethernet0/2ip address 172.16.0.2 255.255.255.0!ip route 10.1.1.0 255.255.255.0 172.16.0.1ip route 10.10.0.0 255.255.255.0 172.16.0.1 Redistribute + Default-Information Podemos inserir uma rota default no BGP usando os comandos redistribute e default-information originate. Observe que no roteador R1 temos uma rota default (estática) e também o comando redistribute static já configurado (redistribuindo a outra rota estática). No entanto a rota default não está na tabela BGP dos roteadores R1, R2 e R3. R1#sh ip route Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2 E1 – OSPF external type 1, E2 – OSPF external type 2 i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2 ia – IS-IS inter area, * – candidate default, U – per-user static route o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP a – application route + – replicated route, % – next hop override Gateway of last resort is 172.16.0.2 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 172.16.0.2 4.0.0.0/32 is subnetted, 1 subnets S 4.4.4.4 [1/0] via 172.16.0.2 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.1.1.0/24 is directly connected, Ethernet0/0 L 10.1.1.1/32 is directly connected, Ethernet0/0 C 10.10.0.0/24 is directly connected, Ethernet0/1 L 10.10.0.1/32 is directly connected, Ethernet0/1 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.0.0/24 is directly connected, Ethernet0/2 L 172.16.0.1/32 is directly connected, Ethernet0/2 R1# R1#sh ip bgp BGP table version is 11, local router ID is 172.16.0.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 *> 4.4.4.4/32 172.16.0.2 0 32768 ? *> 10.1.1.0/24 0.0.0.0 0 32768 ? * i 10.1.1.2 0 100 0 ? *> 10.10.0.0/24 0.0.0.0 0 32768 ? * 10.10.0.2 0 0 30 ? *> 172.16.0.0/24 0.0.0.0 0 32768 ? R1# R2#sho ip bgp BGP table version is 20, local router ID is 10.1.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 *>i 4.4.4.4/32 10.1.1.1 0 100 0 ? * i 10.1.1.0/24 10.1.1.1 0 100 0 ? *> 0.0.0.0 0 32768 ? *>i 10.10.0.0/24 10.1.1.1 0 100 0 ? *>i 172.16.0.0/24 10.1.1.1 0 100 0 ? R2# R3#sh ip bgp BGP table version is 16, local router ID is 10.10.0.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 *> 4.4.4.4/32 10.10.0.1 0 0 10 ? *> 10.1.1.0/24 10.10.0.1 0 0 10 ? * 10.10.0.0/24 10.10.0.1 0 0 10 ? *> 0.0.0.0 0 32768 ? *> 172.16.0.0/24 10.10.0.1 0 0 10 ? R3# Vamos agora inserir o comando default-information originate para que a rota default também seja redistribuída (sem esse comando o BGP redistribui as rotas estáticas, mas não a rota default). R1#conf t R1(config)#router bgp 10 R1(config-router)# default-information originate R1(config-router)#end R1# R1#sh ip bgp BGP table version is 12, local router ID is 172.16.0.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 *> 0.0.0.0 172.16.0.2 0 32768 ? *> 4.4.4.4/32 172.16.0.2 0 32768 ? *> 10.1.1.0/24 0.0.0.0 0 32768 ? * i 10.1.1.2 0 100 0 ? *> 10.10.0.0/24 0.0.0.0 0 32768 ? * 10.10.0.2 0 0 30 ? *> 172.16.0.0/24 0.0.0.0 0 32768 ? R1# R2#sh ip bgp BGP table version is 21, local router ID is 10.1.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 *>i 0.0.0.0 10.1.1.1 0 100 0 ? *>i 4.4.4.4/32 10.1.1.1 0 100 0 ? * i 10.1.1.0/24 10.1.1.1 0 100 0 ? *> 0.0.0.0 0 32768 ? *>i 10.10.0.0/24 10.1.1.1 0 100 0 ? *>i 172.16.0.0/24 10.1.1.1 0 100 0 ? R2# R3#sh ip bgp BGP table version is 17, local router ID is 10.10.0.2 Status codes: s suppressed, d
Internal Usage VLANs
(Era pra ser um post curto) O que faz o comando vlan internal allocation policy ascending (que já vem configurado nos switches Cisco)? Para responder isso precisamos falar de alguns outros itens antes. Primeiro é importante lembrar que o padrão 802.1Q suporta até 4096 VLANs, e a quantidade de VLANs que podem estar ativas em um switch depende do modelo. Segundo, em switches Cisco podemos criar VLANs de 1 à 1001 (standard) ou de 1006 à 4094 (extended). Os IDs de 1002 até 1005 são reservados, bem como as VLANs 0, 4095 e 4096, e não podem ser editadas ou deletadas. Terceiro, sabemos que switches multilayers (MLS – Multi Layer Switch), suportam roteamento. E para isso podemos usar uma SVI – Switched Virtual Interface, ou uma Routed Port (porta física onde desabilitamos o modo switch com o comando no switchport e associamos IP). Quando usamos uma SVI fazemos a associação dela com a respectiva VLAN explicitamente, ao colocar o mesmo ID na VLAN e na SVI. Já quando usamos uma Routed Port não fazemos nenhuma amarração, e aparentemente a porta não pertence a nenhuma VLAN. No entanto, internamente o switch aloca uma VLAN para cada porta física roteada. Isso porque o switch, apesar de fazer o papel de roteador, continua sendo um switch, e os trâmites internos são realizados com base em VLANs. Assim, para cada porta física L3 criada em um switch, é criada automaticamente uma VLAN (chamada internal usage VLAN) onde os protocolos L2 como Spanning-Tree são desabilitados. Estas VLANs não são divulgadas para outros switches e ficam “escondidas”. O que o comando vlan internal allocation policy ascending faz (finalmente…) é justamente instruir o switch à escolher IDs para estas vlans internas a partir do 1006 (primeiro ID do range estendido), e acima, conforme necessidade. Observe que no primeiro momento não havia nenhuma VLAN alocada. Depois de criar uma interface roteada a VLAN 1006 foi reservada. Claro que se tentarmos criar uma VLAN 1006, não será possível (veja os logs apresentados). Interessante notar que esta associação da vlan “interna” com a porta física é dinâmica, e caso coloquemos a porta em shutdown a associação é desfeita. Da mesma forma quando reiniciamos o equipamento a vlan utilizada pode mudar. Depois de dar um shutdown na interface 2 e 3, e voltar a interface 3, a VLAN mudou. Com tudo isso posto, fica claro que precisamos ter atenção quando usamos o range estendido. A boa prática diz que devemos começar usando o ID 4094 e descer, evitando (ou postergando) assim problemas com a alocação interna (e claro usar o comando show vlan internal usage para ver quais vlans já estão em uso no switch). Alguns modelos suportam o comando vlan internal allocation policy descending, que faz o switch escolher os IDs a partir do 4094 e descer. Neste caso devemos fazer o contrário, e escolher os IDs a partir de 1006 e subir. Se você precisar usar um ID que já está alocado internamente, basta dar shutdown na interface associada, criar a VLAN e voltar a porta (no shutdown). Ela usará o próximo ID livre de acordo com a política (ascending ou descending). VTPv3 Quem usa VTPv3, capaz de gerenciar VLANs do range estendido, precisa ficar atento com as VLANs usadas internamente. Quando você cria uma VLAN no VTP Server ele faz a checagem localmente, mas não verifica se o ID já está em uso nos demais switches do domínio VTP. Assim, pode acontecer de você criar uma VLAN mas ela não ser criada em algum outro switch do domínio (e neste caso não vai ter log no VTP Server). Mais informações neste link. Até a próxima.
