PowerConnect VRRP issues

[ipsec]

Wij hebben voor een nieuw platform 2 DELL PowerConnect 8024F switches (non-stacked) in opbouw staan in ons datacenter als core switches. Beide switches draaien dezelfde firmware (meest recent):

code:

unit image1      image2      current-active next-active
---- ----------- ----------- -------------- --------------
1    5.1.10.1    5.1.10.1    image1         image1

Op deze switches heb ik VRRP als volgt geimplementeerd:
- We hebben een /29 subnet met onze netwerkleverancier, waarvan het VRRP adres aan de kant van de netwerkleverancier ingesteld is als default gateway voor 0.0.0.0/0. Hierop hebben wij ook een VRRP aan onze kant geconfigureerd staan. De config is als volgt:

CORE-01#show running-config interface vlan 900

code:

interface vlan 900 2
ip address xxx.xxx.xxx.188 255.255.255.248
no ip proxy-arp
ip igmp
vrrp 150
vrrp 150 mode
vrrp 150 description UPLINK
vrrp 150 ip xxx.xxx.xxx.190
vrrp 150 track interface Vl900 decrement 100
vrrp 150 priority 200
vrrp 150 timers advertise 10
vrrp 150 accept-mode
vrrp 150 preempt delay 900

CORE-02#show running-config interface vlan 900

code:

interface vlan 900 2
ip address xxx.xxx.xxx.189 255.255.255.248
no ip proxy-arp
ip igmp
vrrp 150
vrrp 150 mode
vrrp 150 description UPLINK
vrrp 150 ip xxx.xxx.xxx.190
vrrp 150 track interface Vl900 decrement 100
vrrp 150 priority 150
vrrp 150 timers advertise 10
vrrp 150 accept-mode
vrrp 150 preempt delay 900

Achter dit VLAN, hebben wij dan nóg een VLAN gemaakt, VLAN 955, waarin we een /24 hebben staan die als test dient. Onze netwerkleverancier heeft de route voor xxx.xxx.xxx.0/24 naar bovenstaand VRRP adres staan. De config van het 2e VRRP adres is als volgt:

CORE-01#show running-config interface vlan 955

code:

interface vlan 955 3
ip address xxx.xxx.xxx.252 255.255.255.0
no ip proxy-arp
ip igmp
vrrp 222
vrrp 222 mode
vrrp 222 description XXXXXX
vrrp 222 ip xxx.xxx.xxx.254
vrrp 222 track interface Vl955 decrement 100
vrrp 222 priority 200
vrrp 222 accept-mode
vrrp 222 preempt delay 900
exit

CORE-02#show running-config interface vlan 955

code:

interface vlan 955 3
ip address xxx.xxx.xxx.253 255.255.255.0
no ip proxy-arp
ip igmp
vrrp 222
vrrp 222 mode
vrrp 222 description xxxxx
vrrp 222 ip xxx.xxx.xxx.254
vrrp 222 track interface Vl955 decrement 100
vrrp 222 priority 150
vrrp 222 timers learn
vrrp 222 accept-mode
vrrp 222 preempt delay 900
exit

Nu heb ik in VLAN 955 een test VM opgezet, en hierbij een publiek IP adres gegeven in de xxx.xxx.xxx.0/24 range. Internet connectiviteit werkt verder prima. Althans, dat denk je, totdat je over een langere tijd een ping gaat openzetten naar de default gateway en Google:

code:

ping -t xxx.xxx.xxx.254
Ping statistics for xxx.xxx.xxx.254:
Packets: Sent = 663, Received = 517, Lost = 146 (22% loss)
Approximate rount trip times in milli-seconds:
Minimum = 0ms, Maximum = 120ms, average = 2ms

Dit is nog een korte tijd, maar over het weekend hebben we gemiddeld een packet loss van 25%. Om de 5 pings lijkt er een packet gedropped te worden, en daarna komt hij weer terug. Dit is dus vanuit de VM in VLAN 955.

Dit zijn de ping resultaten naar Google:

code:

ping -t 8.8.8.8
Ping statistics for 8.8.8.8:
Packets: Sent = 208269, Received = 194749, Lost = 13520 (6% loss)
Approximate rount trip times in milli-seconds:
Minimum = 5ms, Maximum = 39ms, average = 5ms

