Prev: USB Networking and Interconnectivity adapters
Next: Cross communication between Linux and XP
From: Rahul on 30 Jun 2010 20:26
Jan Kandziora <jjj(a)gmx.de> wrote in news:i0gmof$7gl$1(a)online.de:

Thanks Jan!

> I would expect the ping is getting into 172.16.0.3, but the pong
> cannot be received correctly by the machine which issued the ping.

I agree. That seems what I think too based on Rick's comments. Is there a
way to find if the BMC ever issued a pong or not? Maybe a tcpdump would
show? But I am not sure of what the packet dump command should be to trap
the pong.

Something like this?

tcpdump -c 100 -ennqti eth0 \( arp or icmp \)


> Should be irrelevant as long you don't route the ping from/to outside
> through a router.

So, you think the BMC will blindly echo pongs back on the same physical net
by force. No matter what IP subnet the ping emanated from? So long as the
ping reaches the BMC it will pong back correctly?

>>
> First check the machine issuing the ping. Maybe it's something wrong
> there, e.g. firewall setting.

It doesn't have a firewall running. It can ping everywhere else. In fact it
can even ping this very same BMC so long as the BMC IP is within the
10.0.x.x subnet.

--
Rahul
From: Rahul on 30 Jun 2010 20:42
Rick Jones <rick.jones2(a)hp.com> wrote in news:i0gj74$u3r$1
@usenet01.boi.hp.com:

> You could try that - setting the default gateway in the BMC to the
> BMC's own local IP and have it rely on Proxy ARP too. Otherwise, I
> suspect you will need to find another system in the 172.16.X.X subnet
> to act as a gateway.
>

Unfortunately that didn't work. I tried setting the default gateway to
the local machine:

ipmitool lan set 1 defgw ipaddr 10.0.0.3

If I try
ipmitool lan set 1 defgw ipaddr 127.0.0.1 it throws an error.

What's the ProxyARP? Does it have to be enabled in some way? Any other
sugesstions?

Of course, I can always set up a gateway machine but not sure what needs
to be done on it. Can it still have just a single eth adapter. I mean
both subnets are essentially on the same physical network anyways. In
fact, I do have a gateway machine already.

Kernel IP routing table
DestinationGateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.255.0.0 U 0 0 0 eth0
172.16.0.0 * 255.255.0.0 U 0 0 0 eth0
default euadmin.che.wis 0.0.0.0 UG 0 0 0 eth0


Do I just have to add some routing lines on the gateway machine then? I
tried this but doesn't seem to work:

gateway>route add -net 172.16.0.0 netmask 255.255.0.0 dev eth3


--
Rahul
From: Rick Jones on 30 Jun 2010 21:07
Rahul <nospam(a)nospam.invalid> wrote:
> Rick Jones <rick.jones2(a)hp.com> wrote in news:i0gj74$u3r$1
> @usenet01.boi.hp.com:

> > You could try that - setting the default gateway in the BMC to the
> > BMC's own local IP and have it rely on Proxy ARP too. Otherwise, I
> > suspect you will need to find another system in the 172.16.X.X subnet
> > to act as a gateway.

> Unfortunately that didn't work. I tried setting the default gateway
> to the local machine:

> ipmitool lan set 1 defgw ipaddr 10.0.0.3

With a few exceptions, a default gateway IP must be in the same IP
subnet as the stack itself. In this case since you are putting the
BMC stack into 172.16.mumble, so you would use the BMC's own IP, not
the IP of the host stack.

> If I try ipmitool lan set 1 defgw ipaddr 127.0.0.1 it throws an
> error.

That would be telling the BMC to reach non-local IP addresses by going
to the loopback interface - I don't think that could work even if it
didn't throw an error :)

> What's the ProxyARP?

Proxy ARP is where one tells the stack to be its own default gateway -
one configures the stack's local (non-loopback) IP address as the
gateway IP address (and uses a hop count of 0 when that is part of the
deal). The routing code notices this and then will pretend as if any
remote IP address is actually local and will ARP for it. It is hoping
that a system in the local LAN (broadcast domain) will act as a
"proxy." Typically, the router(s) on the LAN will respond to the ARP
request as if they were the remote destination IP, but giving their
own MAC address. The end-system then encapsulates the IP datagrams in
an Ethernet Frame with the "proxy" MAC address as the destination MAC.

In the case of running multiple IP subnets in the same broadcast
domain, chances are good that the actual destination sees the ARP
request and responds with its own MAC address. You've seen an example
of that already with your setup of the gateway on what you/we were
calling the "remote system" - it ARPed for the remote IP address, the
BMC responded to the ARP request with its own MAC. Now we are trying
to get the BMC stack to do that too.

> Does it have to be enabled in some way?

That will depend entirely on the IP stack in the BMC.

> Any other sugesstions?

> Of course, I can always set up a gateway machine but not sure what needs
> to be done on it. Can it still have just a single eth adapter. I mean
> both subnets are essentially on the same physical network anyways. In
> fact, I do have a gateway machine already.

