skrevet af i Netværk

Ingen kommentarer

I den første artikel i denne serie, undersøgte jeg processen hvor sender bliver registreret i PIM, og vi sluttede ved situation hvor RP er bekendt med senders eksistens. Jeg identificerede tre mulige scenarier på dette punkt, og i dag vil vi undersøge scenarie, hvor sender er registreret, men der er ingen modtagere som er interesseret i at modtage denne trafik. For at fortsætte undersøgelsen af PIM sender registrerings processen, vil vi bruge følgende diagram, der anvendes i den foregående artikel.

PIM_Reg1

Vi stoppede vores analyse på det tidspunkt, hvor sender er registreret hos RP. Men på dette tidspunkt, har sender endnu ikke tilsluttet sig den gruppe som er annonceret i staten, hvilket betyder, at RP er ikke bekendt med at dette overhovedet eksisterer. Multicast-trafik indkapslet som unicast som sendes fra FHR og behandles af RP er unødvendig. På grund af det, RP vil straks begynde at kassere denne trafik og sende unicast svar tilbage til FHR at stoppe med at sende det. Dette er den såkaldte “PIM Register Stop”. Når FHR modtager denne besked, vil den straks stoppe unicasting af multicast trafik fra sender til RP og begynde at også at kassere den. På billedet nedenfor har vi de trin fra PIM Registrerings proces, så lad os kigge kronologisk på dem.

PIM_Reg2

1. På dette tidspunkt (efter trin 4 i første artikel) indser RP at der ikke er direkte eller indirekte forbundne modtagere som er villige til at modtage trafik sendt til gruppe G. Det straks kasserer alle pakker, som sagt, men (S, G) tilstand, opbevares på RP.
2. Unicast meddelelse sendes til FHR at stoppe at sende de unicastede multicast registrering pakker.
3. FHR stopper registreringsprocessen og begynder straks at kassere indkommende pakker fra sender. Omregistrering timeren begynder at tælle ned fra 180 sekunder (3 minutter).
4. Sender er uvidende om noget foregår på FHR, og det heldigvis holder på at sende multicast trafik til FHR.

Jeg vil gerne påpege et punkt i trin # 3: Omregistrering timer. Så længe sender fortsætter til at sende multicast trafik til FHR, vil registreringsprocessen gentage hvert tredje minut. Grunden til dette er behovet for at opretholde RP informeret om tilstedeværelsen af kilden. Hvis sender stopper at sende multicast trafik i mellemtiden, vil både FHR og RP mister deres (S, G) hedder.
Hvad sker der, når kunden endelig slutter sig til gruppen? Lad os tage et kig. Jeg vil starte denne forklaring med et billede og tale igennem den.

PIM_Reg3

1. Mens sender (punkt 0) fortsat at sende, multicast trafik, modtager slutter sig til gruppe G ved hjælp af IGMP join.
2. Modtagers medlemskab rapport vil medføre Modtager router/DR (og alle andre PIM routere på segmentet) til at skabe lokal (*, G) tilstand, med modtager-vendende interface i udgående interface liste (olist) for (*, G).
3. DR genererer PIM join for (*, G) gruppe og sende den mod den kendte RP-adresse til gruppe G.
4. Da RP har (S, G) stat registreret i forvejen, og i kraft af multicast regler associerede (*, G) indgang i denne tabellen, vil det tilføje nedstrøms interface til DR, til udgående interface liste (olist) for denne (S, G). RP sender (S, G) join til sender via FHR at slutte dette mod sender.
5. FHR modtager join fra RP og tilføjer interface nedstrøms for RP til olist for (S, G). FHR stopper at kassere indgående multicast trafik sendt af vores sender og sender den videre ud fra alle de registrerede interfaces i “olist” for (S, G).
Bemærk: Join bliver ikke sendt fra FHR til sender, da der, som vi har snaget for, sender ved ikke hvad det foregår op i hierarkiet og hele tid sender multicast trafik mod FHR.
6. RP modtager nu multicast trafikken fra FHR, og den sender det ud til alle interfaces i “olist” for (S, G).
7. DR nu modtager trafik og videresender trafik ud alle interfaces i olist for (*, G), som har den virkning at modtageren modtager trafik som sendes af sender i gruppen (S,G).

