pfSense op ESX5i packet loss bij switch naar glasvezel

[Mozart]

Ik heb een goed werkende gevirtualiseerde pfSense installatie op ESX5i welke ik rechtstreeks op mijn Ziggo modem heb geprikt. De WAN interface van pfSense krijgt dus het WAN IP.
Deze installatie heeft het afgelopen jaar goed gewerkt, geen problemen en dus had ik ook geen problemen verwacht bij het switchen naar glasvezel.
Sinds halverwege vorige maand heb ik een glasvezelmodem in huis met daarop internet via Concepts ICT.
Ik heb dus mijn pfSense eenvoudig omgezet van het Ziggo modem naar het glasvezelmodem, even DHCP renew op de WAN interface en er zat een nieuw publiek IP op.
Vervolgens begonnen de problemen die het beste duidelijk worden bij b.v. videogesprekken. Er ontstaat een packet loss van ruim 10% in deze situatie waardoor videoconferencing (Skype, Lync) gewoon niet te doen is.

Helaas levert dit een niet werkbare situatie op en was ik genoodzaakt om er een Draytek router die ik nog had liggen tussen te zetten. Hierdoor werkt de verbinding weer perfect en haal ik mijn 60/60 snelheid.

Ik heb geprobeerd om extra settings in de /boot/loader.conf.local te zetten zoals hieronder maar dat helpt niks.

• kern.ipc.nmbclusters="131072"
• hw.em.rxd=4096
• hw.em.txd=4096

De fysieke netwerkkaart is een dual port Intel 82571EB, voor het management netwerk heb ik een afzonderlijke kaart, de ingebouwde Realtek 8168 NIC.

Nu wil ik graag weer terug naar de situatie dat ik geen Draytek er tussen hoef te zetten. Iemand een idee wat ik nog kan proberen? Meer dan bovenstaande settings kon ik niet vinden.

[Xudonax]

Hoe is de netwerkkaart aan pfSense doorgegeven? Heb je het PCI(e) device doorgegeven via ESXi of heb je een virtueel netwerk gecreeërd op die poort en aan de switch daarvan vervolgens de pfSense VM gehangen? En probeer de andere optie eens

[Kabouterplop01]

Hoe meet je die packetloss eigenlijk?

[Mozart]

Xudonax schreef op dinsdag 10 september 2013 @ 20:22:
Hoe is de netwerkkaart aan pfSense doorgegeven? Heb je het PCI(e) device doorgegeven via ESXi of heb je een virtueel netwerk gecreeërd op die poort en aan de switch daarvan vervolgens de pfSense VM gehangen? En probeer de andere optie eens

Ik heb een vSwitch welke gekoppeld is met de fysieke netwerkkaart. Ik kan dat niet anders doen omdat ik met behulp van VLAN's meerdere netwerken over de fysieke kaart gebruik.
Wat ik zelf zo vreemd vind, is dat het allemaal prima werkt met het Ziggo modem maar niet met het glasmodem. Waarom is dat? Wat is anders tussen die 2 modems?

Ik heb ook al geprobeerd om van de standaard Intel Nic gebruik te maken van de VMXNET3 netwerkkaart, maakt ook geen verschil

[Mozart]

Kabouterplop01 schreef op dinsdag 10 september 2013 @ 21:04:
Hoe meet je die packetloss eigenlijk?

Dat doet pfSense voor me door middel van een ping naar de default gateway van pfSense. Daar zie je dus, en merk je ook, dat het mis gaat als je gaat uploaden.

[DukeBox]

Een ping is geen water dichte methode om packet loss te meten. ICMP afhandeling heeft altijd een lagere prio dan data routeren. Dat zie je ook op managed switches terug, een ping naar het management ip geeft hoge latency's en soms timeouts terwijl het verkeer er doorheen zonder issues werkt.
Daarnaast kan er ook nog een protocol issue zijn (storm control, back preassure, flow control, duplex mismatch). Zeker dingen als flow control waarbij drop's niet meer dan logisch zijn als je langdurig meer aanvoert dan je modem kan doorsturen..
Overigens, de juiste manier is om je tcp/ip stats uit te lezen op je interface.

[ Voor 9% gewijzigd door DukeBox op 11-09-2013 09:42 ]

[Mozart]

