Arquivo

Archive for abril \26\UTC 2010

Curso IRR – Parte IX: objeto aut-num

Introdução

A referência [2] é uma descrição da RPSL (Routing Policy Specification Language) e foi atualizada por [3], que estende para IPv6. É uma linguagem muito poderosa, que permite aos administradores e operadores de redes especificarem políticas de roteamento em vários níveis e, escalável, ou seja, preparada para receber especificações de novos protocolos que, eventualmente, surjam no futuro. Finalmente, foi projetada com a expectativa de estabelecer políticas de roteamento globalmente que permitissem, cooperativamente, sua manutenção através de bases de dados distribuídas devidamente homologadas ou reconhecidas.

Definindo políticas de roteamento através da RPSL os administradores de ASes:

  • Melhorariam, cada vez mais, a integridade do roteamento na Internet.
  • Usariam ferramentas, que a partir do alto nível de especificação da RPSL, gerassem as configurações necessárias aos diversos roteadores disponíveis.
  • Teriam uma documentação de toda a política de roteamento, da topologia de suas redes e, fácil de ser lida, entendida e mantida, com visão de conjunto.
  • Teriam disponível uma linguagem baseada em objetos, que representam informações de política de roteamente e informações administrativas, extremamente importantes para todos os administradores de redes. Tais objetos são registrados no IRR por pessoas autorizadas.
  • Estariam confiantes (como consequência da cooperação), de que é uma ferramenta capaz de contribuir para que as configurações dos roteadores onde, a pouca intervenção humana protegeria adequadamente seus ambientes, de informações pouco precisas por motivações acidentais ou maliciosas. Vide [3].

As referências [1] e [2], são respeitadas pelos servidores do IRR, que fazem uma análise sintática e semântica sobre os atribustos e seus respectivos valores (como os compiladores). Mais recentemente, os servidores do IRR se ajustaram aos novos objetos propostos na RPSL e estão mais poderosos ao dar sustentação às ferramentas de manipulação das informações da base de dados do RADB (também, as homoladas – intermediárias – e, as privadas). Ganharam os administradores de ASes.

Recomenda-se a leitura do item 2 de [1]: “RPSL Names, Reserved Words, and Representation”.

O objeto aut-num

O objeto aut-num descreve as informações sobre um AS e suas políticas de roteamento, tanto sob o ponto de vista dos anúncios, como da aceitação de redes. Ele se aplica tanto ao IPv4 como ao IPv6.

Um dos mais importantes objetos de uma base IRR usa, intensivamente, a capacidade de relacionamento dos objetos, entre si. Alguns já vistos e outros a serem descritos nesse treinamento nos próximos segmentos. Assim, o objeto aut-num é combinado com o objeto que caracteriza o roteador (inet-rtr) e que fornece o número do sistema autônomo, indica as interfaces do roteador e que por sua vez é combinado com o objeto que mapeia os ASes envolvidos (as-set) e, finalmente se estendem aos objetos route(6) e route-set, dando segurança à informação dos prefixos que são anunciados. Os objetos as-set, route-set e inet-rtr serão discutidos nos próximos segmentos, mas podem ser encontrados em [1] e [2]

Os atributos do objeto aut-num

aut-num:        [obrigatório]  [único]      [primary/look-up key]
as-name:        [obrigatório]  [único]      [ ]
descr:          [obrigatório]  [único]      [ ]
member-of:      [opcional]     [multiplo]   [inverse key]
import:         [opcional]     [multiplo]   [ ]
export:         [opcional]     [multiplo]   [ ]
default:        [opcional]     [multiplo]   [ ]
remarks:        [opcional]     [multiplo]   [ ]
admin-c:        [obrigatório]  [multiplo]   [inverse key]
tech-c:         [obrigatório]  [multiplo]   [inverse key]
cross-mnt:      [opcional]     [multiplo]   [inverse key]
cross-nfy:      [opcional]     [multiplo]   [inverse key]
notify:         [opcional]     [multiplo]   [inverse key]
mnt-by:         [obrigatório]  [multiplo]   [inverse key]
changed:        [obrigatório]  [multiplo]   [ ]
source:         [obrigatório]  [único]      [ ]

Usando o objeto aut-num

No que segue, algumas adaptações foram feitas de [4].

Um cenário simples, para começar

A figura 1 exibe esse cenário simples e, razoavelmente comum:

Figura 1: Uma representação simples de uma conexão usando o BGP

Na figura 1, acima, a política de roteamento tendo em vista o conceito básico de anúncio e aceitação, para que dados da \textbf{Rede 1 } possam trafegar na direção da \textbf{Rede 2 } e vice-versa, está resumida nos seguintes pontos:

  1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{y }.
  2. \textbf{AS} _ \textbf{y } deve aceitar o anúncio de \textbf{AS} _ \textbf{x } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 2 } para a \textbf{Rede 1 }.
  3. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{x }.
  4. \textbf{AS} _ \textbf{x } deve aceitar o anúncio de \textbf{AS} _ \textbf{y } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 1 } para a \textbf{Rede 2 }.

O objeto aut-num é quem nos permitirá explicitar a política acima no IRR, através dos atributos import e export. Os respectivos objetos aut-num relativos aos sistemas autônomos \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, enviados para \textbf{email\_automatico@} \textbf{redepegasus.net.br} seriam:

aut-num:    \textbf{AS} _ \textbf{x }
as-name:    \textbf{AS} _ \textbf{x }-NET
descr:      \textbf{AS} _ \textbf{x } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asx.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:     to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
admin-c:    IDASx-NICBR
tech-c:     IDASx-NICBR
notify:     asx-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{x }
changed:    asx-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{x }

aut-num:    \textbf{AS} _ \textbf{y }
as-name:    \textbf{AS} _ \textbf{y }-NET
descr:      \textbf{AS} _ \textbf{y } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asy.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:     to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
admin-c:    IDASy-NICBR
tech-c:     IDASy-NICBR
notify:     asy-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{y }
changed:    asy-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{y }

Simplificando a apresentação

Para efeito didático, iremos suprimir os atributos já conhecidos e, assim, representaremos nosso objeto, da seguinte forma, com o nome de “Configuração”:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
...
aut-num: \textbf{AS} _ \textbf{y }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
...

Configuração 1. Cenário simples

Um cenário não tão simples

Vamos ampliar para o cenário representado na figura 2, abaixo, onde agora podemos identificar a Internet:

Figura 2. Um cenário não tão simples

Em tese são quatro, os administradores de ASes envolvidos nesse cenário. Pouco se conhecem e devem pensar de maneira independente. O caráter colaborativo do IRR, entretanto induz a pensarmos que cada um deles estará atento às especificações dos outros em relação à política de roteamento. Tal atenção ocorre de três maneiras: (a) pela pesquisa à base IRR em relação aos ASes que fazem “peering” (seja qual for o tipo de tráfego), (b) durante o uso das ferramentas de apoio (p.ex., RTConfig), momento em que possíveis inconsistências podem ser encontradas e, (c) através de ferramentas de monitoramento próprias ou de terceiros (p.ex., MyASN). Vale um comentário de que tais ferramentas estão cada vez mais interessantes e eficazes, com mudanças nos protocolos e nos equipamentos (em especial roteadores). Um dos indutores dessas transformações é a área de conhecimento que está sendo chamada de “route analytics”. Eis as observações que caracterizam a política de roteamento do cenário exibido na figura 2, sob o ponto de vista de cada um dos sistemas autônomos envolvidos:

  • Sob o ponto de vista do \textbf{AS} _ \textbf{w }:
    1. \textbf{AS} _ \textbf{w } fornece trânsito para \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }.
    2. \textbf{AS} _ \textbf{w } fornece rotas locais para \textbf{AS} _ \textbf{z }.
    3. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{x }.
    4. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para para o resto do mundo.
    5. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y }.
    6. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{y }.
    7. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para para o resto do mundo.
    8. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x }.
    9. \textbf{AS} _ \textbf{w } deve anunciar a rede do \textbf{AS} _ \textbf{y } para para o \textbf{AS} _ \textbf{z }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{x }
    1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{x } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{y }
    1. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{y } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{z }
    1. \textbf{AS} _ \textbf{z } deve aceitar todos os anúncios vindos de \textbf{AS} _ \textbf{w }.

O objeto aut-num sob a ótica do \textbf{AS} _ \textbf{w }

Vamos nos abstrair de alguns pontos da política de roteamento, nesse exemplo. Primeiro, não iremos definir a política para os itens 4 e 6. Isso porque nos falta algumas considerações sobre outros objetos e recursos dos respectivos atibutos. Portanto, deixaremos para abordar no próximo segmento. Segundo, não estamos interessados em em detalhes do \textbf{AS} _ \textbf{z } exceto o fato de que ele recebe anúncios do \textbf{AS} _ \textbf{w }.

Dito isso, eis o objeto aut-num para o \textbf{AS} _ \textbf{w }:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{x }
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{y }
import:  from \textbf{AS} _ \textbf{z } accept \textbf{AS} _ \textbf{z }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{z } announce \textbf{AS} _ \textbf{w }
...

Configuração 2. Sob a ótica do \textbf{AS} _ \textbf{w }

Uma pergunta que pode surgir, ao olhar a configuração 2 é: os anúncios de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } já não fazem parte dos anúncios de \textbf{AS} _ \textbf{w }? Boa pergunta! Fica como exercício. Assim, também, os objetos aut-num para os demais ASes envolvidos.

Adicionando mais complexidade ao cenário

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, através de um acordo bilateral estabeleceram um enlace privativo (em vermelho):

Figura 3: Um enlace privativo no cenário.

Iremos abordar esse novo cenário, na Parte X. A figura foi colocada antes, para se pensar sobre quais preocupações devem ser inseridas na política de roteamente. Por exemplo, se o enlace para o provedor de trânsito falhar, os \textbf{ASes} do acordo bilateral irão permitir o acesso ao trânsito pela conexão privativa?

Itens relacionados:

Referências do segmento

[1] \textbf{RFC2622}, Routing Policy Specification Language (RPSL) C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes \textbf{RFC2280}) (Updated-By \textbf{RFC4012}) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[2] \textbf{RFC4012 }, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725 }, \textbf{RFC2622 }) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

