* arping and ipoib question
@ 2010-03-09 19:59 Tom Ammon
0 siblings, 0 replies; only message in thread
From: Tom Ammon @ 2010-03-09 19:59 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi,
I'm trying to build a failover setup for multiple ib-ethernet gateways
(routing IP) and I was wondering how/if the linux "arping" utility works
with ipoib. I would like to send a gratuitous ARP to the ipoib subnet to
announce a change of IP ownership, but it doesn't seem to be working
like it does on ethernet.
So I have host labfs01 and labfs03. They are plugged in to an SDR switch
with opensm managing the fabric. I can see them on the IB fabric, I can
see them in ibnetdiscover and I can perfquery their port counters from
each other. So I'm sure the IB fabric is okay.
Here's what I see when I try to send a gratuitous ARP from labfs03:
[root@labfs03 ~]# arping -c 3 -A -I ib0 172.17.30.7
ARPING 172.17.30.7 from 172.17.30.7 ib0
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
[root@labfs03 ~]#
And here's some output from labfs01 before, while, and after I send the
gARP:
[root@labfs01 ~]# ip neigh s
192.168.0.13 dev bond1 lladdr 00:02:b3:90:a9:3e REACHABLE
192.168.0.10 dev bond1 lladdr 00:50:45:00:b8:aa REACHABLE
172.17.6.1 dev bond0 lladdr 00:16:9c:54:80:00 REACHABLE
192.168.0.14 dev bond1 FAILED
172.17.6.32 dev bond0 lladdr 00:50:45:00:bc:2c REACHABLE
172.17.6.31 dev bond0 lladdr 00:50:45:00:be:de REACHABLE
192.168.0.12 dev bond1 lladdr 00:02:b3:cc:1c:e2 REACHABLE
[root@labfs01 ~]#
[root@labfs01 ~]# tcpdump -i ib0
tcpdump: WARNING: arptype 32 not supported by libpcap - falling back to
cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
12:54:15.912672 arp reply 172.17.30.7 is-at
80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:24:34:8d hardware #32
12:54:16.913677 arp reply 172.17.30.7 is-at
80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:24:34:8d hardware #32
12:54:17.914625 arp reply 172.17.30.7 is-at
80:00:04:04:fe:80:00:00:00:00:00:00:00:02:c9:02:00:24:34:8d hardware #32
3 packets captured
3 packets received by filter
0 packets dropped by kernel
[root@labfs01 ~]# ip neigh sh
192.168.0.13 dev bond1 lladdr 00:02:b3:90:a9:3e REACHABLE
192.168.0.10 dev bond1 lladdr 00:50:45:00:b8:aa REACHABLE
172.17.6.1 dev bond0 lladdr 00:16:9c:54:80:00 REACHABLE
192.168.0.14 dev bond1 FAILED
172.17.6.32 dev bond0 lladdr 00:50:45:00:bc:2c REACHABLE
172.17.6.31 dev bond0 lladdr 00:50:45:00:be:de REACHABLE
192.168.0.12 dev bond1 lladdr 00:02:b3:cc:1c:e2 REACHABLE
So we can see the gARP packets making it to labfs01, but the ARP cache
in labfs01 is not being updated by the gARP.
If I just do a ping from labfs01 to labfs03, the ARP entry shows up.
Is this something that ipoib can do? Is there a better way to approach this?
Tom
--
--------------------------------------------------------------------
Tom Ammon
Network Engineer
Office: 801.587.0976
Mobile: 801.674.9273
Center for High Performance Computing
University of Utah
http://www.chpc.utah.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2010-03-09 19:59 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-09 19:59 arping and ipoib question Tom Ammon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.