Re: [Xen-users] domU loses incoming network after period of inactivity

["Matthew Law" <matt@xxxxxxxxxxxxxxxxxx>]

On Wed, February 17, 2010 11:07 am, Fajar A. Nugraha wrote:
> At first glance it looks like switch problem. You should be able to
> trace it when the problem occurs:
> - ping from outside host
> - "brctl showmacs name_of_bridge", see if domU MAC is listed there
> - tcpdump on uplink interface (usually peth0), see if arp goes through
> correctly and domU replies it
> - look at mac address table on the switch, see if you can find domUs
> MAC on the correct port
>
> It might be that the switch who should be doing arp broadcast to all
> port when a MAC is not cached didn't do that, so the request from
> outside world to domU never reach dom0's port.

Ok, after some investigation, here's where I'm at with this little peach
of a problem!

1) Confirm I can't ping or ssh onto the domU.
2) From dom0, confirmed domU is running and consoled onto it.
3) Check again that I can't ping or ssh onto it (just in case the act of
consoling onto it has changed anything).  No change.
4) 'brctl showmacs peth0' shows the correct domU mac address
5) On dom0 I ran 'tcpdump -i peth0 -e -n arp or icmp' and then ping the
domU from outside.  This results in:

grep -v Broadcast tcpdump.log
11:09:59.481106 00:d0:01:78:a4:00 > ae:00:59:15:1a:09, ethertype IPv4
(0x0800), length 98: my.ip.address > domu.ip.address: ICMP echo request,
id 59096, seq 0, length 64
11:09:59.481206 ae:00:59:15:1a:09 > 00:00:0c:07:ac:05, ethertype IPv4
(0x0800), length 98: domu.ip.address > my.ip.address: ICMP echo reply, id
59096, seq 0, length 64
11:10:00.480863 00:d0:01:78:a4:00 > ae:00:59:15:1a:09, ethertype IPv4
(0x0800), length 98: my.ip.address > domu.ip.address: ICMP echo request,
id 59096, seq 1, length 64
11:10:00.480925 ae:00:59:15:1a:09 > 00:00:0c:07:ac:05, ethertype IPv4
(0x0800), length 98: domu.ip.address > my.ip.address: ICMP echo reply, id
59096, seq 1, length 64
11:10:01.481083 00:d0:01:78:a4:00 > ae:00:59:15:1a:09, ethertype IPv4
(0x0800), length 98: my.ip.address > domu.ip.address: ICMP echo request,
id 59096, seq 2, length 64
11:10:01.481138 ae:00:59:15:1a:09 > 00:00:0c:07:ac:05, ethertype IPv4
(0x0800), length 98: domu.ip.address > my.ip.address: ICMP echo reply, id
59096, seq 2, length 64
11:10:04.471206 ae:00:59:15:1a:09 > 00:00:0c:07:ac:05, ethertype ARP
(0x0806), length 42: arp who-has gateway.ip.address tell domu.ip.address
11:10:04.471773 00:00:0c:07:ac:05 > ae:00:59:15:1a:09, ethertype ARP
(0x0806), length 60: arp reply gateway.ip.address is-at 00:00:0c:07:ac:05

So, the domU is replying to the pings.  Interesting.

6) I try the domU again and it is now accessible - different behaviour to
what I was seeing before, but it may be that just before I ran the tcpdump
command, something on the domU initiated a connection to the outside world
and threw a spanner in the works...

I don't have access to the switches I am immediately connected to in this
case, but I do know that they are running HSRP which has been known to
'crap out' in the past, so I will get that looked into.  Also, I run
ebtables on the dom0 to prevent IP spoofing, so another possibility is
that ebtables might be the issue - perhaps it is 'forgetting' the MAC to
IP mapping?.

I will enable logging and investigate some more...

Regards,

Matt.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users