Vinnaren i pepparkakshustävlingen!
  • 1
  • 2
2018-02-23, 20:54
  #13
Medlem
Citat:
Ursprungligen postat av studioxswe
VLAN är per definition L2, vad skulle det annars vara? Röksignaler?


Ett L2 nät pratar precis med varandra, alla pratar med just alla, en broadcast-storm kan döda hela nätet, ja visst räcker L2.


Så bra att du förstår då, för det verkar du ju inte göra. Fint att du svarar på ett inlägg som inte du var användare till också. Förklara för mig i en mening vad L3 betyder, så får vi se vem som är troll.

Gosse, du är ute och cyklar. Självklart används L2. Eller du anser att man skall köra L3 (routing, och skall vi verkligen isolera är det på MPLS nivå) på hostnivå?

Du lever kanske i en källare med hubbar eller switchar modell hemprylar, men i en enterprisemiljö funkar L2 utmärkt om man använder utrustning med modern teknik och protokoll. Broadcaststormar är inget problem i moden utrustning. L2 funkar utmärkt, och idag när spanning tree inte är nödvändigt är dessutom risken för loopar minimal, troligen eliminerad.

Som exempel har vi 8000+ noder i ett L2 nätverk med VLAN/EPG separering som är stabilt som berget.

Isolering mellan admin-nät och critical/produktion-nät sker på alla sjukhus. Detta sker på L3, men respektive del kör L2. Allt annat är vansinne både ur kostnads och administrationsperspektiv.
Citera
2018-02-23, 21:01
  #14
Medlem
Citat:
Ursprungligen postat av ziggemannen
Isolering mellan admin-nät och critical/produktion-nät sker på alla sjukhus. Detta sker på L3, men respektive del kör L2. Allt annat är vansinne både ur kostnads och administrationsperspektiv.

Routar ni mellan segment för admin i sjukvårdsnät? Kör ni inte jumpservrar?
Citera
2018-02-23, 21:07
  #15
Medlem
Citat:
Ursprungligen postat av helofin
Routar ni mellan segment för admin i sjukvårdsnät? Kör ni inte jumpservrar?

Jumpservrar eller ej, kommunikation måste ju finnas mellan näten på L3. Normalt ur ett säkerhetsperspektiv sker detta via brandvägg som då agerar som L3 terminering med ett ”dmz” för jumphostar. Normalt förfarande, inte bara för sjukhus. Finns dom som kör VRF’er med läckning och ACL’er också. Doch inget sjukhus vad jag känner till
Citera
2018-02-23, 21:12
  #16
Medlem
Citat:
Ursprungligen postat av ziggemannen
Jumpservrar eller ej, kommunikation måste ju finnas mellan näten på L3. Normalt ur ett säkerhetsperspektiv sker detta via brandvägg som då agerar som L3 terminering med ett ”dmz” för jumphostar. Normalt förfarande, inte bara för sjukhus. Finns dom som kör VRF’er med läckning och ACL’er också. Doch inget sjukhus vad jag känner till

Hör du vet vad du pratar om. Vad är din teori om problemen på NKS?
Citera
2018-02-23, 21:28
  #17
Medlem
Teori? Puuhh...det kan vara bad som helst. Vad man normalt kan utgå ifrån är att hårdvaran i sig säkert är ok. Men sen kommer det en hiskelig massa saker på toppen som kan strula. Exempelvis 802.x certifikat på portnivå. Strul med certifikatservrar kan skapa problem. VPN för vissa accesser? Microsoft Direct Access? Brandväggar och dess versioner? Listan med felkällor är oändlig, och ju mer nivåer av säkerhet och komplexitet, desto jävligare är det. Bara en minor release i en brandvägg kan vara skillnaden mellan succe och katastrof. Och om man har beslutat lägga tjugo säkerhetslager på toppen av sitt nätverk så kommer utmaningar som ett brev på posten..

Summa summarum, spekulation meningslöst.
Citera
2018-02-23, 22:18
  #18
Medlem
Citat:
Ursprungligen postat av helofin
Vad är din teori om problemen på NKS?