[3] \textbf{RFC2725 }, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By \textbf{RFC4012 }) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[4] Wijayatunga, C. (Part I) e Upadhaya, G. R. (Part II), APNIC Internet Routing Registry Tutorial. Disponível em http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf. Acessado em: 29/04/2010.

[5] Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.ciscopartner.biz/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 29/04/2010.

Anúncios
Categorias:IRR, Peering, Protocolos, TCP/IP, Whois

Curso IRR – Parte VIII: objetos inet(6)num

Introdução

Ao longo desse segmento faremos referência a inet(6)num para falar tanto do objeto inetnum, como do objeto inet6num. Quando for necessário esclarecer questões particulares, faremos referência a cada objeto, individualmente.

Os objetos inetnum ou inet6num representam as alocações e atribuições de endereços IPv4 ou IPv6 definidos pelos RIRs/NIRs ao AS em questão. O objeto inetnum, originalmente existia antes do objeto route. Já o objeto inet6num apareceu depois, juntamente com o route6.A diferença é que o objeto route(6) explicita o prefixo enquanto que o int(6)num explicita o espaço de endereçamento.

Atributos do objeto inetnum

inetnum:       [obrigatório]  [único]      [chave primária e de pesquisa]
netname:       [obrigatório]  [único]      [pesquisa]
descr:         [obrigatório]  [único]      [ ]
country:       [obrigatório]  [múltiplo]   [ ]
admin-c:       [obrigatório]  [múltiplo]   [chave inversa]
tech-c:        [obrigatório]  [múltiplo]   [chave inversa]
rev-srv:       [opcional]     [múltiplo]   [chave inversa]
status:        [obrigatório]  [único]      [ ]
remarks:       [opcional]     [múltiplo]   [ ]
notify:        [opcional]     [múltiplo]   [chave inversa]
mnt-by:        [obrigatório]  [múltiplo]   [chave inversa]
changed:       [obrigatório]  [múltiplo]   [ ]
source:        [obrigatório]  [único]      [ ]

Atributos do objeto inet6num

inet6num:  [obrigatório] [único]    [chave primária e de pesquisa]
netname:   [obrigatório] [único]    [pesquisa]
descr:     [obrigatório] [múltiplo]
country:   [obrigatório] [múltiplo]
admin-c:   [obrigatório] [múltiplo] [chave inversa]
tech-c:    [obrigatório] [múltiplo] [chave inversa]
rev-srv:   [opcional]    [múltiplo] [chave inversa]
status:    [opcional]    [único]
remarks:   [opcional]    [múltiplo]
notify:    [opcional]    [múltiplo] [chave inversa]
mnt-by:    [opcional]    [múltiplo] [chave inversa]
changed:   [obrigatório] [múltiplo]
source:    [obrigatório] [único]

Descrição dos atributos mais importantes

inet(6)num

O atributo inetnum do objeto inetnum contem a faixa de endereços IPv4 para o qual o objeto está dando informações. Há várias formas de representar a faixa de endereços, item 2 de [1], vejamos:

  • Uma classe IP:
    inetnum: 192.168.10.0
    

    onde a rede pode ser uma classe A, B ou C.

  • Duas classes IP:
    inetnum: 192.168.10.0 - 192.168.11.0
    

    onde a rede pode ser uma classe A, B ou C. Nesse caso o hífen (“-“) deve estar presente, juntamente com o IP final que representa a classe. No exemplo, a representação de uma classe C.

  • Representação “classeless” => opção preferida!:
    inetnum: 192.168.10.0 > 192.168.11.255
    

    No exemplo, a representação de duas classes C, pelas especificações dos endereços IPv4, inicial e final. Poderia ser qualquer representação de endereços inicial e final.

O atributo inet6num do objeto inet6num, por outro lado, tem o formato de seu valor simplificado. É a representação IPv6, em CIDR. Por exemplo:

inet6num: 2001:DB8::/32

Uma boa referência está em [3], onde alguns padrões de objetos excedem os padrões representados nos segmentos. Estes devem ser considerados!

netname

É um nome simbólico para o espaço de endereçamento especificado no atributo inet(6)num. Não há restrições, cf. [3], quanto ao nome escolhido. Entretanto, recomenda-se algo parecido com a proposta do RIPE, que seja o nome do objeto conforme descrito no item 2 da RFC2622, atualizada por [3]. A sugestão é: nome_curto_da_empresa-NET. É importante lembrar, que o atributo netname é um atributo de pesquisa. Se não houver uma padronização, dificilmente o usaremos em pesquisa. A recomendação é de que as instituições responsáveis recomendem uma padronização, pelo menos no âmbito de um país ou região.

mnt-by

Esse atributo é múltiplo, o que significa que pode haver diversos mantenedores para o objeto. Então, o atributo mnt-by é quem será usado para identificar o(s) mantenedor(es) autorizado(s) a fazer solicitações de alterações. O mecanismo de autenticação irá verificar no respectivo objeto mntner se o mantenedor está com autoridade para a inclusão, alteração ou exclusão.

O ponto principal a ser lembrado das observações acima é de que há um inter-relacionamento entre os objetos da base IRR, através de seus atributos. Em particular, o atributo mnt-by é quem identifica se a intervenção está devidamente autorizada.

Itens relacionados:

Referências do segmento

[1] Lord, A., Terpstrahttp, M., RIPE Database Template for Networks and Persons, \textbf{RIPE-119}.

[2] \textbf{RFC2772}, 6Bone Backbone Routing Guidelines R. Rockell, R. Fink [ February 2000 ] (TXT = 28565) (Obsoletes \textbf{RFC2546}) (Updated-By \textbf{RFC3152}) (Status: INFORMATIONAL) (Stream: IETF, Area: ops, WG: ngtrans).

[3] \textbf{RFC4012}, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725}, \textbf{RFC2622}) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

Categorias:IRR, TCP/IP

Curso IRR: Aula complementar I – Espelhamento e segurança nos IRRs

Atualização em 30/05/2010.
Atualização em 25/05/2010.
Atualização em 22/05/2010.

Como é feito o espelhamento

Os grandes provedores de backbone estão usando, sistematicamente, o IRR por razões de segurança, principalmente. Então, cada um estabeleceu um servidor IRR e muitos deles são espelhadas pelo RADB e, também, espelham o RADB. Mas, não necessariamente espelham TODOS os IRRs(1).

Cada IRR gera uma base (texto) populada por seus respectivos objetos. Geralmente leva o nome da base, como por exemplo, radb.db, level3.db, pegasus.db, etc. O whois e/ou ferramentas quando dirigidos a uma base específica, podem não encontrar um objeto pelo fato da base na qual ele foi inserido não existir naquele servidor. Se ela não existe é porque o servidor não espelha aquele IRR e nem armazena a base do IRR (via ftp, p. ex.).

As razões pelas quais nem todos os servidores IRR espelham ou mantem muitas das bases IRRs, a exemplo do RADB, não interessa no debate. Não merece o debate porque, nesse caso há ausência do princípio da cooperação (estima-se umas 60 bases descentralizadas de IRR). Cooperação contribui, significativamente, para Internet mais saudável. Para ilustrar a questão do espelhamento, o exemplo abaixo é interessante, além de exibir uma incoerência técnica:

     whois -m 187.49.0.0/20
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

     route:      187.49.0.0/20
     descr:      SCW Telecom - IPv4 CIDR block
     origin:     AS28138
     mnt-by:     MAINT-AS28138
     remarks:    Sat Apr 10 12:58:25 BRT 2010
     changed:    herbert@scw.net.br 20100410
     source:     PEGASUS

O whois da PCCW, na relação de IRRs é rr.ntt.net. O resultado da mesma consulta naquele servidor é:

     whois -h whois.pccwbtn.com 187.49.0.0/20    
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

Uma tentativa de consultar o AS28138, tem o resultado abaixo:

    whois -h rr.ntt.net AS28138
    %  No entries found for the selected source(s).

De onde pode-se concluir:

  1. O IRR da NTTCOM é espelhado pelo RADB.
  2. O IRR da NTTCOM não espelha o RADB.
  3. A NTTCOM registra seus objetos na sua própria base IRR e usa como valor do atributo source, o RADB.
  4. À incoerência técnica junte-se inconsitência da informação contida no atributo descr.

A Level3, por exemplo, não adota tal postura.

Entretanto há outras razões para tal comportamento: segurança e confiabilidade.

Segurança e confiabilidade do IRR

Recentemente, na lista Alumni (ex-alunos do curso de IPv6 do Nic.br – Alumni at ceptro dot br) houve um rápido debate sobre segurança nos IRRs. Tal debate envolvia RPKI (“Resource Public Key Infrastructure”), IRR e, por tabela, roteadores. Não iremos entrar no mérito das técnicas usadas pelo RPKI. Para quem se interessar em detalhes, os engenhos de pesquisas, são ótimos amigos. Um trabalho recente, sobre os padrões RPKI em desenvolvimento está em [7]. Também não iremos abordar nada relacionado a roteadores, mas há um sentimento de que o futuro deles passará por computações pervasiva e ubíqua. O conhecimento inicial para acompanhar as noções de criptografia para entender RPKI está vastamente exposto em [8] e [9].

Uma questão que tem sido lembrada mas, não tanto enfaticamente como deveria é a confiabilidade da base IRR. Por um lado, o fator custo da manutenção e, por outro, a razoável complexidade da linguagem de especificação (RPSL) das políticas de roteamento, que enfraquecem o espírito da atualização sistemática. Confiabilidade passa necessariamente por processos de aquisição de conhecimento e, naturalmente, orientação permanente uma vez que o cenário é muito dinâmico. Há um visível crescimento, em especial no Brasil, de novos ASes, com perspectiva de maior intensidade à medida que o IPv6 for aumentando a presença.