Næste gang, vil vi tage et kig ind i, hvad der sker, når modtagere melder at de vil deltage i gruppen, og få multicast trafik, men der er ingen sender. God fornøjelse!

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

skrevet af i Netværk

Ingen kommentarer

Hej alle sammen! Efter kortere pause fra arbejde her på side, pga. af mine forpligtelser, jeg vender nu tilbage og vil gerne starte endnu en emne som kan være guldåre eller værste mareridt i konfiguration af netværk.

IP Multicast routing er et af de emner hvor flest af netværks folk altid kæmpe med. Gennem den her artikel, vil jeg snakke om en af de “tynge” emner, netop Multicast routing og præcis om PIM udgave. Her vil jeg ikke forklare det grundlegende om Multicast eller hvad PIM er. Jeg vil undersøge sender (Source) registrerings processen. Dette er en af tre stillinger, som jeg vil undersøge i denne proces. Først vil jeg kigge lidt hvad er sender registrering? I Sparse-mode Multicast netværk, et af de design mål er at begrænse den mængde trafik, der unødvendigt sendes (oversvømmet) i hele topologi.
Oversvømmelser som jeg taler om, er den proces, der anvendes af Dense -mode Multicast til at “informere” Multicast routere om tilstedeværelse af Multicast sender (Source). For at opsummere hurtigt, i Dense-mode netværk, når sender begynder at sende trafik, vil disse data blive at oversvømme hele netværket og derefter beskæres fra dele, hvor det ikke er nødvendige, dvs. hvor der ikke er modtager (Client), der søger at modtage denne trafik. Denne oversvømmelse-and-prune proces gentages hver tredje minutten. Dette er ikke en optimal proces, men det løser problemet med bevarelse af små Multicast routing tabeller i routere og hjælpe at give sender oplysninger til alle routere i topologi.
I Sparse-mode netværk, er ideen at holde små Multicast router tabeller og samtidig at undgå oversvømmelse-and-prune proces, som vi har i Dense-mode, når det er muligt. For at opnå dette mål, har vi behov for en mødested (Rendezvous point – RP), så routere med sendere kan registreres der. Samtidig der er sted, hvor routere med modtagere kan kigge efter aktive sendere. Dette møde sted er en router, der er udpeget til at være mødested (RP).
RP er routeren som har viden om alle aktive sendere i netværket. For at nå dette mål, alle routere, der har direkte knyttet sendere skal registrere dem hos RP. Denne registrering er selvfølgelig “PIM Register” som jeg vil gerne forklare i dag.

Nedenfor har vi et netværk som vi kan bruge til vores gennemgang af problematikken:

Som vi kan se på diagrammet, vil vi bruge eksempel med tre routere og to andre enheder hvor:
• Multicast sender deltager ikke i Multicast routing, dvs. det behøver ikke at køre hverken PIM eller IGMP.
• Multicast modtager vil anmode trafik for en bestemt gruppe med IGMP.
• De tre Multicast routere er konfigureret til at køre PIM Sparse-mode blandt dem.

Alt i alt er dette et temmelig grundlæggende IP Multicast routing topologi.

Men, vi kan ikke begunde med læring uden at vi stiler første spørgsmål:
Hvordan sender registrerer sin eksistens hos RP, hvis denne deltager ikke selv i Multicast routing?

Svaret er simpelt – det gør den ikke. Alt som sender har behov for, er at være i stand at generere IP-trafik med destination IP-adresse. I dette her tilfalde der er IP-adresse i en gyldig IP Multicast område: 224.0.0.0 / 4 (224.0.0.0 – 239.255.255.255).

Næste spørgsmål:
Hvis sender ikke registreres hos RP, hvordan så RP vide om det?