Sjukhuset har två stycken så kallade core switchar. En av switcharna hade ett defekt kort som skulle bytas ut och under arbetet uppstod ett oväntat fel. Bägge switcharna gick ner och det tog dryga tre timmar innan nätverket var uppe igen.

It-systemet som lanserades redan 2013 är helt enkelt för dåligt och dessutom underdimensionerat. NKS stängdes ned under ett dygn den 19–20 februari och den gamla hårdvaran ersattes med en ny hårdvara av samma modell och typ som tidigare, förutom att det aktiva kortet i chassit är av en något nyare version.

Om jag fick bestämma så skulle core switcharna ersättas med helt nya modeller. Ett par mille hit & dit är ingenting om man jämför med vad allt annat har kostat i detta vansinne.

Folk har fan dött på grund av dessa jävla nollor.
Citera
2018-02-24, 10:11
  #19
Medlem
Citat:
Ursprungligen postat av obyn
Sjukhuset har två stycken så kallade core switchar. En av switcharna hade ett defekt kort som skulle bytas ut och under arbetet uppstod ett oväntat fel. Bägge switcharna gick ner och det tog dryga tre timmar innan nätverket var uppe igen.

It-systemet som lanserades redan 2013 är helt enkelt för dåligt och dessutom underdimensionerat. NKS stängdes ned under ett dygn den 19–20 februari och den gamla hårdvaran ersattes med en ny hårdvara av samma modell och typ som tidigare, förutom att det aktiva kortet i chassit är av en något nyare version.

Om jag fick bestämma så skulle core switcharna ersättas med helt nya modeller. Ett par mille hit & dit är ingenting om man jämför med vad allt annat har kostat i detta vansinne.

Folk har fan dött på grund av dessa jävla nollor.

Sitter det ett par gamla Catalyst 6500-serien som core? Och för klena SFP? Är det SFP korten som crashade? De börjar att bli svåra att få tag reservkort på.

Nu vet jag inte hur stort NKS nätet är, men ett par Nexus borde duga långt. Som du säger, ett par miljoner för det när hela skiten kostat miljarder är dumsnålt.
Citera
2018-02-24, 10:20
  #20
Medlem
Citat:
Ursprungligen postat av ziggemannen
Teori? Puuhh...det kan vara bad som helst. Vad man normalt kan utgå ifrån är att hårdvaran i sig säkert är ok. Men sen kommer det en hiskelig massa saker på toppen som kan strula. Exempelvis 802.x certifikat på portnivå. Strul med certifikatservrar kan skapa problem. VPN för vissa accesser? Microsoft Direct Access? Brandväggar och dess versioner? Listan med felkällor är oändlig, och ju mer nivåer av säkerhet och komplexitet, desto jävligare är det. Bara en minor release i en brandvägg kan vara skillnaden mellan succe och katastrof. Och om man har beslutat lägga tjugo säkerhetslager på toppen av sitt nätverk så kommer utmaningar som ett brev på posten..

Summa summarum, spekulation meningslöst.

Lägg där till att man trycker in IP TV och annat skit som äter bandbredd. Skicka ut stora uppdateringar till många klienter och så sänker man vilket nät som helst.

Men har man bara två coreswitchar och båda strular som Obyn skriver sitter de på en jättemina som kan smälla när som helst. Speciellt om det är gamla Catalyst switchar. Vansinne. Jag hade inte byggt ett så känsligt nät med mindre än fyra. Att en smäller kan hända. Att två kan smälla har jag varit med om. Väldigt ovanligt men risken är inte 0. Inte ovanligt att FSP korten packar ihop efter några år. Eller en brand eller vattenläcka. Att fyra ryker är dock högst osannolikt. Och när det handlar om liv ska det vara nära 0 sannolikhet.
Citera
2018-02-24, 11:23
  #21
Medlem
TheWires avatar
Det är anmärkningsvärt att HP vann upphandlingen. Deras produkter är ej anpassade efter en sådan komplex miljö som NKS.

https://www.dn.se/sthlm/karolinskas-...iga-it-risker/

