Telia FS-WAN DHCP offer unicast droppas

Permalänk
Medlem

Telia FS-WAN DHCP offer unicast droppas

Hej allesammans,

Jag har ett problem som jag stångas lite med.

Håller på att sätta upp ett nätverk mellan fastigheterna i min BRF och har då aktiverat en tjänst hos Telia som de kallar för FS-WAN.
Detta är enligt Telia någon form av L2 tunnel, så i varje fastighet har jag en port på deras switch som ska vara precis som att jag drog en kabel mellan fastigheterna.

Problemet är att min Ubiquiti utrustning inte får IP-adress och efter lite research med Wireshark och tcpdump i min UDM Pro och USW switch så upptäckte jag att DHCP servern i UDMn svarar med DHCP offer med unicast till den IP-adress den vill tilldela enheten. Det gör att paketet droppas på vägen (då genom Telias utrustning).

När DHCP servern svarar med multicast så går det bra.

Jag har kontaktat Telias support men har fortfarande efter flera dagar inte fått ett svar så jag tänkte kolla om det finns någon som har erfarenhet av detta sedan tidigare som kanske vet vad det kan bero på, och om det finns någon fix eller workaround?

Tack på förhand!

Permalänk
Medlem

Ingen aning egentligen. Men eftersom du redan plockat upp Wireshark så kan det väl vara läge att titta lite mer på vilka L2-adresser som används också. När servern skickar unicast-IP, vilken MAC-adress skickar den till? Den förväntade? Vad innehåller chaddr-fältet?

Det är möjligt att tunneln blir förvirrad när det kommer en IP-unicast till en adress den rimligen inte kan mappa till en MAC-adress, eftersom det aldrig gått någon ARP-trafik som har berättat om den mappningen. Å andra sidan borde den ju veta var klientens MAC-adress finns, om den har tittat på DHCP Discover-paketen (fast varför skulle tunnel-manicken bry sig om dem?)

Hur servern ska bete sig ska tydligen bero på hur klienten sätter broadcast-biten:

Citat:

If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address.

men du har tydligen lyckats konfa servern att alltid svara till multicast? Så... eftersom det funkar är problemet redan löst? I alla fall för den specifika klienten.

Det verkar vara lite olika med hur en klient-IP-stack hanterar unicast-trafik till en IP-adress som den inte ännu har:

Citat:

To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
defined as the BROADCAST (B) flag.

En klient som inte klarar av att ta emot unicast och som inte sätter broadcast-biten är förstås puckad. Men det kanske inte är så lätt för DHCP-klienten att veta hur IP-stacken tänker bete sig. Konfiguration på klientsidan?

Permalänk
Medlem

Hmm. Onekligen intressant. Har du provat med något annat än switchar i ändarna?

Jag har varit med om märkliga MAC-learning fel ibland när man kopplar switchar mot switchar.

Permalänk
Medlem
Skrivet av KAD:

Ingen aning egentligen. Men eftersom du redan plockat upp Wireshark så kan det väl vara läge att titta lite mer på vilka L2-adresser som används också. När servern skickar unicast-IP, vilken MAC-adress skickar den till? Den förväntade? Vad innehåller chaddr-fältet?

Det är möjligt att tunneln blir förvirrad när det kommer en IP-unicast till en adress den rimligen inte kan mappa till en MAC-adress, eftersom det aldrig gått någon ARP-trafik som har berättat om den mappningen. Å andra sidan borde den ju veta var klientens MAC-adress finns, om den har tittat på DHCP Discover-paketen (fast varför skulle tunnel-manicken bry sig om dem?)

Skrivet av KAD:

Hur servern ska bete sig ska tydligen bero på hur klienten sätter broadcast-biten:
men du har tydligen lyckats konfa servern att alltid svara till multicast? Så... eftersom det funkar är problemet redan löst? I alla fall för den specifika klienten.

Det verkar vara lite olika med hur en klient-IP-stack hanterar unicast-trafik till en IP-adress som den inte ännu har:
En klient som inte klarar av att ta emot unicast och som inte sätter broadcast-biten är förstås puckad. Men det kanske inte är så lätt för DHCP-klienten att veta hur IP-stacken tänker bete sig. Konfiguration på klientsidan?

Tack för svar!

Här kommer lite svar på dina frågor.

Citat:

Ingen aning egentligen. Men eftersom du redan plockat upp Wireshark så kan det väl vara läge att titta lite mer på vilka L2-adresser som används också. När servern skickar unicast-IP, vilken MAC-adress skickar den till? Den förväntade? Vad innehåller chaddr-fältet?

Den skickar till förväntad MAC adress

DHCP Discover

DHCP Offer

Citat:

Hur servern ska bete sig ska tydligen bero på hur klienten sätter broadcast-biten:
men du har tydligen lyckats konfa servern att alltid svara till multicast? Så... eftersom det funkar är problemet redan löst? I alla fall för den specifika klienten.

Precis, jag kan se att alla mina Ubiquiti prylar sätter broadcast bitten till unicast i sitt DHCP Discover paket.

Däremot, när jag t.ex. kopplar in en annan klient, t.ex. en Dell dator som sätter broadcast bitten till multicast, då fungerar det.
Har alltså inte ställt in servern till att svara med multicast (hittar inte heller hur man gör det hos Ubiquiti, känns också som att det kan bli fel med en dump klient som kräver unicast men får multicast )
DHCP Discover med multicast

Permalänk
Medlem
Skrivet av maDa:

Hmm. Onekligen intressant. Har du provat med något annat än switchar i ändarna?

Jag har varit med om märkliga MAC-learning fel ibland när man kopplar switchar mot switchar.

Hej,

Det har jag gjort. Har testat både

Router <-> Telia Switch <-> Min switch <-> Dell dator
samt
Router <-> Telia Switch <-> Dell dator

I båda fallen får Dell datorn IP adress, men switchen (som är en managed switch från Ubiquiti med ett management interface som behöver ip) får aldrig IP.

Skillnaden är då att Dell datorn i sitt DHCP Discover önskar multicast medan Ubiquiti switchen önskar Unicast, och det verkar då som att Unicast paketet droppas av Telia switchen. (Se mitt förgående svar ovan).

Permalänk
Medlem
Skrivet av xervz:

Hej,

Det har jag gjort. Har testat både

Router <-> Telia Switch <-> Min switch <-> Dell dator
samt
Router <-> Telia Switch <-> Dell dator

I båda fallen får Dell datorn IP adress, men switchen (som är en managed switch från Ubiquiti med ett management interface som behöver ip) får aldrig IP.

Skillnaden är då att Dell datorn i sitt DHCP Discover önskar multicast medan Ubiquiti switchen önskar Unicast, och det verkar då som att Unicast paketet droppas av Telia switchen. (Se mitt förgående svar ovan).

Hej,

Det är inte möjligt för dig att köra med statisk IP på din switch? Eller har du tjänster som kräver inställningar via DHCP-options?
Om du inte för ofta planerar att ändra din topologi i nätverket så kan jag rekommendera att sätta statiska adresser på viktiga tjänster som switchar, routrar samt servrar m.m.

/Mvh, csoM

Permalänk
Hedersmedlem

Om du misstänker att DHCP unicast droppas av Telias nät, varför testar du då inte bara att skicka igenom lite sådan testtrafik? Du bör kunna använda hping3 för att generera ett lämpligt testpaket och sedan wireshark på någon lämplig maskin på andra sidan att ta emot med. Se till att köra UDP och samma portar bara, payloaden spelar nog mindre roll.

Permalänk
Medlem

bara en notis, det är inte multicast. bara broadcast och unicast.

Vilken sida om tunneln kör du wireshark?

Kör du med VLAN?

Visa signatur

"Det här systemet fungerar urkasst." - operatör.
"Hur ska det fungera då?" - jag
"Gör så att det fungerar som jag vill." - operatör.
/facepalm

Permalänk
Medlem
Skrivet av csom:

Hej,

Det är inte möjligt för dig att köra med statisk IP på din switch? Eller har du tjänster som kräver inställningar via DHCP-options?
Om du inte för ofta planerar att ändra din topologi i nätverket så kan jag rekommendera att sätta statiska adresser på viktiga tjänster som switchar, routrar samt servrar m.m.

/Mvh, csoM

Tyvärr kräver Ubiquitis prylar dynamisk IP.
Alla enheter har vid uppstart 192.168.1.20 och får IP adress tilldelat. Om man sätter fast IP i ubiquitis mjukvara så innebär det egentligen bara att DHCP servern alltid tilldelar samma IP till klienten.
SSH:ar man in och sätter IP kommer denna att skrivas över vid omstart.