Om te beginnen heb ik het meeste zorgen over de packetloss richting de default gateway. Ik heb zo ongeveer alles geprobeerd (aan/uitzetten van IGMP snooping, proxy-arp uitzetten, dynamic arp updates aanzetten en weer uitzetten).

Wanneer ik echter op bijvoorbeeld de CORE-01 en de CORE-02 de complete VRRP configuratie van VLAN 955 weghaal, en bijvoorbeeld op de CORE-01 ip VLAN 955 het IP adres van de default gateway rechtstreeks configureer dan heb ik 0,0 packet loss naar de default gateway. Ik vermoed dus dat het ergens in de configuratie of implementatie van VRRP zit..

De VM draait op Citrix XenServer, heeft vanuit het blade chassis een dubbele 10Gb glas verbinding richting 2 (stacked) switches, waarvandaan dan weer een 10Gb glas verbinding ligt richting de core switches.

De core switches hebben allebei een eigen 10Gb uplink richting onze netwerkleverancier.

Ik zie het even niet meer. Wellicht heeft iemand van jullie ervaring met deze switches en/of VRRP.

[ Voor 2% gewijzigd door ipsec op 04-07-2016 12:18 . Reden: Opmaak... ]

[Tijntje]

Ik kan je helaas niet verder helpen maar zou je adviseren een ticket bij Dell te openen via http://www.dell.com/suppo...cal-support-phone-numbers

[winux]

Kun je debugging op VRRP aanzetten, en kijken wat er om de 5 pakketten gebeurd?
Lijkt erop dat hij continue staat te wisselen tussen je actieve en passieve gateway.

Probeer ook eens de volgende regels weg te halen op beide switches, puur om te kijken of de normale functionaliteit (verkeer verschepen, zonder packetloss) werkt.

vrrp 222 track interface Vl955 decrement 100
vrrp 150 track interface Vl900 decrement 100

[ Voor 43% gewijzigd door winux op 04-07-2016 12:23 ]

[ipsec]

winux schreef op maandag 04 juli 2016 @ 12:18:
Kun je debugging op VRRP aanzetten, en kijken wat er om de 5 pakketten gebeurd?
Lijkt erop dat hij continue staat te wisselen tussen je actieve en passieve gateway.

Probeer ook eens de volgende regels weg te halen op beide switches, puur om te kijken of de normale functionaliteit (verkeer verschepen, zonder packetloss) werkt.

vrrp 222 track interface Vl955 decrement 100
vrrp 150 track interface Vl900 decrement 100

Ik heb de debugging van VRRP aangezet, en vooralsnog zie ik enkel logs voorbij komen dat er VRRP pakketten binnenkomen en uitgaan over verschillende interfaces. In principe geen errors, wel andere VRID's maar dat is logisch. Die mogen namelijk niet hetzelfde zijn op één VLAN.

Op VLAN 900 bijvoorbeeld zie ik de VRID's voorbij komen die onze netwerkleverancier gebruikt. Aan mijn "achterkant" zie ik netjes de VRID's voorbij komen die we zelf geconfigureerd hebben staan. Verder geen errors.

[ Voor 27% gewijzigd door ipsec op 04-07-2016 12:39 ]

[winux]

SuperKevin schreef op maandag 04 juli 2016 @ 12:29:
[...]


Ik heb de debugging van VRRP aangezet, en vooralsnog zie ik enkel logs voorbij komen dat er VRRP pakketten binnenkomen en uitgaan over verschillende interfaces. In principe geen errors, wel andere VRID's maar dat is logisch. Die mogen namelijk niet hetzelfde zijn op één VLAN.

Op VLAN 900 bijvoorbeeld zie ik de VRID's voorbij komen die onze netwerkleverancier gebruikt. Aan mijn "achterkant" zie ik netjes de VRID's voorbij komen die we zelf geconfigureerd hebben staan. Verder geen errors.

Error's zou ik ook niet verwachten, ik vermoed, naar aanleiding van het beeld wat je schetst, dat de VRRP instance continue staan te wisselen van actief naar standby. Dus dat je berichten krijg dat CORE-01 nu active is en paar seconden later dat CORE-02 active is.
Vandaar mijn advies om de track configuraties even weg te laten om te kijken of je verkeer dan wel rustig blijft, zonder uitval.

[ Voor 58% gewijzigd door winux op 04-07-2016 12:43 ]

[ipsec]

winux schreef op maandag 04 juli 2016 @ 12:39:
[...]


Error's zou ik ook niet verwachten, ik vermoed, naar aanleiding van het beeld wat je schetst, dat de VRRP instance continue staan te wisselen van actief naar standby. Dus dat je berichten krijg dat CORE-01 nu active is en paar seconden later dat CORE-02 active is.
Vandaar mijn advies om de track configuraties even weg te laten om te kijken of je verkeer dan wel rustig blijft, zonder uitval.

Helaas niet....

[winux]

Kom nog een stukje tegen op https://www.force10networ..._TroubleshootingVRRP.aspx

Symptom: Packet Loss When Pinging the Virtual IP Address

When pinging the virtual IP address of a VRRP group, packet loss is experienced.
Troubleshooting Steps
Force10 does not support 100% pings to VRRP virtual addresses. The reasons are:
Pings to the virtual IP address are forwarded to the CPU RP2 on the Route Processor Module (RPM) using the network entry in the line card CAM. By design, such RP2-bound packets are rate-limited to protect the CPU from DOS attacks and other unwanted packets.

The E-Series supports hardware and software throttling to limit packets destined to any of the RPM CPUs -- CP, RP1, or RP2. Such throttling ensures that one packet type does not consume an excessive number of CPU cycles. The throttling mechanism works by placing packets in one of several predetermined queues, which have inherent rate limits.

Weet niet of dat van toepassing is?

[ipsec]

winux schreef op maandag 04 juli 2016 @ 13:00:
Kom nog een stukje tegen op https://www.force10networ..._TroubleshootingVRRP.aspx


[...]


Weet niet of dat van toepassing is?

Zou inderdaad kunnen, maar volgens mij draaien deze switches geen FTOS.
En daarbij komt dan natuurlijk dat mijn pings naar Google ook packetloss ervaren. Niet gelijktijdig overigens.

[winux]

Kun je de uitkomst van show VRRP, van zowel een primaire als secondary switch eens posten?

[ Voor 33% gewijzigd door winux op 04-07-2016 13:18 ]

[ipsec]

winux schreef op maandag 04 juli 2016 @ 13:17:
Kun je de uitkomst van show VRRP, van zowel een primaire als secondary switch eens posten?

CORE-01#show vrrp

code:

Admin Mode..................................... Enable
Router Checksum Errors......................... 0
Router Version Errors.......................... 0
Router VRID Errors............................. 268141
Vlan 900 - Group 150
Primary IP Address............................. xxx.xxx.xxx.190
VMAC Address................................... 0000.xxxx.xxxx
Authentication Type............................ None
Priority....................................... 200
Configured Priority............................ 200
Advertisement Interval (secs).................. 10
Accept Mode.................................... Enable
Pre-empt Mode.................................. Enable
Pre-empt delay................................. 900
Administrative Mode............................ Enable
State.......................................... Master
Timers Learn mode.............................. Disable
Description.................................... UPLINK
Track Interface................................ Vl900
Track Interface State.......................... Up
Track Interface Decrement Priority............. 10
No routes are tracked for this vrid and interface combination [b]<-- Komt door het weghalen van de decrement regels[/b]
--More-- or (q)uit
Vlan 955 - Group 222
Primary IP Address............................. xxx.xxx.xxx.254
VMAC Address................................... 0000.xxxx.xxxx
Authentication Type............................ None
Priority....................................... 200
Configured Priority............................ 200
Advertisement Interval (secs).................. 1
Accept Mode.................................... Enable
Pre-empt Mode.................................. Enable
Pre-empt delay................................. 900
Administrative Mode............................ Enable
State.......................................... Master
Timers Learn mode.............................. Disable
Description.................................... xxxx
Track Interface................................ Vl955
Track Interface State.......................... Up
Track Interface Decrement Priority............. 10
No routes are tracked for this vrid and interface combination [b]<-- Komt door het weghalen van de decrement regels[/b]

CORE-02#show vrrp

code:

Admin Mode..................................... Enable
Router Checksum Errors......................... 0
Router Version Errors.......................... 0
Router VRID Errors............................. 261296
Vlan 900 - Group 150
Primary IP Address............................. xxx.xxx.xxx.190
VMAC Address................................... 0000.xxxx.xxxx
Authentication Type............................ None
Priority....................................... 150
Configured Priority............................ 150
Advertisement Interval (secs).................. 10
Accept Mode.................................... Enable
Pre-empt Mode.................................. Enable
Pre-empt delay................................. 900
Administrative Mode............................ Enable
State.......................................... Backup
Timers Learn mode.............................. Enable
Description.................................... UPLINK
Track Interface................................ Vl900
Track Interface State.......................... Up
Track Interface Decrement Priority............. 10
No routes are tracked for this vrid and interface combination [b]<-- Komt door het weghalen van de decrement regels[/b]
--More-- or (q)uit
Vlan 955 - Group 222
Primary IP Address............................. xxx.xxx.xxx.254
VMAC Address................................... 0000.xxxx.xxxx
Authentication Type............................ None
Priority....................................... 150
Configured Priority............................ 150
Advertisement Interval (secs).................. 1
Accept Mode.................................... Enable
Pre-empt Mode.................................. Enable
Pre-empt delay................................. 900
Administrative Mode............................ Enable
State.......................................... Backup
Timers Learn mode.............................. Enable
Description.................................... xxxx
Track Interface................................ Vl955
Track Interface State.......................... Up
Track Interface Decrement Priority............. 10
No routes are tracked for this vrid and interface combination [b]<-- Komt door het weghalen van de decrement regels[/b]

[winux]

CORE-01 Router VRID Errors............................. 268141
CORE-02 Router VRID Errors............................. 261296

Dit is wat mijn als eerste opvalt. Probeer deze counters eens te resetten en kijk na 10-15 minuten nog eens om te zien of de counters boven 0 staan.

[ipsec]

winux schreef op maandag 04 juli 2016 @ 13:24:
CORE-01 Router VRID Errors............................. 268141
CORE-02 Router VRID Errors............................. 261296

Dit is wat mijn als eerste opvalt. Probeer deze counters eens te resetten en kijk na 10-15 minuten nog eens om te zien of de counters boven 0 staan.

Dat is mij eerder ook al opgevallen inderdaad. Resetten gaat niet zonder de VRRP config opnieuw aan te maken, maar ik zie zo al dat de counters oplopen. Nogmaals het command en ik krijg een hogere counter voor beide VRRP adressen.

Op VLAN 900 kan ik dat nog begrijpen, want daar zie ik natuurlijk ook het VRRP traffic van onze netwerkleverancier.

[Bigs]

We hebben een /29 subnet met onze netwerkleverancier, waarvan het VRRP adres aan de kant van de netwerkleverancier ingesteld is als default gateway voor 0.0.0.0/0. Hierop hebben wij ook een VRRP aan onze kant geconfigureerd staan.

Bedoel je nu dat jullie allebei in datzelfde subnet/segment VRRP aan het doen zijn? Dan is het wel belangrijk om allebei een afwijkend router ID te kiezen. Ik zie dat nu niet terug in je configuratie. Ik zou tevens authenticatie inschakelen.

[chaoscontrol]

SuperKevin schreef op maandag 04 juli 2016 @ 13:02:
[...]


Zou inderdaad kunnen, maar volgens mij draaien deze switches geen FTOS.
En daarbij komt dan natuurlijk dat mijn pings naar Google ook packetloss ervaren. Niet gelijktijdig overigens.

Google geeft overal wel af en toe een pingloss, dat kan los van je vrrp probleem staan.

[ipsec]

Bigs schreef op maandag 04 juli 2016 @ 13:39:
[...]


Bedoel je nu dat jullie allebei in datzelfde subnet/segment VRRP aan het doen zijn? Dan is het wel belangrijk om allebei een afwijkend router ID te kiezen. Ik zie dat nu niet terug in je configuratie. Ik zou tevens authenticatie inschakelen.

Op zowel CORE-01 als CORE-02 hebben alleen de uplink poorten op CORE-01 en CORE-02 VRRP het /29 met de netwerkleverancier. Daar leeft dus aan onze kant én aan hun kant VRRP en dat zie ik wel voorbij komen (ID 210).

Zij gebruiken daar VRRP ID 210, en wij 150. De uplink poorten zitten untagged in VLAN 900 (verder géén andere interfaces aan onze kant). Aan de "achterkant" hebben wij verder alleen VRRP op VLAN 955, welke tagged op alle andere poorten (2 t/m 8 zijn op dit moment in gebruik, dit VLAN moet in de rest van ons netwerk namelijk wel gebruikt kunnen worden) van de core-01 en de core-02. Aan onze "achterkant" wordt VRRP ID 222 als enige gebruikt, verder nergens aan onze "achterkant".

[ Voor 5% gewijzigd door ipsec op 04-07-2016 13:46 ]

[ipsec]

chaoscontrol schreef op maandag 04 juli 2016 @ 13:41:
[...]

Google geeft overal wel af en toe een pingloss, dat kan los van je vrrp probleem staan.

Klopt, mee eens, maar ik vind 6% over een weekend wel aardig wat...
Alhoewel ik nu met een ping naar tweakers.net al géén packetloss heb (tot nu toe 0 over 100 verstuurde pakketten, waar bij Google 6 van de 100 al gemakkelijk gehaald kan worden).

[ Voor 24% gewijzigd door ipsec op 04-07-2016 13:45 ]

[winux]

SuperKevin schreef op maandag 04 juli 2016 @ 13:29:
[...]


Dat is mij eerder ook al opgevallen inderdaad. Resetten gaat niet zonder de VRRP config opnieuw aan te maken, maar ik zie zo al dat de counters oplopen. Nogmaals het command en ik krijg een hogere counter voor beide VRRP adressen.

Op VLAN 900 kan ik dat nog begrijpen, want daar zie ik natuurlijk ook het VRRP traffic van onze netwerkleverancier.

Zou toch dan zoeken naar een log of debug waarin je de errors terug krijg, want daar ligt je grondslag van het probleem en dus ook je oplossing uiteindelijk.

[ipsec]

winux schreef op maandag 04 juli 2016 @ 13:57:
[...]


Zou toch dan zoeken naar een log of debug waarin je de errors terug krijg, want daar ligt je grondslag van het probleem en dus ook je oplossing uiteindelijk.

Dit zeggen de debug logs:

code:

VRRP Pkt RX - Intf:0/4/2(275,Vl900),SrcIP:xxx.xxx.xxx.187,DestIp:224.0.0.18,Version:2,PktType:1,VrId: 210,Priority: 150,Count IP Addrs:1,AuthType:0,Adver int:1,AuthData :,Addresses:xxx.xxx.xxx.185 
VRRP Pkt TX - Intf: 0/4/3(276,Vl955),SrcIP:xxx.xxx.xxx.252,DestIp :224.0.0.18,Version:2,PktType:1,VrId:222,Priority:200,Count IP Addrs:1,AuthType:0,Adver int:1,AuthData :,Addresses:xxx.xxx.xxx.254 
VRRP Pkt TX - Intf: 0/4/2(275,Vl900),SrcIP:xxx.xxx.xxx.188,DestIp :224.0.0.18,Version:2,PktType:1,VrId:150,Priority:200,Count IP Addrs:1,AuthType:0,Adver int:10,AuthData :,Addresses:xxx.xxx.xxx.190 
VRRP Pkt RX - Intf:0/4/2(275,Vl900),SrcIP:xxx.xxx.xxx.187,DestIp:224.0.0.18,Version:2,PktType:1,VrId: 210,Priority: 150,Count IP Addrs:1,AuthType:0,Adver int:1,AuthData :,Addresses:xxx.xxx.xxx.185 
VRRP Pkt TX - Intf: 0/4/3(276,Vl955),SrcIP:xxx.xxx.xxx.252,DestIp :224.0.0.18,Version:2,PktType:1,VrId:222,Priority:200,Count IP Addrs:1,AuthType:0,Adver int:1,AuthData :,Addresses:xxx.xxx.xxx.254

Verder géén errors dus...

Wat overigens opvalt is dat de counters gelijk lopen. Ik vermoed dus dat de counter voor VRRP globaal is, en niet per VLAN/VRID. De counters lopen dus op door de uplink met de netwerkleverancier waar ik hun VRID in de broadcast krijg.

[ Voor 8% gewijzigd door ipsec op 04-07-2016 14:10 ]

[Bigs]

Dat zou die error counter inderdaad wel kunnen verklaren ja. Het zou niet het probleem mogen zijn, maar hoe is je ping naar het VRRP IP als je de uplinks afkoppelt?

Voor de duidelijkheid: het is niet zo dat de switches elke vijf seconden van master/backup rol wisselen zoals winux vermoedde? Want dat mis ik nog in het topic.

[ipsec]

Bigs schreef op maandag 04 juli 2016 @ 14:16:
Dat zou die error counter inderdaad wel kunnen verklaren ja. Het zou niet het probleem mogen zijn, maar hoe is je ping naar het VRRP IP als je de uplinks afkoppelt?

Voor de duidelijkheid: het is niet zo dat de switches elke vijf seconden van master/backup rol wisselen zoals winux vermoedde? Want dat mis ik nog in het topic.

Nee, de switches wisselen niet van master/backup. Ik zie in de statistics ook dat er in totaal maar 3 master failovers zijn geweest in totaal, en dat kan kloppen met het aantal reboots van de switches.

Daarom heb ik ook de preempt periode van 900 seconden ingebouwd, dat hij pas na 15 minuten stabiel weer terug klapt. Ik begin steeds meer het idee te krijgen dat het "by design" is dat ik timeouts krijg. Mijn ping naar tweakers.net is nog steeds rock-stable met 2ms response.

Overigens reageren de pings nog wel gewoon wanneer ik de uplinks afkoppel. Hij kijkt namelijk naar de state van de VLAN interfaces, en omdat meerdere interfaces member zijn van dit VLAN blijft dat goed gaan. Kan wel eens kijken wat er gebeurt als ik de interfaces van VLAN 900 shut wat er gebeurt.

[ Voor 14% gewijzigd door ipsec op 04-07-2016 14:51 ]

[jeroen|IA]

Misschien kun je een andere insteek proberen om meer informatie boven water te krijgen. Kun je in die test VM niks bijzonders in de logging zien?

Om een voorbeeld te geven: je hebt in je console output het VMAC address netjes uitgekruisd, maar als het goed is zou dat volgens de VRRP standaard 00-00-5E-00-01-{VRID} op beide switches (swouters ) moeten zijn. Zie je dat mac address ook terug in de arp table van de VM?

Misschien kun je zelfs met tcpdump kijken of je af en toe antwoord krijgt van beide switches of juist met af en toe een ander mac address?

Just a hunch...

[ipsec]

jeroen|IA schreef op maandag 04 juli 2016 @ 16:39:
Misschien kun je een andere insteek proberen om meer informatie boven water te krijgen. Kun je in die test VM niks bijzonders in de logging zien?

Om een voorbeeld te geven: je hebt in je console output het VMAC address netjes uitgekruisd, maar als het goed is zou dat volgens de VRRP standaard 00-00-5E-00-01-{VRID} op beide switches (swouters ) moeten zijn. Zie je dat mac address ook terug in de arp table van de VM?

Misschien kun je zelfs met tcpdump kijken of je af en toe antwoord krijgt van beide switches of juist met af en toe een ander mac address?

Just a hunch...

Ik krijg inderdaad op beide switches netjes het zelfde VMAC address.
Voor VRID 150 (VLAN900) is dat: 0000.5E00.0196
Voor VRID 222 (VLAN 955) is dat: 0000.5E00.01DE

Op de VM zelf (is een 2012R2 machine) zie ik met arp -a ook netjes het VRRP VMAC adres, en voor de 2 "routers" (.252 en 253) de MAC adressen van de CORE-01 en de CORE-02.

Ik begin simpelweg steeds meer het gevoel te krijgen dat het "by design" is dat ik soms ping timeouts krijg op het VRRP IP adres. Ben nu met DELL bezig om deze informatie boven water te krijgen, maar het duurt allemaal even.

In elk geval iedereen bedankt voor de hulp en het meedenken voor nu, zodra ik meer informatie heb dan zal ik dit topic updaten. Ben in elk geval weer 100 dingen wijzer geworden met dit project