Trådlös förbindelse som reserv: routad omkoppling eller ett segment?

Två byggnader, en punkt-till-punkt-radio och en internet-VPN som kan tjäna som en andra väg. Innan reserven blir automatisk avgör en fråga nästan allt annat: vad måste överleva — IP-nåbarhet mellan separata subnät eller ett gemensamt Ethernet-segment? Att radion beter sig som en kabel är inte ett argument för att skicka varje broadcast-ram över internet. Svara på frågan först, eftersom de två svaren kräver olika slingkontroll, olika hälsokontroller och olika föreställningar om vad återställning betyder.

Avgör vad som måste överleva avbrottet

Lista applikationerna som måste fortsätta fungera och notera om de är beroende av nåbarhet på Layer 3 eller av grannskap på Layer 2. Fildelning, databasanslutningar och webbtjänster bryr sig vanligtvis bara om rutter; upptäcktsprotokoll, vissa klusterprodukter och allt som förväntar sig en enda broadcast-domän bryr sig om grannskap. En reserv som återställer fel sorts nåbarhet ger en plats som är tekniskt ansluten och praktiskt oanvändbar.

Skriv ned listan och bifoga den till designen, eftersom svaret vanligtvis flyttar sig så snart den första applikationsägaren hör talas om den nya förbindelsen.

Routad omkoppling: två prefix, en föredragen väg

Med separata plats-prefix blir reserven ett routingproblem. Varje router har en föredragen väg över radion och en mindre föredragen väg över tunneln, och den föredragna rutten dras tillbaka när radion slutar leverera trafik. Den andra sidan behöver sin egen returväg, och båda sidor bör komma överens om vilken väg som är föredragen i varje riktning, så att trafiken inte tar den långa vägen bara i en riktning.

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

Läs det tredje kommandot på samma sätt som det andra: en policyregel, en andra tabell eller ett källbaserat beslut kan skicka trafik från ett subnät annorlunda än från ett annat, och en enda standarduppslagning döljer det.

Brolad omkoppling: ett segment, en blockerande väg

Om grannskap verkligen krävs måste reserven bära Ethernet-ramar, vilket en routad IP-tunnel inte gör. Att broa ett VPN-gränssnitt in i ett lokalt segment stöds av vissa plattformar, och dessa gränssnitt blir då bromedlemmar med de följder som hör till. Två samtidigt vidarebefordrande vägar på Layer 2 bildar en slinga, så designen behöver ett spännande träd som omfattar båda platserna och ett tydligt uttalande om vilken väg som ska blockera.

Det är ett väsentligt designbeslut och inte en kryssruta, och brodokumentationen för din plattform, till exempel broöversikten för pfSense, är platsen där du bekräftar vad en VPN-medlem faktiskt deltar i. Att aktivera ett spännande-träd-alternativ på en enda orelaterad enhet bevisar ingenting om arrangemanget från ände till ände.

Övervaka gränsen som spelar roll

En radio med strömförsörjning, ett gränssnitt som är uppe och en frisk tunnel beskriver var och en ett lokalt faktum. Ingen av dem bevisar att ett paket från den ena byggnaden nådde en värd i den andra, och det är det enda faktum som omkopplingslogiken bör agera på. Övervaka ett mål bortom den avlägsna routern om policyn tillåter det, och övervaka båda riktningarna separat så att ett asymmetriskt fel blir synligt.

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

Håll kontrollen billig och avgränsad: ett kort intervall, ett litet antal och en tidsgräns som passar applikationens tolerans. En monitor som själv är beroende av vägen den testar kommer att rapportera framgång ända till det ögonblick den slutar rapportera något alls.

Öva båda riktningarna under last

Kopiera inte ett enda konvergensmål från någon annans topologi. Detektionstid, rutt- eller brokonvergens, tunnelberedskap och applikationsåterställning bidrar var och en med sin egen fördröjning, och summan på din utrustning är det enda talet som spelar roll. Öva medan representativ trafik går, så att mätningen omfattar köerna och sessionerna som finns i produktion.

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

Testa återställning lika noggrant som felet. En instabil radio som fladdrar in och ut kommer att dra trafiken fram och tillbaka om preferenslogiken inte har dämpning, och användare upplever det som värre än ett rent enstaka avbrott. Registrera den valda vägen i varje steg, vilka nya förfrågningar som lyckades och vad som hände med sessioner som var öppna när vägen ändrades. Just den registreringen gör en andra kabel till en driftsstrategi.