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

[Martin GombaÄ <martin@xxxxxx>]

Tnx for the followup. Keep us informed if or how you solve the problem.
Regards,
M.

Matthew Law wrote:
> 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
>   
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users