Ceritanya ada case menarik selama pekerjaan kali ini. Saat ini lagi ada kerjaan implementasi UCS dengan 2 buah Spine dan 2 buah Leaf (spine dan leaf menggunakan nexus 5k).

Saat ini sudah berjalan dengan baik, dari blade server menuju ke network sesama dan luar. Kondisi saat ini tiap blade server untuk 1 network itu mempunyai 2 adapter vnic dari UCS yang diarahkan ke FI yang berbeda dengan tujuan dibuat loadbalance.

Jadi tiap blade server itu dia punya 2 adapter, masing2 adapter koneksi mengarah ke ke FI (Fabric Interconnect) A dan FI B dengan mode fail over di sisi UCSnya.

Untuk yang didalem blade server os-nya memakai baremetal windows ada pula yg menggunakan ESXI. Sudah terset NIC teaming / bonding dengan native vlan, jadi komunikasi sudah berjalan dengan baik hanya menggunakan 1 FI saja.

Problemnya adalah meskipun sudah di set teaming/bonding dan jg sudah ditambahkan konfigurasi di sisi ucs supaya bisa lewat 2 adapter vnic. Namun ketika di cek sisi gateway (kedua leaf). Kedua leaf menampilkan arp yang berbeda, arp dari blade server cuman kedetek di sisi leaf 1 saja, yang harusnya menurut pemahaman untuk load balance sendiri untuk arp terdetek di leaf 1 dan leaf 2.

Note: Akses dr Leaf ke FI menggunakan port-channel biasa, bukan menggunakan VPC seperti best-practice yang dianjurkan.

Pada intinya apabila traffic itu melewati leaf B itu tidak bisa, tapi kalau lewat leaf A itu baru bisa. Maka untuk temporary workaround yang ada itu dirubah untuk lewat ke leaf A semuanya seperti berikut (sebelumnya modelnya A B, B A, A B, BA).

Untungnya, di UCS sendiri ada mode fail over.. Jadi ketika Leaf A mati bisa langsung take over ke Leaf B. Jadi posisi sekarang itu tidak load balance antar Leaf A dan Leaf B :((.

Dan ada anomali lain yaitu terdapat log di sisi leaf 1 dan leaf 2 seperti berikut…

2016 Dec 23 22:12:14 Leaf B %OSPF-4-SYSLOG_SL_MSG_WARNING: SYSLOG-4-SL_MSG_WARNING: message repeated 2 times in last 10 sec
2016 Dec 23 22:12:20 Leaf B %OSPF-4-SOURCE_ERR:  ospf-200 [5290] (VRF_SERVICE) Bad source address 1.1.1.1 – ours on Vlan101
2016 Dec 23 22:12:22 Leaf B %OSPF-4-DUPRID:  ospf-200 [5290] (VRF_SERVICELAIN) Router 2.2.2.2 on interface Vlan302 is using our routerid, packet dropped
2016 Dec 23 22:12:24 Leaf B %OSPF-4-SYSLOG_SL_MSG_WARNING: SYSLOG-4-SL_MSG_WARNING: message repeated 2 times in last 10 sec
2016 Dec 23 22:12:32 Leaf B %OSPF-4-SOURCE_ERR:  ospf-200 [5290] (VRF_SERVICE) Bad source address 2.2.2.2 – ours on Vlan201
2016 Dec 23 22:12:33 Leaf B %OSPF-4-DUPRID:  ospf-200 [5290] (VRF_SERVICELAIN) Router 1.1.1.1 on interface Vlan302 is using our routerid, packet dropped
2016 Dec 23 22:12:34 Leaf B %OSPF-4-SYSLOG_SL_MSG_WARNING: SYSLOG-4-SL_MSG_WARNING: message repeated 2 times in last 10 sec
Leaf B#

Nampaknya terdapat duplicate router id diantara kedua Leaf ini, namun kan kedua leaf di set sebagai cluster? Apakah memang kurang cocok dengan port channel? ahh suhuu pemahaman saya belum sampai sana…

Setelah melewati melompati masa sulit itu, bertemu lagi dengan masa sulit lain yaitu terdapat issue dimana vCenter tidak bisa add host ESXI ke dalam Cluster di vCenter. Untuk vCenter sendiri terinstall diatas baremetal Windows Server 2012 dan juga issue ini muncul ketika ditambahkan NIC Teaming di Windows server itu sendiri. Padahal status NIC di windows server enabled. Berikut alarm yang sempat tercapture, saya ambil dari history alarm di vCenternya.

A general system error occured: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

atau ada yang lain.

Cannot contact the spesified host (xxx.xxx.xxx.xxx). The host may not be available on the network, a network configuration problem may exist, or the management services on this host may not be responding.

Sempat hopeless, namun setelah ditelusuri ternyata ada miss configured attribut / attribut yang gak sesuai. Intinya perlu dilakukan perubahan pada mode NIC Teaming di windows server supaya bisa cocok dengan load balance versi UCS sendiri.

Kalau di windows itu ada beberapa attribut dan mode yang musti di perhatikan. Diantaranya saya copas langsung dari website nya.

Teaming Mode

Static Teaming requires configuration on the switch and the computer to identify which links form the team. Because this is a statically configured solution.  This is a switch dependent mode of NIC teaming.

Switch Independent mode allows you to distribute the NICs in your team across numerous Network Switches in your environment.

LACP provides the Link Aggregation and allows for the expansion and reduction of the NIC team.  This is a switch independent mode of NIC teaming.

Load Balancing Mode

Load balancing mode: your choices are either Address Hash, or Hyper-V Port.  Address Hash is  how you configure your team to load balance network traffic between the NICs in the team.  Hyper-V Port load balancing will load balance your traffic by VM.  With Hyper-V Port, the good news is that each VM will transact on a separate NIC, but the down side is that each VM will only transact over a single NIC.  If you have multiple virtual NICs in your VM and they are teamed, the Hyper-V Port may be the best choice.   For most configurations, I expect that the Address Hash will be your best choice to allow your VM to still access the network in case the NIC the VM is utilizing fails.  Remember that with Hyper-V Port the failure of the NIC the VM is utilizing disrupts communication between the VM and the network.  Address Hash won’t have this problem.

Standby Adapter

This allows you to define a Standby Adapter for the team.  Take note that you can only define one Standby Adapter, but you can ensure that your teamed bandwidth is available even if a NIC in your team fails.

Ada referensi dari Cisco sendiri untuk interoperability antara Cisco UCS ke Vmware ESXI yang di windows server 2012 untuk NIC Teaming cuman saya lupa link nya dimana.

Sebelumnya saya menggunakan mode :

Teaming Mode : Switch Independent
Load Balancing : Addressh Hash

Dengan menggunakan konfigurasi tersebut bisa aktif mode teamingnya, namun untuk di vCenter ada issue ketika akan menambahkan host ke cluster vCenter, muncul error seperti yang saya sebutkan sebelumnya.

Akhirnya saya coba-coba rubah mode nya dan akhirnya bisa menggunakan mode berikut, di sisi vCenter bisa menambahkan host yang menggunakan teaming ke cluster. Dari saya sendiri kurang paham sebetulnya untuk interoperability ini. Dan juga masih ada PR issue yang saya sebutkan pertama kali diatas.