openbmc / phosphor-net-ipmid

Network IPMI server
Apache License 2.0
9 stars 11 forks source link

Unable to run IPMI commands to BMC VLAN interface #7

Open prkatti1 opened 5 years ago

prkatti1 commented 5 years ago

Precondition: VLAN with id 100 is created IP address xx.xx.xx.2 was configured on VLAN interface eth0_100 IP address yy.yy.yy.2 is configured on physical interface eth0 Src IP of the machine from where we are running curl & IPMI is xx.xx.xx.1

Problem Description BMC does not respond to IPMI commands that are sent to VLAN interface Where as ping and curl commands work to same IP address. IPMI commands work with physical interface eth0.

tomjoseph83 commented 5 years ago

@vmauery Can you help confirm the expected behavior of network IPMI on the VLAN IP address?

vmauery commented 5 years ago

I am not exactly sure what is happening to configure VLAN interfaces. On our BMCs prior to OpenBMC, if VLAN was configured, the 'native' interface was de-configured. i.e., you could only have one address per physical interface, be it VLAN or native.

But either way, if an interface is added, a new service instance would need to be added (and a new channel config entry) in order for netipmid to work correctly.

try running systemctl start phosphor-ipmi-net@eth0_100 . That should at least start up the new channel. In order for that channel to work correctly, though, the /usr/share/ipmi-providers/channel_config.json file would need to have an entry for this new channel.

To make it persistent, we would need to add code that enables the new instance of netipmid.

bradbishop commented 5 years ago

at 7:12 PM, Vernon Mauery notifications@github.com wrote:

I am not exactly sure what is happening to configure VLAN interfaces. On
our BMCs prior to OpenBMC, if VLAN was configured, the 'native' interface
was de-configured. i.e., you could only have one address per physical
interface, be it VLAN or native.

@vmauery what is the rationale behind this policy? I’m just curious. If
it is obvious…sorry…I haven’t finished my coffee yet :-)

But either way, if an interface is added, a new service instance would
need to be added (and a new channel config entry) in order for netipmid
to work correctly.

try running systemctl start phosphor-ipmi-net@eth0_100 . That should at
least start up the new channel. In order for that channel to work
correctly, though, the /usr/share/ipmi-providers/channel_config.json file
would need to have an entry for this new channel.

To make it persistent, we would need to add code that enables the new
instance of netipmid.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

amboar commented 5 years ago

at 7:12 PM, Vernon Mauery notifications@github.com wrote: I am not exactly sure what is happening to configure VLAN interfaces. On our BMCs prior to OpenBMC, if VLAN was configured, the 'native' interface was de-configured. i.e., you could only have one address per physical interface, be it VLAN or native. @vmauery what is the rationale behind this policy? I’m just curious. If it is obvious…sorry…I haven’t finished my coffee yet :-)

Also not entirely awake, but also think it needs some justification if we're to adopt it.

nest1ing commented 4 years ago

We are facing a similar problem. We have both physical and VLAN interfaces configured. According to IPMI specification, the expected behavior after ipmitool lan set 1 vlan id is netipmid bound to the VLAN interface only and not responding on the physical interface.

There is currently a possible and actually occuring race between netipmid and phorsphor-networkd. At BMC startup netipmid start may occur during phosphor-networkd restarting the ethernet interfaces. As a result, the VLAN interface does not exist when netipmid looks for it, and so the daemon binds to the physical interface instead.

I guess netipmid should be modified. Probably it should catch the DBus signal about creation/deletion of the VLAN interface from phosphor-networkd and rebind the socket direct in runtime.

What do you think?

AlexanderAmelkin commented 4 years ago

what is the rationale behind this policy?

I believe it's IPMI Specification v2.0 revision 1.1, Table 23-4 "Get LAN Configuration Parameters Command":

[7] - VLAN ID enable. 0b = disabled, 1b = enabled. If enabled, the BMC will only accept packets for this channel if they have 802.1q fields and their VLAN ID matches the VLAN ID value given in this parameter.

AlexanderAmelkin commented 4 years ago

According to IPMI, there is no way to enable VLAN on a channel without setting that bit and thus unbinding IPMI from the 'native' interface.