[WINDOWS NLB] Unicast configuratie met multicast adres

[battler]

Vreemde situatie hier;

Twee IIS servers in een NLB Unicast configuratie en een SQL server waar ze mee praten.

[IIS001]
IP: 1
MAC: A

[IIS002]
IP: 2
MAC: B

[IIS NLB]
IP: 3
MAC: C

[SQL]
IP: 4
MAC: D

Nu is het vreemde dat wanneer de SQL server een packet stuurt naar de IIS001 hij wel IP:1 gebruikt maar een multicast mac adres daarbij verzint Ik kan dat MAC adres nergens vinden (dus ook niet het NLB adres). Groot nadeel van dit is dat al het SQL verkeer het netwerk rond verstuurd wordt.

Zijn er mensen met NLB kennis die kunnen aangeven of deze functionaliteit by design is?

[Dennism]

In unicast mode, Network Load Balancing induces switch flooding by design, so that packets sent to the cluster's virtual IP address go to all the cluster hosts. Switch flooding is part of the Network Load Balancing strategy of obtaining the best throughput for any specific load of client requests.
If, however, the cluster shares the switch with other (noncluster) computers or other clusters, switch flooding can add to the other computers' network overhead by including them in the flooding.

https://technet.microsoft.com/en-us/library/cc962174.aspx

Makkelijke manier om dit op te lossen is door alle cluster interfaces in een eigen vlan te zetten of als je switches het ondersteunen naar Multicast NLB of IGMP te gaan en de juiste configuratie door te voeren (niet alle switches kunnen dit)

zie o.a. https://www.vcloudnine.de...ing-switches-windows-nlb/

Of bijvoorbeeld over te stappen op een Loadbalancer als bijv. Kemp, F5 of Netscaler of iets in die richting.

[ Voor 27% gewijzigd door Dennism op 25-10-2016 13:43 ]

[F_J_K]

cf. verzoek een kleine titelaanpassing.

[Dennism]

F_J_K schreef op dinsdag 25 oktober 2016 @ 13:23:
cf. verzoek een kleine titelaanpassing.

Ik weet niet wat de vorige titel was, maar iets zegt me dat Multicast adres hier niet de juiste term is in deze

[battler]

Dennism schreef op dinsdag 25 oktober 2016 @ 12:51:
[...]


https://technet.microsoft.com/en-us/library/cc962174.aspx

Makkelijke manier om dit op te lossen is door alle cluster interfaces in een eigen vlan te zetten of als je switches het ondersteunen naar Multicast NLB of IGMP te gaan en de juiste configuratie door te voeren (niet alle switches kunnen dit)

zie o.a. https://www.vcloudnine.de...ing-switches-windows-nlb/

Of bijvoorbeeld over te stappen op een Loadbalancer als bijv. Kemp, F5 of Netscaler of iets in die richting.

Dit is als NLB is geconfigureerd met Multicast. Hier is NLB geconfigureerd als Unicast. Ik denk overigens dat ik het heb opgelost. Ik heb een aparte NIC aangemaakt voor NLB (conform Microsoft best practices) en opniew in het cluster gehangen. Nu weet ik niet of het opnieuw maken van het cluster of de extra separate nic heeft geholpen maar het probleem doet zich niet meer voor in de test omgeving. Bij het uitvoeren van deze change in de productie omgeving kan ik nakijken wat de exacte oplossing is.

[Dennism]

battler schreef op dinsdag 25 oktober 2016 @ 13:49:
[...]


Dit is als NLB is geconfigureerd met Multicast. Hier is NLB geconfigureerd als Unicast. Ik denk overigens dat ik het heb opgelost. Ik heb een aparte NIC aangemaakt voor NLB (conform Microsoft best practices) en opniew in het cluster gehangen. Nu weet ik niet of het opnieuw maken van het cluster of de extra separate nic heeft geholpen maar het probleem doet zich niet meer voor in de test omgeving. Bij het uitvoeren van deze change in de productie omgeving kan ik nakijken wat de exacte oplossing is.