Skrivet av pv2b:

Om du misstänker att DHCP unicast droppas av Telias nät, varför testar du då inte bara att skicka igenom lite sådan testtrafik? Du bör kunna använda hping3 för att generera ett lämpligt testpaket och sedan wireshark på någon lämplig maskin på andra sidan att ta emot med. Se till att köra UDP och samma portar bara, payloaden spelar nog mindre roll.

Tack för tipset av mjukvaran, tanken har slagit mig men jag har inte haft en aning om hur jag ska kunna skicka testtrafik.

Skrivet av Otur:

bara en notis, det är inte multicast. bara broadcast och unicast.

Vilken sida om tunneln kör du wireshark?

Kör du med VLAN?

Wireshark har jag kört på en port som är mirrored mot den port som går till Telias switch på DHCP serverns sida.
Har även gjort Tcpdump på min switch i andra ändan för att se vad som trillar in där och kan bara se utgående DHCP Discover men ingen inkommande DHCP Offer.

På detta nätverket kör jag inte VLAN, men har ett par VLAN som körs på andra portar.

Permalänk
Medlem
Skrivet av xervz:

Tyvärr kräver Ubiquitis prylar dynamisk IP.
Alla enheter har vid uppstart 192.168.1.20 och får IP adress tilldelat. Om man sätter fast IP i ubiquitis mjukvara så innebär det egentligen bara att DHCP servern alltid tilldelar samma IP till klienten.
SSH:ar man in och sätter IP kommer denna att skrivas över vid omstart.

Enligt min egna erfarenhet då jag själv kör Unifi-serien så går det alldeles utmärkt att köra statisk IP. Dock krävs att man anslutit enheten till någon sorts kontroller, antigen en cloud key eller en mjukvara som körs på extern maskin t.ex Raspberry Pi. Har iofs ingen DHCP som körs på Unifi utan kör den på separat hårdvara.

/Mvh, csoM

Permalänk
Medlem
Skrivet av csom:

Enligt min egna erfarenhet då jag själv kör Unifi-serien så går det alldeles utmärkt att köra statisk IP. Dock krävs att man anslutit enheten till någon sorts kontroller, antigen en cloud key eller en mjukvara som körs på extern maskin t.ex Raspberry Pi. Har iofs ingen DHCP som körs på Unifi utan kör den på separat hårdvara.

/Mvh, csoM

Jag provade detta. Tog mina enheter (en AP och en USW), adopterade direkt mot UDMn, satte 'fast IP' och flyttade tillbaka dem till där de skulle vara, då startade de upp med 192.168.1.20 och vägrade få rätt IP. Googlade runt och det verkar då som att det inte går att ändra detta förfarande. Men jag kan ha fel, känns lite otydligt..

Permalänk
Medlem

@xervz Spännande inlägg!
Just det här med att skicka L2 över routrar är något jag inte rört så mycket utanför en labb-miljö.
Men baserat på det lilla jag vet så finns det väldigt många olika metoder att skicka L2 trafik över routade nät.

Egentligen tycker jag att det är lite löjligt att allt alltid ska routas. Jag menar man förstår att Telia vill ha skalbara, homogena lösningar och att när man ska skicka L2 trafik över stora avstånd så måste det nästan routas, men i ditt fall hade jag nog bara kört ett separat VLAN mellan dina lägenheterna.

Hade jag varit du så hade jag gjort som @pv2b föreslog och skickat lite testtrafik. Ändra en variabel i taget och se vad som kommer ut på andra änden av linan - du kan även köra Python, finns massa moduler för att skicka olika paket/frames.
Sedan hade jag förmedlat datan till Telia - snyggast är ju om de faktiskt erbjuder en fungerande L2 koppling.

Annars kan du ju alltid bygga något eget ex. köra en router på var sida om L2 linan och så konfa DHCP-relay. Alternativt sätta upp typ L2TP mellan routrarna, men känns som en dålig lösning byggt på en annan dålig lösning. Blir onödigt komplicerat.

Visa signatur
Permalänk
Medlem
Skrivet av gurfin:

@xervz Spännande inlägg!
Just det här med att skicka L2 över routrar är något jag inte rört så mycket utanför en labb-miljö.
Men baserat på det lilla jag vet så finns det väldigt många olika metoder att skicka L2 trafik över routade nät.

Egentligen tycker jag att det är lite löjligt att allt alltid ska routas. Jag menar man förstår att Telia vill ha skalbara, homogena lösningar och att när man ska skicka L2 trafik över stora avstånd så måste det nästan routas, men i ditt fall hade jag nog bara kört ett separat VLAN mellan dina lägenheterna.

Hade jag varit du så hade jag gjort som @pv2b föreslog och skickat lite testtrafik. Ändra en variabel i taget och se vad som kommer ut på andra änden av linan - du kan även köra Python, finns massa moduler för att skicka olika paket/frames.
Sedan hade jag förmedlat datan till Telia - snyggast är ju om de faktiskt erbjuder en fungerande L2 koppling.

Annars kan du ju alltid bygga något eget ex. köra en router på var sida om L2 linan och så konfa DHCP-relay. Alternativt sätta upp typ L2TP mellan routrarna, men känns som en dålig lösning byggt på en annan dålig lösning. Blir onödigt komplicerat.

Tack för svar!

Ja det verkar vara en djungel med tekniker som används för att lösa detta, MPLS, EVC mm samtidigt som olika hårdvara stödjer olika tekniker. I sin marknadsföring för FS-WAN tjänsten nämner man just EVC, men blev inte klokare av att läsa på om det

Punkt-till-punkt eller Punkt-till-multipunkt
Denna topologi ger dig ett stjärnnät. Förbindelserna kallas även
Ethernet Virtual Connection, EVC. De två portarna som terminerar
en förbindelse ska ligga på var sin access.

Gällande din tanke om att köra VLAN - Problemet är att jag har inget sätt att få ut en egen kabel till den fastigheten, måste alltså gå via fibern som kommer från Telia och således måste jag förlita mig på deras routing.

Min last restort lösning är att sätta upp en L2TP mellan fastigheterna, precis så som du beskriver.

Här kommer en liten paint skiss som kanske förtydligar min topologi.

Har fortfarande inte fått svar från Telia så tanken är väl att jag ska köra lite testtrafik i helgen för att forska vidare i problemet.
Tack för tipset angående Python också

Permalänk
Hedersmedlem

Jag funderar på en annan sak, jag har ingen koll på hur just Telias L2-tjänst fungerar, men många L2-tjänster har en begränsning i hur många MAC-adresser maximalt som får förekomma på varje port. Jag vet att med andra leverantörer har jag sett gränser satt så låga som kanske 10 per port.

Det problem du stöter på kanske är att det finns för många MAC-adresser lärda på andra sidan, inte nödvändigtvis problem med DHCP. Och även om det inte är det problem du stöter på så kanske den begränsningen kommer bita dig i arslet senare även om du löser dina DHCP-problem.

Jag hade kollat med Telia, hur skalbar är lösningen, hur många MAC-adresser får du maximalt ha per ändpunkt eller i hela ditt nät? Om begränsningen är för låg för att funka för ditt use case så blir du kanske tvungen att routa ändå. Du får då se telia-tjänsten som ett sätt att sätta upp ett länknät mellan två routrar, en i vardera fastighet.

Oklart om du kan få igång den sortens routing på den utrustning du kör med, det är inte allt från Ubiquiti som klarar av att köra L3-switching. Har aldrig kört det själv heller på Ubiquiti.

Permalänk
Medlem

Yo @xervz!

Hur har det gått med denna? Blir riktigt nyfiken!

Visa signatur
Permalänk
Medlem
Skrivet av gurfin:

Yo @xervz!

Hur har det gått med denna? Blir riktigt nyfiken!

Yo! Tack för att du frågar.
Telia var ju hopplösa. Väntade veckor, skickade en påminnelse och fick ett nytt ärendenummer.
Ingen svarade på det nya ärendet.

Under tiden hitta jag en gammal asus router jag haft liggandes och tänkte att det kanske fungerar om jag sätter en router med egen DHCP server på andra sidan telia switchen - vilket det gjorde.
Känns dock inte som en jättebra långsiktig lösning då jag vill ha all utrustning managed via UniFi. Funderar på om det kanske går att göra något med en L3 switch från Ubiquiti. Men men, det får bli när jag har tid över till det