Thanks for your information, Thomas
OK, then for "0c:c4:7a:58:c7:6a!*NOIP*", it seems xCATd can not get the hostname "tars-113-eth2" resolved, will you pls check whether "tars-113-eth2" can be resolved to ip "192.168.128.115" on the xCAT MN?
BTW, can you ping me(zet809) in https://gitter.im/xCAT2/xcat-core ? It is much easier to Q/A and debug issues.
Thx!
Best Regards,
-----------------------------------
Zhao Er Tao
IBM China System and Technology Laboratory, Beijing
Tel:(86-10)82450485
Email: erta...@cn.ibm.com
Address: 1/F, 28 Building,ZhongGuanCun Software Park,
No.8 DongBeiWang West Road, Haidian District,
Beijing, 100193, P.R.China
-----------------------------------
Zhao Er Tao
IBM China System and Technology Laboratory, Beijing
Tel:(86-10)82450485
Email: erta...@cn.ibm.com
Address: 1/F, 28 Building,ZhongGuanCun Software Park,
No.8 DongBeiWang West Road, Haidian District,
Beijing, 100193, P.R.China
----- Original message -----
From: Thomas HUMMEL <thomas.hum...@pasteur.fr>
To: xcat-user@lists.sourceforge.net
Cc:
Subject: Re: [xcat-user] Discovery race condition ?
Date: Fri, Mar 22, 2019 10:37 PM
On 3/22/19 3:20 PM, Er Tao Zhao wrote:
> Hi, Thomas
Hello, thanks for your time !
> For "0c:c4:7a:4d:85:a8|0c:c4:7a:58:c7:6a!*NOIP*", so
> "0c:c4:7a:58:c7:6a" is the MAC address of eth2, right?
Yes,
the mac table entry reads :
"tars-113",,"0c:c4:7a:4d:85:a8|0c:c4:7a:58:c7:6a!*NOIP*",,
and eth2: 0c:c4:7a:58:c7:6a is the MAC address of eth2
> Will you pls show me the result of "tabdump discoverydata | grep
> 0c:c4:7a:58:c7:6a -A20"?
# tabdump discoverydata | grep -i 0c:c4:7a:58:c7:6a -A20
"00000000-0000-0000-0000-0CC47A4D85A8","tars-113","undef","03-20-2019
17:51:09","x86_64","12","Intel(R) Xeon(R) CPU E5-2620 v3 @
2.40GHz","258373MB",,"E162178X5A02118","eth0!igb,eth1!igb,eth2!ixgbe","eth0!192.168.134.250/21,eth2!192.168.134.252/21","eth0!0C:C4:7A:4D:85:A8,eth1!0C:C4:7A:4D:85:A9,eth2!0C:C4:7A:58:C7:6A","eth0!0000:03:00.0,eth1!0000:03:00.1,eth2!0000:81:00.0","eth0!Onboard
Ethernet 1,eth1!Onboard Ethernet 2","eth0!1,eth1!2","eth0! Intel
Ethernet i350 #1,eth1! Intel Ethernet i350
#2","eth0!B10D2.pasteur.fr,eth1!Agent instance for device not found
,eth2!B10B4.pasteur.fr","eth0!157.99.128.218,eth2!157.99.128.231","eth0!Arista
Networks EOS version 4.15.0F running on an Arista Networks
DCS-7010T-48,eth1!Agent instance for device not found ,eth2!Arista
Networks EOS version 4.15.0F running on an Arista Networks
DCS-7280SE-64","eth1!Agent instance for device not found
","<discoveryotherdata>
<disksize>sda:256GB</disksize>
<mac>igb|eth0|0C:C4:7A:4D:85:A8|192.168.134.250/21</mac>
<mac>igb|eth1|0C:C4:7A:4D:85:A9|</mac>
<mac>ixgbe|eth2|0C:C4:7A:58:C7:6A|192.168.134.252/21</mac>
<sha512sig>
iDq3hJkwqfCLJ53Of1tZmDTTWVNjXuTsw+7OYGqZrNVQ1DgMncHQj0bNzPd6CBVM
/UgNi7GpMmzTsCZuE5Jtz7L8psVQEUguygzNImAJrJPkG0GLGxYmeea7xUox8sae
86Q9mqxXSW7TbYFQmf6lYV0kCfYl41ZQAQpfl+UtDxE=
</sha512sig>
<xcatpubkey>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCfZLW0BHjiEw4OD4nn9ZcXUpjgGb5bwaYL6nvsl4Tq3m9FwdP8HQZ0RgU2cim2yv0yId9fhEJUQdDqXgrV/Bgky6+oh+M13PaNCMPHXX2VnIVrYaIy9gFMn8jxONFn3XXtW9vflgfSEHK5snPLVNFIWdhcXtJuHzwONx6QLxNG0QIDAQAB</xcatpubkey>
</discoveryotherdata>
",,
Thanks
--
Thomas H.
> Thx!
> Best Regards,
> -----------------------------------
> Zhao Er Tao
>
> IBM China System and Technology Laboratory, Beijing
> Tel:(86-10)82450485
> Email: erta...@cn.ibm.com
> Address: 1/F, 28 Building,ZhongGuanCun Software Park,
> No.8 DongBeiWang West Road, Haidian District,
> Beijing, 100193, P.R.China
>
> ----- Original message -----
> From: Thomas HUMMEL <thomas.hum...@pasteur.fr>
> To: xcat-user@lists.sourceforge.net
> Cc:
> Subject: Re: [xcat-user] Discovery race condition ?
> Date: Thu, Mar 21, 2019 2:19 AM
> On 2/25/19 10:04 AM, Er Tao Zhao wrote:
> > Hi, Thomas
> > Yeah, I agree with Kevin that if you not plan to bond eth0 and eth2,
> > you'd better set then in different VLAN.
> > But if eth0 and eth2 are in same vlan, xCAT can deal with it
> after xCAT 2.13
> > Will you pls show me the output of `lsdef tars-113`
> > And can `tars-113-eth0` or `tars-113-eth2` can be resolved to the
> same
> > ip with `tars-113` in your DNS? And can be get from MN?
> > For example `ping tars-113-eth0` or `ping tars-113-eth2` can get
> same ip
> > in node `xcat-tars`
> Hello,
>
> as I said, sorry for the delay I've been in vacation then busy.
>
> A quick reminder :
>
> Nodes are normally physically configured like this :
>
> conf 1:
>
> a) eth0 -> switch A (1G) : ipmi (ipmi subnet) traffic allowed
> b) eth2 -> switch B (10G) : only data (data subnet) traffic allowed
>
> and logically configured to get switch-based discovered using swith B
>
> I did configure on purpose one node/port like this :
>
> conf 2:
>
> a) eth0 -> switch A (1G) : data (data subnet) + ipmi (ipmi subnet)
> traffic allowed
> b) eth2 -> switch B (10G) : data (data subnet) only traffic allowed
>
>
> precisely to be able to handle (by knowing what's happening and/or
> forcing eth2 install) a switch misconfiguration which would result to
> the conf2 above [and at the time I wrote my initial message, a BIOS boot
> order misconfiguration too, but I'm not so sure it has something to do
> with the MAC address ending up in the mac table]
>
> What I'm seeing on the console is basically, once loaded and having got
> an ip address on the BOOTIF nic ('Aquiring network address message'),
> genesis getting 2 ips from the dynamic range by DHCP, one for each nic
> after the 'Beginin node discovery process' message and the final MAC
> registration in the mac table beeing for the eth0 nic despite the
> fact that
>
> - discoverydata entry for tars-113 was cleared beforehand
> - switch-based discovery attributes where those of eth2 (switch B)
>
> So the node gets finally netbooted via eth0, which is not what I'd want.
>
> - lsdef tars-113 beforehand was :
>
> ---
> # <xCAT data object stanza file>
>
> tars-113:
> objtype=node
> addkcmdline=ipv6.disable=1 biosdevname=0 net.ifnames=0
> rd.driver.blacklist=nouveau nouveau.modeset=0
> arch=x86_64
> bmc=10.6.96.115
> bmcpassword=XXX
> bmcport=0
> bmcusername=XXXX
>
> chain=runcmd=bmcsetup,runimage=https://urldefense.proofpoint.com/v2/url?u=http-3A__xcat-2Dtars_install_sum-5Factivate_sum-5Factivate.tgz-2Cosimage-3Dcentos6.10-2Dx86-5F64-2Dnetboot-2Dcompute-2Dprod&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=GXZJILRYuh625D1P_w_8vxyNDAEGDWoFmPVwQ0NBUcY&m=R1A2OwgmdSDPRQP3MXYSuzUCIWGpAWk8bpM5NoHWq3Q&s=UJEv9keKLIZgJb82yOkFWl-SO8dvtOLom0qkSIJ_DtM&e=
> groups=tars-compute,tars-ipmi,tars,standard,b10
> ip=192.168.128.115
> mgt=ipmi
> os=centos6.10
> profile="">> provmethod=centos6.10-x86_64-netboot-compute-prod
> supportedarchs=x86,x86_64
> switch=b10b4.dc1.pasteur.fr
> switchport=8
>
> - lsdef afterwards is
>
> Object name: tars-113
> addkcmdline=ipv6.disable=1 biosdevname=0 net.ifnames=0
> rd.driver.blacklist=nouveau nouveau.modeset=0
> arch=x86_64
> bmc=10.6.96.115
> bmcpassword=XXXX
> bmcport=0
> bmcusername=XXXX
>
> chain=runcmd=bmcsetup,osimage=centos6.10-x86_64-netboot-compute-prod
> cpucount=12
> cputype=Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
> currstate=netboot centos6.10-x86_64-compute
> disksize=sda:256GB
> groups=tars-compute,tars-ipmi,tars,standard,b10
>
> initrd=xcat/osimage/centos6.10-x86_64-netboot-compute-prod/initrd-stateless.gz
> ip=192.168.128.115
>
> kcmdline=imgurl=https://urldefense.proofpoint.com/v2/url?u=http-3A__-21myipfn-21-3A80__install_netboot_centos6.10_x86-5F64_compute_prod_rootimg.gz&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=GXZJILRYuh625D1P_w_8vxyNDAEGDWoFmPVwQ0NBUcY&m=R1A2OwgmdSDPRQP3MXYSuzUCIWGpAWk8bpM5NoHWq3Q&s=yfck6JfRE_2gEtvh0FAJDU-dFXebaciN9sc4OvYC27Y&e=
> XCAT=!myipfn!:3001 NODE=tars-113 FC=0
> kernel=xcat/osimage/centos6.10-x86_64-netboot-compute-prod/kernel
> mac=0c:c4:7a:4d:85:a8|0c:c4:7a:58:c7:6a!*NOIP*
> memory=258373MB
> mgt=ipmi
> netboot=xnba
> os=centos6.10
> postbootscripts=otherpkgs
> profile="">> provmethod=centos6.10-x86_64-netboot-compute-prod
> serial=E162178X5A02118
> status=booted
> statustime=03-20-2019 17:55:02
> supportedarchs=x86,x86_64
> switch=b10b4.dc1.pasteur.fr
> switchport=8
>
> - neither tars-113-eth0 nor tars-113-eth2 (fully qualified or not) can
> be resolved
>
>
> Again, the actual need is not to have 2 nics on the same subnet but to
> have some way to choose which MAC will get discovered if so.
>
> Does BIOS PXE order makes any difference to what nic gets into the mac
> address at the end ?
> Which nic does genesis picks up between the 2 to put in the mac
> address ?
> Does a discovery happen on each nic ?
>
> It seems like genesis actually did the switch-based discovery but
> registered the first MAC it saw, thus the mismatch
>
> Thanks.
>
> --
> Thomas H.
>
>
> _______________________________________________
> xCAT-user mailing list
> xCAT-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
>
>
>
> _______________________________________________
> xCAT-user mailing list
> xCAT-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
_______________________________________________
xCAT-user mailing list
xCAT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcat-user
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