Nee, dat gaat over NLB in Unicast, de oplossing is NLB in Multicast, IGMP, of Unicast met een eigen VLAN.

zie dit stuk uit die link:

The explanation

To make the long story short: It was the Windows NLB, more precisely the unicast mode which was used to run the NLB. Using unicast for NLB is really ugly. The mac address of the cluster adapter, the adapter which is used for cluster communication, is mapped to all cluster members. Due this the switch is not able to add a valid CAM table entry for this mac address. It appears on all ports to which NICs are connected, that are used for NLB. The switch thinks “Fuck you” and blows the packets out on all ports. This ensures that all NLB nodes receives the traffic. But this causes also flooding the network with traffic for the Windows NLB nodes. And this is exactly what the customer and I saw today. Normally the NLB cluster interfaces comes into their own VLAN, so the flooded packets do not leave the VLAN. But the customer used NLB inside their default VLAN… Bad idea. But hey, I didn’t designed it.

Als jouw nieuwe nic's in hun eigen vlan hangen zal dat trouwens het issue inderdaad moeten oplossen.

[battler]

Dennism schreef op dinsdag 25 oktober 2016 @ 13:52:
[...]


Nee, dat gaat over NLB in Unicast, de oplossing is NLB in Multicast, IGMP, of Unicast met een eigen VLAN.

zie dit stuk uit die link:


[...]

Dan mogen we hier van geluk spreken dat het gaat om virtuele machines. Vanuit switch perspectief blijft het MAC adres op 1 poort. Desalniettemin is het natuurlijk enorm smerig. Bedankt voor je toelichting!

[Dennism]

battler schreef op dinsdag 25 oktober 2016 @ 13:55:
[...]


Dan mogen we hier van geluk spreken dat het gaat om virtuele machines. Vanuit switch perspectief blijft het MAC adres op 1 poort. Desalniettemin is het natuurlijk enorm smerig. Bedankt voor je toelichting!

Als dit op vSphere is neem dan even dit artikel door, daar er bij vSphere ook wat haken en ogen aan NLB unicast zitten, en er wat configuratie aanpassingen nodig zijn voor goede werking, denk er wel aan dat als je het gebruikt of wil gaan gebruiken dat vMotion niet supported is met NLB Unicast.

https://kb.vmware.com/sel...KB_1_1&externalId=1006778

[battler]

Dennism schreef op dinsdag 25 oktober 2016 @ 14:01:
[...]


Als dit op vSphere is neem dan even dit artikel door, daar er bij vSphere ook wat haken en ogen aan NLB unicast zitten, en er wat configuratie aanpassingen nodig zijn voor goede werking, denk er wel aan dat als je het gebruikt of wil gaan gebruiken dat vMotion niet supported is met NLB Unicast.

https://kb.vmware.com/sel...KB_1_1&externalId=1006778

Hyper-v omgeving, had het artikel inderdaad gelezen. In de test omgeving draaide alle IIS servers op 1 host. In de prod. omgeving is het verspreid over meerdere hosts, daar gaat unicast sowieso niet werken dus.

[Dennism]

battler schreef op dinsdag 25 oktober 2016 @ 14:09:
[...]


Hyper-v omgeving, had het artikel inderdaad gelezen. In de test omgeving draaide alle IIS servers op 1 host. In de prod. omgeving is het verspreid over meerdere hosts, daar gaat unicast sowieso niet werken dus.

Op Hyper-V durf ik het niet te zeggen, geen ervaring met NLB en Hyper-V, op vSphere kan het op zich wel Unicast over meerdere hosts, maar netjes is het niet.

