Da Telenor skulle bytte ut gamle gatewayer slo det ut Posten sine IT-systemer i flere dager

[Redaksjonen.]

Da Telenor skulle bytte ut gamle gatewayer slo det ut Posten sine IT-systemer i flere dager

[Sondre K]

At de håndholdte terminalene var ute av drift er ikke helt korrekt. Disse har mulighet til å gå i offline-modus om de ikke kommer på nett. Da får man fortsatt skannet pakker som skal leveres både inn og ut, men informasjonen om hva man har gjort med pakkene blir da lagret lokalt på terminalen fram til neste gang den kommer på nett.

[Øystein H]

"Størrelsen på IP-pakkene har vært for store, og de nye gatewayene har derfor stoppet leveransen mellom systemene til Posten, konkluderer hun"

 

Dette var da en veldig merkelig konklusjon. Har posten benyttet datasystemer som ikke håndterer IP trafikk (eller Ethernet frames) i henhold til gjeldende RFC-er ? Det er vel heller tvilsomt at Telenors utstyr bryter med standarder for datatrafikk.

[YH6ELJ93]

Både pakkesystemet (Logistikkmotor) og PDA-systemet (FOT) var nede. Servicedesken fikk over 2000 samtaler de tre  første dagene. At det skulle ta ca. en uke å få fikset dette er helt utrolig. Du har rett at det lagres internt på Motorola-PDA-ene, men her gikk flere system ned. At Posten/Bring har outsourca mye til India, og at en av underleverandørene (EVRY) selv har outsourca mye dit har bare ført til enda større forsinkelser og rot.

Endret 7. oktober 2016 av YH6ELJ93

[asshole]

"Størrelsen på IP-pakkene har vært for store, og de nye gatewayene har derfor stoppet leveransen mellom systemene til Posten, konkluderer hun"

 

Dette var da en veldig merkelig konklusjon. Har posten benyttet datasystemer som ikke håndterer IP trafikk (eller Ethernet frames) i henhold til gjeldende RFC-er ? Det er vel heller tvilsomt at Telenors utstyr bryter med standarder for datatrafikk.

 

Skal vel bruke path mtu discovery, så det skal ikke være mulig å sende for store pakker. Høres vel ut som postens systemer ikke følger standarder.

[Vice]

Er det Telenor selv som faktisk drifter slikt utstyr/hardware ?? Høres rart ut.

[kpolberg]

Blitt ganske vanlig i default config å blokke icmp, som da knekker PMTU. Har vært borti dette selv.

[asshole]

Blitt ganske vanlig i default config å blokke icmp, som da knekker PMTU. Har vært borti dette selv.

 

Vil si det en bug i firmwaren hvis man får lov til å feilkonfigurere slik at protokollen bryter sammen. Dessuten kortenk at de ikke forutså blokkering, burde probet icmp funksjonalitet først og ellers nekte å sende en eneste pakke. Men er vel for sent nå.

[kpolberg]

Og akkurat derfor er det ingen som tenker at det kan være default config, og da tar feilsøkingen lengre tid.

 

Det å forvente full ICMP end-to-end for applikasjons utviklere vil være ren utopi.

Endret 7. oktober 2016 av kpolberg

[mmm...]

Og akkurat derfor er det ingen som tenker at det kan være default config, og da tar feilsøkingen lengre tid.

 

Det å forvente full ICMP end-to-end for applikasjons utviklere vil være ren utopi.

Å finne ut av hvorfor informasjonen ikke kommer frem fra terminaler til server burde vært gjort på en halvtimes tid. Mye er gjort med pakkefangst og analyse av trafikken ut og inn av terminalene. Ligger årsaken i pakkestørrelse som foreslått ovenfor så burde nettverksfolka skamme seg. Bruker de en uke på å finne ut av slikt har de en jobb de ikke er kvalifisert for. Jeg tror ikke applikasjonsutviklerne har hatt noe forhold til ICMP i det hele tatt, unntatt muligens noen feilkoder om det nett-api'et de benytter tilbyr det. Det er det sjelden slike utviklere trenger å forholde seg til protokoller på lavere nivå. Hvis nettverks-ingeniørene derimot ikke forstår konsekvensen av blind blokkering av den ICMP-trafikken som inngår i kontroll-signalering så er det bare å vise dem døra.

 

Uten at jeg vet det sikkert så tipper jeg at årsaken til at det tok så lang tid å løse problemet er en kombinasjon av 3 ting.

 

1. Bruk av rimelig/low-end nettverks-utstyr som ikke tilbyr pakkefangst på klient-siden. Det hjelper ikke med all verdens monitor-fasiliteter på server-siden når man har slike problemer som dette.

 

2. Offshoring av drift. Uten fysisk adgang til utstyr og uten fasiliteter for pakkefangst fra klient-perspektiv blir feilsøking på protokoll-nivå mer eller mindre ren gjetting.

 

3. Inkompetente nettoperatører. Den gjennomsnittlige kompetansen hos flere av de utenlandske driftsorganisasjonene jeg har vært i befatning med er skremmende lav. De har noen svært dyktige ingeniører som bidrar ved innsalg av tjenestene, men man skal eskalere saker i uker og måneder før man får tilgang til tilsvarende kompetanse til feilsøking,

Endret 9. oktober 2016 av mmm...

[mmm...]

Blitt ganske vanlig i default config å blokke icmp, som da knekker PMTU. Har vært borti dette selv.

Overdreven filtrering av ICMP har vært et alvorlig problem i mer enn 20 år. Det og klassifisering av IP-subnett etter størrelse (A/B/C) er vranglære som dessverre fremdeles er utbredt.

Endret 9. oktober 2016 av mmm...

[kpolberg]

Nå er det ikke sikkert at nettverksfolka ble involvert før løsningen ble funnet på 5 minutter

[Thomas Håland]

Adri gjør slikt på en fredag..

[ozone]

Posten sine pakker var for store!!! Kostelig :-D