Dette er et af de ansvarsområder som ”ligger” hos første hop router, eller routeren, som er direkte forbundet til sender. Når en Multicast sender begynder at sende trafikken, og denne trafik når første-hop-router, vil denne router gøre flere ting.

1. Sender begynder at sende trafikken.
2. Multicast state (S, G) er skabt på FHR, hvor S er sender IP-adressen, og G er gruppen adresse (multicast destination IP-adresse af pakkerne).
3. Multicast trafik er indkapslet i unicast pakker og sendes mod RP.
4. Ved modtagelse af unicast trafik og afkapsler originale multicast-pakker, opretter RP lokal (S, G) tilstand
Bemærk at der ikke vil være multicast-trafik som nu videresendes i retning af RP – det vil være unicast. Denne unicast trafik er sender registrering. Vi kan sige disse ting kommer til at ske “samtidigt”, men i virkeligheden sker i rækkefølge. Det er vigtigt at holde dette i tankerne, når I kommer at fejlfinde i levende netværk! Her, for lab miljø, kan vi behandle disse som samtidige begivenheder.

Som vi kan konkludere, på dette tidspunkt, ved afslutning af punktet 4. er sender registreret hos RP. Hvad der sker herefter, afhænger af, om RP har kendskab til modtagere, der ønsker at modtage denne trafik eller ej. Dette efterlader os med følgende muligheder:
• Sender begynder at sende trafik, før der er nogen interesserede modtagere (klienter).
• Modtagere tilmelder sig gruppen, før sender begynder at sende.
• Der er kunder direkte forbundet til FHR eller RP.

Disse vil jeg snakke ved de neste artikler og forklare grundig teoretisk set.
Inden da god fornøjelse og held og lykke med Multicast routing.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

skrevet af i Ikke kategoriseret

Ingen kommentarer

Fra i dag byder vi velkommen til Christian Aagaard Nielsen som ny blogger her på ikanovic.dk.

