Distribuição de rotas de VPN
Este tópico descreve a configuração de um roteador para tratar informações de rota em BGP, sinalização MPLS e políticas.
Habilitação de troca de informações de roteamento para VPNs
Para VPNs de Camada 2, VPNs de Camada 3, instâncias de roteamento de roteador virtual, VPLS, EVPNs e circuitos de Camada 2 funcionarem corretamente, os roteadores PE e P do provedor de serviços devem ser capazes de trocar informações de roteamento. Para que isso aconteça, você deve configurar um IGP (como OSPF ou IS-IS) ou rotas estáticas nesses roteadores. Você configura o IGP na instância mestre do processo de protocolo de roteamento no nível de [edit protocols] hierarquia, não dentro da instância de roteamento usada para a VPN — ou seja, não no nível de [edit routing-instances] hierarquia.
Ao configurar o roteador PE, não configure nenhuma resumo dos endereços de loopback do roteador PE no limite da área. O endereço de loopback de cada roteador PE deve aparecer como uma rota separada.
Configuração de sessões de IBGP entre roteadores PE em VPNs
Você deve configurar uma sessão de IBGP entre os roteadores PE para permitir que os roteadores PE troquem informações sobre rotas originadas e terminantes na VPN. Os roteadores PE contam com essas informações para determinar quais rótulos usar para o tráfego destinado a locais remotos.
Configure uma sessão do IBGP para a VPN da seguinte forma:
[edit protocols]
bgp {
group group-name {
type internal;
local-address ip-address;
family evpn {
signaling;
}
family (inet-vpn | inet6-vpn) {
unicast;
}
family l2vpn {
signaling;
}
neighbor ip-address;
}
}
O endereço IP na local-address declaração é o endereço da interface de loopback no roteador PE local. A sessão do IBGP para VPN passa pelo endereço de loopback. (Você também deve configurar a interface de loopback no nível da [edit interfaces] hierarquia.)
O endereço IP na neighbor declaração é o endereço de loopback do roteador PE vizinho. Se você estiver usando a sinalização RSVP, este endereço IP é o mesmo que você especifica na to declaração no nível de [edit mpls label-switched-path lsp-path-name] hierarquia quando configura o MPLS LSP.
A family declaração permite configurar a sessão do IBGP para VPNs de Camada 2, VPLS, EVPNs ou para VPNs de Camada 3.
Para configurar uma sessão do IBGP para VPNs de Camada 2 e VPLS, inclua a
signalingdeclaração no nível de[edit protocols bgp group group-name family l2vpn]hierarquia:[edit protocols bgp group group-name family l2vpn] signaling;
Para configurar uma sessão do IBGP para EVPNs, inclua a
signalingdeclaração no nível de[edit protocols bgp group group-name family evpn]hierarquia:[edit protocols bgp group group-name family evpn] signaling;
Para configurar uma sessão de IBGP IPv4 para VPNs de Camada 3, configure a
unicastdeclaração no nível de[edit protocols bgp group group-name family inet-vpn]hierarquia:[edit protocols bgp group group-name family inet-vpn] unicast;
Para configurar uma sessão IPv6 IBGP para VPNs de Camada 3, configure a
unicastdeclaração no nível de[edit protocols bgp group group-name family inet6-vpn]hierarquia:[edit protocols bgp group group-name family inet6-vpn] unicast;
Você pode configurar ambos family inet e family inet-vpn ou ambos family inet6 e family inet6-vpn dentro do mesmo grupo de peer. Isso permite que você habilite suporte para rotas VPN IPv4 e IPv4 ou para rotas VPN IPv6 e IPv6 no mesmo grupo de peer.
Configuração de rótulos agregados para VPNs
Rótulos agregados para VPNs permitem que uma plataforma de roteamento da Juniper Networks agregasse um conjunto de rótulos recebidos (rótulos recebidos de um roteador de peer) em um único rótulo de encaminhamento selecionado no conjunto de rótulos recebidos. O rótulo de encaminhamento único corresponde a um único próximo hop para esse conjunto de rótulos. A agregação de rótulos reduz o número de rótulos de VPN que o roteador deve examinar.
Para que um conjunto de rótulos compartilhe um rótulo de encaminhamento agregado, eles devem pertencer à mesma classe de equivalência de encaminhamento (FEC). Os pacotes rotulados devem ter a mesma interface de saída de destino.
Incluindo a community community-name declaração com a aggregate-label declaração, você pode especificar prefixos com uma comunidade de origem comum. Definidos por política no peer PE, esses prefixos representam um FEC no roteador peer PE.
Se a comunidade-alvo for definida por erro em vez da comunidade de origem, o encaminhamento de problemas na saída de PE pode resultar. Todos os prefixos do peer PE parecem estar no mesmo FEC, resultando em um único rótulo interno para todos os roteadores CE por trás de um determinado PE na mesma VPN.
Para trabalhar com refletors de rota em redes VPN de Camada 3, o roteador M10i da Juniper Networks agrega um conjunto de rótulos recebidos apenas quando as rotas:
São recebidos do mesmo roteador peer
Tenha o mesmo local da comunidade de origem
Tenha o mesmo próximo salto
O próximo requisito de salto é importante porque os refletors de rota encaminham rotas originadas de diferentes pares BGP para outro peer BGP sem alterar o próximo salto dessas rotas.
Para configurar rótulos agregados para VPNs, inclua a declaração de rótulo agregado :
aggregate-label { community community-name; }
Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte o resumo da declaração para esta declaração.
Para obter informações sobre como configurar uma comunidade, consulte a compreensão das comunidades BGP, comunidades estendidas e comunidades grandes como condições de correspondência de políticas de roteamento.
Configuração de um protocolo de sinalização e LSPs para VPNs
Para que as VPNs funcionem, você deve habilitar um protocolo de sinalização, seja o LDP ou o RSVP nos roteadores de borda do provedor (PE) e nos roteadores de provedor (P). Você também precisa configurar caminhos comutados por rótulos (LSPs) entre os roteadores de entrada e saída. Em uma configuração VPN típica, você precisa configurar LSPs de cada roteador PE para todos os outros roteadores PE que participam da VPN em uma malha completa.
Como em qualquer configuração envolvendo MPLS, você não pode configurar nenhuma das interfaces voltadas para o núcleo nos roteadores PE em PICs Ethernet rápidos densos.
Para habilitar um protocolo de sinalização, execute as etapas em uma das seguintes seções:
Usando LDP para sinalização de VPN
Para usar o LDP para sinalização vpn, execute as seguintes etapas nos roteadores PE e provedor (P):
Configure o LDP nas interfaces no núcleo da rede do provedor de serviços, incluindo a
ldpdeclaração no nível de[edit protocols]hierarquia.Você precisa configurar o LDP apenas nas interfaces entre roteadores PE ou entre roteadores PE e P. Você pode pensar nisso como as interfaces "voltadas para o núcleo". Você não precisa configurar o LDP na interface entre os roteadores pe e de borda do cliente (CE).
[edit] protocols { ldp { interface type-fpc/pic/port; } }Configure a família de endereços MPLS nas interfaces nas quais você habilitou o LDP (as interfaces que você configurou na Etapa 1) incluindo a
family mplsdeclaração no nível de[edit interfaces type-fpc/pic/port unit logical-unit-number]hierarquia.[edit] interfaces { type-fpc/pic/port { unit logical-unit-number { family mpls; } } }Configure o OSPF ou o IS-IS em cada roteador PE e P.
Você configura esses protocolos na instância mestre do protocolo de roteamento, não dentro da instância de roteamento usada para a VPN.
Para configurar o OSPF, inclua a
ospfdeclaração no nível de[edit protocols]hierarquia. No mínimo, você deve configurar uma área de backbone em pelo menos uma das interfaces do roteador.[edit] protocols { ospf { area 0.0.0.0 { interface type-fpc/pic/port; } } }Para configurar o IS-IS, inclua a
isisdeclaração no nível de[edit protocols]hierarquia e configure a interface de loopback e a família da Organização Internacional para Padronização (ISO) no nível de[edit interfaces]hierarquia. No mínimo, você deve habilitar o IS-IS no roteador, configurar um título de entidade de rede (NET) em uma das interfaces do roteador (de preferência a interface de loopback, lo0) e configurar a família ISO em todas as interfaces nas quais você deseja que o IS-IS seja executado. Quando você habilita o IS-IS, o Nível 1 e o Nível 2 são habilitados por padrão. A seguir, a configuração is-IS mínima. Na declaraçãoaddress,addressestá a NET.[edit] interfaces { lo0 { unit logical-unit-number { family iso { address address; } } } type-fpc/pic/port { unit logical-unit-number { family iso; } } } protocols { isis { interface all; } }
Usando RSVP para sinalização de VPN
Para usar o RSVP para sinalização de VPN, execute as seguintes etapas:
Em cada roteador PE, configure a engenharia de tráfego.
Para isso, você deve configurar um protocolo de gateway interior (IGP) que oferece suporte à engenharia de tráfego (is-IS ou OSPF) e habilitar o suporte de engenharia de tráfego para esse protocolo.
Para habilitar o suporte à engenharia de tráfego OSPF, inclua a
traffic-engineeringdeclaração no nível de[edit protocols ospf]hierarquia:[edit protocols ospf] traffic-engineering { shortcuts; }Para o IS-IS, o suporte de engenharia de tráfego é habilitado por padrão.
Em cada roteador PE e P, habilite o RSVP nas interfaces que participam do caminho comutador de rótulos (LSP).
No roteador PE, essas interfaces são os pontos de entrada e saída para o LSP. No roteador P, essas interfaces conectam o LSP entre os roteadores PE. Não habilite RSVP na interface entre os roteadores PE e CE, porque essa interface não faz parte do LSP.
Para configurar RSVP nos roteadores PE e P, inclua a
interfacedeclaração no nível de[edit protocols rsvp]hierarquia. Inclua umainterfacedeclaração para cada interface na qual você está habilitando o RSVP.[edit protocols] rsvp { interface interface-name; interface interface-name; }Em cada roteador PE, configure um MPLS LSP para o roteador PE que é o ponto de saída do LSP.
Para isso, inclua as declarações e
label-switched-pathasinterfacedeclarações no nível hierárquicos[edit protocols mpls]:[edit protocols] mpls { interface interface-name; label-switched-path path-name { to ip-address; } }toNa declaração, especifique o endereço do ponto de saída do LSP, que é um endereço no roteador PE remoto.interfaceNa declaração, especifique o nome da interface (tanto as porções físicas quanto lógicas). Inclua umainterfacedeclaração para a interface associada ao LSP.Quando você configura a porção lógica da mesma interface no nível de
[edit interfaces]hierarquia, você também deve configurar as declarações efamily mplsasfamily inetdeclarações:[edit interfaces] interface-name { unit logical-unit-number { family inet; family mpls; } }Em todos os roteadores P que participam do LSP, habilite o MPLS incluindo a
interfacedeclaração no nível de[edit mpls]hierarquia.Inclua uma
interfacedeclaração para cada conexão com o LSP.[edit] mpls { interface interface-name; interface interface-name; }Habilite o MPLS na interface entre os roteadores PE e CE, incluindo a
interfacedeclaração no nível de[edit mpls]hierarquia.Isso permite que o roteador PE atribua um rótulo MPLS ao tráfego que entra no LSP ou remova o rótulo do tráfego que sai do LSP.
[edit] mpls { interface interface-name; }Para obter informações sobre a configuração do MPLS, consulte a configuração do roteador de entrada para LSPs sinalizados por MPLS.
Veja também
Configuração de políticas para a tabela VRF sobre roteadores PE em VPNs
Em cada roteador PE, você deve definir políticas que definem como as rotas são importadas e exportadas a partir da tabela VRF do roteador. Nessas políticas, você deve definir o alvo da rota, e você pode definir opcionalmente a origem da rota.
Para configurar a política para as tabelas VRF, você executa as etapas nas seguintes seções:
- Configuração do alvo de rota
- Configuração da origem da rota
- Configuração de uma política de importação para a tabela VRF do roteador PE
- Configuração de uma política de exportação para a tabela VRF do roteador PE
- Aplicando tanto a exportação de VRF quanto as políticas de exportação BGP
- Configuração de um alvo VRF
Configuração do alvo de rota
Como parte da configuração de políticas para a tabela de roteamento VPN, você deve definir um alvo de rota, que define de que VPN a rota faz parte. Quando você configurar diferentes tipos de serviços VPN (VPNs de Camada 2, VPNs de Camada 3, EVPNs ou VPLS) no mesmo roteador PE, certifique-se de atribuir valores de destino de rota exclusivos para evitar a possibilidade de adicionar informações de rota e sinalização à tabela de roteamento VPN errada.
Para configurar o alvo de rota, inclua a opção target na community declaração:
community name members target:community-id;
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit policy-options][edit logical-systems logical-system-name policy-options]
name é o nome da comunidade.
community-id é o identificador da comunidade. Especifique-o em um dos seguintes formatos:
as-number:number, ondeas-numberestá um número AS (um valor de 2 byte) enumberum valor de comunidade de 4 byte. O número AS pode estar na faixa de 1 a 65.535. Recomendamos que você use um número AS atribuído por IANA, semprivado, de preferência o próprio ISP ou o número AS do próprio cliente. O valor da comunidade pode ser um número na faixa de 0 a 4.294.967.295 (232 – 1).ip-address:number, ondeip-addressestá um endereço IPv4 (um valor de 4 byte) enumberum valor de comunidade de 2 byte. O endereço IP pode ser qualquer endereço unicast único globalmente. Recomendamos que você use o endereço que configura narouter-iddeclaração, que é um endereço nãoprivado na faixa de prefixo atribuída. O valor da comunidade pode ser um número na faixa de 1 a 65.535.
Configuração da origem da rota
Nas políticas de importação e exportação para a tabela VRF do roteador PE, você pode atribuir opcionalmente a origem da rota (também conhecida como o local de origem) para as rotas VRF de um roteador DE PE usando uma política de exportação VRF aplicada a atualizações de rota VPN IPv4 multiprotocol externas (MP-EBGP) enviadas para outros roteadores PE.
Combinar o atributo de origem da rota atribuído na política de importação VRF de um PE que recebe ajuda a garantir que as rotas VPN-IPv4 aprendidas por meio de atualizações MP-EBGP de um PE não sejam reimportadas para o mesmo site VPN de um PE diferente conectado ao mesmo site.
Para configurar uma origem da rota, complete as seguintes etapas:
Inclua a
communitydeclaração com a opçãoorigin:community name members origin:community-id;
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit policy-options][edit logical-systems logical-system-name policy-options]
nameé o nome da comunidade.community-idé o identificador da comunidade. Especifique-o em um dos seguintes formatos:as-number:number, ondeas-numberestá um número AS (um valor de 2 byte) enumberum valor de comunidade de 4 byte. O número AS pode estar na faixa de 1 a 65.535. Recomendamos que você use um número AS atribuído por IANA, semprivado, de preferência o próprio ISP ou o número AS do próprio cliente. O valor da comunidade pode ser um número na faixa de 0 a 4.294.967.295 (232 – 1).ip-address:number, ondeip-addressestá um endereço IPv4 (um valor de 4 byte) enumberum valor de comunidade de 2 byte. O endereço IP pode ser qualquer endereço unicast único globalmente. Recomendamos que você use o endereço que configura narouter-iddeclaração, que é um endereço nãoprivado na faixa de prefixo atribuída. O valor da comunidade pode ser um número na faixa de 1 a 65.535.
Inclua a comunidade na política de importação para a tabela VRF do roteador PE configurando a
communitydeclaração com ocommunity-ididentificador definido na Etapa 1 no nível de[edit policy-options policy-statement import-policy-name term import-term-name from]hierarquia. Consulte a configuração de uma política de importação para a tabela VRF do roteador PE.Se a cláusula da
frompolítica não especificar uma condição da comunidade, avrf-importdeclaração em que a política é aplicada não pode ser comprometida. A operação de confirmação do Junos OS não passa na verificação de validação.Inclua a comunidade na política de exportação para a tabela VRF do roteador PE configurando a
communitydeclaração com ocommunity-ididentificador definido na Etapa 1 no nível de[edit policy-options policy-statement export-policy-name term export-term-name then]hierarquia. Consulte a configuração de uma política de exportação para a tabela VRF do roteador PE.
Consulte a configuração da origem da rota para VPNs para um exemplo de configuração.
Configuração de uma política de importação para a tabela VRF do roteador PE
Cada VPN pode ter uma política que define como as rotas são importadas para a tabela VRF do roteador PE. Uma política de importação é aplicada às rotas recebidas de outros roteadores PE na VPN. Uma política deve avaliar todas as rotas recebidas durante a sessão do IBGP com o roteador peer PE. Se as rotas corresponderem às condições, a rota será instalada na tabela VRF do routing-instance-name.inet.0 roteador PE. Uma política de importação deve conter um segundo termo que rejeite todas as outras rotas.
A menos que uma política de importação contenha apenas uma then reject declaração, ela deve incluir uma referência a uma comunidade. Caso contrário, quando você tenta cometer a configuração, o compromisso falha. Você pode configurar várias políticas de importação.
Uma política de importação determina o que importar para uma tabela VRF especificada com base nas rotas VPN aprendidas com os roteadores pe remotos por meio do IBGP. A sessão do IBGP está configurada no nível de [edit protocols bgp] hierarquia. Se você também configurar uma política de importação no nível de [edit protocols bgp] hierarquia, as políticas de importação no nível de [edit policy-options] hierarquia e no nível hierárquico [edit protocols bgp] são combinadas por meio de uma operação lógica E. Isso permite filtrar o tráfego em grupo.
Para configurar uma política de importação para a tabela VRF do roteador PE, siga essas etapas:
Para definir uma política de importação, inclua a
policy-statementdeclaração. Para todos os roteadores PE, uma política de importação deve incluir sempre apolicy-statementdeclaração, no mínimo:policy-statement import-policy-name { term import-term-name { from { protocol bgp; community community-id; } then accept; } term term-name { then reject; } }Você pode incluir a
policy-statementdeclaração nos seguintes níveis de hierarquia:[edit policy-options][edit logical-systems logical-system-name policy-options]
A
import-policy-namepolítica avalia todas as rotas recebidas durante a sessão do IBGP com o outro roteador de PE. Se as rotas corresponderem às condições dafromdeclaração, a rota será instalada na tabela .inet.0 VRF do routing-instance-nameroteador PE. O segundo mandato na política rejeita todas as outras rotas.Para obter mais informações sobre a criação de políticas, consulte as políticas de roteamento, filtros de firewall e o guia de usuário dos policiais de tráfego.
Opcionalmente, você pode usar uma expressão regular para definir um conjunto de comunidades a serem usadas para a política de importação de VRF.
Por exemplo, você pode configurar o seguinte usando a
communitydeclaração no nível de[edit policy-options policy-statement policy-statement-name]hierarquia:[edit policy-options vrf-import-policy-sample] community high-priority members *:50
Observe que você não pode configurar uma expressão regular como parte de uma comunidade estendida de destino de rota. Para obter mais informações sobre como configurar expressões regulares para as comunidades, consulte Entender como definir comunidades BGP e comunidades estendidas .
Para configurar uma política de importação, inclua a
vrf-importdeclaração:vrf-import import-policy-name;
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Configuração de uma política de exportação para a tabela VRF do roteador PE
Cada VPN pode ter uma política que define como as rotas são exportadas da tabela VRF do roteador PE. Uma política de exportação é aplicada a rotas enviadas a outros roteadores PE na VPN. Uma política de exportação deve avaliar todas as rotas recebidas durante a sessão de protocolo de roteamento com o roteador CE. (Esta sessão pode usar os protocolos de roteamento BGP, OSPF ou Roteamento [RIP], ou rotas estáticas.) Se as rotas corresponderem às condições, o alvo da comunidade especificado (que é o alvo da rota) é adicionado a eles e eles são exportados para os roteadores pe remotos. Uma política de exportação deve conter um segundo termo que rejeite todas as outras rotas.
As políticas de exportação definidas na instância de roteamento VPN são as únicas políticas de exportação aplicáveis à tabela VRF. Qualquer política de exportação que você definir na sessão do IBGP entre os roteadores PE não tem efeito na tabela VRF. Você pode configurar várias políticas de exportação.
Para configurar uma política de exportação para a tabela VRF do roteador PE, siga estas etapas:
Para todos os roteadores PE, uma política de exportação deve distribuir rotas vpn de e para os roteadores CE conectados de acordo com o tipo de protocolo de roteamento que você configura entre os roteadores CE e PE na instância de roteamento.
Para definir uma política de exportação, inclua a
policy-statementdeclaração. Uma política de exportação deve incluir sempre apolicy-statementdeclaração, no mínimo:policy-statement export-policy-name { term export-term-name { from protocol (bgp | ospf | rip | static); then { community add community-id; accept; } } term term-name { then reject; } }Nota:Configurar a
community adddeclaração é um requisito para políticas de exportação VRF VPN de Camada 2. Se você alterar acommunity adddeclaração para acommunity setdeclaração, o roteador na saída do link VPN de Camada 2 pode abandonar a conexão.Nota:Ao configurar VPNs multicast draft-rosen operando no modo específico da origem e usando a
vrf-exportdeclaração para especificar a política de exportação, a política deve ter um termo que aceita rotas da tabela de roteamento vrf-name.mdt.0. Este termo garante autodiscovamento de PE adequado usando a família deinet-mdtendereços.Ao configurar VPNs multicast de draft-rosen operando no modo específico da origem e usando a
vrf-targetdeclaração, a política de exportação VRF é gerada automaticamente e aceita automaticamente rotas da tabela de roteamento vrf-name.mdt.0.Você pode incluir a
policy-statementdeclaração nos seguintes níveis de hierarquia:[edit policy-options][edit logical-systems logical-system-name policy-options]
A
export-policy-namepolítica avalia todas as rotas recebidas durante a sessão de protocolo de roteamento com o roteador CE. (Esta sessão pode usar os protocolos BGP, OSPF ou rip de roteamento ou rotas estáticas.) Se as rotas corresponderem às condições dafromdeclaração, othen community addalvo da comunidade especificado na declaração é adicionado a eles e eles são exportados para os roteadores pe remotos. O segundo mandato na política rejeita todas as outras rotas.Para obter mais informações sobre a criação de políticas, consulte as políticas de roteamento, filtros de firewall e o guia de usuário dos policiais de tráfego.
Para aplicar a política, inclua a
vrf-exportdeclaração:vrf-export export-policy-name;
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Aplicando tanto a exportação de VRF quanto as políticas de exportação BGP
Quando você aplica uma política de exportação VRF conforme descrito na Configuração de uma Política de Exportação para a Tabela VRF do Roteador PE, as rotas de instâncias de roteamento VPN são anunciadas para outros roteadores PE com base nesta política, enquanto a política de exportação BGP é ignorada.
Se você incluir a vpn-apply-export declaração na configuração BGP, tanto a exportação de VRF quanto o grupo BGP ou políticas de exportação vizinhas são aplicadas (VRF primeiro, depois BGP) antes que as rotas sejam anunciadas nas tabelas de roteamento VPN para outros roteadores PE.
Quando um dispositivo PE também está atuando como um Refletor de Rota (RR) ou um roteador de fronteira do sistema autônomo (ASBR) em uma VPN Carrier-over-Carrier ou inter-AS, a manipulação do next-hop na política de exportação vrf é ignorada.
Ao incluir a vpn-apply-export declaração, esteja ciente do seguinte:
As rotas importadas para a tabela de roteamento bgp.l3vpn.0 mantêm os atributos das rotas originais (por exemplo, uma rota OSPF permanece uma rota OSPF mesmo quando está armazenada na tabela de roteamento bgp.l3vpn.0). Você deve estar ciente disso quando configurar uma política de exportação para conexões entre um roteador IBGP PE e um roteador PE, um refletor de rotas e um roteador PE, ou roteadores de fronteira ASBR (ASBR).
Por padrão, todas as rotas da tabela de roteamento bgp.l3vpn.0 são exportadas para os pares do IBGP. Se a última declaração da política de exportação negar tudo e se a política de exportação não corresponder especificamente às rotas na tabela de roteamento bgp.l3vpn.0, nenhuma rota é exportada.
Para aplicar as políticas de exportação de VRF e BGP às rotas VPN, inclua a vpn-apply-export declaração:
vpn-apply-export;
Para obter uma lista de níveis de hierarquia nos quais você pode incluir esta declaração, consulte a seção de resumo da declaração para esta declaração.
Configuração de um alvo VRF
Incluindo a vrf-target declaração na configuração para uma comunidade alvo vrf faz com que políticas padrão de importação e exportação de VRF sejam geradas que aceitam e marcam rotas com a comunidade alvo especificada. Você ainda pode criar políticas mais complexas configurando explicitamente políticas de importação e exportação de VRF. Essas políticas substituem as políticas padrão geradas quando você configura a vrf-target declaração.
Se você não configurar a e export as import opções da vrf-target declaração, a cadeia de comunidade especificada será aplicada em ambas as direções. As import palavras-chave export oferecem mais flexibilidade, permitindo que você especifique uma comunidade diferente para cada direção.
A sintaxe para a comunidade-alvo VRF não é um nome. Você deve especifique-o no formato target:x:y. Um nome da comunidade não pode ser especificado porque isso também exigiria que você configurasse os membros da comunidade para essa comunidade usando a policy-options declaração. Se você definir as policy-options declarações, você pode configurar políticas de importação e exportação vrf como de costume. O objetivo da vrf-target declaração é simplificar a configuração, permitindo que você configure a maioria das declarações no nível da [edit routing-instances] hierarquia.
Para configurar um alvo VRF, inclua a vrf-target declaração:
vrf-target community;
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Um exemplo de como você pode configurar a vrf-target declaração segue:
[edit routing-instances sample] vrf-target target:69:102;
Para configurar a vrf-target declaração com as opções e import opçõesexport, inclua as seguintes declarações:
vrf-target { export community-name; import community-name; }
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
[edit routing-instances routing-instance-name][edit logical-systems logical-system-name routing-instances routing-instance-name]
Configuração da origem da rota para VPNs
Você pode usar a origem da rota para evitar que as rotas aprendidas com um roteador de borda do cliente (CE) marcado com a comunidade de origem sejam anunciados de volta a ele a partir de outro roteador CE no mesmo AS.
No exemplo, a origem da rota é usada para evitar que as rotas aprendidas com o Roteador CE A que estão marcadas com a comunidade de origem sejam anunciadas de volta ao Roteador CE E pelo AS 200. A topologia de exemplo é mostrada na Figura 1.
Nesta topologia, o roteador CE A e o roteador CE E estão no mesmo QUE (AS200). Eles usam o EBGP para trocar rotas com seus respectivos roteadores de borda de provedor (PE), roteador PE B e roteador PE D. Os dois roteadores CE têm uma conexão traseira.
As seções a seguir descrevem como configurar a origem da rota para um grupo de VPNs:
- Configurando o site da comunidade de origem no roteador CE A
- Configuração da comunidade no roteador CE A
- Aplicação da declaração de política no roteador CE A
- Configuração da política no roteador PE D
- Configuração da comunidade no roteador PE D
- Aplicação da política no roteador PE D
Configurando o site da comunidade de origem no roteador CE A
A seção a seguir descreve como configurar o roteador CE A para anunciar rotas com um site de origem da comunidade até o Roteador PE B, por exemplo.
Neste exemplo, as rotas diretas estão configuradas para serem anunciadas, mas qualquer rota pode ser configurada.
Configure uma política para anunciar rotas com my-soo a comunidade no roteador CE A da seguinte forma:
[edit]
policy-options {
policy-statement export-to-my-isp {
term a {
from {
protocol direct;
}
then {
community add my-soo;
accept;
}
}
}
}
Configuração da comunidade no roteador CE A
Configure a my-soo comunidade no roteador CE A da seguinte forma:
[edit]
policy-options {
community my-soo {
members origin:100:1;
}
}
Aplicação da declaração de política no roteador CE A
Aplique a declaração de política de exportação para meu isp como uma política de exportação para o peering EBGP no roteador CE A da seguinte forma:
[edit]
protocols {
bgp {
group my_isp {
export export-to-my-isp;
}
}
}
Ao emitir o show route receive-protocol bgp detail comando, você deve ver as seguintes rotas originadas do Roteador PE B com a my-soo comunidade:
user@host> show route receive-protocol bgp 10.12.99.2 detail
inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
vpn_blue.inet.0: 8 destinations, 10 routes (8 active, 0 holddown, 0 hidden)
* 10.12.33.0/30 (2 entries, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
10.12.99.0/30 (2 entries, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
* 10.255.71.177/32 (1 entry, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
* 192.168.64.0/21 (1 entry, 1 announced)
Nexthop: 10.12.99.2
AS path: 100 I
Communities: origin:100:1
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
__juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0
hidden)
Configuração da política no roteador PE D
Configure uma política no Roteador D de PE que impeça que rotas com my-soo a comunidade marcada pelo Roteador CE A sejam anunciadas para o Roteador CE E da seguinte forma:
[edit]
policy-options {
policy-statement soo-ce1-policy {
term a {
from {
community my-soo;
then {
reject;
}
}
}
}
}
Configuração da comunidade no roteador PE D
Configure a comunidade no roteador PE D da seguinte forma:
[edit]
policy-options {
community my-soo {
members origin:100:1;
}
}
Aplicação da política no roteador PE D
Para evitar que as rotas aprendidas com o roteador CE A sejam anunciadas para o Roteador CE E (os dois roteadores podem comunicar essas rotas diretamente), aplique a declaração de soo-ce1-policy política como uma política de exportação para a sessão vpn_bluede EBGP do Roteador PE e CE.
Veja a sessão de EBGP no roteador PE D usando o show routing-instances comando.
user@host# show routing-instances
vpn_blue {
instance-type vrf;
interface fe-2/0/0.0;
vrf-target target:100:200;
protocols {
bgp {
group ce2 {
advertise-peer-as;
peer-as 100;
neighbor 10.12.99.6;
}
}
}
}
Aplique a soo-ce1-policy declaração de política como uma política de exportação para a sessão vpn_blue EBGP do roteador EBGP do Roteador PE e CE da seguinte forma:
[edit routing-instances]
vpn_blue {
protocols {
bgp {
group ce2{
export soo-ce1-policy;
}
}
}
}