Ik weet niet hoeveel bandbreedte dat Cluster verstookt, maar als het minder is dan 20mbit continu zou je bijv. eens de gratis versie van de Kemp Loadbalancer (of Netscaler heeft er ook een geloof ik) kunnen proberen. In mijn optiek vaak een stuk netter dan NLB te gebruiken. Bij hoger bandbreedte gebruik zal je echter naar een betaalde versie toe moeten.

[Jazzy]

Hier nog een stem voor een load balancer. Niet alleen omdat NLB smerig is maar ook omdat je dan fatsoenlijke health checks kunt uitvoeren.

[Meekoh]

Tip 1:
Gebruik geen NLB.
Heb een tijd met Microsoft Engineers gewerkt aan een bepaald cloud product van ze. Deze gebruikte eerst ook NLB, daar kwam zoveel gezeik uit dat zelfs zij er vanaf gestapt zijn.

Enneh met Jazzy ^^

Edit:
Tip 2
kijk eens naar een echte Loadbalancer (F5, netscaler etc.) of als je daar geen geld aan wilt uitgeven een extra Server met IIS + ARR.

[ Voor 24% gewijzigd door Meekoh op 25-10-2016 15:11 ]

[Question Mark]

Met IIS + ARR ga je een extra spof introduceren, niet handig in een HA opzet.

Kies dan idd. voor een "echte" loadbalancer(s), die zijn nl. in een HA opzet te implementeren.

[battler]

Bedankt voor al het advies. Uiteraard is NLB en de manier van implementatie niet mijn keuze daar is een gespecialiseerd bedrijf voor ingehuurd.

[Meekoh]

Question Mark schreef op dinsdag 25 oktober 2016 @ 15:29:
Met IIS + ARR ga je een extra spof introduceren, niet handig in een HA opzet.

Kies dan idd. voor een "echte" loadbalancer(s), die zijn nl. in een HA opzet te implementeren.

True, was even vergeten dat wij nog F5's voor ARR/WFF hebben zitten.

Maargoed, verder heb ik de afgelopen 8 jaar nog NOOIT een probleemloos werkende NLB implementatie gezien. Met name bij switches die "onthouden" waar het NLB mac uithangt. In dat geval bij MS waren er Dell switches in gebruik die een feature moeten hebben om dit uit te zetten....Uitgezet....Onthouden die switches het nog steeds Toen switchde MS naar F5's

[ Voor 33% gewijzigd door Meekoh op 25-10-2016 16:48 ]

[battler]

Dennism schreef op dinsdag 25 oktober 2016 @ 13:52:
[...]


Nee, dat gaat over NLB in Unicast, de oplossing is NLB in Multicast, IGMP, of Unicast met een eigen VLAN.

zie dit stuk uit die link:


[...]


Als jouw nieuwe nic's in hun eigen vlan hangen zal dat trouwens het issue inderdaad moeten oplossen.

De reden hiervoor is me nu duidelijk:

"
Unicast Mode

Here are some notes about the use of NLB in Unicast mode:
In Unicast mode, NLB replaces the actual Media Access Control (MAC) address of each server in the cluster with a common NLB MAC address. When all of the servers in the cluster have the same MAC address, all of the packets that are forwarded to that address are sent to all of the members in the cluster. The NLB creates a fictitious MAC address and assigns it to each server in the NLB cluster. The NLB assigns each NLB server a different fictitious MAC address, based on the host ID of the member. This address appears in the Ethernet frame header.

The MAC address is used in the Address Resolution Protocol (ARP) header, not the Ethernet header. The switch uses the MAC address in the Ethernet header, not the ARP header. This causes an issue when a packet is sent to the NLB cluster with the destination MAC address as the cluster MAC address 00-bf-ac-10-00-01. The switch views the Content Addressable Memory (CAM) table for the MAC address 00-bf-ac-10-00-01, and since there is no port registered with the NLB cluster MAC address 00-bf-ac-10-00-01, the frame is delivered to all of the switch ports. This introduces unicast flooding. In order to avoid flooding, Cisco recommends that you use a dedicated VLAN for NLB so that the flooding is constrained."