Christian kommer fra Alsion i Sønderborg – Sønderjyllands viden- og kulturcenter (en del af Syddanskuniversitet), og vil gerne skrive indlægs til server HW og SW (http://ikanovic.dk/category/server/)

God fornøjelse!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

skrevet af i Netværk

Ingen kommentarer

Hvad er Cisco ASA Identity Firewall?

Traditionelt Cisco ASA policy og rules håndhæves primært ved hjælp af en Access Control List (ACL), som tillader eller afviser adgang til visse netværksressourcer baseret på source / destination IP-adresser og portnumre. For eksempel, lad os sige vi ønsker source IP 10.1.1.1 at kunne få adgang til serveren med IP 10.2.2.2 og port 80. Vi ville skabe en post på en ACL hvori det hedder udtrykkeligt, at den specifikke source IP er tilladt adgang til den specifikke destination IP på port 80.

Fra Cisco ASA udgave 8.4 (2), er begrebet Identity Firewall indført. Dybest set, den nye funktion gør det muligt for firewall til at tillade eller nægte adgang til netværksressourcer baseret på username identity i stedet for en simpel source IP-adresse. For eksempel, nu kan vi oprette roules, der siger user “Claus” kan få adgang til serveren 10.2.2.2 på port 80. Som I kan se, den nye funktion introduceret begrebet “user-based authentication” (“user-baseret godkendelse”) i stedet for ren “IP based authentication” (“IP-baseret godkendelse”).

Den måde, denne funktion virker, er at integrere Cisco ASA med Microsoft Active Directory. En særlig Active Directory Agent software skal installeres på en server (normalt installeret fra selve AD). Denne agent giver brugernavn til IP-adresse mappings til ASA. Så når user “Claus” logger ind på AD, vil agenten hente IP-adressen på den computer, Claus bruger (dvs. 10.1.1.1 at være i overensstemmelse med vores eksempel ovenfor). Så vil ASA vide, at brugeren Claus har IP-adresse 10.1.1.1 og vil gælde net regler i overensstemmelse hermed.

Andre netværksfirewalls såsom Fortinet, Checkpoint, Palo Alto osv. kunnet tilbyde “user-based authentication” funktion i lang tid nu. Cisco er ved at indhente tiden på dette fra sidste år, for glade af os alle sammen.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

skrevet af i Ikke kategoriseret

Ingen kommentarer

Nu er IP-telefoni og VoIP vejledning lavet med Cisco Jabber til mobile Android brugere samt Cisco ASA QoS til VoIP opsætning for administratorer. Efter nogen har behov for lid Windows agtigt vejledning, jeg kan lave også vejledning til CallManager Express GUI Software installation og konfiguration.

CallManager Express GUI

God fornøjelse!

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

skrevet af i Hardware

Ingen kommentarer

Mange virksomheder producerer high-speed SSD’er, men det trick at producere en vinder er at afbalancere høje niveauer af ydeevne med en pris, der er lav nok til at friste entusiaster til at åbne deres tegnebøger.
SandForce er en af de største navne, når det kommer til SSD-controllere, men under kølerhjelmen fra Performance serien Pro, har Corsair valgt en Marvell 88SS9174 chip. Det er en usædvanlig afgørelse truffet hvor mange drev bruger SandForce hardware, men afgørende, det er den samme controller bruges af M4-drev, så det har masser af stamtavle når det kommer til at flytte data hurtigt.

Corsair er gået imod strømmen, når det kommer til hukommelsen også. De anvendte chips er stadig lavet af velkendte MLC-hukommelse, men de 32nm moduler er Toshiba-made “Toggle Mode” NAND chips snarere end de synkrone chips bruges på de fleste andre SSD’er. Toshiba hævder disse kan behandle flere dataoverførsler per sekund, og der er bakket op af en konsekvent hastighed.
Dens resultat af 500.9MB/sec i store fil skrive benchmark er fremragende, let overgår 387.4MB/sec score af Crucial M4, og begge SSD’er returnerede fine scoringer af 320MB/sec når du læser store filer. Corsaren også imponeret ved håndtering af små filer: dens skrive og læse resultaterne af 186.4MB/sec og 30.4MB/sec var bedre end M4 s 167.4MB/sec og 29.7MB/sec hastigheder.
Corsaren er også hurtigere end sin rival i AS SSD sekventiel skrivehastighed test med et resultat af 413.85MB/sec, og det fulgte det op med fremragende tempo i resten af den app tests.
Det er konsekvent rå hastighed, og det er afbalanceret med en konkurrencedygtig pris. Det gør Corsair ydeevne Pro den bedste SSD vi har endnu ikke set, især for entusiaster, der ønsker top-kvalitet. M4 er stadig et fint budget valg, men hvis du søger efter det bedste en SSD kan tilbyde, efter min mening og varmt anbefaling, Corsair Performance serien Pro er det.

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

skrevet af i Software

Ingen kommentarer

Er der sikkerhed huller i Microsofts nye barn i familien, netop Windows 8 styresystem?

Måske og måske ikke, det kommer vi at se, men ifølge flere sikkerhedseksperter er det ikke tilfældet. Personlig jeg vil ikke læne sig tilbage og forvente, at alt er helt beskyttet.

En af de nyheder(gamle sager) som er indbygget i nye styresystemet heder Windows Defender. Ja, og hvad er fidus? Windows Defender i højere grad end tidligere beskytter mod malware fremfor kun spyware. Det betyder, at den almindelige bruger har et vist niveau af sikkerhed fra dag ét.

Ifølge Aryeh Goretsky, sikkerhedsanalytiker i firmaet ESET betyder det at:
“Windows Defender giver en god beskyttelse, men er primært rettet mod dem, der er uvillige eller ude af stand til at købe en kommerciel antimalware-løsning. Denne form for beskyttelse er bedre end ingen, og Microsoft skal have ros for at inkludere et produkt af denne kaliber i Windows 8. Windows Defender kan betragtes som den mindste bar for niveauer af beskyttelse,” skriver han i gennemgangen af Windows 8-sikkerheden.

Ja, det er fint, de begynder at tænker lidt på almindelige brugere frem for at skovle penge i huset, men slipper vi for at patch-opdatere sit system? Nej, det gør vi IKKE! Og oveni tredjeparts programmer som fx. Adobe Acrobat er stadigvæk afhængige at producenterne udvikler opdateringer til de sårbarhers huller.

Microsoft har også en anden sikkerhedsforanstaltning – brugen af digitale certifikater. Det betyder, at man ikke kan boote kompromitterede Windows-installationer. Den regulering i Windows 8 betyder at systemet foretager en såkaldt Secure Boot.
Hvad er det for noget?
Det betyder, at boot loaderen skal signeres med en nøgle, før maskinen kan starte. Det vil blokere for ikke-signeret kode som betyder at man kan stoppe ondsindet software. En af eksempler er rootkits, der spionerer på maskinen på enkelt spørg sagt at overtage boot-processen. Internet Explorer 10 kommer med Windows 8 og er også blevet sikkerhedsopdateret i forhold til de tidligere versioner Microsoft browsere. Og det nye Early Launch Anti Malware (ELAM) skanner operativsystemet for malware. Samtidig sørger ELAM at antivirusprogrammet afvikles som det første på den ny-bootede maskine, så brugeren får en sikker start. For mig, kort sagt, lower level-sikkerheden er væsentlig strammet op i Windows 8 meeeeeen, jeg vil ikke læne sig tilbage og vente! 

VN:F [1.9.22_1171]
Rating: 4.5/5 (4 votes cast)

Campus L3 design

nov
2012
14

skrevet af i Netværk

Ingen kommentarer

Den hierarkiske campus design bruger en full mesh equal-cost path routing design for at udnytte Layer 3 switching i Core og mellem Distribution layers af nettet i mange år. I den nuværende hardware, Layer 2-switching og Layer 3-routing udføres med samme hastighed, men Cisco anbefaler et routede Core netværk i alle tilfælde. Routede Core netværk har talrige fordele, herunder følgende:
• Høj tilgængelighed
—Deterministiske konvergens tid for et link eller node svigt i et equal-cost path Layer 3
design på mindre end 200 ms
—Ingen mulighed for Layer 2 Spanning Tree loops

• Skalerbarhed og fleksibilitet
—Dynamisk trafik load balancing med optimal path udvælgelse
—Strukturerede routing tilladelser til brug af modulært design og nem vækst

• Forenklet og fejlfinding
—Forenklet routing design letter operationel støtte
—Fjernelse af behovet for at foretage fejlfinding L2/L3 interaktioner i Core

De mange fordele ved Layer 3-routing i campus stammer fra routing protokoller kombineret med fleksibilitet og ydeevne af Layer 3 hardware switching. Den øgede skalerbarhed og robusthed Layer 3 Distribution / Core design har vist sig som bedste i mange kundes netværk gennem årene og er fortsat at være den bedste praksis anbefaling til campus design.

De mange potentielle fordele ved at anvende Layer 3 Access konstruktion omfatter følgende:

• Forbedret konvergens
• Forenklet multicast konfiguration
• Dynamisk trafik load balancing
• Enkelt kontrol plan
• Enkelt sæt fejlfindingsværktøjer (f.eks. ping og traceroute)

Af alle disse er den mest betydelige måske forbedringen konvergens tider i nettet, ved hjælp af en routede Access design konfigureret med EIGRP eller OSPF som routingprotokol. Sammenligning af konvergens tider for en optimal Layer 2 Access design (enten med en Spanning Tree loop eller uden) mod det færdige Layer 3-Access design, viser at her kan man få en firedobbelt forbedring i konvergensen tider, fra 800-900msec for Layer 2, til mindre end 200 ms for Layer 3 access.

 

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)