IP Anycast Fonte: CMU 1
Overview Porquê o anycast? Balanceamento de carga Fiabilidade Transparência para os clientes Localidade / latência Resposta a DoS 2
Unicast Unicast: Uma única máquina recebe o tráfego B C 10.10.0.1 A D E 10.20.0.1 Source 172.16.0.1 F G Destination 10.30.0.1 3
Multicast Multicast: Múltiplas máquinas recebem todo o tráfego para um grupo Multicast B C 10.10.0.1 233.0.9.3(M) A D E 10.20.0.1 Source 172.16.0.1 F G 10.30.0.1 233.0.9.3(M) 4
Anycast Múltiplos nós configurados par aaceitar tráfego para um único endereço IP Normalmente, um nó recebe todos os pacotes O pacote pode ser descartado Idealmente, apenas um nó recebe o pacote, mas não existem garantias O nó que recebe um pacote especifico é determinado através de routing. 5
Anycast Três nós configurados com o endereço anycast (10.5.0.1) B C 10.10.0.1 10.5.0.1(A) A D E 10.20.0.1 10.5.0.1(A) Source 172.16.0.1 F G 10.30.0.1 10.5.0.1(A) 6
Anycast Equal-cost multi-path Routing Table Destination Next Hop Metric 10.5.0.1/32 B 10 10.5.0.1/32 D 10 10.5.0.1/32 F 10 B C 10.10.0.1 10.5.0.1(A) A D E 10.20.0.1 10.5.0.1(A) Source 172.16.0.1 F G 10.30.0.1 10.5.0.1(A) 7
Anycast Pacotes sequenciais podem ser entregues a diferentes nós anycast B 3 C 3 10.10.0.1 10.5.0.1(A) 3 A 1 D 1 E 1 10.20.0.1 10.5.0.1(A) 1,2,3 2 Source 172.16.0.1 F 2 G 2 10.30.0.1 10.5.0.1(A) 8
Anycast Tráfego de diferentes nós podem seguir caminhos diferentes Source 172.17.0.1 2 2 B 2 C 2 10.10.0.1 10.5.0.1(A) A 1 D 1 E 1 10.20.0.1 10.5.0.1(A) 1 Source 172.16.0.1 F G 10.30.0.1 10.5.0.1(A) 9
Anycast O servidor que recebe o pacote é determinado através de routing unicast Pacote sequenciais de um cliente para um endereço anycast podem ser entregues a servidores diferentes Melhor em protocolos do tipo pedido/resposta 10
Anycast Clientes, servidores e routers não precisam de nenhum software/firmware especial. Não interfere com redes já existentes. Apenas melhora a infra-estrutura já existente. 11
Documentação sobre o Anycast Conceito discutido no RFC1546 (11/93) As práticas correntes evoluíram a partir da experiencia operacional CIDR eliminou alguns problemas no 1546 A evolução é documentada brevemente no RFC2101 (2/97) O DNS com uso do Anycast é referenciado no RFC2181 (7/97) O endereço de origem das respostas tem de ser o mesmo para o qual os endereços foram enviados 12
Documentação sobre o Anycast Anycast IPv6 diferente, mencionado mais tarde Arquitectura (RFC 1884, agora RFC 3513) Endereços anycast reservados (RFC 2526) Prefixo Anycast v4 para routers 6to4 (RFC 3068) Seleccção do endereço de origem (RFC 3484) DHCPv6 (RFC 3315) Anycast authoritative name service (RFC 3258) Anycast para multicast RP (RFC 3446) ISC Technote (ISC-TN-2003-1) Termo anycast usado em 51 RFCs no total 13
Serviços Anycast IPv4 14
Selecção do endereço A prática corrente é usar um endereço a partir do espaço de endereçamento de unicast Usar pequenas subnets para uso de anycast Anúncios para inter-domain routing /24 é uma escolha popular A sub-rede não pode existir em nenhuma interface 15
Configuração dos hosts Têm de ser configurados para aceitar tráfego para o endereço anycast É necessário manter um endereço de gestão nas máquinas Tipicamente os endereços de anycast são configurados como loopbacks adicionais 16
Configurar os endereços IP Linux # ifconfig lo:1 10.5.0.1 netmask 255.255.255.255 up # ifconfig lo:1 lo:1 Link encap:local Loopback inet addr:10.5.0.1 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:16436 Metric:1 OpenBSD # ifconfig lo0 alias 10.5.0.1 netmask 255.255.255.255 # ifconfig lo0 lo0: flags=8049<up,loopback,running,multicast> mtu 33224 inet 127.0.0.1 netmask 0xff000000 inet 10.5.0.1 netmask 0xffffffff 17
Configuração da rede A parte mais complexa é configurar a rede Configuração intra-domain vs. inter-domain 18
Configuração Intra-Domain Se o serviço anycasted é inteiramente dentro de um domínio de routing então apenas é preciso considerar intra-domain. Todos os nós anycasted estão dentro de um domínio Ou múltiplas localizações intra-domain É preciso configurar o routing para entregar o tráfego anycast aos servidores 19
Rotas IGP estáticas Simples: configurar rotas estáticas nos routers first-hop Garantir que as rotas são propagadas dentro do domínio Não responde rapidamente a falhas nos servidores Fornece a facilidade de relocalizar os servidores sem falhas do serviço B C route 10.5.0.1/32 via 10.10.0.1 10.10.0.1 10.5.0.1(A) A D E 10.20.0.1 10.5.0.1(A) Source 172.16.0.1 F G 10.30.0.1 10.5.0.1(A) 20
Rotas IGP dinâmicas Correr um daemon de routing nos servidores que usem endereços de anycast GateD Zebra/Quagga O servidor é a origem das rotas Quando o servidor está em baixo a rota é removida Facilita a infra-estrutura de routing 21
Rotas IGP dinâmicas Cada máquina anuncia a rota através de IGP B C 10.10.0.1 10.5.0.1(A) 10.5.0.1/32 connected A D E 10.20.0.1 10.5.0.1(A) 10.5.0.1/32 connected Source 172.16.0.1 F G 10.30.0.1 10.5.0.1(A) 10.5.0.1/32 connected 22
Rotas IGP dinâmicas Configuração dependente do IGP Redistribuição das rotas ligadas, se os endereços de anycast forem loopbacks A máquina em cima não implica que o serviço esteja em cima É necessário um mecanismo que remova as rotas automaticamente quando o serviço não está utilizável 23
Configuração Inter-Domain Seguir as regras operação de BGP tradicionais Anunciar de um AS de origem consistente Anunciar a supernet do serviço/anycast Limitar as flutuações (flapping) das rotas Usar um conjunto de endereços PI (Provider Independet) O routing Intra-domain tem de estar a funcionar Os servidores podem ser peers de ibgp peered; anúncios na máquina como se fosse uma rede Pode usar IGP com redistribuição das rotas Remover as rotas quando o serviço estiver indisponivel numa determinada localização 24
Configuração Inter-Domain Algumas implementações destinguem nós globais de nós locais Os globais são anunciados sem limitações; os routers acima fornecem o trânsito Os nós locais adicionam o atributo no-export para limitar os clientes que irão utilizar o nó Porquê? Custos (globais/locais implicam diferentes relações) Estabilidade dos nós, capacidades (devido à área abrangida pelo serviço) 25
Configuração Inter-Domain AS65515 End Site Global 1 10.5.0.1/24 AS65500 AS65505 End Site AS65510 Transit Peer AS65501 Transit AS65530 NoExport Peer AS65535 End Site AS65520 NoExport Local 1 10.5.0.1/24 AS65500 AS65525 End Site 26
Configuração do serviço Depende da implementação Configurar o serviço para ficar à escuta no endereço de anycast A maioria não precisa de qualquer configuração especial Verificar que o serviço usa como endereço de origem o endereço de anycast Podemos limitar o serviço apenas a ficar à escuta apenas no endereço de anycast Assumir um serviço idêntico em cada servidor 27
Uso de endereços anycast Os clientes são apontados para os endereços de anycast O serviço com anycast é configurado pelo nome DNS Autoritário, Syslog, Kerberos Pode-se utilizar o round-robin do DNS para redundância adicional ;; ANSWER SECTION: ns1.example.com. 86400 IN A 10.5.0.1 28
Uso de endereços anycast Serviço de Caching DNS Atribuir os endereços dos servidores por DHCP, PPP, word of mouth Cuidado com a implementação má dos Resolvers de DNS O primeiro servidor de DNS configurado é o usado em todos os pedidos Resulta em atrasos para muitos pedidos Oportunidade para uso do anycast 29
Monitorização É mais complicada Pode monitorizar o IP único (não anycast), mas não verifica o serviço actual Monitorizar o serviço anycast não pode ser feito centralmente É necessária uma monitorização distribuida E também é necessário monitorizar as rotas 30
Case studies 31
Uso de anycast em produção DNS autoritário AS 112 Root Servers: F, I, K, outros.org Top Level Domain Serviços de Caching DNS Anycast para Multicast RP (Rendezvous Points) Anycast Sink Holes Routers 6to4 (RFC3068) 32
Projecto AS112 Problema: Muitos clientes tentam pedidos e actualizações para as zonas reversas dos endereços privados (RFC1918/link local) Objectivo: Reduzir a carga desnecessária dos root servers originada por estes pedidos/actualizações Solução: Delegar as zonas reversas para black-holes anycast www.as112.net Os servidores black-hole usam IPs da gama 192.175.48.0/24 Anunciados a partir de 16 localizações mundiais Origem comum a todos: AS112 33
Configurar o BGP Um vendedor.. router bgp 112 bgp router-id 192.175.48.254 network 192.175.48.0 neighbor PEER_IP remote-as PEER_AS neighbor PEER_IP ebgp-multihop neighbor PEER_IP next-hop-self [http://www.chagreslabs.net/jmbrown/research/as112/] Outro vendedor.. policy-statement advertise-aggregate { term first-term { from protocol aggregate; then accept; } term second-term { from route-filter 192.175.48.0/24 longer; then reject; } } [continued] 34
Configurar o BGP Another Vendor.. # set routing-options aggregate route 192.175.48.0/24 [edit protocols bgp group 112] # set export advertise-aggregate # set type external # set peer-as PEER_AS # set neighbor PEER_IP 35
Projecto AS112 Configuração do BIND zone 10.in-addr.arpa { type master; file db.rfc-1918 ; }; zone 254.169.in-addr.arpa { type master; file db.rfc-1918 ; };... Zone File: db.rfc-1918 $TTL 300 @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. ( 2002040800 30m 15m 1w 1w ) NS blackhole-1.iana.org. NS blackhole-2.iana.org. [http://www.chagreslabs.net/jmbrown/research/as112/] 36
Root Servers Problemas: Baixa concentração de root servers fora dos Estados Unidos (latência elevada, custos de ligações elevados) Ataque DoS atingem os root servers e a infra-estrutura até eles Não é possível adicionais mais registos NS à root zone Objectivo: Adicionar root servers às áreas sub-representadas do mundo Solução: Usar anycast inter-domain para servir os endereços IP dos root servers 37
Root Servers F root server (ISC) anycasted Primeiro nó clonado anunciado em Nov. 2002 46 sites (44 locais + 2 globais) Origem AS3557 O segundo salto AS também está atribuído ao ISC Global Node AS Path... 3557 3557 3557 Local Node AS Path (Ex)... 23709 3557 38
.ORG Top Level Domain Uso de anycast desde 2003 DDoS contra os servidores em Setembro de 2003 Sugestão de uma falha numa localização a monitorização que testa cada um dos nós de anycast não reportaram qualquer falha DNS fornecido pois 2 servidores anycast (204.74.112.1, 204.74.113.1) Duas /24; fornecedores de trânsito diferentes 11 ASs diferentes de segundo salto 39
Caching DNS Problemas: Os hosts respondem deficientemente quando o caching nameserver está inatingível É dificil trocar os IPs ao Caching NS Objectivo: Ter o serviço sempre disponível no primeiro endereço IP disponibilizado aos clientes Solução: Usar servidores anycasted; configurar o IPs de anycast nos clientes 41
Caching DNS Exemplo: 128.2.1.0/26 para intra-domain anycast Dois servidores de caching com os IPs: 128.2.1.10, 128.2.1.11 Usam o BIND9 Configurado em 4 servidores; 6 interfaces Os endereços são distribuídos por DHCP e/ou PPP 42
Caching DNS Cada servidor usa um serviço de encaminhamento (Quagga) para se ligar à nuvem OSPF Usa áreas NSSA do OSPF para as máquinas Minimiza o número de rotas nos servidores Permite multiplas interfaces nos servidores em áreas NSSA separadas mas sem qualquer encaminhamento através dos servidores 43
Caching DNS Config Alterações no BIND 9 options { listen-on { 128.2.1.10; 128.2.1.11; }; query-source address 128.2.4.21; }; Modificações nos routers acima router ospf 1 area 0.0.0.0 authentication message-digest area 128.2.4.0 authentication message-digest area 128.2.4.0 nssa default-information-originate no-summary network 128.2.4.0 0.0.0.63 area 128.2.4.0 network 128.2.0.0 0.0.255.255 area 0.0.0.0 44
Caching DNS Config Alterações no BIND 9 options { listen-on { 128.2.1.10; 128.2.1.11; }; query-source address 128.2.4.21; }; Nota: Modificações nos routers acima Garantir que os servidores não enviam tráfego que não seja router ospf 1 area 0.0.0.0 respostas authentication da interface message-digest anycast area 128.2.4.0 authentication message-digest area 128.2.4.0 nssa default-information-originate no-summary network 128.2.4.0 0.0.0.63 area 128.2.4.0 network 128.2.0.0 0.0.255.255 area 0.0.0.0 45
Caching DNS Config Routers acima, de outra forma [edit protocols ospf] area 4 { nssa { area-range 128.2.4.0/26; default-lsa { default-metric metric; type-7; } no-summaries; } authentication-type md5; interface interface; } 46
Configuração do Routing nos Hosts quagga.conf interface eth0 ip address 128.2.4.21/26! interface lo:1 ip address 128.2.1.10/32! interface lo:2 ip address 128.2.1.11/32 ospfd.conf interface eth0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 [key]! router ospf ospf router-id 128.2.4.21 ospf abr-type cisco compatible rfc1583 area 128.2.4.0 authentication message area 128.2.4.0 nssa network 128.2.4.21/26 area 128.2.4.0 redistribute connected distribute-list 50 out connected! access-list 50 permit host 128.2.1.10 access-list 50 permit host 128.2.1.11 47
Multicast RP Problema: PIM-SM especifica um RP activo por grupo de multicast numa determinada altura Um dominio de routing pode ser grande demais para isto ser possível (RP na outra ponta do mundo) Failover lento se o RP falhar Se usarmos o balanceamento da shared-tree pode não ser possível Objectivo: Multiplos RPs para o mesmo grupo dentro de um domínio de routing Solução: Usar endereços anycast para o RP (RFC3446) 48
Multicast RP Designar mais que um RP Atribui um endereço de anycast com um loopback em cada RP Configurar todos os outros routers para usar endereços de anycast como RP em todos os grupos Configurar a malha MSDP (Multicast Source Discovery Protocol) em todos os RPs (usando endereços unicast) Os endereços do RP não podem ser usados em mensagens SA (Source Active) 49
Multicast RP RP Routers interface Loopback0 description Router Management ip address 10.2.4.249 255.255.255.255 ip pim sparse-mode interface Loopback1 description Anycast RP Interface ip address 10.2.1.130 255.255.255.255 ip pim sparse-mode! ip msdp peer 10.2.4.248 connect-source Loopback0 ip msdp peer 10.2.4.250 connect-source Loopback0 ip msdp mesh-group CMU-MSDP 10.2.4.248 ip msdp mesh-group CMU-MSDP 10.2.4.250 ip msdp cache-sa-state ip msdp originator-id Loopback0 Non-RP Routers ip pim rp-address 10.2.1.130 override ip pim accept-rp 10.2.1.130 50
Multicast RP RP Routers [edit interfaces lo0 unit 0 family inet] # set address 10.2.4.249/32 # set address 10.2.1.130/32 [edit protocols pim] rp { local { address 10.2.1.130; } } interface all { mode sparse; version 2; } [edit protocols msdp] group CMU-MSDP { local-address 10.2.4.249; mode mesh-group; peer 10.2.4.248; peer 10.2.4.250; } Non-RP Routers [edit protocols pim] rp { static { address 10.2.1.130 { version 2; } } } 51
Multicast RP Non-Anycast RP Source Único RP para os grupos RP Routers ebgp, MBGP Receiver RP pode não ser interessante para a shared tree 52
Multicast RP Anycast RP Múltiplos RPs para os grupos Source MSDP Mesh, Endereços Unicast RP RP Routers ebgp, MBGP RP Pode optimizar a localização dos RPs Receiver 53
Sinkholes Anycast Problema: Tráfego Homeless (e.g. worms, etc) pode causar problemas para aos routers de core para os afundar ; sinkholes ajuda mas também não queremos enviar o tráfego ao longo da rede só para ser afundado Objectivo: Ser capaz de encaminhar o tráfego para múltiplos sinkholes para análise Solução: Usar anycast para permitir sinkholes distribuídos ao longo da rede 54
Sinkholes Anycast O tráfego pode ser direccionado para um sinkhole através de: default route Bocados de endereçamento IP não usado Alteração do next-hop do BGP next-hop, ex: para vítimas de DoS Pode ser usados endereços anycast para criarmos múltiplos sinkholes 55
Routers 6to4 Problema: Ligar ilhas v6 ao longo da infra-estrutura v4 existente envolve routers de relay 6to4 Objectivo: Fornecer uma forma fácil para os end sites localizarem os relays para o mundo IPv6 nativo Solução: Usar um endereço IPv4 bem conhecido para os routers 6to4 56
Routers 6to4 Native IPv6 Site Using 6to4 Prefix 6to4 R IPv4 Backbone Anuncia internamente 0::/0 Anuncia o prefixo anycast v4 6to4 192.88.99.0/24 6to4 RR IPv6 Backbone 6to4 RR Anuncia 2002::/16 para o backbone IPv6 57
Serviços baseados em TCP Não é bom usar anycast para serviços TCP longos no tempo, por causa das mudanças de rotas Apesar de tudo a experiencia mostra que as rotas são relativamente estáveis Especialmente\ entre domínios, devido aos protocolos de encaminhamento O equal cost load balancing pode ainda causar mais problemas Mas, os routers muitas vezes fazem caching do flow path 58
TCP-Based Services Poucas formas de direccionar o tráfego em caso de resposta à carga do servidor as long as you don't make silly assumptions about client locality based on "which anycasted server heard it", such that you give back incoherent answers in hopes that they will be somehow client-optimal, bgp-anycast isn't even controversial at this point in time. - Paul Vixie, 4/03 59
Outros usos Potenciais NTP/Time Syslog RADIUS Kerberos Todos os pacotes baseados numa resposta de um único pacote são fáceis 60
Tópicos avançados 61
Hosts Multi-Homed Multi-homing na interface física do host Pode ser usado com endereçamento anycast Caso especial: um único multi-homed host configurado com um endereço de anycast Endereço do serviço Redundancia do servidor, sem separação de serviços Configuração já conhecida Complicações com a default route para o host 62
Anycast em IPv6 As implementações baseadas no RFC 3513 (Abril 2003) consideram o anycast restrito aos routers Nas implementações baseadas no RFC 4291 (Fev 2006) esta restrição já não existe e o funcionamento é análogo ao em IPv4 63
Identificar um nó anycast específico F Root Server dig hostname.bind @f.root-servers.net chaos txt K Root Server dig id.server @k.root-servers.net chaos txt.org TLD Servers dig whoareyou.ultradns.net @tld1.ultradns.net dig whoareyou.ultradns.net @tld2.ultradns.net 69