http://www.cisco.com/c/en...995-configure-nlb-00.html

Ik heb dit getest in Windows 2012. En daar blijkt dit inderdaad nog zo te zijn.

[Dennism]

Meekoh schreef op dinsdag 25 oktober 2016 @ 16:42:
[...]

True, was even vergeten dat wij nog F5's voor ARR/WFF hebben zitten.

Maargoed, verder heb ik de afgelopen 8 jaar nog NOOIT een probleemloos werkende NLB implementatie gezien. Met name bij switches die "onthouden" waar het NLB mac uithangt. In dat geval bij MS waren er Dell switches in gebruik die een feature moeten hebben om dit uit te zetten....Uitgezet....Onthouden die switches het nog steeds Toen switchde MS naar F5's

Ik heb wel een paar probleemloze implementaties gezien, maar dan wel op zeer kleine schaal (paar nodes maximaal), en altijd met eigen vlan e.d.

Neemt niet weg dat de kans op vage issues zeker met bepaalde switches gewoon zeer aanwezig is wanneer er een andere dan de meest standaard implementatie gebruikt wordt.

Kijken naar afhankelijk van het budget naar bijv een Kemp, F5 of Netscaler valt mijn inziens altijd te zien als de betere oplossing, tenzij je echt gebonden bent aan een 0 budget oplossing en de gratis varianten van bijv. Kemp of Netscaler echt niet voldoen qua te loadbalancen bandbreedte.

[battler]

Ik wil een eerlijk verhaal kunnen vertellen over het probleem, de oorzaak en de mogelijke oplossingen. Een smerige korte termijn oplossing om de unknown unicast te mitigeren is het defineren van het cluster MAC adres (statisch in de switch) op meerdere poorten.

https://kb.vmware.com/sel...playKC&externalId=1006525

[Dennism]

battler schreef op woensdag 26 oktober 2016 @ 11:18:
Ik wil een eerlijk verhaal kunnen vertellen over het probleem, de oorzaak en de mogelijke oplossingen. Een smerige korte termijn oplossing om de unknown unicast te mitigeren is het defineren van het cluster MAC adres (statisch in de switch) op meerdere poorten.

https://kb.vmware.com/sel...playKC&externalId=1006525

Is dat niet alleen bij multicast mode, ik meen me iig iets te herinneren waarbij me dat bij staat.

Voor unicast is voor zover ik weet de meest simpele oplossing als je NLB wil blijven gebruiken gewoon een apart VLAN maken op de aanwezige (virtuele) switches, daar de Cluster nic's in hangen en je bent af van het Flood probleem (is quick en dirty, want in de basis is het flood issue er nog steeds, maar omdat enkel cluster nic's in dat vlan hangen heeft de rest er geen last meer van want alleen de cluster nic's worden dan nog geflood).

[ Voor 4% gewijzigd door Dennism op 26-10-2016 11:36 ]

[battler]

Dennism schreef op woensdag 26 oktober 2016 @ 11:34:
[...]


Is dat niet alleen bij multicast mode, ik meen me iig iets te herinneren waarbij me dat bij staat.

Voor unicast is voor zover ik weet de meest simpele oplossing als je NLB wil blijven gebruiken gewoon een apart VLAN maken op de aanwezige (virtuele) switches, daar de Cluster nic's in hangen en je bent af van het Flood probleem (is quick en dirty, want in de basis is het flood issue er nog steeds, maar omdat enkel cluster nic's in dat vlan hangen heeft de rest er geen last meer van want alleen de cluster nic's worden dan nog geflood).

Dat kan best kloppen want ik weet niet waarom een switch hetzelfde mac adres op verschillende poorten zou accepteren. Voor een multicast adres kan ik me dat wel voorstellen, laat dit nou net het "probleem" zijn wat ik heb opgelost