On Thu, 25 Feb 1999, Eric van Dijken wrote:

> Hi,
> 
> Recently we ran into the following network problem:
> 
> Network topology:
> 
> 
>                         Production backbone
>         --------+----------------------------+-------------
>                 |       ---> 1               |
>                 |       <--  2               |
>            mac1 |       ---> 3          mac2 |
>            ip1  |                       ip2  |
>          .------------.               .-------------.
>          |            |               |             |
>          |    FW      |               |    MHH      |
>          |            |               `-------------'
>          |            | mac4                 | ip3
>          |            | ip4                  | mac3
>          |            |----------------------+--------
>          |            |    <--- 4 Maintenance backbone
>          `------------'    ---> 5
>                 |          <--- 6
>                 |
>                 |
>                 |
>          .------------.
>          |            |
>          |    PC      |
>          |            |
>          `------------'
> 
> The firewall FW routes 'forward' traffic from PC to the ip2 via the
> production backbone. The Multi-Homed-Host MHH routes the return traffic
> via the maintenance backbone.
> 
> The FW reports changes in MAC address for the production interface of the
> MHH, ip2.  Running tcpdump on FW reveals the following scenario:
> 
> 1. PC tries to connect to ip2 (HTTP request
> 2. FW issues an arp-request (asking for mac2) on the production
>    backbone: packet 1
> 3. MHH replies with an arp-reply: packet 2
> 4. FW sends first IP packet to MHH: packet 3
> 5. MHH issues an arp-request (asking for mac4) on the maintenance
>    backbone: packet 4
> 6. FW replies with an arp-reply: packet 5
> 7. MHH sends first IP return packet to FW: packet 6.
> 
> This should work but the arp-request from MHH, packet 4, contains unexpected
> information:
> 
> source hardware addres = mac3
> source protocol address = ip2 (I expected ip3)
> destination hardawre addres = NULL
> destination protocal addres = ip4
> 
> This packet forces the FW to change its arp-cache: the mac addres for ip2
> is set to mac3. This effectively blocks all traffic between PC end MHH
> 
> How to solve this ?? Regrettable we cannot change the routing configuration.
> 
> Greetings, Eric.
> 

This looks complex, but probably becomes simple once you see that
there are duplicate routes created. You need to force a preferred
route which is usually done using the keyword "metric". The lower
the number, the most preferred.

Cheers,
Dick Johnson
                 ***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.1 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom  : It's not a Y2K problem. It's a Y2Day problem.


-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to