Två ägare, en adress: dubbla IP:n på en TAP-brygga

En Windows-klient håller 10.8.0.2 och fungerar tills startordningen ändras; då rapporteras samma adress som en konflikt trots att inget på klienten har ändrats. En andra värd i samma bryggade segment gör anspråk på samma värde, och maskinen som blir klar med konfigurationen sist förlorar oftast. Båda tror att de äger den, och förloraren slutar tyst att använda en adress som den blev tillsagd att använda. Just det att behandla detta som ett tidsproblem är vad som gör att det återkommer vid varje omstart.

Läs konfliktbevisen innan du rör en brygga

Windows rapporterar en adresskonflikt tillsammans med den andra anspråkstagarens maskinvaruadress. Den maskinvaruadressen är det användbara faktumet, eftersom den pekar på ett gränssnitt på en värd, medan händelsens visade namn inte säger något om var dubbletten finns. Skriv ned maskinvaruadressen innan du ändrar något.

ARP-baserad dubblettdetektering undersöker konkurrerande ägare innan en adress används och fortsätter att övervaka efteråt. Därför kan en värd som saknades när du konfigurerade nätet fortfarande orsaka en konflikt en timme senare. Undersökningen är inte en engångskontroll vid start. En maskin som dyker upp senare kan ta en adress som har varit i lugn användning hela dagen, och därför läses felet som ett lopp istället för ett konfigurationsfel.

En konflikthändelse säger i sig inte vilken konfiguration som skapade det andra anspråket, och att rensa adresser experimentellt förstör den mappning som skulle ha sagt det. Poängen med beviset är att göra en maskinvaruadress till ett gränssnitt du kan undersöka. Att söka i inventariet efter maskinnamn skickar dig oftast till fel värd.

Inventera varje anspråk i segmentet

En bryggad TAP-uppsättning sammanfogar Ethernet-segment som tidigare var åtskilda, så adresser som var unika inom sina egna nät kan kollidera så snart ramar delar en länk. Därför finns denna felklass på ett VPN och inte på de routade nät som den ersatte. Räkna upp varje möjlig ägare istället för den första du misstänker.

Gå igenom listan i denna ordning: adresserna på varje bryggenhet och dess medlemsportar, OpenVPN-poolen och varje fast tilldelning per klient, samt varje DHCP-server som täcker det bryggade segmentet. Jämför sedan maskinvaruadressen från konfliktrapporten med de gränssnitt du hittade.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Poolen och DHCP-intervallet är de två ägare som folk glömmer. Skriv ut båda intervallen tillsammans och leta efter överlapp innan du gör något annat. En handtilldelad bryggadress och en pool som delar ut samma värde kommer förr eller senare att kollidera, och kollisionen verkar slumpmässig tills båda intervallen skrivs ut sida vid sida.

Numrera bryggor bara där de behöver en identitet

I en normal värdbrygga bär bryggenheten värdens konfiguration för tredje lagret, och Ethernet- och TAP-medlemmarna fungerar som portar. Att ge varje medlem sin egen adress, eller kopiera ett installationsskript till flera maskiner utan att ändra adressen, är sättet ett enda segment hamnar med tre ägare av samma värde. Medlemmarna behöver inga egna identiteter för att vidarebefordra ramar. De behöver exakt en identitet per värd som måste vara nåbar i det segmentet.

En brygga som bara switchar ramar behöver ingen adress alls i det segmentet. Lämnar du den onumrerad försvinner en hel klass av kollisioner, förutsatt att värden fortfarande har en administrativ väg som du har verifierat. Bekräfta åtkomsten först, ta bort adressen som andra steg och kontrollera nåbarheten som tredje.

Om adressen du är på väg att ta bort är den enda vägen in i maskinen, är det ett självförvållat avbrott och inte en diagnos att ta bort den som ett experiment. Verifiera den oberoende vägen innan du testar något.

Se till att rättelsen överlever en omstart

Att ändra ett aktivt gränssnitt rättar den nuvarande starten och inget annat. Vad som än återskapar adressen vid start kommer att återställa konflikten vid nästa omstart, och du kommer att dra slutsatsen att rättelsen inte fungerade trots att den i själva verket aldrig var beständig. Anteckna vilken fil du ändrade, så att nästa omstart bekräftar ett beslut istället för att avslöja en överraskning.

Hitta ägaren till den konfigurationen: en nätverkshanterarprofil, en fil per gränssnitt, en container- eller VM-definition, eller ett cloud-init-fragment. Ändra den där och starta sedan medvetet om en påverkad värd för att bekräfta att det är det nya värdet som kommer tillbaka. En omstart är det enda prov som bevisar beständighet.

Reservera bryggadresserna inom DHCP-intervallet som undantag, eller flytta dem utanför det. En reservation som bara finns i ett kalkylark är inte ett undantag, och tilldelaren kommer inte att läsa den.

Bevisa det med alla klienter online

En enda lyckad anslutning bevisar ingenting, eftersom det ursprungliga symptomet bara uppträdde när ordningen ändrades. Starta varje avsedd klient, variera startordningen och upprepa efter en återanslutning. Starta sedan om värden som brukade förlora loppet och bekräfta att adressen överlever.

För direkt bekräftelse, undersök om det finns en dubbel ägare innan adressen tilldelas och övervaka sedan grannabellen. Om inget svarar på undersökningen och adressen förblir unikt ägd genom en full omstartscykel, är konflikten löst och inte bara dold. Kommandona nedan utför båda kontrollerna på bryggenheten. RFC 5227 beskriver det undersöknings- och annonseringsbeteende som dessa verktyg utövar, och det är referensen att citera när någon föreslår att detekteringen ska stängas av istället.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

En undersökning utan svar är det förväntade resultatet i ett rent segment. En undersökning som lockar fram ett svar ger dig maskinvaruadressen för den kvarvarande ägaren, samma bevis som Windows-händelsen gav dig i början. Spara den utskriften med ändringsloggen, eftersom den är det enda beviset på att adressen hålls unikt.