Desde uns dois anos atrás tem sido debatido e exposto(2) e, mais recentemente(3), a questão da segurança nas bases IRR. Randy Bush e outros colaboradores(3), têm insistido em um modelo interessante. Segurança muito mais atenta à confiabilidade do IRR e sua importância na direção de manter a Internet funcionando sem os problemas causados por erros de configuração, de originação (AS de origem) e na prevenção de ataques maliciosos. Tal proposta tem recebido aplausos e indicações de que os fundamentos que deram origem à RPSL, que especifica os objetos formadores da base IRR. Os seguintes pontos e motivações retiram eventuais dúvidas de interpretação da proposta:

  • Garantir a qualidade dos dados dos IRRs.
  • Criação de mecanismos formais de verificação da legitimidade dos objetos criados no IRR.
  • Criação de mecanismos formais para verificar as políticas de roteamento e respectivos anúncios.
  • Verificar a ORIGEM das políticas.
  • Verificar a corretude das políticas de roteamento criadas nos IRRs.
  • Administradores de ASes não compreendem ou, simplesmente, não querem usar IRRs.
  • A dependência pela disponibilidade da Internet tem crescido vertiginosamente.
  • Segurança dos sistemas de roteamento tem piorado, ao invés de melhorar(6).
  • A implementação completa do RPKI está disponível em “open source”(5).
  • Foco na validação dos anúncios de prefixos e não na proteção do transporte das conexões.
  • Toda e qualquer implementação do projeto deve ser “openSource”.

Finalmente, a figura abaixo, retirada de [6], indica que não se está pensando em substituir o IRR.

Figura 1: IP Address Allocation, Assignment, and IRR Conceptual Model(6).

Comentários finais

Os pequenos e médios provedores devem ficar atentos ao fato de que as propostas estão na mesa, com testes sendo feitos e disponíveis. A iniciativa é dos grandes provedores, principalmente os de backbone. Portanto, é preciso ficar atento e participar do debate, sob pena de haver consequências indesejáveis nas decisões que forem tomadas, à revelia e envolvendo interesses que podem afetar a futura infraestrutura da Internet. Mudanças que podem desagradar somente aos troianos. Os gregos querem, naturalmente, resolver o seu problema. E, rapidamente!

Eis algumas lembranças que devemos ter no processo do debate:

  • Evitar a descentralização de IRRs. Não se deve impor restrições na criação de uma base, mas não deveriam ser reconhecidas (digamos, homologadas), as bases criadas com características exclusivas.
  • Como as políticas de roteamento representam um componente importante para o funcionamento da Internet, não deveriam incorrer a custos. Em particular custos de certificação. Há um ponto de vista sensível sobre o debate: “uso do IRR custa dinheiro”. No LACNIC, aparente fato consumado está em [10]: “The objective is for all RIRs to be ready to start issuing
    certificates by no later than 01 January 2011.” . O que é bom, principalmente se os ASes puderem usar sem custo. Mas, os ASes, que possuem voz e voto no LACNIC devem se movimentar, principalmente, porque já existem custos sobre o ASN.
  • Evitar a centralização e controle excessivo sobre políticas de roteamento. O administrador de um AS está, em tese, preparado para gerenciar sua rede. Caso contrário devem ser estimulados a se preparar.
  • Evitar a classificação de um AS pelo sua dimensão. Para a Internet, quanto mais for descentralizada a competência e administração da rede, melhor. O modelo da governança atual da Internet deve ser mantido, a qualquer preço. Portanto, não se deve permitir que uma questão importante (como é o caso de políticas de roteamento), influencie negativamente, com reflexos em eventuais mudanças de gestão.
  • O Brasil, com um único IRR (aparentemente) é dono de uma rara oportunidade de desenvolver experiências de cooperação enfática, no momento em que a operação do Pegasus IRR ficará sob responsabilidade da Abranet.

Epílogo do segmento

Uma pergunta em palestra no GTER29(11), não foi bem respondida. A pergunta se referia a questões de segurança do IRR atual. Eis as respostas e comentários adicionais, fazendo uma referência à relação IRR x RPKI:

  1. A inclusão dos objetos mnter e person é, obrigatoriamente, feita pelo administrador da base IRR. Somente um descuido muito grande ou má fé poderiam permitir que tais objetos fossem manipulados por não administradores de ASes.
  2. A base principal do IRR, o RADB é sistematicamente atenta a abusos. Portanto, qualquer um pode enviar um e-mail para eles que serão imediatamente respondidos! É pura responsabilidade, por estar cuidando de uma comunidade sensível.
  3. O administrador de um AS pode manipular seus objetos sem nenhuma autenticação. Por pura opção pessoal. Nâo se tem notícias de que alguém faça isso. Até porque, dificilmente um administrador de IRR incluiria o objeto mntner, sem autenticação e, sem o objeto person.
  4. Há duas formas de autenticação: via senha criptografada e via PGP. Ambos são seguros dentro dos limites conhecidos. Na remota hipótese de sequestro de senhas ou chaves, a reação pode ser imediata. O telefone do INOC está ai com esse objetivo, por exemplo.
  5. O RPKI é semelhante ao DNSSEC. No final, seu objetivo é estabelecer a cadeia de confiança. A cadeia de confiança é mais problemática nos processos automáticos que transmitem informações em redes inseguras (aka Internet), no caso do IRR, unidirecional.
  6. Deveriam haver estudos na direção de identificar como será o comportamento dos administores de ASes e as propostas dos fabricantes que estão trabalhando em diversas direções. A tendência vem mostrando que técnicas associadas a SOA podem se tornar vitoriosas. Nesse caso, pensa-se em outras técnicas e tecnologias que não o RPKI.
  7. O RPKI sobre o IRR é um paradigma, no conceito de Kuhn(12). A origem da proposta de RPKI no IRR, provavelmente veio de uma recomendação no item 8 (último parágrafo), da RFC2725(13), como alternativa no fortalecimento da autenticação mas, não única alternativa. Duas constatações que induzem à ampliação do debate com a participação insistente, dos administradores de ASes.

Itens relacionados:

Referências do segmento

1. List of Routing Registries. IRR. Disponível em: http://www.irr.net/docs/list.html. Acessado em: 18/05/2010.

2. Bush, R. e McPherson, D., Using the RPKI to Construct Validated IRR Data, em mensagem de McPherson, D., Policy Proposal: Minimum Allocation in the Caribbean Region , Disponível em: http://lists.arin.net/pipermail/arin-ppml/2008-May/010788.html. Acessado em 18/05/2010.

3. Bush, R., Austein, R. Austein, Bellovin, S., The RPKI \& Origin Validation, RIPE-60, Praga 03/05/2010. Disponível em: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The\_RPKI\_Origin\_Validation.pdf. Acessado em: 18/05/2010.

4. Bush, R., Austein, R., “The RPKI/Router Protocol”, Randy Bush, Rob Austein, 20-Feb-10. Disponível em http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-05. Acessado em: 18/05/2010.

5. Implementação em OpenSSL, do RPKI.

6. Steenbergen, R.,Volk, R., Kumari, W., Blunk, L. e McPherson, D., ISP Route Filtering: Responsibilities & Technical Challenges. Disponível em: http://www.nanog.org/meetings/nanog43/presentations/DanMcP_Route_Filter_Panel_N43.pdf. Acessado em 18/05/2010.

7. Patara, R., RPKI: Actualización sobre estándares en desarrollo, LACSEC, LACNIC XIII, 19/05/2010. Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/LACSEC/03-rpki-5seguridad.pdf. Acessado em: 19/05/2010.

8. Carlos, M. C., Sutil, J. M., Moecke, C. T., Kohler, J. G., Introdução a Infraestrutura de Chaves Públicas e Aplicações (ICPEDU), ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/icpedu?categoria=3&download=44f683a84163b3523afe57c2e008bc8c. Acessado em: 20/05/2010.

9. Moreira, E. Q., Foscarini, E. D., Silva Junior, G. C. da, Alixandrina, L. A. O., Vieira Neto, L. P. V., Federação CAFe: Implantação do Provedor de Identidade, ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/cafe?categoria=3&download=03afdbd66e7929b125f8597834fa83a4. Acessado em: 20/05/2010.

10. Rada, G., Sistema de Certificación de Recursos vBetaRPKI-LACNIC, LACNIC XIII, 19/05/2010, Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/tutoriales/rpkivbeta.pdf. Acessado em: 20/05/2010.

11. Braga, J., Políticas de roteamentos: como resolver a impossibilidade de implementação na tecnologia “hop-by-hop” e o futuro. Disponível em: ftp://ftp.registro.br/pub/gter/gter29/01-PoliticasRoteamento.pdf. Acessado em: 25/05/2010.

12. Kuhn, Thomas S., A Estrutura das Revoluções Científicas, Editora Perspectiva, São Paulo, 1996.

12. RFC2725, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

Categorias:IRR, RPKI, TCP/IP

Curso IRR – Parte VII: Planos de roteamento

Introdução

Mais de 37.000 \textbf{ASes} formam a Internet, operados por diferentes dominios administrativos tais como provedores de acesso à Internet (ISPs), empresas, universidades, etc. [1]. Embora não tenhamos interesse direto, os aspectos econômicos que envolvem um \textbf{AS} representam componentes importantes, que afetam as atividades operacionais do \textbf{AS}. Recomeda-se a leitura de [3] onde respostas a perguntas dos tipos abaixo, poderão ser encontradas:

  • Porque os preços da banda estão se aproximando de R$0,00?
  • Será que as concessionárias fazem peering entre elas, estritamente fechado?
  • As concessionárias nos vendem trânsito, mas lucram muito com o tráfego local?

O artigo foi escrito em 2003, mas mantém sua atualidade. Também, recomenda-se inscrever no grupo da Abranet sobre Sistemas Autônomos [4].

Voltando aos interesses desse curso, as Partes VI e VII, tem o objetivo de relembrar conceitos importantes para a compreensão dos outos objetos usados pela base IRR. Nessa linha, vamos recordar algumas noções importantes sobre o BGP, no que diz respeito a planos de roteamento (alguns autores chamam, também, de políticas de roteamento). Nos textos que antecederam a este fizemos questão de deixar claro que no nosso contexto, políticas de roteamento estão em um patamar que muitas vezes não são representáveis diretamente nos planos de roteamento do BGP, quando interconectamos pelo menos dois \textbf{ASes} Quando trabalhamos com o IRR devemos nos abstrair de eventuais dificultades que possam surgir quando da implementação efetiva em um protocolo como o BGP (o exemplo dos \textbf{ASes} azuis e vermelhos, discutidos na Parte VI). Há um bom material em [1] onde, em particular, recomendo o [2], disponível na BC. Em [2], os autores argumentam que pouco se sabe sobre quais as políticas de roteamento são usadas pelos administradores para configurar suas redes, além de outras conclusões interessantes como, por exemplo, o fato deles acharem que as informações contidas no IRR são, incompletas ou não atualizadas de forma sistematica pelos seus responsáveis.

