Incompatibilidade do ARP entre Linux e routers Cisco


A norma que especifica o protocolo ARP é omissa relativamente a que endereço IP deve ser utilizado no pedidos de resolução. Segundo interpretações filosóficas de um endereço IP pertencer a uma interface (interpretação que, pessoalmente, me parece a mais correcta) ou a um nó, existem implementações que usam o endereço IP da interface onde é enviado o pedido de ARP e implementações onde é usado o endereço IP da interface associada ao pacote que despoleta o pedido de ARP (v. parâmetro arp_announce abaixo).

O potencial problema com esta questão resulta do facto de algumas máquinas filtrarem os pedidos de ARP cujo endereço IP de origem não pertençe à sub-rede na qual foi recebido (v. parâmetro arp_filter). Numa situação em que a máquina que envia o pedido de ARP usa um IP doutra interface que não aquela por onde envia o pedido e em que a máquina que recebe o pedido faz a referida filtragem (contrariando assim o princípio de robustez para as comunicações na Internet be conservative in what you do, be liberal in what you accept from others enunciado por Jon Postel), alguns pedidos de ARP podem ficar sem resposta, inviabilizando a comunicação.

O caso anterior ocorre quando uma máquina Linux com mais de uma interface envia um pedido de ARP a um router Cisco (ambos com a configuração-padrão).

A solução para este problema consiste em alterar na máquina Linux o parâmetro arp_announce do seu valor-padrão 0 para 1 ou 2. Isto pode fazer-se de forma imediata (e temporária) usando o comando sysctl -w net.ipv4.conf.all.arp_announce=1 ou de forma permanente adicionando ao ficheiro /etc/sysctl.conf a linha net.ipv4.conf.all.arp_announce=1.

Extracto do ficheiro ip_sysctl.txt
arp_filter - BOOLEAN
        1 - Allows you to have multiple network interfaces on the same
        subnet, and have the ARPs for each interface be answered
        based on whether or not the kernel would route a packet from
        the ARP'd IP out that interface (therefore you must use source
        based routing for this to work). In other words it allows control
        of which cards (usually 1) will respond to an arp request.

        0 - (default) The kernel can respond to arp requests with addresses 
        from other interfaces. This may seem wrong but it usually makes
        sense, because it increases the chance of successful communication.
        IP addresses are owned by the complete host on Linux, not by
        particular interfaces. Only for more complex setups like load-
        balancing, does this behaviour cause problems.

        arp_filter for the interface will be enabled if at least one of
        conf/{all,interface}/arp_filter is set to TRUE,
        it will be disabled otherwise

arp_announce - INTEGER
        Define different restriction levels for announcing the local
        source IP address from IP packets in ARP requests sent on
        interface:
        0 - (default) Use any local address, configured on any interface
        1 - Try to avoid local addresses that are not in the target's
        subnet for this interface. This mode is useful when target
        hosts reachable via this interface require the source IP
        address in ARP requests to be part of their logical network
        configured on the receiving interface. When we generate the
        request we will check all our subnets that include the
        target IP and will preserve the source address if it is from
        such subnet. If there is no such subnet we select source
        address according to the rules for level 2.
        2 - Always use the best local address for this target.
        In this mode we ignore the source address in the IP packet
        and try to select local address that we prefer for talks with
        the target host. Such local address is selected by looking
        for primary IP addresses on all our subnets on the outgoing
        interface that include the target IP address. If no suitable
        local address is found we select the first local address
        we have on the outgoing interface or on all other interfaces,
        with the hope we will receive reply for our request and
        even sometimes no matter the source IP address we announce.

        The max value from conf/{all,interface}/arp_announce is used.

        Increasing the restriction level gives more chance for
        receiving answer from the resolved target while decreasing
        the level announces more valid sender's information.

arp_ignore - INTEGER
        Define different modes for sending replies in response to
        received ARP requests that resolve local target IP addresses:
        0 - (default): reply for any local target IP address, configured
        on any interface
        1 - reply only if the target IP address is local address
        configured on the incoming interface
        2 - reply only if the target IP address is local address
        configured on the incoming interface and both with the
        sender's IP address are part from same subnet on this interface
        3 - do not reply for local addresses configured with scope host,
        only resolutions for global and link addresses are replied
        4-7 - reserved
        8 - do not reply for all local addresses

        The max value from conf/{all,interface}/arp_ignore is used
        when ARP request is received on the {interface}