Prev: USB Networking and Interconnectivity adapters
Next: Cross communication between Linux and XP
From: Rick Jones on 30 Jun 2010 19:15
Rahul <nospam(a)nospam.invalid> wrote:
> David Schwartz <davids(a)webmaster.com> wrote in
> news:7af58078-aa68-45c3-a04c-d0620fdd4b43(a)o14g2000pri.googlegroups.com:

> > Did you properly configure the BMC with a default route, netmask,
> > and so on?

> Yup. I think so.

> ipmitool lan set 1 ipsrc static
> ipmitool lan set 1 ipaddr 172.16.0.3
> ipmitool lan set 1 netmask 255.255.0.0

> I think this was sucessful because the same set of steps do work if
> I just change the 172.16.0.3 to 10.0.4.3.

> Also, even if I use the 172.16.0.3 subnet the arp on the remote
> machine does recognise the correct mapping between the IP and the
> MAC.

Keep in mind that routing is symmetric - for traffic to be exchanged
not only does System A need to know how to reach System B, System B
needs to know how to reach System A. The above simply suggests that
your remote machine is configured for Proxy ARP and knows how to reach
your BMC. It says nothing about your BMC knowing how to reach your
remote system.

> i.e. arp figures out that 172.16.0.3 is associated with 00:26:B9:58:E6:48
> (the right MAC)

> There is one thing that I wasn't sure about though: "the default gateway".
> Not sure what to set it to. i.e. in the command

> ipmitool lan set 1 defgw ipaddr ??
> ipmitool lan set 1 defgw netmask ??

> But I was thinking that was not really required since when I use the
> 10.0.x.x subnet it just works without setting this.

Ostensibly the stack in the BMC will assume that anything other than
172.16.X.X is remote and will want to use a gateway to reach it. If
there is no (default) gateway, the IP code in the BMC stack will not
now how to get back to anything outside of 172.16.X.X.

That the system from which you are pinging gets an IP/MAC mapping in
the ARP table suggests it is using its own local IP address as the
default gateway and relying on Proxy ARP.

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.

rick jones
--
It is not a question of half full or empty - the glass has a leak.
The real question is "Can it be patched?"
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 19:51
Rick Jones <rick.jones2(a)hp.com> wrote in news:i0gj74$u3r$1
@usenet01.boi.hp.com:

What you say makes a lot of sense, Rick! Thanks!

> That the system from which you are pinging gets an IP/MAC mapping in
> the ARP table suggests it is using its own local IP address as the
> default gateway and relying on Proxy ARP.
>
This may have to do with the fact that on the remote system I explicitly
told it to by doing:

route add -net 172.16.0.0 netmask 255.255.0.0 dev eth0

[sorry forgot to mention this earlier]

Maybe the solution is that on the system I am trying to ping I will set up
a similar route and then just like you suggested set the gateway to itself
in the BMC. Let me check!


--
Rahul
From: Denis McMahon on 30 Jun 2010 20:12
On 30/06/10 23:42, Rahul wrote:

> But I was thinking that was not really required since when I use the
> 10.0.x.x subnet it just works without setting this.

All the machines involved need to know that they're in both subnets.

The target machine might know about the second subnet from the
specialist controller setup, but what about the other machine that
you're using to control it with? It also needs to know about the second
subnet.

e.g. I could tell the webserver on my lan to listen to ip addresses in
multiple subnets, but I can't browse to those ip addresses from my
desktop or laptop machines unless I also tell those machines about the
subnets and how to talk to them, otherwise they just try and send the
data to my router, which gets totally confused because it has no route
to reach private subnet space.

Rgds

Denis McMahon
From: Jan Kandziora on 30 Jun 2010 20:17
Rahul schrieb:
>
> i.e. arp figures out that 172.16.0.3 is associated with 00:26:B9:58:E6:48
> (the right MAC)
>
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.


> There is one thing that I wasn't sure about though: "the default gateway".
> Not sure what to set it to. i.e. in the command
>
> ipmitool lan set 1 defgw ipaddr ??
> ipmitool lan set 1 defgw netmask ??
>
Should be irrelevant as long you don't route the ping from/to outside
through a router.


> But I was thinking that was not really required since when I use the
> 10.0.x.x subnet it just works without setting this.
>
First check the machine issuing the ping. Maybe it's something wrong there,
e.g. firewall setting.

Kind regards

Jan
From: Rahul on 30 Jun 2010 20:20
Denis McMahon <denis.m.f.mcmahon(a)googlemail.co.uk> wrote in news:4c2bdd8a$0
$6720$bed64819(a)gradwell.net:

> All the machines involved need to know that they're in both subnets.
>
> The target machine might know about the second subnet from the
> specialist controller setup, but what about the other machine that
> you're using to control it with? It also needs to know about the second
> subnet.
>

Thanks Denis! On the controlling machine I did:

route add -net 172.16.0.0 netmask 255.255.0.0 dev eth0

Shouldn't that be sufficient? Or do I need to do something else?

Furthermore on the controlling machine the arp tables are so:

Address HWaddress Flags Mask Iface
10.0.0.3 00:26:B9:58:E6:46 C eth0
172.16.0.3 00:26:B9:58:E6:48 C eth0

To me it looked like then the controlling machine seems to know where
172.16.0.3 is. Maybe I am wrong?

Also, these are the routing tables on the controlling machine:

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



--
Rahul
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: USB Networking and Interconnectivity adapters
Next: Cross communication between Linux and XP