Fatos a serem relembrados

Vamos lembrar de alguns fatos conhecidos e, considerar a Figura 1, adaptada de [2]:

Figura 1. Uma representação formal de um grafo \textbf{AS}.
  • A Internet é formada por \textbf{ASes} interconectados (mais de 37.000, no mundo todo).
  • Cada \textbf{AS} é representado por um número único conhecido como \textbf{ASN}.
  • Um \textbf{AS} pode anunciar um ou mais prefixos de IP.
  • Os prefixos anunciados pelos \textbf{ASes} devem ter sido previamente alocados pelo Registro.br (no nosso caso).
  • Se um \textbf{AS} anuncia um prefixo não associado a ele pelo Registro.br, ocorre o que chamamos de “sequestro do prefixo” (“prefix hijacking”). Vale lembrar que quando falamos em um AS “emprestar” um bloco de IP para outro \textbf{AS} está implícito o fato de que este empréstimo deve ser reconhecido pelo Registro.br. Caso contrário, seria interpretado com sequestro.
  • “Interpretado como sequestro” porque há mecanismos na Internet (por exemplo, “route views”, “looking glass” e outros), que ficam monitorando a infraestrutura da Internet. Melhor dizer, ficam tentando monitorar. Mais de 37.000 \textbf{ASes} são complicados de monitorar. Por isso existem tantas ferramentas de montitoramente e, muitas vezes precisamos recorrer a várias delas para localizar um problema. O núcleo da Internet (formado pelos provedores de backbone nacional/internacional) está aparentemente bem monitorado, pois são pouco \textbf{ASes} que o formam. Há protocolos proprietários desconhecidos, entretanto, nas interconexões de peering entre concessionárias que abusam dos interesses econômicos envolvidos. Há alguns anos atrás, em uma conversa no Nic.br entendi que o peering construido entre as concessionárias brasileiras não era legal e estavam sendo monitorados. Mas, até hoje não ficou bem claro as implicações, exceto algumas conclusões de que talvez por isso, os preços da banda estejam reduzindo rapidamente. Algo como, as operadoras vendem trânsito (para a Internet), mas concentram uma boa parte do tráfego ao redor de um espaço de interconexão limitado. E boa parte delas se recusam aos acordos de peering com pequenos provedores de trânsito. Questões como essa implicam no esforço do Nic.br na direção dos PTTs.
  • Na Figura 1, \textbf{AS} _ \textbf{1 }, \textbf{AS} _ \textbf{2 }, …, \textbf{AS} _ \textbf{6 } são \textbf{ASes} ou simplesmente, nós do grafo (representação formal).
  • Roteamento dentro dos \textbf{ASes} se torna operacional através do iBGP. Informações de roteamento entre \textbf{AS} _ \textbf{1 } é ddeterminado pelo BGP, que inclui o iBGP e o eBGP. O eBGP troca informações de acesso entre \textbf{ASes} e o iBGP troca tais informações dentro de um \textbf{AS}.
  • O BGP usa mensagens de “update” para propagar alterações de roteamento (ou de rotas). O BGP usa um AS-path completo para chegar a um prefixo de destino, informado nas alterações de rotas.
  • Seleção e anúncio de rotas no BGP são determinadas pelos planos de roteamento das redes (ou políticas de roteamento, dentro do contexto da interconexão). Tais planos dependem das relações comerciais estabelecidas quando da conexão de um \textbf{AS} com outro \textbf{AS}.
  • As relações comerciais, são basicamente de dois tipos:
    • \textbf{Cliente}-----\textbf{Provedor}
    • \textbf{Peer}-----\textbf{Peer}
  • Há uma outra relação comercial denominada “siblings” (relações comerciais familiares …), onde dois \textbf{ASes} pertencem à mesma organização.
  • Na relação \textbf{Cliente}-----\textbf{Provedor}, o cliente paga ao provedor, pelo serviço de acesso ao resto da Internet.
  • Na relação \textbf{Peer}-----\textbf{Peer}, não há envolvimente financeiro (usualmente). Os dois \textbf{ASes} envolvidos no peering trocam tráfego entre seus clientes, somente. Tradicionalmente, um \textbf{AS} cliente não encaminha tráfego de peering entre seus provedores e nem tampouco deixa que um \textbf{AS} peer encaminhe, através dele, tráfego de peering entre dois outros pares. Na Figura 1, o \textbf{AS} _ \textbf{1 } é cliente do \textbf{AS} _ \textbf{2 } e do \textbf{AS} _ \textbf{3 }. O \textbf{AS} _ \textbf{1 } não gostaria de servir trânsito entre \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 } evitando assim, pagar pela troca de tráfego entre \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 }. Entrentanto, vale lembrar que essa troca de tráfego existe na Internet e é chamado de “vale livre”. Em 2000, a Profa. Linxin Gao, em [2], comenta esse tipo de tráfego além de outros tráfegos estabelecidos no esquema de relações familiares e, nas configurações mal feitas por eminentes técnicos que não sabem o que estão fazendo.
  • Quando \textbf{ASes} escolhem seu melhor caminho, usualmente fazem na seguinte ordem: rotas de clientes, rotas de peer e rotas de provedores de trânsito. Muitos caracterizam um “deny” para evitar o “vale livre” entre clientes (“no valley prefer customer”). Veremos um exemplo mais à frente pois é muito importante para a questão do sequestro de prefixos. Quem não está atento a esse “deny”? Aliás, será que é uma preocupação dos mais de 700 \textbf{ASes} brasileiros?

Seleção de rotas

  • Vejamos como a Figura 1 ilustra a seleção e propagação de rotas.
    • O \textbf{AS} _ \textbf{1 } anuncia um prefixo (por ex.; 189.89.0.0/20) para seus provedores de trânsito (ou provedores de “upstream”), \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 }. O \textbf{AS} _ \textbf{1 } é chamado de \textbf{AS} de origem para o prefixo 189.89.0.0/20 (origin \textbf{AS}).
    • Cada um dos provedores de trânsito do \textbf{AS} _ \textbf{1 }, prefixa o seu \textbf{ASN} ao AS-path e propaga para seus ASes vizinhos.
    • o \textbf{AS} _ \textbf{3 } recebe o caminho {1} do seu cliente \textbf{AS} _ \textbf{1 } e anuncia {3;1} para seus pares \textbf{AS} _ \textbf{4 } e \textbf{AS} _ \textbf{5 }.
    • O \textbf{AS} _ \textbf{5 } recebe rotas do \textbf{AS} _ \textbf{3 } e \textbf{AS} _ \textbf{2 } (peerings, talvez melhor, pares). O administrador do \textbf{AS} _ \textbf{5 } decide por anunciar {5;3;1} para seu cliente \textbf{AS} _ \textbf{6 }. Um \textbf{AS} escolhe quais as rotas serão importadas por seus vizinhos e quais aquelas a serem exportadas para seus vizinhos. Um \textbf{AS} que recebe inúmeras rotas escolhe a melhor rota, baseada no plano de preferência. A seleção do melhor caminho deve ser previamente estabelecida em parâmetros do BGP e, pode ser um pouco trabalhoso e sujeito a erros pelo ser humano. Aqui, vale lembrar, entram as ferramentas de apoio do IRR para traduzir as políticas de roteamento definidas em regras do BGP (para os diversos equipamentos).
  • Muito importante, como já disse, são os coletores de informações sobre os roteadores operacionais. Como falei, basicamente, as coletas são feitas sobre os roteadores dos provedores de trânsito (que segundo a literatura devem ser pouco mais 10% => ~3.700). São os tais membros do chamado Tier-1, na hierarquia dos ASes. Estes provedores (Tier-1) estão interconectados em uma malha fortemente estabelecida e compõem o núcleo (“core”) da infraestrutura de roteamento da Internet.

Itens relacionados:

Referências

[1] Gao, Lixin, Página pessoal.
[2] Wang, F., Gao, L., Inferring and Characterizing Internet Routing Policies, ACM SIGCOMM Internet Measurement Conference 2003.
[3] Huston, G., Interconnection, Peering, and Settlements.
[4] Lista GT-AS, Abranet. Grupo de debates sobre Sistemas Autônomous.

Categorias:IRR, Sem categoria

Curso IRR – Parte VI: Políticas de roteamento

Atualizado em 17/05/2010, com base em [6].

Introdução

Política de roteamento é a troca de informações de roteamento entre ASes.

Nas Referências, iremos observar que o RIPE é o principal RIR atento a políticas de roteamento. O grupo europeu é insistente e, provavelmente, quem cuida melhor de sua infraestrutura de Internet. Ele é, realmente, o melhor nesse aspecto. Há várias razões para isso mas, certamente a participação da comunidade (os ASes europeus!) é a principal. Assim, pode-se notar que há recursos adicionais no RIPE, para facilitar nossa vida como administrador de AS, que não estão disponíveis em outros RIRs ou NIRs. Face a isso, recomendo evitar ansiedades quando um recurso ou facilidade não estiver disponível no Brasil. Muitas facilidades do RIPE podem ser usados por nós, como por exemplo, o MyASN. Por outro lado, mais cedo ou mais tarde, as facilidades do RIPE chegarão por aqui.

NOTA:Sempre que buscar por uma RFC (principalmente, vindo de referências), primeiro vá ao índice do RFC-Editor. Nesse índice, garante-se a última versão da RFC e, também, se há atualizações. É um bom hábito!

Considerações importantes

Um AS é um grupo de redes IP com políticas de roteamento bem definidas por um ou mais operadores de rede. Dentro de um AS, os pacotes IPs são roteados através de protocolos IGPs (iBGP, OSPF, IS-IS, RIP, etc). Os ASes trocam informações de rotas com outros ASes, através dos protocolos EGPs (\text{BGP4}, por exemplo). As decisões de rotas entre ASes, são baseadas em políticas de rotas (definidas por regras, nos EGPs). Pequenos ASes necessitam de políticas simples. A complexidade das políticas é diretamente proporcional ao tamanho do AS. Mas ambos (o pequeno e o grande) possuem a mesma responsabilidade de garantir o funcionamento adequado de toda a Internet. Um pequeno AS pode gerar uma confusão imensa em um setor regional da Internet ou em toda ela. O BGP, possui recursos para implementar políticas de roteamento através de filtros (ou regras). MAS, não possuem facilidades para anunciar ou aceitar as políticas, propriamente ditas. O trabalho é manual, estabelecendo as regras (e filtros). Não é um trabalho trivial. É muito trabalhoso e carrega as dificuldades naturais inerentes à fragilidade do ser humano. Essa é a questão mais importante, pois um erro trivial numa regra, um pequeno esquecimento, gera um resultado grave na Internet como um todo. Assim, um AS com uma pequena rede ou um AS com uma rede complexa, não se diferenciam, nesse aspecto.

