Resumo
MULTI_EXIT_DISCé uma sugestão fraca, opcional e não transitiva sobre a entrada preferida entre vários enlaces ao mesmo AS anunciante; o menor valor só participa depois que critérios locais mais fortes permanecem iguais.- A rede receptora controla o efeito: pode remover ou alterar MED antes da seleção, e a regra comum compara valores apenas entre caminhos aprendidos do mesmo AS vizinho.
- Uso correto exige significado bilateral, candidatos suficientemente visíveis e prova em execução. Tratar números de redes distintas como escala única pode causar escolhas incoerentes ou oscilação persistente em topologias específicas.
AS 65001 encontra AS 65002 em São Paulo e Fortaleza. Para o mesmo prefixo, anuncia MED 20 em Fortaleza e MED 80 em São Paulo. A mensagem diz que, se outros atributos importantes forem iguais, 65001 prefere receber esse tráfego em Fortaleza. Talvez haja mais capacidade, caminho interno menor ou restrição no outro local.
65002 ainda escolhe. Seu contrato pode dar LOCAL_PREF menor ao caminho de Fortaleza. Pode aceitar MED só em algumas relações, retirar o atributo, substituir o valor ou decidir em um roteador que não vê a alternativa. O número baixo não escreve política remota; ele é avaliado dentro de outro sistema governado separadamente.
RFC 4271 representa essa modéstia em MULTI_EXIT_DISC: inteiro sem sinal de quatro octetos, opcional e não transitivo. Mantidos iguais os demais fatores, o menor deve ser preferido. Recebido por EBGP, pode circular por IBGP no AS receptor, mas não deve ser propagado a outro AS vizinho. A sugestão termina na relação que lhe dá contexto.
O poder do receptor é explícito. A implementação deve oferecer mecanismo local para remover MED antes de calcular preferência e selecionar; pode também alterar o valor nessa etapa. O emissor controla o que anunciou. O receptor controla se o número permanece e qual consequência produz.
A fraqueza foi deliberada. RFC 1773 descreveu o antigo inter-AS metric como fator tardio. O objetivo era impedir que operador remoto obrigasse outra rede a absorver ou expulsar tráfego quando ela já havia declarado preferência mais forte. LOCAL_PREF, comprimento de AS_PATH e passos anteriores são a fronteira que mantém a sugestão condicional.
Assim, “o menor MED vence” está errado. MED 10 perde para MED 100 quando o segundo caminho possui LOCAL_PREF melhor ou vence antes. RFC 8326 mostra a limitação em manutenção: elevar MED não drena um enlace quando a alternativa perde anteriormente por LOCAL_PREF ou comprimento de AS_PATH.
O domínio comum é mais estreito. RFC 4271 compara MED apenas entre rotas do mesmo AS vizinho, identificado em AS_PATH. Três valores do AS 65001 podem ordenar suas entradas. Uma rota do AS 65003 provavelmente usa outra topologia, custos e política. Vinte numa relação não é naturalmente menor que quarenta em outra.
MED não cria ordem total. A pode superar B porque ambos vêm do mesmo vizinho e A tem menor MED; B e C, vindos de vizinhos diferentes, seguem outros critérios. Isso não cria sequência transitiva entre A, B e C. Importam agrupamento, vencedor do grupo e informações visíveis ao decisor.
IOS XR descreve o modelo: agrupa candidatos por AS vizinho, escolhe o menor MED de cada grupo e continua a seleção entre os vencedores. É a expressão do domínio limitado e explica por que ordem e integridade dos candidatos podem mudar a resposta.
Alguns produtos permitem comparar MED entre ASes distintos. A opção parece uniforme por colocar todos os números na mesma disputa, mas amplia a influência concedida a valores remotos. Juniper adverte contra escalas sem origem comum e RFC 3345 rejeita esse caminho como remédio geral. O mesmo tipo numérico não prova a mesma unidade.
O receptor pode criar uma escala comum: reescrever todos os valores com política própria ou combinar uma métrica de serviço com participantes específicos. A comparabilidade passa a vir do significado local. Grupo, derivação, ausência e precedência precisam ser registrados; quatro octetos vindos da Internet não carregam unidade automática.
A ausência também exige regra. Como MED é opcional, um caminho pode trazer valor e outro não. Produtos e políticas podem interpretar o silêncio de formas diferentes. O operador verifica o comportamento ativo, sem supor que ausência vale sempre zero, infinito ou a escolha de um fornecedor.
Visibilidade altera a decisão. Full-mesh IBGP distribui mais saídas; Route Reflection e confederações reduzem carga ao não mostrar todo candidato em todo lugar. RFC 4456 alerta que MED nem sempre é comparável e a distância IGP varia por roteador, então certas topologias refletidas podem escolher diferente de uma malha completa.
Isso não condena hierarquia. Exige incluir visibilidade na prova. Se um reflector vê A e B, outro B e C, e a relação não é transitiva, cada decisão local razoável pode retirar informação necessária em outro ponto. A economia de escala mudou a superfície de decisão.
RFC 3345 documenta condições limitadas para oscilação persistente: estruturas específicas de reflectors ou confederação, visibilidade parcial e incoerente de saídas e seleção sensível a MED. Nessas condições, o fenômeno é determinístico. Não ocorre em toda rede, mas também não é ruído físico aleatório.
As respostas mudam autoridade ou visão: redesenhar reflectors, dar visão mútua a bordas, aplicar LOCAL_PREF ao ingressar, normalizar ou remover MED, limitar relações ou distribuir caminhos adicionais. Comparar tudo pode misturar espaços incompatíveis; remover tudo perde conselho útil. A correção corresponde ao mecanismo comprovado.
RFC 5004 trata mudança mais estreita. Se o melhor externo atual e seu candidato sobrevivem até comparação tardia de identificador, o speaker pode manter o atual e evitar troca gratuita. Reduz transições e interrompe seu exemplo, sem resolver todas as oscilações de RFC 3345.
Ordem de chegada também importa. RFC 4451 registra implementações em que guardar a rota mais antiga e ordenar caminhos criava decisão temporal não determinística. O resultado deve vir de entradas e política definidas, não do UPDATE que entrou primeiro na memória. Processamento estável ainda requer verificação por rota.
A prova começa antes do tráfego. Guardar rota bruta, AS de agrupamento, presença de MED, valor após política, LOCAL_PREF, AS_PATH, conjunto visível e motivo do best path. Comparar bordas e pontos internos, não depender de um único looking glass.
Depois verificar forwarding. A escolha BGP deve criar o NEXT_HOP esperado no FIB, e telemetria deve mostrar o fluxo no enlace pretendido. Ver MED baixo não prova vitória. Um best path em um RIB não prova pacotes de outro ingresso. Enlace quieto pode significar desvio, descarte ou falta de demanda.
O teste cobre as duas autoridades. Alterar de modo limitado o valor do emissor e observar recepção e seleção; depois remover ou reescrever no receptor e confirmar política local. Cobrir ausência, igualdade, atributos anteriores diferentes, vários ASes, retirada de saída, reflexão, ordem de chegada e rollback. O objetivo é provar o alcance do conselho.
O acordo vale mais que a sintaxe. Se cliente espera que fornecedor aceite MED em dois links privados, ambos definem prefixos, famílias, links, faixas, LOCAL_PREF anterior, ausência, direito de exceção e telemetria de disputa. Sem contexto, o atributo é válido no fio e ambíguo no serviço.
O princípio de especificação inicial mínima de Heng Lu se encaixa. O protocolo comum oferece objeto pequeno: métrica opcional, propagação limitada e comparação condicional. Não decide se o número representa capacidade, custo ou política. As redes que operam e assumem o resultado mantêm essa escolha.
A primazia do código em execução define aceitação. Documento e commit representam intenção; atributo recebido, reescrita efetiva, candidatos visíveis, razão da escolha, NEXT_HOP e tráfego entregue são o sistema. Se os pacotes não entram pela porta prevista, a métrica não exerceu autoridade prática.
Soberania de dados aqui é controlar o próprio estado operacional, não possuir a rota remota. O emissor descreve a entrada preferida; o receptor aceita quando coincide com contratos e risco. A coordenação funciona porque nenhum entrega sua máquina de decisão.
MED funciona quando ambos entendem sua modéstia. Um número menor recomenda uma porta; não garante corredor, visão interna, acordo de política mais forte ou tráfego real. A fraqueza não é autoridade incompleta. É a proteção que permite aconselhar sem governar.
Fontes
- RFC 4271: A Border Gateway Protocol 4
- RFC 4451: BGP MULTI_EXIT_DISC Considerations
- RFC 3345: BGP Persistent Route Oscillation Condition
- RFC 5004: Avoid BGP Best Path Transitions
- RFC 4274: BGP-4 Protocol Analysis
- RFC 1773: Experience with the BGP-4 Protocol
- RFC 4456: BGP Route Reflection
- RFC 8326: Graceful BGP Session Shutdown
- Cisco: Select BGP Best-path Algorithm
- Cisco IOS XR: Order of comparisons and nontransitivity
- Juniper Networks: BGP MED Attribute
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
- Heng Lu: On Data Sovereignty
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