Saxat från artikeln ovan:

"Det är HP som är leverantör av det fasta och trådlösa nätverket till Nya Karolinska, efter en upphandling som gjorts av landstinget 2013. Utvärderingen av anbuden, som DN tagit del av, visar att HP lade det klart billigaste anbudet på 206 miljoner kronor, cirka 34 miljoner kronor lägre än den näst billigaste, Cygate. Högsta anbudet lade IBM på 350 miljoner kronor. "


Undrar om samma situation hade uppstått om Cygate eller IBM vunnit upphandlingen???
Citera
2018-02-24, 11:33
  #22
Medlem
studioxswes avatar
Citat:
Ursprungligen postat av ziggemannen
Gosse, du är ute och cyklar. Självklart används L2. Eller du anser att man skall köra L3 (routing, och skall vi verkligen isolera är det på MPLS nivå) på hostnivå?

Du lever kanske i en källare med hubbar eller switchar modell hemprylar, men i en enterprisemiljö funkar L2 utmärkt om man använder utrustning med modern teknik och protokoll. Broadcaststormar är inget problem i moden utrustning. L2 funkar utmärkt, och idag när spanning tree inte är nödvändigt är dessutom risken för loopar minimal, troligen eliminerad.

Som exempel har vi 8000+ noder i ett L2 nätverk med VLAN/EPG separering som är stabilt som berget.

Isolering mellan admin-nät och critical/produktion-nät sker på alla sjukhus. Detta sker på L3, men respektive del kör L2. Allt annat är vansinne både ur kostnads och administrationsperspektiv.

Jag cyklar ofta så där har du helt rätt.
Hemma kör jag en EX3300 som core switch samt två stycken EX2300 som access, självklart med 10GE upplänkar. All L3 sker i min EX3300. Jag kör ett par routing-instanter, DMZ, Server, Office osv. All trafik mellan routing-instanter måste gå till FW (som är ett vSRX kluster). Kör både IPv4 samt IPv6, OSPF som routing-protokoll internt, statiskt och BGP-4 externt. Så jag kör nog mer enterprise än många.. enterprise.

Kod:
loophole> show ospf neighbor instance all   
Instance: master
Address          Interface              State     ID               Pri  Dead
192.168.169.13   ge-0/0/1.0             Full      192.168.169.104  128    34
192.168.169.5    ge-0/0/2.0             Full      192.168.169.102  128    32
192.168.169.17   ge-0/0/4.0             Full      192.158.169.106  128    33

Jag administrerar ett nät med ett par tusen noder, vi kör all L3 i access med VRRP mellan två separata VC, kan uppgradera vilken komponent som helst i nätet utan störning. Har ganska många routing-instanter (eller VRF som cisco folk förstår) och således en hel del säkerhetszoner i fw klustret. Tidigare körde vi flat L2 överallt, med intra-vlan "routing"

Vi har ingen större administration, vi har ett webbgränssnitt som pratar med IPAM. Vi har MYCKET broadcast-trafik då en stor del av utrustningen använder det som primär kommunikationsväg.

Vad som gick fel på KS har jag ingen aning om, men även stora bolag kan få problem men något har man inte testat eller knopat rätt. Innan vi gör en större ändring testar vi det i vårt labb, som kör samma switcher som prod.
Citera
2018-02-24, 12:27
  #23
Medlem
Citat:
Ursprungligen postat av TheWire
Det är anmärkningsvärt att HP vann upphandlingen. Deras produkter är ej anpassade efter en sådan komplex miljö som NKS.

https://www.dn.se/sthlm/karolinskas-...iga-it-risker/

Saxat från artikeln ovan:

"Det är HP som är leverantör av det fasta och trådlösa nätverket till Nya Karolinska, efter en upphandling som gjorts av landstinget 2013. Utvärderingen av anbuden, som DN tagit del av, visar att HP lade det klart billigaste anbudet på 206 miljoner kronor, cirka 34 miljoner kronor lägre än den näst billigaste, Cygate. Högsta anbudet lade IBM på 350 miljoner kronor. "