Aqui entra o IRR e ferramentas associadas, para garantir facilidades e funcionalidades efetivas na criação de regras para os protocolos, que eliminem as preocupações inseridas no contexto das dificuldades acima. Imagino que nesse ponto, já começa a ficar mais claro o objetivo do IRR.

A limitações das políticas de roteamento da tecnologia atual (“hop-by-hop”)

Suponha a topologia representada na figura abaixo:

Figura 1. Rede ideal entre dois ASes.

As seguintes observações se aplicam à figura acima:

  1. As nuvens com \textbf{ ? } representam topologias desconhecidas. Não sabemos nada sobre sua estrutura (redes, subredes, ASes, etc.). Sabemos que são topologias que fazem parte da Internet.
  2. \textbf{AS} _ \textbf{x } sabe como chegar na Rede 1.
  3. \textbf{AS} _ \textbf{y } sabe como chegar na Rede 2.
  4. Para haver tráfego da Rede 2 na direção da Rede 1 é necessário que tal tráfego flua entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }. Portanto, \textbf{AS} _ \textbf{x } TEM de anunciar a Rede 1 para \textbf{AS} _ \textbf{y }.
  5. Há uma disposição de \textbf{AS} _ \textbf{x } em aceitar o tráfego dirigido à Rede 1. Na figura, esse tráfego vem de \textbf{AS} _ \textbf{y }

Com base nas posições acima é possível definir a primeira política de roteamento do nosso modelo exibido na Figura 1: \textbf{AS} _ \textbf{x } anuncia a Rede 1 para \textbf{AS} _ \textbf{y }.

Por outro lado, \textbf{AS} _ \textbf{y } deve aceitar essa informação de roteamento e usá-la. Também, \textbf{AS} _ \textbf{y } tem o privilégio de reconhecer ou de ignorar, a prédisposição de \textbf{AS} _ \textbf{x } em aceitar tráfego para a Rede 1. Com isso, \textbf{AS} _ \textbf{y } pode, eventualmente, decidir enviar tráfego para a Rede 1, através de uma outra rota mais apropriada. Do que foi dito nesse parágrafo pode-se inferir a segunda política de roteamento: \textbf{AS} _ \textbf{y } aceita o anúncio feito pelo \textbf{AS} _ \textbf{x }.

O inverso também é semelhante, produzindo as, terceira e quarta políticas de roteamente, respectivamente: \textbf{AS} _ \textbf{y } anuncia a Rede 2 para \textbf{AS} _ \textbf{x } e, \textbf{AS} _ \textbf{x } aceita o anúncio feito pelo \textbf{AS} _ \textbf{y }

É incomum que as políticas de anúncio e aceitação do \textbf{AS} _ \textbf{x } e do \textbf{AS} _ \textbf{y } não sejam idênticas e, portanto, configuradas separadamente para cada rede. Na prática, são feitas por grupos de redes (através dos respectivos administradores), que formam um ou mais ASes (retirando as abstrações das nuvens \textbf{ ? } tornaria compreensível a afirmação). E, também, não é comum, que existam somente políticas unilaterais. Portanto, é necessário a integração dos ASes, em sua grande maioria, como sabemos, desconhecidos entre si.

Mas, o parágrafo anterior é verdade, para ASes que estejam diretamente conectados entre si e, também, diretamente conectados com suas respectivas redes. A figura 2, abaixo, ilustra tais conexões adjacentes.

Figura 2. Interconexões adjacentes

Nesse momento é importante lembrar como pacotes são encaminhados pelos roteadores da Internet. Eles passam, no caminho entre a origem e o destino, no esquema “hop-by-hop” (ponto-por-ponto ou, roteador-por-roteador). Os roteadores que fazem o trânsito (e que estão no caminho origem -> destino), avaliam cada cabeçalho do pacote e presquisam uma tabela chamada FIB (Forward Information Base). Esta tabela é construida por cada nó (hop ou roteador) do caminho, cada um de maneira própria e, eventualmente, diferente do outro (adjacente ou não). Ao consultar a FIB, o nó toma a decisão e define o próximo salto a ser dado em direção ao destino. A figura 3 abaixo ilustra como é construida a FIB em cada roteador da Internet.

Figura 4. Como a base de dados FIB é construída em cada roteador.

As rotas estáticas alimentam a base OSPF (quando houver) e a RIB (Route Information Base). A tabela de rotas do BGP, também alimenta a RIB. A RIB, portanto, tem um conjunto de informações sobre rotas, originadas de várias fontes. Em particular, tem uma relação de todos os próximos nós (ou hops, ou roteadores) que podem levar ao destino de acordo com a proposta especificada pelo nó de origem. Mas, somente a informação do melhor próximo nó (“next-hop”) será colocado na FIB. Baseada na FIB, o roteador toma a decisão, que pode ser diferente do caminho traçado inicialmente pelo roteador de origem do pacote.

Por tal razão, a tecnologia atual, não consegue tratar políticas em termos de ANÚNCIOS de redes e de ACEITAÇÃO de redes em toda sua extensão, já que cada roteador (o próximo nó – “next-hop”) é quem dá a palavra final e não há nenhuma comunicação dessa decisão para o resto da rede. Olhando a figura, não se pode intervir, nas decisões tomadas pelos roteadores que estão entre \textbf{AS} _ \textbf{a } e \textbf{AS} _ \textbf{z }, mostrados na figura 5, abaixo, agora mais completa.

Figura 5. Ilustração completa do problema dos enlaces azuis e vermelhos

Reflexões adicionais

Tem-se, até esse momento, a seguinte questão em pauta: políticas baseadas em ANÚNCIO e ACEITAÇÃO, não são implementáveis na tecnologia de roteamento disponíveis atualmente.

Com essa abordagem queremos fixar o fato de que, as políticas de roteamento (incluindo políticas de acesso) podem ser implementadas nos IRR e as ferramentas associadas irão auxiliar a transformar tais políticas nas regras de implementação disponíveis na tecnologia atual do ”hop-by-hop” que é um impedimento tecnológico.

A interconexão ideal, também, exibe um fato importante para efeito do entendimento de política de roteamento: um lado anuncia e o outro lado aceita. Anúncio e aceitação estão em lados contrários. Essa é a caracterização ideal de uma conexão efetiva.Mas, na atual tecnologia de roteamente, não é possível estabelecer políticas de roteamente na base de anúncio e aceitação. A tecnologia atual é o hop-by-hop. Um pacote segue um caminho da origem até o destino, passando em roteadores, no caminho, que tomam suas próprias decisões sem, absolutamente, nenhuma cooperação entre si.

Duas questões como exercício: A política de roteamento, sobre conexões azul e vermelho, para tráfego vindo dos ASes vermelhos e azuis, poderia ou não ser implementada? O que acontece com o tráfego, quando ele passa no \textbf{AS} _ \textbf{a }?

Itens relacionados:

Referências

[1] RFC1786, Representation of IP Routing Policies in a Routing Registry (ripe-81++), T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu [ March 1995 ] (TXT = 133643) (Status: INFORMATIONAL) (Stream: Legacy).
[2] RFC2622, Routing Policy Specification Language (RPSL), C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes RFC2280) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps)
[3] RFC2725, Routing Policy System Security, C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps)
[4] RFC4012, Routing Policy Specification Language next generation (RPSLng), L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates RFC2725, RFC2622) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP)
[5] JPNIC: IRR (JPIRR) Operation Policies and User Guideline
[6] Braga, J., Politicas de roteamento: Como resolver a impossibilidade de implementação na tecnologia “hop-by-hop” e o futuro. GTER 29. Disponível em:
ftp://ftp.registro.br/pub/gter/gter29/01-PoliticasRoteamento.pdf”. Acessado em 17/05/2010.

Categorias:IRR, TCP/IP

LaTex: Experiências pessoais

Atualização em 22/05/2010

Introdução

Na medida do possível serão expostas as experiências (boas e más) com o \LaTeXe, em particular, as referências mais úteis. Usuário do \LaTeX há muitos anos atrás, nos primórdios do \LaTeX e hoje, às voltas novamente com ele. É um editor imprescindível para quem precisa ou deseja escrever textos de qualidade, em particular, científicos.

No WordPress estamos interessados no básico do \LaTeX. No Windows (XP e 7). No Windows, em recente experiência, o MiKTex (2.8) e o editor TeXworks, que vem junto com ele. Outros editores foram testados até que o problema da acentuação no TeXworks + Windows foi resolvido. Assim, a escolha recaiu sobre os dois.

O texto será suscinto e não muito cuidadoso, em benefício do lado prático. O princípio básico é: “para um bom entendedor, meia palavra basta”. Nada mais do que puras referências.

É bom, que o interessado saiba que sempre haverá mudanças e, portanto, recomenda-se o uso do “Notifique-me de novos artigos por e-mail” no final da apresentação, já que não há compromissos sobre o momento das alterações.

Finalmente, a preocupação fundamental são os padrões da ABNT. Mas haverá abordagens, também, fora desse contexto. Não se pode esquecer de que, quando usamos o \LaTeX, o Google é nosso amigo …

\textbf{\LaTeX} no MiKTex

Dicas de instalação do MiKTeX no Windows.

  1. Faça o download aqui e instale-o normalmente.

Instalando o padrão ABNT

  1. Faça o download da versão estável do abntex aqui.
  2. Descompacte-o e copie o diretório abntex no diretório do disco:\Arquivo de Programas\MiKTex 2.8\tex\latex. (Obs.: Em itálico, possíveis divergências).
  3. Vá em Todos os programas procure pelo MiKTex e execute o Settings (Admin), conforme a figura abaixo:

    Figura 1. MiKTex Settings

    O resultado é a janela da figura abaixo. Clique em Refresh FNDB e quando terminar a execução, clique em Update Formats. Nesse ponto, o padrão abntex está pronto para ser usado.

    Figura 2. Finalizando a instalação do padrão abntex.

Estrutura do documento

A principal preocupação ao desenvover textos em \LaTeX é estabelecer uma organização do documento ou, manter uma estrutura lógica do documento. Uma divisão razoável, em mais alto nível é:

  • Preâmbulo do \textbf{\LaTeX}: Sempre começa pelo comando \documentclass[opções]{…}. É a parte inicial que orienta o \LaTeX sobre as informações que terão efeito sobre TODO o documento.
  • Preâmbulo do documento: São as informações que começam logo após o preâmbulo do \textbf{\LaTeX} até, imediatamente antes do comando \begin{document}. Contem informações pertinentes ao documento propriamente dito (títúlo, autor, instituição, cabeçalho, rodapé, etc.).
  • Corpo do documento: é tudo aquilo que começa pelo \begin{document} e termina com \end{document}. O corpo do documento deve ser, também, estruturado, cuja proposta é:
    • Comandos de aparência
    • Documento propriamente dito e respectivos comandos \LaTeX, quando necessários
    • Bibliografia: começa com \begin{thebibliography}{} e termina com \end{thebibliography}{}

Resumindo, a estrutura do documento será assim representada, usando o %, que é o comando comentário no \LaTeX:

% Preâmbulo do \LaTeX
% \documentclass[opções]{...}
% ...
% Preâmbulo do documento
% ...
% Corpo do documento
% \begin{document}
   % Comandos de aparência
   % Documento propriamente dito e respectivos comandos \LaTeX, quando necessários
   % Bibliografia
%    \begin{thebibliography}{}
%       \bibitem{...}
%          ...
%       \bibitem{...}
%          ...
%       ...
%    \end{thebibliography}{}
% \end{document}

Quadro 1. Organização do documento completo.

Refinamento da estrutura do documento para usar o abntex

Usando o TeXWorks

  • Defina um diretório e subdiretórios para os trabalhos com o \LaTeX.
  • Quando você executa o TeXWorks, aparece a figura 3 na metade esquerda:
  • Figura 3. Tela inicial do TeXWorks.

  • Vamos copiar o esboço do Quadro 1, para dentro do TeXWorks e salvar (o nome será refinamento-1). Como na figura 4, abaixo.
  • Figura 4. Estrutura do documento no TeXWorks.