DukeBox schreef op woensdag 11 september 2013 @ 09:40:
Een ping is geen water dichte methode om packet loss te meten. ICMP afhandeling heeft altijd een lagere prio dan data routeren. Dat zie je ook op managed switches terug, een ping naar het management ip geeft hoge latency's en soms timeouts terwijl het verkeer er doorheen zonder issues werkt.
Daarnaast kan er ook nog een protocol issue zijn (storm control, back preassure, flow control, duplex mismatch). Zeker dingen als flow control waarbij drop's niet meer dan logisch zijn als je langdurig meer aanvoert dan je modem kan doorsturen..
Overigens, de juiste manier is om je tcp/ip stats uit te lezen op je interface.

Ik merk het ten eerste doordat een video gesprek niet goed werkt. Daarna ben ik gaan kijken op de firewall en zag ik dat die aangeeft dat het pingen niet lukt. Als ik er dan een draytek tussen zet, heb ik er helemaal geen last van.

[DukeBox]

Dan lijkt het meer op een negotiation error..

[Nickvandelaar]

wellicht is het een idee om beide devices in te stellen op full duplex speed 100/1000


**********************

Zie bovenstaande

[ Voor 23% gewijzigd door Nickvandelaar op 11-09-2013 12:23 ]

[Kabouterplop01]

Als ze maar beiden gelijk zijn! niet een op fixed en de andere op auto.

[Mozart]

Beide zijn gekoppeld aan een switch, de Netgear GS108. Wat is dan belangrijk, dat je je nic fixed op 1 Gb zet van beide devices? Het enige dat is veranderd is het draadje van de switch naar het modem.
Glasvezelmodem van Concepts is niet in te stellen volgens mij.

[ Voor 34% gewijzigd door Mozart op 11-09-2013 17:36 ]

[fast-server]

Ik geloof dat je de laatste pfsense (beta versie?) moet gebruiken omdat o.a. concepts een afwijkend DHCP server script gebruikt.

[ Voor 3% gewijzigd door fast-server op 11-09-2013 19:47 ]

[johnkeates]

Wat zie je eigelijk op de pfSense console? Veel hypervisors geven problemen met de timer. Meestal krijg je dan messages als 'time went backwards'.

Dat zie je alleen op de console, niet op de interface of shell menu's.

[Zenix]

Ik zou ook gateway monitoring uitzetten.
Zie hier http://forum.pfsense.org/index.php?topic=65452.0

[ Voor 42% gewijzigd door Zenix op 11-09-2013 20:19 ]

[Raven]

fast-server schreef op woensdag 11 september 2013 @ 19:47:
Ik geloof dat je de laatste pfsense (beta versie?) moet gebruiken omdat o.a. concepts een afwijkend DHCP server script gebruikt.

Semi-offtopic: Wait wut? Zou dat de reden kunnen zijn dat mijn verbinding afgesloten werd omdat pfSense na een tijd goed gewerkt te hebben ineens 10.000 DHCP requests in een half uurtje stuurde? Heb daar nooit de oorzaak van gevonden, ben overgestapt op IPFire en toen werkte alles weer goed.

[Mozart]

fast-server schreef op woensdag 11 september 2013 @ 19:47:
Ik geloof dat je de laatste pfsense (beta versie?) moet gebruiken omdat o.a. concepts een afwijkend DHCP server script gebruikt.

Ok, dat ga ik proberen.

12-9-2013
Ik heb inmiddels pfSense geupdate naar 2.1 RC2 en de gateway monitoring uitgezet. Eens kijken hoe het gaat vandaag. In ieder geval alvast bedankt voor de tips.

[ Voor 24% gewijzigd door Mozart op 12-09-2013 08:39 ]

[Kabouterplop01]

Nog even terug: De switchport moet hetzelfde staan als de NIC. (Ik weet niet of dat een managed switch is, maar auto op je switchport betekent ook auto op je nic etc...)

[Mozart]

Helaas heeft het allemaal niet geholpen
Nog steeds heb ik een slechte verbinding als ik pfsense gebruik rechtstreeks op het glasvezelmodem aangesloten.

[Mozart]

Update:

Goed, ik kom er vanavond bij toeval dus achter dat de problemen ontstaan wanneer ik het glasmodem rechtstreeks aansluit op de Netgear GS108E. Wat er dan gebeurd is dat het glasmodem gaat 'klapperen'. De poort gaat van up naar down en weer terug met een tussenpoos van een seconde of 5.
Dat lijkt me dan typisch een probleem met de onderhandeling tussen de snelheid en full duplex tussen die 2.
Alleen jammer dat ik op de switch geen setting kan wijzigen hiervoor en ook niet in kan loggen op het modem...
Binnenkort maar eens contact opnemen met de technische dienst van Concepts ICT om te vragen of zij daar iets aan in kunnen stellen.

[DukeBox]

Niet toevallig ergens een spanning tree probleempje ?