Re: Kernel drops UDP datagrams between interface and process

On Thu, 15 Apr 2010 17:59:22 -0700 (PDT) David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Apr 15, 5:31 pm, phil-news-nos...@xxxxxxxx wrote:
|
|> | You claim this is supposed to be for failover, but you have no
|> | failover mechanism. There are many ways to do network interface
|> | failover in Linux, but this is not one of them.
|>
|> The mechanism is called ARP.
|
| You have no method to prevent one interface from responding to ARP
| requests under any circumstances. If you had logic to disable one
| interface when the other was working, then you could use ARP as
| failover mechanism.

Irrelevant. If the connection is not working, there will not be any ARP
requests coming in on that interface. I don't need any added logic.
The ARP requests will come in on one or more of the working interfaces.
Nothing needs to be further disabled.


|> You have mentioned one mechanism so far.  You claim "There are many ways to
|> do network interface failover in Linux".  Maybe you can list or name at least
|> two more of them just so I can see what you have in mind.  If one of them is
|> suitable for my situation, I'll even consider using it.
|
| VRRP and OSPF. My personal preference is to use OSPF, assigning the
| service IP address to a loopback interface and advertising its
| availability across both physical interfaces.

There is no VRRP. VRRP is for failover of two or more routers as seen by
other hosts via a single virtual MAC address. This is NOT a case where I
want a quick fallback to an alternate machine that picks up that MAC when
the other fails. VRRP is similar to HSRP. OpenBSD has a similar system
called CARP. But, again, it is for two or more machines operating in a
way where they coordinate with each other to share the same virtual MAC.

There is no OSPF. OSPF is routing. There is no routing taking place here.
This is switching redundancy; nothing more.

BTW, I did try assigning the IP address only to the loopback interface a
couple days ago. The end result was that ARPs were answered as before,
but ALL packets arriving on BOTH ethernet interfaces were discarded. The
only packets that would reach the listening process were those that were
transmitted from the same machine itself. Advertising OSPF isn't even
applicable because the peer machines share the same subnet and ethernet
segments. ARP is the mechanism of neighbor discovery here (for IPv4).

Also, assigning the IP address to the loopback interface used to work in
older kernels. I know because I have done it that way before. It SHOULD
work. It doesn't now. In software development we call this "regression".

Now, back to the original problem ... why the kernel discards packets for
one interface and not the other. If it were to discard packets on both,
then it would be clear something is wrong with how they are configured.
But it discards packets for JUST ONE and not for the other. Both interfaces
are working and both are configured the same. Keep your mind away from the
why aspect of my configuration. If you don't know why the kernel does one
thing with on interface, and something different for another, when both are
configured the same, then you have nothing to contribute.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.

Relevant Pages

  • Re: Which cable for ASA failover?
    ... Can you post your failover config of both unit. ... interface Ethernet0/0 ... mtu management 1500 ... timeout xlate 3:00:00 ...
    (comp.dcom.sys.cisco)
  • Re: Which cable for ASA failover?
    ... Can you post your failover config of both unit. ... interface Ethernet0/0 ... mtu management 1500 ... timeout xlate 3:00:00 ...
    (comp.dcom.sys.cisco)
  • Re: IP Failover: strange behaviour
    ... As long as both machines are up and running, IP failover ... network interface, and enters the status described in 1). ... IPPSA2> tcpip ifconfig -a ... IE2 are not participating in a ip failover. ...
    (comp.os.vms)
  • Re: CISCO ASA 5505 Failover
    ... the following exerpts (Cisco Systems, ... You can use any unused Ethernet interface on the device as the ... The failover link interface is not configured ...
    (comp.dcom.sys.cisco)
  • Failover problem with PIX 515
    ... with failover cable ... Cisco PIX Firewall Version 6.2 ... Normal Interface inside: Normal Other host: Secondary - ... Hardware is i82559 ethernet, address is 000b.46aa.a620 ...
    (comp.security.firewalls)