> Kernel IP routing table
> DestinationGateway Genmask Flags Metric Ref Use Iface
> 10.0.0.0 * 255.255.0.0 U 0 0 0 eth0
> 172.16.0.0 * 255.255.0.0 U 0 0 0 eth0
> default euadmin.che.wis 0.0.0.0 UG 0 0 0 eth0


> Do I just have to add some routing lines on the gateway machine
> then? I tried this but doesn't seem to work:

> gateway>route add -net 172.16.0.0 netmask 255.255.0.0 dev eth3

If the gateway system already has IP addresses configured in both
subnets then IIRC that gateway system is fine. (Well, ip_forward(ing)
may need to be enabled via sysctl) The issue is then pointing the BMC
at the 172.16.mumble IP address of the gateway machine.

It may help to think of the BMC as a completely separate system, even
though it is embedded in the NIC in the host. At least that is how
I'm thinking of it in this situation - at the risk of completely
misunderstanding how BMCs really work :)

rick jones
--
I don't interest myself in "why". I think more often in terms of
"when", sometimes "where"; always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: Rahul on 30 Jun 2010 21:47
Rick Jones <rick.jones2(a)hp.com> wrote in news:i0gpnn$sa$1
@usenet01.boi.hp.com:

>> ipmitool lan set 1 defgw ipaddr 10.0.0.3
>
> With a few exceptions, a default gateway IP must be in the same IP
> subnet as the stack itself. In this case since you are putting the
> BMC stack into 172.16.mumble, so you would use the BMC's own IP, not
> the IP of the host stack.
>

Solved! You saved my day! :-)

ipmitool lan set 1 defgw ipaddr 172.16.0.3

That works!! I'd never have figured this out by myself! Thanks again for
all the useful tips!

--
Rahul
From: Rick Jones on 30 Jun 2010 21:32
Rahul <nospam(a)nospam.invalid> wrote:
> Jan Kandziora <jjj(a)gmx.de> wrote in news:i0gmof$7gl$1(a)online.de:

> Thanks Jan!

> > I would expect the ping is getting into 172.16.0.3, but the pong
> > cannot be received correctly by the machine which issued the ping.

> I agree. That seems what I think too based on Rick's comments. Is there a
> way to find if the BMC ever issued a pong or not? Maybe a tcpdump would
> show? But I am not sure of what the packet dump command should be to trap
> the pong.

If the BMC does not have a route back to the 10network configured it
will not emit anything to be traced.

Consider this picture, which is a logical rather than physical
diagram. I don't recall the specific IPs involved so will make some
up. Any similarity to your actual IPs is accidental :) We ignore for
the moment the idea of ProxyARP.

+--------+ +--------+ +--------+
| | 172.16.0.0/16 | | 10.1.0.0/16 | |
| Kaos +---------------+ GW +---------------+Control |
| |.2 .1| |.1 .3| |
+--------+ +--------+ +--------+

Kaos is 172.16.0.2 and should have a default GW pointing at
172.16.0.1, the 172.16/16 IP of the GW system.

The GW is already configured in both IP subnets and only needs
ip_foward set.

The Control system is configured with an IP of 10.1.0.0.3 and a route
to 172.16/16 pointing at 10.1.0.1 - the 10.1 IP of the GW
system. (Could be the default route if there were no other IP subnets
involved).

So, Kaos knows how to reach Control, and Control knows how to reach
Kaos - they each reach-out and touch one another via GW.

Now, you have already demonstrated that "Control's" stack knows how to
do ProxyARP and that Kaos and Control are in the same broadcast
domain. Now lets do a more physical picture:

+--------+
| |
| GW |
| |
+---+----+
.|.
172.16.0.1/16|10.1.0.1/16
.|.
+--------+ +---+----+ +--------+
| |...............|... ....|...............| |
| Kaos +---------------+ Switch +---------------+Control |
| |===============|========|===============| |
+--------+ +--------+ +--------+
172.16.0.0.2/16 10.1.0.3/16

Unless we learn that Kaos knows how to do ProxyARP it is still
configured as before - a default gateway pointing at 172.16.0.1. When
Kaos wants to send an IP datagram to Control, it will see that Control
is in a remote IP subnet, find the default route, and pick 172.16.0.1
as the next hop destination. It will then ARP for 172.16.0.1, get the
GW's MAC address, and encapsulate the IP datrgram destinted for
Control in an Ethernet frame with GW's MAC address. The switch
delivers that to GW, GW receives it, sees the destination is not one
of its own IP addresses, does a route lookup of its own, and will
forward it out its 10.1.0.1 interface after ARPing for Control's IP
address and getting Control's MAC address. This is also what would
happen in the logical case above. That is the path through the diagram
indicated by "."

GW remains configured as before.

Control, instead of pointing a 172.16/16 route at 10.1.0.1 can point
it at its own 10.1.0.3 interface. When it wants to send an IP
datagram to Kaos it will ARP for Kaos, Kaos will see the ARP request
and Control will send IP datagrams following the "=" path.

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: USB Networking and Interconnectivity adapters
Next: Cross communication between Linux and XP