Undrar om samma situation hade uppstått om Cygate eller IBM vunnit upphandlingen???

Sån stor skillnad var det inte mellan HP och Cygate. Alla tre fick rätt lika bedömning och prisavdrag på Produkt, teknisk lösning och funktion. Det kunde likaväl blivit Cygate. IBM dock var långt mycket dyrare, vilket de brukar vara. Men HP ville uppenbarligen ha affären.

Alla dokumenten finns här om du vill läsa in dig på detaljer:
http://www.nyakarolinskasolna.se/sv/...infrastruktur/

Upphandlingen avbröts en gång för att första anbuden som kom in översteg budget långt mer än vad man räknat. Därefter delade man upp upphandlingen. Hur man delade den framgår inte.

http://www.nyakarolinskasolna.se/sv/...nfrastruktur-/

HP är minst lika proffsiga som Cygate och IBM. Jag tror mer på som Obyn redan berört att man varit dumsnål och kanske återanvänt gammal utrustning. Som sen havererat och inte orkat med de nya förutsättningarna som nätet kommer ha i Nya KS.
__________________
Senast redigerad av helofin 2018-02-24 kl. 12:34.
Citera
2018-03-06, 13:08
  #24
Medlem
Megaforces avatar
Citat:
Ursprungligen postat av studioxswe
Jag cyklar ofta så där har du helt rätt.
Hemma kör jag en EX3300 som core switch samt två stycken EX2300 som access, självklart med 10GE upplänkar. All L3 sker i min EX3300. Jag kör ett par routing-instanter, DMZ, Server, Office osv. All trafik mellan routing-instanter måste gå till FW (som är ett vSRX kluster). Kör både IPv4 samt IPv6, OSPF som routing-protokoll internt, statiskt och BGP-4 externt. Så jag kör nog mer enterprise än många.. enterprise.

Kod:
loophole> show ospf neighbor instance all   
Instance: master
Address          Interface              State     ID               Pri  Dead
192.168.169.13   ge-0/0/1.0             Full      192.168.169.104  128    34
192.168.169.5    ge-0/0/2.0             Full      192.168.169.102  128    32
192.168.169.17   ge-0/0/4.0             Full      192.158.169.106  128    33

Jag administrerar ett nät med ett par tusen noder, vi kör all L3 i access med VRRP mellan två separata VC, kan uppgradera vilken komponent som helst i nätet utan störning. Har ganska många routing-instanter (eller VRF som cisco folk förstår) och således en hel del säkerhetszoner i fw klustret. Tidigare körde vi flat L2 överallt, med intra-vlan "routing"

Vi har ingen större administration, vi har ett webbgränssnitt som pratar med IPAM. Vi har MYCKET broadcast-trafik då en stor del av utrustningen använder det som primär kommunikationsväg.

Vad som gick fel på KS har jag ingen aning om, men även stora bolag kan få problem men något har man inte testat eller knopat rätt. Innan vi gör en större ändring testar vi det i vårt labb, som kör samma switcher som prod.

På jobbet har vi runt 40000 noder inkl wifi. Nu är jag inte helt insatt i grundarkitekturen men vi har fyra core-switchar samt två mot internet som leverantören står för (10 Gb på vardera). 20 Gb etherchannel mellan dessa och de core-switcharna vilket gör att vi kan ha max 20 Gb trafik mot internet via redundanta vägar (core-switcharna står i olika maskinhallar, totalt fyra st vilket gör att redundansen är rätt bra och en störning drabbar inte hela nätet samtidigt). Svagheten är att olika hallar har olika nivåer på dieselkraft (två av hallarna befinner sig 300 meter från varandra men delar samma dieselkraftverk. Vid långvarigt strömavbrott kan vi ha igång 2 maskinhallar i över en vecka och ca 20% av nätverket.

Vad jag förstår av NKS så är problemet att man bara har enkel redundans i samma maskinhall, dvs ett lokalt problem kan lätt sprida sig till redundansen. Man verkar också sakna reservnät som kan användas för drift av kritiska funktioner.
Citera
  • 1
  • 2

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback