Nesse vídeo falamos sobre conceitos básicos de roteamento como a tabela de roteamento, rotas estáticas, rotas dinâmicas, rota padrão, distância administrativa, balanceamento, etc. Até logo! A tabela de roteamento possui registro dos destinos para encaminhamento dos pacotes. As rotas podem ser aprendidas manualmente (rotas estáticas ou redes diretamente conectadas) e dinamicamente (aprendidos via protocolo de roteamento dinâmico como OSPF, BGP,etc). Nesse vídeo faremos uma breve descrição do funcionamento, aprendizado e escolha das rotas por um Roteador. Valeu! Galera, gostaria de compartilhar uma dúvida frequente sobre como alterar o roteamento entre redes que esteja sendo executado por um firewall e mover essa função para um “Switch Core”. Segue abaixo um dos e-mails: “Estou com uma dúvida com relação a
gateway padrão da rede. Recentemente adicionei ao core de rede um switch L3, com isto estou projetando adicionar VLANs, mas para haver roteamento entre VLANs é necessário que o gateway padrão seja o switch, assim o firewall que atualmente é o gateway da rede, o deixará de ser. Como posso encaminhar os pacotes o quais atualmente são tratados pelo firewall? ” Para melhor entendimento dos cenários, fiz um desenho com a topologia das redes sendo roteadas pelo firewall (cenário A)
e o roteamento entre a rede executado pelo Switch L3 (cenário B). No cenário A, temos todo tráfego entre redes sendo processado pelo firewall. Em um cenário que o Switch possa fazer o roteamento entre as redes, você configurará a VLAN e a Interface-VLAN para as respectivas redes (cenário B). Cada rede terá uma VLAN e uma Interface-VLAN. Dessa forma você trabalhará para que o endereço IP da interface-vlan seja o gateway das máquinas (ao invés do firewall). Assim então o Switch fará o roteamento automático das redes, pelo fato de tê-las em sua tabela de roteamento, como diretamente conectadas. Já o Firewall deverá ter uma rota de retorno para cada rede apontando como next-hop o endereço IP da rede de trânsito, com o IP do Switch (próximo salto). As regras de Segurança, tradução de endereço, etc, continuam no firewall. O roteamento entre VLANs acontecerá sem restrições no Switch Core. O Switch só encaminhará para o firewall o tráfego de saída da LAN. Dúvidas e colocações, deixe um comentário. Para o anuncio de redes no processo BGP, utilizamos o comando “network” ou a redistribuição de rotas com o comando “import“. Há também a possibilidade de manualmente sumarizarmos as redes no anuncio de prefixos para os roteadores vizinhos. O comando BGP aggregate permite a sumarização manual (diferente do comando auto-summary), baseando-se em qualquer prefixo da tabela BGP. No exemplo abaixo os ASN 11 e 12 anunciam cada um 2 prefixos /24 para o ASN 22.  Sem a sumarização de rotas a tabela BGP estaria da seguinte forma para o Roteador do ASN 33: [RoteadorASN33]display bgp routing-table ipv4 Total number of routes: 4 BGP local router ID is 192.168.23.3 Status codes: * - valid, > - best, d - dampened, h - history, s - suppressed, S - stale, i - internal, e – external Origin: i - IGP, e - EGP, ? - incomplete Network NextHop MED LocPrf PrefVal Path/Ogn * >e 192.168.0.0 192.168.23.2 0 22 11i * >e 192.168.1.0 192.168.23.2 0 22 11i * >e 192.168.2.0 192.168.23.2 0 22 12i * >e 192.168.3.0 192.168.23.2 0 22 12iCriando as rotas agregadas O comando aggregate irá criar as rotas sumarizadas manualmente, iniciando o valor do AS path, simplesmente criando um novo anuncio de prefixos sumarizados sem omitir o anuncio das rotas mais especificas. No exemplo abaixo, sumarizamos os prefixos do ASN 11 em apenas um prefixo /23: ! Configuração BGP do Roteador do ASN 22 com Comware 7 bgp 22 peer 192.168.23.3 as-number 33 peer 192.168.112.1 as-number 11 peer 192.168.212.1 as-number 12 # address-family ipv4 unicast aggregate 192.168.0.0 255.255.254.0 peer 192.168.23.3 enable peer 192.168.112.1 enable peer 192.168.212.1 enable #Analisando a tabela BGP do Roteador do ASN 33 temos o seguinte output: ! tabela BGP do Roteador do ASN 33 com Comware 7 [RoteadorASN33]display bgp routing-table ipv4 Total number of routes: 5 BGP local router ID is 192.168.23.3 Status codes: * - valid, > - best, d - dampened, h - history, s - suppressed, S - stale, i - internal, e - external Origin: i - IGP, e - EGP, ? – incomplete Network NextHop MED LocPrf PrefVal Path/Ogn * >e 192.168.0.0/23 192.168.23.2 0 22i * >e 192.168.0.0 192.168.23.2 0 22 11i * >e 192.168.1.0 192.168.23.2 0 22 11i * >e 192.168.2.0 192.168.23.2 0 22 12i * >e 192.168.3.0 192.168.23.2 0 22 12iSe quisessemos omitir o anuncio dos prefixos mais especificos para os roteadores do ASN 33 acrescentariamos o comando detail-suppressed aggregate 192.168.0.0 255.255.254.0 detail-suppressedAnalisando novamente a tabela BGP do Roteador do ASN 33 temos o seguinte output (sem as rotas mais especificas do /23): [RoteadorASN33]display bgp routing-table ipv4 Total number of routes: 3 BGP local router ID is 192.168.23.3 Status codes: * - valid, > - best, d - dampened, h - history, s - suppressed, S - stale, i - internal, e - external Origin: i - IGP, e - EGP, ? - incomplete Network NextHop MED LocPrf PrefVal Path/Ogn * >e 192.168.0.0/23 192.168.23.2 0 22i * >e 192.168.2.0 192.168.23.2 0 22 12i * >e 192.168.3.0 192.168.23.2 0 22 12iMantendo os ASN Observem que a rota sumarizada pelo ASN 22, inclui apenas o seu próprio ASN no AS_PATH. Os ASN 11 e 12 também receberão a rota sumarizada pelo simples fato de seus ASes serem omitidas na sumarização. Esta ação introduz a possibilidade da criação de loop de roteamento em determinados cenários. O parametro AS_PATH AS_SET resolve essa questão adicionando os ASes de origem. No exemplo abaixo estamos sumarizando também com um /22 para exemplificar a diferença do comando com as-set: aggregate 192.168.0.0 255.255.252.0 detail-suppressed as-set aggregate 192.168.0.0 255.255.254.0 detail-suppressed as-setEssa configuração gera uma rota sumarizada contendo o conjunto de ASes, de 11 e 12 para a rede /22, e AS 11 para o /23, uma vez que o agregado contém rotas provenientes desses sistemas autônomos. No roteador do AS 33, podemos ver o caminho dos Ases na tabela BGP: [RoteadorASN33]display bgp routing-table ipv4 Total number of routes: 2 BGP local router ID is 192.168.23.3 Status codes: * - valid, > - best, d - dampened, h - history, s - suppressed, S - stale, i - internal, e - external Origin: i - IGP, e - EGP, ? - incomplete Network NextHop MED LocPrf PrefVal Path/Ogn * >e 192.168.0.0/22 192.168.23.2 0 22 {11 12}i * >e 192.168.0.0/23 192.168.23.2 0 22 11iA seguinte lista resume as ações do comando aggregate para o anuncio de rotas sumarizadas:
Até logo Referências http://packetlife.net/blog/2008/sep/19/bgp-route-aggregation-part-1/ HP A8800 Configuration Guide – IP Routing CCIE Routing and Switching CERTIFICATION Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue A maneira como efetuamos o roteamento de pacotes baseado endereço de destino do cabeçalho IP possui algumas restrições que não permitem o balanceamento de tráfego de maneira granular de acordo com perfis das aplicações, dessa forma todos os pacotes são roteados para o mesmo lugar sem levarmos em conta a rede de origem, protocolo, etc. A utilização de PBR, policy-based routing, permite ao engenheiro de rede a habilidade de alterar o comportamento padrão de roteamento baseando-se em diferentes critérios ao invés de somente a rede de destino, incluindo o endereço de rede de origem, endereços TCP/UDP de origem e/ou destino, tamanho do pacote, pacotes classificados com fins de QoS, etc. Mas por qual razão utilizaremos PBR ? O PBR pode ser utilizado em diversos cenários, para os mais diversos fins. No exemplo abaixo a rede 192.168.1.0/24 acessa a rede 172.16.0.1 com uma rota default configurada para o Link A, imaginando que uma segunda demanda surge para que a rede de homologação 192.168.2.0/24 acesse assim a Internet pelo Link A mas já o acesso para rede 172.16.0.1, deva ocorrer preferivelmente pelo link B. Nesse caso o PBR entraria para corrigir essa questão (lembrando que na tabela de roteamento o acesso para rede 172.16.0.1 é apontado para o Link A, criaríamos uma exceção somente para a nova rede). Segue exemplo da configuração: # acl number 2000 rule 0 permit source 192.168.2.0 0.0.0.255 ! ACL para match na rede 192.168.2.0 # policy-based-route XYZ permit node 10 if-match acl 2000 apply next-hop 192.168.223.3 ! PBR dando match na ACL 2000 e encaminhar o ! tráfego para o next-hop do link B # # interface GigabitEthernet0/0/3 port link-mode route ip address 192.168.12.2 255.255.255.0 ip policy-based-route XYZ ! Aplicando o PBR na interface Giga0/0/3 #A implementação da PBR é bastante simples, ele é definido para ser configurado usando o processo policy-based routing que é muito similar a configuração de uma route-policy (route-map) . O tráfego a ser tratado pelo PBR será comparado (match) utilizando uma ACL e em seguida tem o novo destino ou parâmetros alterados usando um comando apply + atributo. Se o pacote não corresponder à política de PBR ou se o encaminhamento baseado em PBR falhar, o dispositivo utilizará a tabela de roteamento para encaminhar os pacotes. Outros parametros dentro do PBR Entre os outros parametros do PBR está o output-interface, default-next-hop e o default-output-interface. Output-interface: Esse comando permite atribuir a interface de saída do trafego ao invés do IP do next-hop. Default-next-hop / default-output-interface:Se o processo de roteamento baseado na tabela de rotas falhar, o equipamento utilizará o default next hop ou default output interface definido no PBR para encaminhar os pacotes. Ao utilizar qualquer combinação destes comandos dentro de um PBR os comandos são avaliados na seguinte ordem: apply next-hop O PBR é uma ferramenta muito poderosa que pode ser usada para controlar os caminhos específicos de tráfego de rede, porém certifique-se de usar apenas PBR quando for necessário. Como muitas outras features oferecidas em qualquer tipo de roteador, elas são projetadas para um conjunto específico de circunstâncias, o mesmo e deve ser utilizado para esses fins para assim manter a eficiência. Referências http://blog.pluralsight.com/pbr-policy-based-routing HP 5920 & 5900 Switch Series- Layer 3 – IP Routing – Configuration Guide Uma rota estática flutuante é uma rota estática com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no Comware da HP as rotas estáticas possuem distância administrativa com o valor 60 e o protocolo OSPF com as rotas externas com o valor 150, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas são aprendidas de maneiras distintas pelo roteador, o equipamento escolherá o processo com menor AD ( administative distance/ distancia administrativa). Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via rotas externas OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link. Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link. Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link, a rota estática deixará de ser utilizada, voltando para o encaminhamento de pacotes pela rota aprendida dinamicamente. Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP. Caso tenham alguma dúvida sobre o assunto, deixem um comentário. http://pt.wikipedia.org/wiki/Dist%C3%A2ncia_administrativa http://www.rotadefault.com.br/rota-estatica-flutuante-floating-static-route/ Abração a todos O algoritmo do BGP não permite que rotas aprendidas via iBGP sejam anunciadas para roteadores vizinhos. Lembrando que uma rota aprendida via eBGP deve ser ensinada para um vizinho iBGP, mas uma rota aprendida via iBGP não deve ser anunciada para roteadores vizinhos. Quando BGP foi projetado originalmente, não havia nenhuma provisão para a prevenção de loop dentro de um Sistema Autônomo (AS ou ASN). Em vez disso, a regra de prefixos iBGP proíbe o anuncio de rotas aprendidas via iBGP para outro peer BGP interno. Esta é a razão principal pela qual a inteligência do BGP necessita de conexões full mesh entre roteadores iBGP, isto é, todos roteadores devem estar conectados entre si. Mas a topologia iBGP com full mesh, traz problemas de escalabilidade na configuração, uma vez que o número de sessões para troca de tráfego irá ser N (N-1) / 2, onde N é o número de roteadores internos BGP Perceba no diagrama abaixo que o prefixo aprendido por R3 via iBGP não é encaminhado para o roteador R4 devido a regra de prefixos aprendidos via iBGP citado acima. Utilizando Roteadores Refletores (Router Reflectors ou RRs) em uma topologia iBGP, permitirá ao protocolo BGP quebrar a regra de proibição ao ensinar rotas aprendidas via iBGP para vizinhos internos. Os roteadores configurados como Router Reflector dividem os seus vizinhos iBGP em duas classes: clientes e não-clientes. As rotas aprendidas por roteadores iBGP clientes serão anunciadas para roteadores clientes e não-clientes. No, entanto as rotas aprendidas a partir de não-clientes serão anunciadas apenas para clientes. Perceba no diagrama abaixo o prefixo anunciado para o Roteador R4 pelo Roteador R3 configurado como RR. A configuração do Router Reflector só é necessária no roteador RR “servidor”, nenhuma configuração é necessária nos equipamentos clientes. Segue abaixo a configuração de R3. ! Configuração R3 ! bgp 234 peer 2.2.2.2 as-number 234 peer 2.2.2.2 description R2 peer 2.2.2.2 reflect-client peer 2.2.2.2 connect-interface LoopBack1 !Cluster_List e Originator_ID A configuração de Route Reflector é geralmente a atribuída a ambientes bem complexos. O BGP utiliza-se de alguns mecanismos para prevenção de loops como Cluster List e Originator ID: – Cluster ID: O RR adiciona seu cluster ID ao encaminhar o update. Quando recebe um update BGP que contem o seu próprio Cluster ID os prefixos recebidos são descartados, evitando assim o gerar loop de roteamento pelos anuncios entre clusters. – Originator ID: Uma lista de clusters (cluster-list) é uma seqüência de cluster-IDs que a rota atravessou. Quando um RR reflete uma rota de seus clientes para non-clients fora do cluster, ele adiciona o cluster-id local no final da cluster-list. Usando este atributo, um RR pode identificar se uma informação de roteamento fez um loop e voltou ao mesmo cluster que a originou (por alguma falha de configuração). Se o cluster-id local é encontrado na cluster-list, o anúncio da rota será descartado. Conforme diagrama abaixo, segue um exemplo do output com a lista do Cluster list: Segue abaixo a configuração de R3 e R4 (lembrando que nenhuma configuração BGP adicional é necessária para o Roteador cliente Router Reflector # ! Configuração R3 router bgp 234 bgp cluster-id 1 neighbor 2.2.2.2 remote-as 234 neighbor 2.2.2.2 description R2 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 route-reflector-client ! neighbor 4.4.4.4 remote-as 234 neighbor 4.4.4.4 description R4 neighbor 4.4.4.4 update-source Loopback1 ! # ! Configuração R4 router bgp 234 bgp cluster-id 2 neighbor 1.1.1.1 remote-as 234 neighbor 1.1.1.1 description R1 neighbor 1.1.1.1 update-source Loopback1 neighbor 1.1.1.1 route-reflector-client ! neighbor 3.3.3.3 remote-as 234 neighbor 3.3.3.3 description R3 neighbor 3.3.3.3 update-source Loopback1 !Até logo Referências http://blog.ipexpert.com/2012/02/20/understanding-bgp-originator-id-and-cluster-id/#top http://www.rnp.br/newsgen/0109/bgp4_dicas2.html#ng-6 http://www.rotadefault.com.br/teste-mesa-para-router-reflectors/ http://www.rotadefault.com.br/resumo-bgp-router-reflectors/ CCIE Routing and Switching Certification Guide, 4th Edition, Cisco Press, Wendell Odom, Rus Healy, Denise Donohue Pessoal, segue abaixo a lista de alguns comandos para BGP quando há a necessidade de traduzir de Cisco IOS para HP Comware. Comware Cisco IOS ------------ -------------- bgp xxxxx router bgp xxxxx router-id x.x.x.x bgp router-id x.x.x.x preference 200 200 200 (valor recomendado, não é default) distance 20 200 200 (default) undo synchronization no synchronization (not default) v5: recomendado (não é default) v7: default undo summary automatic (default) no auto-summary (not default) log-peer-change bgp log-neighbor-changes graceful-restart bgp graceful-restart bgp graceful-restart restart-time 120 (default) bgp graceful-restart stalepath-time 360 (default) balance n (default=1) maximum-path (dependente do contexto, default=1) v5: global BGP config v7: in ipv4 address family maximum-path n (n=numero de rotas paralelas) maximum-path ibgp m ebgp-interface-sensitive (default) bgp fast-external-fallover (default) network x.x.x.x y.y.y.y network x.x.x.x mask y.y.y.y aggregate x.x.x.x y.y.y.y aggregate-addresss x.x.x.x y.y.y.y aggregate x.x.x.x y.y.y.y detail-suppressed aggregate-addresss x.x.x.x y.y.y.y summary-only import-route static [route-policy name] redistribute static [route-map name] import-route direct [route-policy name] redistribute connected [route-map name] import-route ospf process_id [route-policy name] redistribute ospf process_id [route-map name] default-information originate reflector cluster-id x.x.x.x bgp cluster-id x.x.x.x dampening bgp dampening peer x.x.x.x as-number AS-number neighbor x.x.x.x remote-as AS-number peer x.x.x.x description blabla neighbor x.x.x.x description blabla peer x.x.x.x connect-interface LoopBack0 neighbor x.x.x.x update-source Loopback0 peer x.x.x.x next-hop-local neighbor x.x.x.x next-hop-self peer x.x.x.x advertise-community neighbor x.x.x.x send-community peer x.x.x.x password simple|cipher string neighbor x.x.x.x password 7 string (default) neighbor x.x.x.x version 4 (no negotiation) peer x.x.x.x ebgp-max-hop neighbor x.x.x.x ebgp-multihop hop_count peer x.x.x.x preferred-value default_prefval neighbor x.x.x.x weight default_weight peer x.x.x.x default-route-advertise route-policy name neighbor x.x.x.x default-originate route-map name peer x.x.x.x timer keepalive keepalive hold holdtime neighbor x.x.x.x timers keepalive holdtime minholdtime peer x.x.x.x route-policy name import | export neighbor x.x.x.x route-map name in | out peer x.x.x.x public-as-only neighbor x.x.x.x remove-private-as peer x.x.x.x fake-as AS-number neighbor x.x.x.x local-as no-prepend AS-number replace-as peer x.x.x.x substitute-as peer x.x.x.x allow-as-loop AS_occurances neighbor x.x.x.x allowas-in AS_occurances peer x.x.x.x route-limit prefix_number % reconnect restart_interval neighbor x.x.x.x maximum-prefix prefix_number % restart restart_interval peer x.x.x.x reflect-client neighbor x.x.x.x route-reflector-client peer x.x.x.x ignore neighbor x.x.x.x shutdown group group_name internal | external neighbor group_name peer-group peer x.x.x.x group group_name neighbor x.x.x.x peer-group group_name compare-different-as-med bgp always-compare-med bestroute compare-med bgp deterministic-med bestroute as-path-neglect bgp bestpath as-path ignore undo default ipv4-unicast no bgp default ipv4-unicast (Default) bgp suppress-inactive peer x.x.x.x capability-advertise orf ip-prefix both neighbor x.x.x.x capability orf prefix-list both peer x.x.x.x capability-advertise route-refresh (default) neighbor x.x.x.x soft-reconfiguration inbound peer x.x.x.x bfd neighbor x.x.x.x fall-over bfd peer x.x.x.x route-update-interval timer neighbor x.x.x.x advertisement-interval seconds (iBGP default=5s, eBGP default=30s) iBGP default=0s, eBGP (na VRF) default=0s, eBGP default=0s) peer x.x.x.x next-hop-local neighbor x.x.x.x next-hop-self peer x.x.x.x capability-advertise orf ip-prefix both neighbor x.x.x.x capability orf prefix-list both Deve ser usado no vpnv4 address-family. Deve ser usado no vpnv4 address-family. peer x.x.x.x advertise-ext-community neighbor x.x.x.x send-community extended | both undo peer x.x.x.x enable no neighbor x.x.x.x activate Verificando a troca de prefixos display bgp routing-table peer x.x.x.x received-routes show ip bgp neighbors x.x.x.x received-routes display bgp routing-table peer x.x.x.x advertised-routes show ip bgp neighbors x.x.x.x advertised-routes MPBGP display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x received-routes show ip bgp vpnv4 vrf vrf-instance-name neighbors x.x.x.x received-routes display bgp vpnv4 all routing-table peer x.x.x.x received-routes v5 show ip bgp vpnv4 all neighbors x.x.x.x received-routes display bgp vpnv4 vpn-instance vpn-instance-name routing-table peer x.x.x.x advertised-routes show ip bgp neighbors x.x.x.x advertised-routes display bgp vpnv4 all routing-table peer x.x.x.x advertised-routes show ip bgpSegue uma lista para rápida comparação de comandos para troubleshooting, reset e refresh para o processo BGP comparando os comandos entre equipamentos 3Com,H3C e HP baseados no Comware e Cisco IOS. Troubleshooting Comware IOS display ip routing-table show ip route display ip routing-table x.x.x.x show ip route x.x.x.x display ip routing-table x.x.x.x longer-match show ip route x.x.x.x longer-prefixes display ip routing-table protocol bgp show ip route bgp display bgp routing-table show ip bgp display bgp routing-table x.x.x.x show ip bgp x.x.x.x display bgp routing peer show ip bgp summary display bgp routing regular-expression AS-number show ip bgp regexp AS-numberReset e Refresh Comware IOS reset bgp x.x.x.x (modo user-view) clear ip bgp x.x.x.x refresh bgp x.x.x.x import (modo user-view) clear ip bgp x.x.x.x in clear ip bgp x.x.x.x soft in refresh bgp x.x.x.x export clear ip bgp x.x.x.x out clear ip bgp x.x.x.x soft outFala Galera, tudo bom!? Segue mais uma vídeo-aula produzida por nós, contendo dessa vez o assunto Roteamento entre VLANs utilizando Switches ou Roteadores, além de falarmos também sobre roteamento estático, Topologia, etc.. para equipamentos baseados no Comware (HP , 3Com e H3C) . Ainda estou apanhando um pouco no formado das vídeo-aulas, mas espero que o vídeo seja útil. 😉 Que tipo de rota estática e criada quando o endereço IP do próximo salto e a interface de saída são especificados?Rota estática totalmente especificada – O endereço IP do próximo salto e a interface de saída são especificados.
O que e uma rota estática?R : Rota estática é quando o administrador do sistema coloca uma entrada manualmente na tabela de roteamento de um roteador, ensinando como ele alcança uma determinada rede. Rotas estáticas, quando necessário, devem ser atualizadas manualmente pelo administrador em cada roteador.
Qual comando seria usado para configurar uma rota estática em R1 de modo que o tráfego das duas LANs possa acessar a rede remota 2001 db8 1 4 ::/ 64?Qual comando seria usado para configurar uma rota estática em R1 para que o tráfego de ambas as LANs pudesse alcançar a rede remota 2001: db8: 1: 4 :: / 64? Explicação: Para configurar uma rota estática IPv6, use o comando ipv6 route seguido pela rede de destino.
Como configurar rota estática?Configurar rotas estáticas IPv4. prefixo - prefixo de rota IP para o destino.. mask - Máscara de prefixo para o destino.. prefix-length - Máscara de prefixo para o destino. ... . ip-address - Endereço IP do próximo salto que pode ser usado para acessar essa rede.. valor métrico - métrica da rota.. |
Que rota foi configurada como rota estática para uma rede específica utilizando o endereço de próximo salto?
Postagens relacionadas
direito autoral © 2024 temalgum Inc.