O preâmbulo do \LaTeX, no padrão ABNT

  • Eis um preâmbulo do \LaTeX, funcional, no Quadro 2, com alguns comentários.

    \documentclass[pagestart=firstchapter,%
    	%twoside,		% Se for imprimir frente-e-verso
    	%openright,		% Todo capítulo começa na página da direita
    	sumario=completo,	%
    	tocpage=plain,		%
    	floatnumber=continuous,	% Numere as figuras sequencialmente. Se o comando \chapter
    				% for usado, então o formato será: capitulo.número
    	espaco=simples,		% Pode serduplo
    	font=times,		% Usar fontes do padrão LaTeX, e não a Times New Roman = times/plain
    	indent=all,		% Indentar as primeiras linhas de todos os parágrafos
    	header=normal,		% Cabeçalho apenas com # da página (plain). Pode ser "normal" para
    				% incluir o nome da sessão, ou "ruled" para ter normal mais
    				% uma linha separando cabeçalho do texto
    	a4paper,		% Papel A4
    	12pt]{abnt}		% Fonte com 12 pontos. 
    
    \usepackage[num, % Citações numéricas e, alfabéticas = alfa
    	overcite, 		% citação superior. Retire e fica normal.
    	abnt-full-initials=yes	% Nome de autor completo
    	abnt-emphasize=bf,	% Como vai ser o grifo nas referênncias? Negrito = bf ou itálico = em
    	abnt-and-type=e,	% Usa "e" como em "Fonseca e Paiva"
    	abnt-etal-cite=3,	% Coloca et al a partir do quinto autor
    	abnt-etal-list=3,	% Na lista de referencias, nao colocar et al, e sim
    				% todos os autores (unica coisa fora do padrão, Se quiser
    				% ficar 100% aderente ao padrão, coloque "3" nesse parâmetro
    	abnt-url-package=url,	% Faz os links dos campos url e doi funcionarem
    	recuo=0.7cm,		% Rrecuo nas entradas
    	bibjustif,		% Justifica o texto da referência
    	abnt-verbatim-entry=no	% Se for yes, permite ver entradas da bibtex no final. 
    	]{abntcite}
    \usepackage[brazil]{babel}  % Português
    \usepackage{unicode} % Acentos Português, compatibilizando o Windows com o texto
    \usepackage[latin1]{inputenc} % Esse tem de ser combinado com o anterior
    \usepackage[T1]{fontenc}
    \usepackage{color}
    \usepackage{float}
    \usepackage{graphicx}
    \usepackage{url}
    \usepackage{listings}
    

    Quadro 2. Preâmbulo do \textbf{\LaTeX}
    (Adaptado do artigo do projeto aplicado 1/2009 – UNATEC – Acesso remoto nos sistemas operacionais)

  • Vamos inserir esse preâmbulo no arquivo Refinamento-1 e liberar o \begin{document} e o \end{document} para facilitar didaticamente. Salve com o nome Refinamento-2. Em seguida, execute (círculo verde claro com set vermelho à esquerda no submenu). Eis a figura 5, com o resultado:

    Figura 5. Primeira compilação do documento.
  • Após a execução, a janela maior foi dividida em duas. A parte de baixo, com letras verdes são as mensagens geradas após a compilação.
  • Raramente iremos alterar esse padrão. Podemos, então criar um arquivo somente com o preâmbulo. Abra um novo documento e copie somente o preâmbulo para a área do TeXWorks e salve-o, no mesmo diretório que está sendo usado, como PreambuloABNT (o TeXWorks irá colocar a extenção .tex).
  • Já que o preâmbulo foi salvo, vamos aplicar o comanto \include{…}. Eis o resultado no Quadro 5:

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    
    % Preâmbulo do documento
    % ...
    
    % Corpo do documento
    \begin{document}
       % Comandos de aparência
       % Documento propriamente dito e respectivos comandos \LaTeX, quando necessários
       % Bibliografia
    %    \begin{thebibliography}{}
    %       \bibitem{...}
    %          ...
    %       \bibitem{...}
    %          ...
    %       ...
    %    \end{thebibliography}{}
    \end{document}
    

    Quadro 2. Preâmbulo do \textbf{\LaTeX}
    (Adaptado do artigo do projeto aplicado 1/2009 – UNATEC – Acesso remoto nos sistemas operacionais)

Preâmbulo do documento

Eis no Quatro 3, com a escolha feita para o preâmbulo do documento:

% Preâmbulo do LaTex - Padrão abnt
\include{PreambuloABNT}

%  Preâmbulo do documento
%\citebrackets[] % Usar colchetes ao invés de ()
\autor{Julião Braga}
\titulo{LaTex: Experiências pessoais }
% \comentario{...}
\instituicao{Universidade Anhanguera }
\local{Sao Jose dos Campos, SP}
\data{2010}
% \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex

% Corpo do documento
\begin{document}
   % Comandos de aparência
   % Documento propriamente dito e respectivos comandos \LaTeX, quando necessários
   % Bibliografia
%    \begin{thebibliography}{}
%       \bibitem{...}
%          ...
%       \bibitem{...}
%          ...
%       ...
%    \end{thebibliography}{}
\end{document}

Quadro 2. Preâmbulo do \textbf{\LaTeX}
(Adaptado do artigo do projeto aplicado 1/2009 – UNATEC – Acesso remoto nos sistemas operacionais)

Avançando sobre o corpo do documento

  • Ao colocar o comando \folhaderosto, já teremos algo para sair. Veja o Quadro 3.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    
    % Corpo do documento
    \begin{document}
    \folhaderosto   % Usa informações do preâmbulo do documento!
       % Comandos de aparência
       % Documento propriamente dito e respectivos comandos \LaTeX, quando necessários
       % Bibliografia
    %    \begin{thebibliography}{}
    %       \bibitem{...}
    %          ...
    %       \bibitem{...}
    %          ...
    %       ...
    %    \end{thebibliography}{}
    \end{document}
    

    Quadro 3. O efeito do comando \folhaderosto no corpo do documento.

  • Levando o conteúdo do Quadro 3 para o TexWorks, após a execução, teremos uma nova janela no lado direito do monitor, com o resultado da execução. Nesse ponto, o arquivo foi gravado (antes da compilação) e um .pdf foi criado como resultado da execução. Esse .pdf está idêntico ao que vemos à direita, da figura 6, abaixo.

    Figura 5. Incluindo o comando \folhaderosto e executando..
  • Esse texto tem 4 capítulos mais a bibliografia (que é um capítulo). Então, que tal começarmos pelos capítulos, exibido no no Quadro 4, compilar, executá-lo e, olhar o resultado.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    % Corpo do documento
    \begin{document}
    \folhaderosto
    \chapter{Introdução}
    \chapter{No WordPress}
    \chapter{\textbf{\LaTeX} no MiKTex}
    \chapter{Abordagens futuras}
    %\begin{thebibliography}{}
    %	\bibitem{...}
    %		...
    %    \bibitem{...}
    %       ...
    %    ...
    %\end{thebibliography}{}
    \end{document}
    

    Quadro 4. O efeito do comando \folhaderosto no corpo do documento.

  • Texto bem planejado (ou já pronto), tem suas vantagens. Já sabemos as seções. O Quadro 5 exibe as modificações. Resta testar.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    % Corpo do documento
    \begin{document}
    \folhaderosto
    \chapter{Introdução}
    \chapter{No WordPress}
    \chapter{\textbf{\LaTeX} no MiKTex}
    	\section{Dicas de instalação do MiKTeX no Windows.}
    		\subsection{Instalando o padrão ABNT}
    	\section{Estrutura do documento}
    	\section{Refinamento da estrutura do documento para usar o abntex}
    		\subsection{Usando o TeXWorks}
    		\subsection{O preâmbulo do \LaTeX, no padrão ABNT}
    		\subsection{Preâmbulo do documento}
    		\subsection{Avançando sobre o corpo do documento}
    \chapter{Abordagens futuras}
    %\begin{thebibliography}{}
    %	\bibitem{...}
    %		...
    %    \bibitem{...}
    %       ...
    %    ...
    %\end{thebibliography}{}
    \end{document}
    

    Quadro 5. Capítulos, seções e subcessões.

  • O incômodo é a falta do índice e a numeração da página. Onde queremos o índice? Que tal após a folha de rosto? Então basta inserir o comando \tableofcontents no lugar escolhido, como exibido no Quadro 6, abaixo.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    % Corpo do documento
    \begin{document}
    \folhaderosto
    \tableofcontents
    \chapter{Introdução}
    \chapter{No WordPress}
    \chapter{\textbf{\LaTeX} no MiKTex}
    	\section{Dicas de instalação do MiKTeX no Windows.}
    		\subsection{Instalando o padrão ABNT}
    	\section{Estrutura do documento}
    	\section{Refinamento da estrutura do documento para usar o abntex}
    		\subsection{Usando o TeXWorks}
    		\subsection{O preâmbulo do \LaTeX, no padrão ABNT}
    		\subsection{Preâmbulo do documento}
    		\subsection{Avançando sobre o corpo do documento}
    \chapter{Abordagens futuras}
    %\begin{thebibliography}{}
    %	\bibitem{...}
    %		...
    %    \bibitem{...}
    %       ...
    %    ...
    %\end{thebibliography}{}
    \end{document}
    

    Quadro 6. Incluindo o sumário e numeração das páginas.

    • Incluindo o texto

      Um CTRL C e CTR V, adiciona o texto no corpo do documento, abaixo do comando \chapter{Introdução}. No Quadro 7. Um teste é sempre recomendável, no sentido de perceber as mudanças e, fixar as idéias.

      % Preâmbulo do LaTex - Padrão abnt
      \include{PreambuloABNT}
      %  Preâmbulo do documento
      %\citebrackets[] % Usar colchetes ao invés de ()
      \autor{Julião Braga}
      \titulo{LaTex: Experiências pessoais }
      % \comentario{...}
      \instituicao{Universidade Anhanguera }
      \local{Sao Jose dos Campos, SP}
      \data{2010}
      % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
      % Corpo do documento
      \begin{document}
      \folhaderosto
      \tableofcontents
      \chapter{Introdução}
      Na medida do possível serão expostas as experiências (boas e más) com o \LaTeXe, em particular, as 
      referências mais úteis. Usuário do \LaTeX há muitos anos atrás, nos primórdios do \LaTeX e hoje, às voltas 
      novamente com ele. É um editor imprescindível para quem precisa ou deseja escrever textos de qualidade, 
      em particular, científicos.
      
      No WordPresse estamos interessados no básico do \LaTeX. No Windows (XP e 7). No Windows, em recente 
      experiência, o MiKTex (2.8) e o editor TeXworks, que vem junto com ele. Outros editores foram testados 
      até que o problema da acentuação no TeXworks + Windows foi resolvido. Assim, a escolha recaiu sobre 
      os dois.
      
      O texto será suscinto e não muito cuidadoso, em benefício do lado prático. O princípio básico é: “para um 
      bom entendedor, meia palavra basta”. Nada mais do que puras referências.
      
      O texto está dividido em quatro capítulos: “No WordPress”, “\LaTeX no TeXworks”, “Abordagens futuras” e 
      “Referências”, com respectivas seções sempre que necessário. É bom, que o interessado saiba que sempre 
      haverá mudanças nesse texto e, portanto, recomenda-se o uso do “Notifique-me de novos artigos por e-mail” 
      no final da apresentação, já que não há compromissos sobre o momento das alterações.
      
      Finalmente, a preocupação fundamental são os padrões da ABNT. Mas haverá abordagens, também, fora 
      desse contexto. Não se pode esquecer de que, quando usamos o \LaTeX, o Google é nosso amigo …
      \chapter{No WordPress}
      \chapter{\textbf{\LaTeX} no MiKTex}
      	\section{Dicas de instalação do MiKTeX no Windows.}
      		\subsection{Instalando o padrão ABNT}
      	\section{Estrutura do documento}
      	\section{Refinamento da estrutura do documento para usar o abntex}
      		\subsection{Usando o TeXWorks}
      		\subsection{O preâmbulo do \LaTeX, no padrão ABNT}
      		\subsection{Preâmbulo do documento}
      		\subsection{Avançando sobre o corpo do documento}
      \chapter{Abordagens futuras}
      %\begin{thebibliography}{}
      %	\bibitem{...}
      %		...
      %    \bibitem{...}
      %       ...
      %    ...
      %\end{thebibliography}{}
      \end{document}
      

      Quadro 7. Incluindo texto. Uma linha em branco indica outro parágrafo.

    Incluindo a bibliografia

    Esse é uma passo desejável, nesse momento, para que as referências possam ser usadas.
    O Quadro 8, mostra a inclusão dos itens de referência. Cada capítulo está sendo colocado em um arquivo e o comando \include usado estensivamente, daqui para frente. Que tal responder a pergunta: é mandatório colocar o comando \chapter no arquivo? Responda experimentando não colocar.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    % \usepackage[pdftex]{hyperref}  % Pacote que permite validar URLs no .pdf. Já existe no abntex. 
                                                    % Exibido aqui só como lembrança.
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    % Corpo do documento
    \begin{document}
    \folhaderosto
    \tableofcontents
    % \chapter{Introdução}
       \include{capitulo01}
    % \chapter{No WordPress}
       \include{capitulo02}   
    \chapter{\textbf{\LaTeX} no MiKTex}
    	\section{Dicas de instalação do MiKTeX no Windows.}
    		\subsection{Instalando o padrão ABNT}
    	\section{Estrutura do documento}
    	\section{Refinamento da estrutura do documento para usar o abntex}
    		\subsection{Usando o TeXWorks}
    		\subsection{O preâmbulo do \LaTeX, no padrão ABNT}
    		\subsection{Preâmbulo do documento}
    		\subsection{Avançando sobre o corpo do documento}
    \chapter{Abordagens futuras}
    \begin{thebibliography}{}
       \bibitem{Wikibooks}
       Wikibooks, \LaTeX. Disponível em http://en.wikibooks.org/wiki/LaTeX. Acessado em: 01/05/2010. É 
    uma excelente referência geral.
       \bibitem{Wikibooks}
       \LaTeX O que vou aprendendo. Disponível em: http://aprendolatex.wordpress.com/. Acessado em: 
    01/05/2010. Ótimo material. Não consegui identificar o autor.
       \bibitem{Campani}
       Campani, Carlos A. P., Tutorial de Beamer: apresentações \LaTeX, Abril 2006. Disponível em: 
    http://ctan.org/tex-archive/info/portuguese/beamer/tutorialbeamer.pdf. Acessado em: 01/05/2010. 
    Beamer é uma classe \LaTeX para produzir apresentações.
       \bibitem{Oetiker}
       Oetiker, T., Partl, H., Hyna, I. e Schlegl, E., Uma não tão pequena introdução ao \LaTeX ou \LaTeX 
    em 137 minutos. Tradução portuguesa por Alberto Simões, Versão 4.20.1, 18 de Setembro de 2007. 
    Disponível em: http://www.ctan.org/tex-archive/info/lshort/portuguese/ptlshort.pdf. 
    Acessado em: 01/05/2010. Manual clássico, em português.
       \bibitem{Roberts}
       Roberts, Andrews, Getting to grips with \LaTeX. Disponível em: http://www.andy-roberts.net/misc/latex/. 
    Acessado em: 01/05/2010. Um ótimo começo.
       \bibitem{CTAN}
       CTAN: Comprehensive \TeX Archive Network. Disponível em: http://www.ctan.org/. Acessado em: 
    01/05/2010. Referência autorizada de material sobre o \TeX.
       \bibitem{Santos}
       Santos, Reginaldo J., Introdução ao \TeX, Departamento de Matemática-ICEx, UFMG. Abril de 2002. 
    Atualizado em 04/03/2010. disponível em: http://www.mat.ufmg.br/~regi/topicos/intlat.pdf. 
    Acessado em 02/05/2010. Material, que parece estar sempre atualizado pelo autor.
    \end{thebibliography}{}
    \end{document}
    

    Quadro 8. Bibliografia

    Nada nos impede deixar nosso arquivo principal mais agradável. Vamos então, colocar a bibliografia em um arquivo, chamado bibliografia e, novamente fazer uso do comando \include, novamente.

    % Preâmbulo do LaTex - Padrão abnt
    \include{PreambuloABNT}
    
    %  Preâmbulo do documento
    %\citebrackets[] % Usar colchetes ao invés de ()
    \autor{Julião Braga}
    \titulo{LaTex: Experiências pessoais }
    % \comentario{...}
    \instituicao{Universidade Anhanguera }
    \local{Sao Jose dos Campos, SP}
    \data{2010}
    % \citeoption{abnt-full-initials=yes}  % É possível alterar o padrão no Preâmbulo do LaTex
    % Corpo do documento
    \begin{document}
    \folhaderosto
    \tableofcontents
    
    % \chapter{\textbf{\LaTeX} no MiKTex}
    	\include{capitulo01}
    	
    % \chapter{No WordPress}
    	\include{capitulo02}
    
    \chapter{\textbf{\LaTeX} no MiKTex}
    	\section{Dicas de instalação do MiKTeX no Windows.}
    		\subsection{Instalando o padrão ABNT}
    	\section{Estrutura do documento}
    	\section{Refinamento da estrutura do documento para usar o abntex}
    		\subsection{Usando o TeXWorks}
    		\subsection{O preâmbulo do \LaTeX, no padrão ABNT}
    		\subsection{Preâmbulo do documento}
    		\subsection{Avançando sobre o corpo do documento}
    
    \chapter{Abordagens futuras}
    
    % \begin{thebibliography}{}
    	\include{bibliografia}
    % \end{thebibliography}{}
    \end{document}
    

    Quadro 9. Texto com includes

     

    Referências

    [1] Wikibooks, \LaTeX. Disponível em http://en.wikibooks.org/wiki/LaTeX. Acessado em: 01/05/2010. É uma excelente referência geral.

    [2] \LaTeX O que vou aprendendo. Disponível em: http://aprendolatex.wordpress.com/. Acessado em: 01/05/2010. Ótimo material. Não consegui identificar o autor.

    [3] Campani, Carlos A. P., Tutorial de Beamer: apresentações \LaTeX, Abril 2006. Disponível em: http://ctan.org/tex-archive/info/portuguese/beamer/tutorialbeamer.pdf. Acessado em: 01/05/2010. Beamer é uma classe \LaTeX para produzir apresentações.

    [4] Oetiker, T., Partl, H., Hyna, I. e Schlegl, E., Uma não tão pequena introdução ao \LaTeX ou \LaTeX em 137 minutos. Tradução portuguesa por Alberto Simões, Versão 4.20.1, 18 de Setembro de 2007. Disponível em: http://www.ctan.org/tex-archive/info/lshort/portuguese/ptlshort.pdf. Acessado em: 01/05/2010. Manual clássico, em português.

    [5] Roberts, Andrews, Getting to grips with \LaTeX. Disponível em: http://www.andy-roberts.net/misc/latex/. Acessado em: 01/05/2010. Um ótimo começo.

    [6] CTAN: Comprehensive \TeX Archive Network. Disponível em: http://www.ctan.org/. Acessado em: 01/05/2010. Referência autorizada de material sobre o \TeX.

    [7] Santos, Reginaldo J., Introdução ao \TeX, Departamento de Matemática-ICEx, UFMG. Abril de 2002. Atualizado em 04/03/2010. disponível em: http://www.mat.ufmg.br/~regi/topicos/intlat.pdf. Acessado em 02/05/2010.

    [8] Mori, L. F., Tables in \LaTex2e: Packages and Methods, 2007 (Revisão). Disponível em http://www.vision.ime.usp.br/~jmena/misc/latex/tables_with_latex.pdf. Acessado em 03/03/2010.

    [9] Love, Tim, Advanced LATEX, Agosto 2006. University of Cambridge. Disponível em:

Curso IRR – Parte V: Objetos routeroute6

Introdução

Há uma linguagem por trás dos objetos que formam o repositório IRR. Trata-se da RPSL (Routing Policy Specification Language). Definida na RFC2622 a atualizada pela RFC4012, adicionando IPv6 e famílias de endereços multicast. Através da RPSL, o administrador estará habilitado a especificar as políticas de roteamento em detalhes suficientes para que, posteriormente possa representá-las nas configurações de baixo nível dos roteadores. Portanto, os construtores do repositório IRR são os objetos, definidos pela RPLS. Alguns objetos inserem informações sobre políticas de roteamento e outros inserem informações administrativas. Já vimos dois objetos, o mntner e o person, que caracterizam informações administrativas: um indica o “dono” da cadeia de informações que será construida e, também, qual o mecanismo de autenticação, enquanto o outro, indica “quem” é(são) o(s) ser(es) humano(s) que está(ão) por trás do “dono”.

O objeto route e route6

O objeto route especifica uma rota que pode ser anunciada pelo AS e somente por ele. O objeto descreve um endereço IPv4, sua máscara de rede e associa o AS a partir do qual a rota pode se originar (atributo origin). Já o objeto route6 faz a mesma coisa para o IPv6!

Abaixo o padrão do objeto route que é idêntico para o objeto route6:

route:          [mandatory]  [single]     [primary/look-up key]
descr:          [mandatory]  [multiple]   [ ]
origin:         [mandatory]  [single]     [primary/inverse key]
holes:          [optional]   [multiple]   [ ]
member-of:      [optional]   [multiple]   [inverse key]
inject:         [optional]   [multiple]   [ ]
aggr-mtd:       [optional]   [single]     [ ]
aggr-bndry:     [optional]   [single]     [ ]
export-comps:   [optional]   [single]     [ ]
remarks:        [optional]   [multiple]   [ ]
cross-mnt:      [optional]   [multiple]   [inverse key]
cross-nfy:      [optional]   [multiple]   [inverse key]
notify:         [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Eis o exemplo do bloco /20 da TeleSA:

route:      189.89.0.0/20
descr:      TeleSA cidr block
origin:     AS28182
remarks:
remarks:    TeleSA IPv4 bloks
remarks:    ===========================================================
remarks:    http://www.TeleSA.com.br
remarks:    ===========================================================
remarks:    Security Note
remarks:    Any Notification about AS28182 security please e-mail to:
remarks:    ABUSE@TeleSA.com.br
remarks:    ===========================================================
remarks:    ===========================================================
remarks:
mnt-by:     MAINT-AS28182
changed:    jb@telesa.net.br 20090607
changed:    jb@PEGASUS.com.br 20090607
remarks:    Sun Jun  7 17:02:52 BRT 2009
changed:    jb@PEGASUS.com.br 20090905
remarks:    Sat Sep  5 18:23:52 BRT 2009
source:     PEGASUS

e o route6:

route6:     2001:1294::/32
descr:      TeleSA IPv6 blocks
origin:     AS28182
remarks:
remarks:    ===========================================================
remarks:    http://www.TeleSA.com.br
remarks:    ===========================================================
remarks:    Security Note
remarks:    Any Notification about AS28182 security please e-mail to:
remarks:    ABUSE@TeleSA.com.br
remarks:    ===========================================================
remarks:    ===========================================================
remarks:
mnt-by:     MAINT-AS28182
changed:    jb@PEGASUS.com.br 20090902
remarks:    Wed Sep  2 10:41:38 BRT 2009
changed:    jb@PEGASUS.com.br 20090905
remarks:    Sat Sep  5 18:23:52 BRT 2009
changed:    jb@PEGASUS.com.br 20091217
remarks:    Thu Dec 17 14:15:45 BRST 2009
source:     PEGASUS

Eis algumas observações interessantes, que se aplicam aos dois objetos route e route6:

  • O objeto route é extremamente simples em sua indicação. Ele não expressa uma política genérica. Ele é bem específico: define quais anúncios irão acontecer a partir de um AS. É preciso ficar bem claro, uma vez que existem outros objetos que complementam as informações de roteamento.
  • Fixando a idéia, o objeto route somente exibe os blocos que podem originar do AS definido no atributo origin.
  • É necessário atenção à agregação. Se seu AS tem vários pontos de interconexão na Internet, remotamente localizados, não interessa identificar tais pontos através do objeto route e, portanto agregar é a melhor recomendação.
  • Não há atributo no objeto route que permita estender a política de roteamento além da simples indicação dos blocos que o AS está habilitado a anunciar.
  • Pode-se criar quantos objetos route forem necessários, para representar os anuncios de blocos limitados pela agregação.
  • A noção de agregação é muito importante para atender à preocupação, quase doentia, de minimizar a tabela de rotas no BGP. Um bom texto sobre agregação está em “Understanding Route Aggregation in BGP” e, “BGP Case Studies”, já disponíveis na BC (em Referências).
  • Preocupação quase doentia para chamar atenção para o fato de que insistir na minimização de rotas parece um excesso pois, na prática, a tendência é desagregar, por necessidade operacional. Quem é o maior desagregador brasileiro? Um bom exemplo é a topologia da TeleSA (que não tem nada de original). Na realidade, exigência imposta por restrições da infraestrutura da Internet brasileira, obrigando a desagregação em blocos /24. Quando usarmos as ferramentas poderemos ver que tal realidade parece não ser nosso privilégio. A desagregação está generalizada. Curiosamente, a expectativa seria anunciar blocos /25, /26, etc. pois, economizaria algumas centenas de IPs (v4!). Raramente alguém fala sobre o fato de que a tabela “full” no BGP gera ineficiência. Ouço falar que elas geram demanda de memória dos roteadores de borda e, que memória é MUITO caro. Ora, memória não é caro! Então porque não posso anunciar blocos /25, por exemplo? Porque, boa parte dos ASes do mundo, restrigem o /25. Mas, no passado, essa boa parte bloqueava o /24 (poucos, ainda o fazem) e deixaram de fazê-lo quando perceberam a importância desse anúncio em ambientes onde interconexões remotas possuem restrições. Pelo que se lê na literatura, as técnicas de routing analytics, do SOA e outras, que se concentram no conceito de computação pervasiva + ubíqua, devem nos levar à centralização das bases de políticas de roteamento. Pensando bem, já temos algo a caminho, com o MyASN do RIPE e o BGMON, sem falar em outras. Provavelmente é uma questão de tempo, pois dependemos, unicamente, da ubiquidade presente na infraestrutura da Internet. São, em tese, conjeturas.
  • O IRR não tem problema de eficiência ou, de memória. E nem tem o poder de restringir rotas não definidas no objeto route. Ou seja, o IRR não tem influência sobre as funcionalidades do BGP, incluíndo as políticas de roteamento. O IRR é uma base de dados que lhe entrega informações com dois objetivos básicos: captura de políticas de roteamento e, não menos importante, documentação da subrede sobre a qual você tem, como administrador, influência única.

Atributo holes

Durante o planejamento de algumas redes, três blocos não são anunciados para nenhum dos ASes empareados ao AS28182:

189.89.4.0/22
189.89.6.0/23
189.89.12.0/22

Essa informação deve ser colocada no atributo holes, do objeto route (ou route6). Vejam em:

whois -h irr.redepegasus.net.br 189.89.0.0/20

O uso do atributo holes é interessante, muito embora ele não seja um atributo obrigatório e nem seja “pesquisável”. Vejam por exemplo o caso do AS18782. Este AS não está ativo e, na época, quando atribuido ficou sem bloco IPv4 associado. Afinal, poderia-se fazer a seguinte política de roteamento, explicitamente:

route:      189.89.0.0/20
descr:      TeleSA cidr block
origin:      AS28182
holes:      189.89.4.0/22
holes:      189.89.6.0/23
holes:      189.89.12.0/22
...

route:      189.89.0.0/20
descr:      Pegasus x TeleSA cidr block
origin:     AS18782
holes:      189.89.0.0/22
holes:      189.89.8.0/22
...

Provavelmente, iríamos fazer uma economia razoável de IPv4, usando a cooperação entre ASes. E, sob o ponto de vista técnico a alternativa é endossada pela RFC1786, com categoria “informational”, escrita em 1995, à luz da RIPE81++, antecedente da RPSL.

 

Itens relacionados:

 

Categorias:IRR, Sem categoria
%d blogueiros gostam disto: