Virtuell polygon på flera nivåer på en persondator

Artikel:

För närvarande är virtualiseringstekniker en integrerad del av IT-världen. Förutom den industriella tillämpningen av virtuell maskinteknik, som gör att du kan minska den totala ägandekostnaden för IT-infrastrukturen, som har skrivits av alla och en del i flera år, används tekniken också i stor utsträckning för att studera eller testa system, nätverk och applikationsprogramvara.

De flesta publikationer handlar oftast om virtualisering på första nivån. På en eller flera fysiska datorer anslutna via riktiga nätverk, baserat på viss virtualiseringsprogramvara, finns det många virtuella maskiner (VM) anslutna av virtuella nätverk (även emulerade med virtualiseringsprogram), som vid behov kommunicerar med riktiga nätverk via nätverksadaptrarna av de fysiska datorerna. Med andra ord, nivån på verkliga enheter och en nivå av virtuella objekt (vanligtvis maskiner på grundval av vilka vissa operativsystem fungerar) övervägs oftast. Det är sant, för att vara mer exakt, i exemplen som behandlas i publikationerna, objekt från den andra eller djupare nivån av virtualisering är implicit närvarande, men författarna fokuserar nästan aldrig på detta.

Tänk på följande nätverk, som uppfanns enbart för ett exempels skull och i sig inte har något speciellt praktiskt värde (var och en kan välja vilket annat exempel som helst för sig själv, inklusive från verklig praktik). Det finns två företag, var och en med ett huvudkontor med en server på en geografisk plats och ett filialkontor med en arbetsstation på en annan geografisk plats. Geografiska punkter delas av vissa MPLS-ryggrad baserat på Cisco-routrar. För varje företag organiseras en Layer 2 VPN separat mellan huvudkontoret och filialen med hjälp av Ethernet over MPLS (EoMPLS) teknologi för möjlighet till "transparent" kommunikation vid datalänkslagret (Ethernet) mellan arbetsstationen och servern via MPLS-ryggrad.
Den fysiska strukturen för nätverket i fråga visas nedan.

Den logiska strukturen för interaktion mellan arbetsstationer och servrar i det aktuella nätverket visas också nedan. I vart och ett av företagen kan arbetsstationen och servern "transparent" interagera med varandra och är isolerade från ett annat företags arbetsstation och server.

Problemet är att detta nätverk måste modelleras och testas, i synnerhet interaktionen mellan arbetsstationer och servrar genom EoMPLS-miljön, och allt detta måste göras med en enda persondator. Detta är en ganska bekant situation för de flesta specialister inom system- och nätverksteknik, som står inför en liknande uppgift och som i regel inte har några extra datorer till hands, och ännu mer Cisco-routrar.

Tja, riktiga datorer ersätts lätt av virtuella maskiner som skapats och körs med en eller annan programvara som implementerar virtuell maskinteknologi, till exempel samma VMware Workstation 6.0 (i den här artikeln undersöker författaren multi-level virtualisering med denna programvara som en exempel). Den populära Dynamips-simulatorn är väl lämpad för modellering av Cisco-routrar med EoMPLS-stöd (samt en bekväm och intuitiv grafisk miljö för den - GNS3). Men ett problem uppstår: det är möjligt att separat simulera virtuella maskiner med "riktiga" fullfjädrade MS Windows-operativsystem installerade på dem, och separat - Cisco-routrar med "riktiga" fullfjädrade Cisco IOS-operativsystem, men hur man länkar de två simuleringsmiljöerna över nätverket?

Ändå finns det en väg ut ur situationen. I VMware Workstation kan du binda virtuella VMnet-switchar till nätverksadaptrarna på en fysisk dator (med hjälp av verktyget Virtual Network Editor) och virtuella nätverkskort för virtuella maskiner respektive binda till motsvarande virtuella VMnet-switchar (när du konfigurerar en virtuell maskin ). Nedan är ett exempel på en sådan bindning genom den virtuella switchen VMnet0:

I sin tur, i GNS3-miljön baserad på Dynamips, finns det ett objekt av typen "Cloud", som också kan projiceras på nätverksadaptrarna på en fysisk dator. Objektet kan sedan anslutas till nätverksgränssnitten för andra objekt i GNS3-miljön, inklusive gränssnitten för Cisco-routrar. Det bör särskilt noteras att ett objekt av typen "moln" inte i sig är någon fullfjädrad virtuell enhet - det är bara en virtuell "gemensam punkt" (som en kontakt på en patchpanel), vilket ur nätverkssynpunkt kan projiceras på något, till exempel till nätverksadaptern på din dator. Framöver noterar vi också att "Dator"- och "Server"-objekten som används i GNS3-miljön också är objekt av typen "Cloud" (enkla "gränssnittspunkter" med motsvarande ikoner för tydlighetens skull), och inte alls något slag av dator- eller serveremuleringsprogram, som till exempel görs i träningssimulatorn Cisco Packet Tracer.

Nedan är ett exempel på projektion av ett objekt av typen "Cloud" C0, anslutet till nätverksgränssnittet för router R0 i GNS3-miljön, på nätverksadaptern på en fysisk dator:

Oerfarna specialister kan bli förvirrade av en lång kod (nätverkstransportidentifierare tilldelad av MS Windows för en nätverksadapter) i inställningarna, och för att inte bli förvirrade i namnen på nätverksanslutningen, namnen på nätverksadaptern, MAC:n adress till adaptern och dess identifierare, kan du använda den inbyggda MS Windows med hjälp av GETMAC-verktyget som startas med V-tangenten (Verbose - detaljerad information):

Genom sådan "tvåvägsprojektion" vid OSI-datalänkslagret (i själva verket Layer 2 Bridging) på samma nätverksadapter på en fysisk dator, kan virtuella routrar i GNS3-miljön baserade på Dynamips interagera med virtuella maskiner i VMware Workstation-miljön på Ethernet-nivå (detta har verifierats experimentellt många gånger). Tyvärr finns det inget sätt att direkt länka VMnet-switchar från en VMware-miljö till objekt av typen "Cloud" (junction points) från GNS3 baserade på Dynamips (åtminstone utan att använda någon speciell programvara).

Nu uppstår en ny hake: antalet nätverkskontaktpunkter mellan en VMware-miljö och en Dynamips-miljö kan vara långt ifrån en, men flera (i det här exemplet finns det 4 av dem - två arbetsstationer och två servrar), medan de är på en fysisk dator det kan vara en eller två eller inga nätverkskort alls. Dessutom är anslutning till nätverksadaptrarna på en fysisk dator inte den vettigaste idén ur säkerhetssynpunkt i alla fall. Slutligen, vi strävar inte särskilt efter att placera allt på den första nivån av virtualisering, syftet med denna artikel är multi-level virtualisering.

I den här situationen kommer vi att ta till följande enkla knep: ingen stör oss att skapa en annan virtuell extra maskin med det erforderliga antalet nätverkskort (liksom många kontaktpunkter), installera ett OS på den och viktigast av allt - GNS3-programvara baserat på Dynamips. Sedan, redan i GNS3, skapa, konfigurera och starta nätverket som krävs för modellering baserat på Cisco-routrar. Således "flyttar" Cisco-routrar till den andra virtualiseringsnivån (den första är den virtuella extramaskinen själv). Nätverks "touchpoints" kommer att implementeras genom motsvarande objekt av typen "Cloud" (kontaktpunkter) i GNS3 baserat på Dynamips, knutna till motsvarande nätverkskort i den virtuella CISCONET-maskinen, som i sin tur är bundna till motsvarande VMnet virtuella switchar som vi kan ansluta andra virtuella maskiner till. I vårt exempel kommer vi att använda en virtuell CISCONET-hjälparmaskin med 4 nätverksadaptrar (VMware Workstation 6.0 stöder upp till 10 nätverksadaptrar per virtuell maskin) bundna till motsvarande virtuella VMnet-switchar.

Således kommer vi fram till två nivåer av virtualisering: VMware-infrastruktur inuti en fysisk dator (1:a nivån av virtualisering), och Dynamips-infrastruktur inuti en extra virtuell maskin (2:a nivån av virtualisering).

Slutligen, om vi kommer ihåg att EoMPLS också är en slags virtualisering med hjälp av Cisco IOS, kommer vi att se att det i exemplet under övervägande också finns en tredje nivå av virtualisering. Virtualization Layer 3 innehåller MPLS virtuella moln och virtuella kretsar ovanpå molnet, som emuleras av Cisco IOS på två Cisco-routrar.

Som ett resultat får vi följande virtualiseringsschema med flera nivåer:

Som framgår av diagrammet ovan är experimentatorns dator i nivå med verkliga objekt och ur nätverkssynpunkt helt isolerad från virtuella maskiner och virtuella routrar, vilket är ganska rimligt och korrekt. Den första virtualiseringsnivån tillhandahålls av programvaran VMware Workstation, på denna nivå finns virtuella arbetsstationer (WINPC1, WINPC2), virtuella servrar (WINSRV1, WINSRV2) och den extra virtuella CISCONET-maskinen, såväl som virtuella switchar VMnet3-VMnet6. Den andra nivån av virtualisering tillhandahålls av mjukvaruverktyget GNS3 baserat på Dynamips, som körs på den virtuella CISCONET-maskinen; på denna nivå finns det Ciscos virtuella routrar (R1, R2), såväl som SW1-SW4 virtuella switchar anslutna till motsvarande nätverksgränssnitt för routrarna (R1, R2). Nätverk mellan den första och andra virtualiseringsnivån utförs genom "tvåvägsprojektion" vid OSI-länklagret: virtuella switchar VMnet3-VMnet6 är bundna till motsvarande LAN1-LAN4-nätverksadaptrar på den extra virtuella CISCONET-maskinen och motsvarande portar av virtuella switchar SW1-SW4 genom motsvarande objekt av typen "Cloud" (de visas inte i diagrammet, eftersom de i huvudsak är enkla "gränssnittspunkter" och inget mer), är också bundna till motsvarande LAN1-LAN4 nätverksadaptrar för den extra virtuella CISCONET-maskinen. Slutligen tillhandahålls den tredje nivån av virtualisering med hjälp av Cisco IOS-operativsystemet som körs på virtuella routrar, på denna nivå är det virtuella MPLS-molnet och virtuella kedjor (VC 111, VC 222) som använder EoMPLS-teknik. EoMPLS virtuella kedjor projiceras med hjälp av själva Cisco OS på motsvarande gränssnitt för virtuella routrar (R1, R2) och ger därmed nätverksinteraktion mellan den andra och tredje nivån av virtualisering.

Låt oss nu gå direkt till resultaten av att modellera denna flernivåstruktur på en persondator. Så här ser allt ut efter att ha skapat, konfigurerat och startat virtuella maskiner, inklusive CISCONET, i vilket ett nätverk med Cisco-routrar också skapades, konfigurerades och lanserades:

Det finns fyra nätverkskort i den virtuella CISCONET-maskinen: LAN1, LAN2, LAN3 och LAN4, som är bundna till motsvarande virtuella switchar VMnet3, VMnet4, VMnet5 och VMnet6. I sin tur är nätverksadaptern för den virtuella maskinen WINPC1 bunden till den virtuella switchen VMnet3, nätverksadaptern WINPC2 till VMnet4, nätverksadaptern WINSRV1 till VMnet5 och nätverksadaptern WINSRV2 till VMnet6. Så här implementeras en sida av beröringspunkterna: de virtuella maskinerna WINPC1, WINPC2, WINSRV1 och WINSRV2 kan kommunicera med den virtuella maskinen CISCONET genom motsvarande nätverksadaptrar på denna maskin. Det är mycket viktigt att notera att all växling eller routing mellan nätverksadaptrar för en virtuell CISCONET-maskin som använder MS Windows själv på denna maskin, per definition, bör vara förbjuden. I sin tur kör CISCONET-maskinen en GNS-miljö baserad på Dynamips, där två virtuella Cisco-routrar körs. Motsvarande routergränssnitt är anslutna till motsvarande virtuella switchar SW1, SW2, SW3 och SW4 (inte att förväxla med virtuella switchar VMnet), och switcharna är i sin tur anslutna till motsvarande objekt PC1, PC2, SRV1 och SRV2 (ej att förväxla med virtuella maskiner VMware med liknande namn). PC1, PC2, SRV1 och SRV2 är i huvudsak molnobjekt — enkla "gränssnittspunkter" som projiceras på motsvarande LAN1, LAN2, LAN3 och LAN4 nätverkskort för den virtuella CISCONET maskinen. Således är den andra sidan av beröringspunkter implementerad: motsvarande routergränssnitt kan också interagera med den virtuella CISCONET-maskinen via motsvarande nätverksadaptrar för denna maskin.

Nedan är en delillustration av hur de nödvändiga bindningarna implementeras mellan VMnets virtuella switchar och nätverksadaptrarna på den virtuella CISCONET-maskinen, såväl som mellan objekten PC1, PC2, SRV1 och SRV2 (gränssnittspunkter) och nätverksadaptrarna i CISCONET virtuell maskin. Skärmdumpen visar ett fönster med konfigurationsfilen för den virtuella CISCONET-maskinen, som visar MAC-adresserna för nätverksadaptrarna och bindningen till VMnets virtuella switchar. Ett annat fönster visar tabellen över nätverksanslutningar för den virtuella CISCONET-maskinen och motsvarande namn på nätverksadaptrar (tilldelade i MS Windows OS på denna maskin), MAC-adresser för adaptrarna och identifierare för nätverkstransporten. Slutligen, i det tredje fönstret, visas anslutningen av PC1-objektet av typen "Cloud" (övergångspunkter) till motsvarande identifierare för nätverkstransporten för den virtuella CISCONET-maskinen.

För att inte bli förvirrad i nätverkskopplingarna mellan olika objekt på olika virtualiseringsnivåer kommer vi att sammanfatta dem i en visuell tabell:

Nätverk	VMware virtuella maskiner	VMware Virtual Switch	CISCONET nätverksanslutning	MAC-adress för CISCONET-nätverksadaptern	CISCONET nätverkstransportidentifierare	GNS3 molnobjekt	Virtuell switch i GNS3	Cisco virtuell router och nätverksgränssnitt	EoMPLS virtuell kedja
	Virtualiseringsnivå 1					Nivå 2			Nivå 3
1	WINPC1 CISCONET	VMnet3	LAN1	00: 0c: 29: 25: 1f: ac	C0E98EFF-BFA7- 472F-A5C0-A22293E1EE26	PC1	SW1	R1: FA0 / 0	VC 111
2	WINPC2 CISCONET	VMnet4	LAN2	00: 0c: 29: 25: 1f: b6	390F3C01-A168- 40D8-A539- 1E417F3D6E1B	PC2	SW2	R1: FA0 / 1	VC 222
3	WINSRV1 CISCONET	VMnet5	LAN3	00: 0c: 29: 25: 1f: c0	6577836B-60A3- 4891-931C- 232ED8B2F8F2	SRV1	SW3	R2: FA0 / 0	VC 111
4	WINSRV2 CISCONET	VMnet6	LAN4	00: 0c: 29: 25: 1f: ca	7834C67F-12F2- 4559-BEF4- C170C3E0B7DC	SRV2	SW4	R2: FA0 / 1	VC 222

Låt oss nu gå vidare till testresultaten. I skärmdumpen nedan kan du se att respektive arbetsstationer och servrar "ser" varandra över nätverket (inklusive att använda nätverkstjänster som använder sändningsförfrågningar) genom MPLS-molnet, tack vare de virtuella EoMPLS-kedjorna. Nätverksspecialister kommer också att vara intresserade av att titta på MPLS-växlingstabellerna och tillståndet för de virtuella EoMPLS-kretsarna på Cisco-routrar. Den andra skärmdumpen visar att de virtuella kedjorna (VC 111, VC 222) fungerar framgångsrikt och ett visst antal byte har överförts i båda riktningarna:

Således låter flerskiktsvirtualisering dig studera och testa olika exempel på nätverksinfrastruktur, effektivt med hjälp av datorresurserna på en persondator till hands, som idag ofta har en flerkärnig processor och RAM med stor kapacitet ombord. Dessutom möjliggör flerskiktsvirtualisering en mer flexibel allokering av datorresurser och kontroll över deras användning. Så, till exempel, i exemplet som diskuterats ovan, fungerar virtuella routrar inom beräkningsresurserna för en extra virtuell maskin, och inte en riktig dator, som det skulle vara i fallet med single-tier virtualisering.

Vänligen aktivera JavaScript för att se

Den nya virtualiseringsinfrastrukturen för Cisco Virtualization Experience Infrastructure (VXI) tar itu med fragmenteringen av befintliga lösningar som avsevärt komplicerar implementeringen av virtuella skrivbord. Dessutom förbättrar den nya infrastrukturen virtualiseringsmöjligheterna hos traditionella skrivbordssystem för multimedia- och videobehandling.

Cisco VXI hjälper dig att övervinna de huvudsakliga hindren som hindrar företag från att, utan att offra användarupplevelsen, skörda de ekonomiska fördelarna, dataskyddet och smidigheten med desktopvirtualisering, såväl som integrationen av multimedia och videosamarbete. Dessutom minskar Cisco VXI den totala ägandekostnaden för desktopvirtualiseringslösningar genom att dramatiskt öka antalet virtuella system som stöds av en enda server.

Analytiker förutspår desktopvirtualisering kan minska PC-supportkostnaderna med 51 procent (per användare), jämfört med 67 procent av PC-relaterade IT-budgetar. Virtuella stationära datorer hjälper också till att skydda företagets immateriella rättigheter genom att lagra information inte på fysiska användarenheter, utan i datacentret. Samtidigt kommer slutanvändare att självständigt kunna välja vilken enhet de ska få tillgång till sin virtuella dator med. Alla dessa fördelar, i kombination med ökad produktivitet och affärsflexibilitet genom multimedia- och videoapplikationer, tillför värde till nätverkslösningar för slutanvändare och företag.

Ciscos rekommenderade arkitekturer baserade på Cisco VXI inkluderar: Cisco Collaboration, Cisco Data Center Virtualization och Cisco Borderless Networks, och den bästa programvaran och utrustningen för desktopvirtualisering.

Följande Cisco-tekniker har testats för kompatibilitet med Cisco VXI-lösningen: Cisco Unified Communications-applikationer optimerade för virtuella miljöer och slutpunkter, inklusive Cisco Cius Tablet. Cisco Quad™-plattform; lösning för lastbalansering och optimering av arbetet med Cisco ACE-applikationer; Cisco WAN-accelerationsprogramvara; Cisco ASA multifunktionssäkerhetsutrustning; Cisco AnyConnect™ VPN-klient; enhetlig datormiljö Cisco UCS ™; switchar i Cisco Nexus®- och Cisco Catalyst®-familjerna för datacenter; flerskiktsswitchar för lagringsnätverk Cisco MDS; Cisco ISR-routrar.

Cisco VXI-lösningen inkluderar Citrix XenDesktop® 5 och VMware View ™ 4.5 desktopvirtualiseringssystem som tillhandahålls av industriledare Citrix och VMware. Den nya infrastrukturen stöder även hanterings- och säkerhetsapplikationer, lagringssystem från EMC och NetApp och många Microsoft-applikationer.

Cisco VXI-systemet stöder ett brett utbud av slutpunkter, inklusive Cisco Unified IP-telefoner, bärbara datorer, företagssurfplattor, inklusive Cisco Cius, och smartphones. Cisco har samarbetat med branschledaren Wyse för att optimera en rad hårdvaru- och mjukvarutekniker för att förbättra applikationernas svarstider i Cisco VXI-miljön och tillhörande arkitekturer. Genom att dra fördel av öppenheten i Ciscos ekosystem har DevonIT ​​och IGEL också testat sina enheter för kompatibilitet med Cisco VXI-lösningen.

Elementen i Cisco VXI-lösningen är designade och testade för att fungera tillsammans i en mängd olika installationer som bäst möter kundernas krav. Förutom flexibelt multimediastöd ger denna lösning kompatibilitet med ett brett utbud av användarenheter och åtkomstmetoder, vilket ger användarna flexibel valfrihet baserat på affärs- eller applikationskrav.

Cisco Desktop Virtualization Appliances optimerade för mediainteraktion

Cisco har tillkännagett två Cisco Virtualization Experience Client (VXC) apparater som stöder desktopvirtualisering i en "klientfri" form tillsammans med Cisco Unified Communications:

• Cisco VXC 2100 är en kompakt enhet som är fysiskt integrerad med Cisco Unified IP Phones 8900- och 9900-serien för att optimera användarens arbetsmiljö. Den stöder Power-over-Ethernet (PoE) och kan fungera med en eller två skärmar. Enheten har fyra USB-portar för anslutning av mus och tangentbord, vid behov för att arbeta i en virtuell miljö.
• Cisco VXC 2200 är en fristående, kompakt, strömlinjeformad, klientlös apparat som ger användare tillgång till ett virtuellt skrivbord och affärsapplikationer som körs i en virtualiserad miljö. Cisco VXC 2200 är designad med miljön i åtanke och kan drivas av antingen Power-over-Ethernet (PoE) eller en valfri strömkälla. Denna enhet har även fyra USB-portar och två videoportar, som kan användas för att ansluta de enheter som krävs för att arbeta i en virtuell miljö.

För att studera Cisco-kurser behöver du ibland arbeta med riktiga bilder, eftersom Packet Tracer inte alltid tillhandahåller alla funktioner vi behöver, är dess firmware kraftigt skuren. Då kommer GNS3 till undsättning, som jag skrev om tidigare. Det ska inte vara några problem att installera och lägga till bilder tycker jag.

GNS3

Därför kommer jag att beskriva en typisk konfiguration som vi kommer att återskapa:

Det är enkelt. På vår riktiga dator kör vi GNS3-emulatorn. Den kör en virtuell Cisco 2961, som håller fast vid en virtuell VirtualBox-maskin (till exempel Windows XP). Du kan bygga konfigurationer av vilken grad av komplexitet som helst, om resurserna tillåter, men vi stannar vid den här.

Så vad behöver vi? Först och främst skapar vi ett nytt gränssnitt i systemet för att slå in det i GNS3.

För att göra detta skapar vi ett nytt Loopback-gränssnitt, en Microsoft-adapter och mappar det till molnet i GNS3.

Jag beskrev hur man installerar en ny Loopback-adapter i videon:

Efter att ha skapat gränssnittet har vi en ny nätverksanslutning i den verkliga maskinhanteraren:

Jag döpte om det till LOOPBACK för att undvika förväxling med någonting.

Öppna nu GNS3:

Vi går in i inställningarna och konfigurerar VirtualBox-maskinen:

Rullgardinslistan innehåller alla maskiner som är installerade i gäst ViBox. Vi väljer det som intresserar oss. I det här fallet är det Windows XP.

Dra sedan objekten vi behöver till GNS3-fältet. Molnet (detta är gränssnittet till den riktiga maskinen), VirtualBox virtuella maskin och c2961-routern, vars bild (du kan ta från vår fillagring) redan har lagts till i hypervisorn.

Vi går in på inställningarna för vårt C1-moln. Här måste vi ange att det är associerat med ett befintligt LOOPBACK-gränssnitt.

Tyvärr har gränssnitten inkonsekventa namn, så du måste läsa noga för att inte ta fel. På samma sätt kan du förresten ansluta den virtuella Cisco i GNS3 till vilket annat gränssnitt som helst, oavsett om det är trådlöst eller WAN. Välj önskad, klicka på "Lägg till"

Vi kopplar ihop allt med anslutningar och lansering. VirtualBox virtuella maskin (Windows XP, vi har specificerat det) startar omedelbart. Där ställer jag upp nätverksgränssnittet, ger till exempel 192.168.200.2/24, och sätter * .1 som gateway, d.v.s. det kommer att finnas på routern.

Sedan i den riktiga maskinen öppnar jag LOOPBACK-egenskaperna och ger den en annan nätverksadress: 192.168.100.2/24, som inte korsar den virtuella maskinen. Tja, standardgatewayen är sig själv * .1 för detta subnät.

Här är en bild i slutet:

Anslut till router R1 och gå till konsolen:

Här har jag hängt IP-adresserna som motsvarar standardgateways för dessa maskiner (riktiga och virtuella)

Här är konfigurationen:

R1 # konf t
R1 (config) #int fa0 / 0
R1 (config-if) #ip-adress 192.168.100.1 255.255.255.0
R1 (config-if) #no shut
R1 (config-if) #exit
R1 (config) #int fa0 / 1
R1 (config-if) #ip-adress 192.168.200.1 255.255.255.0
R1 (config-if) #no shut
R1 (config-if) #exit
R1 (config) #

Det vill säga, från sidan av den riktiga maskinen hänger vi upp IP:n, som är standardgatewayen för Loopback-gränssnittet, och från sidan av den virtuella maskinen - IP, som är standardgatewayen för den virtuella maskinens gränssnitt.

Nu kan vi skicka en PING-förfrågan från en virtuell maskin till en riktig eller vice versa:

Nu kan vi installera lite WireShark eller lära oss att dirigera nätverket på ett annat sätt, om vi lägger till andra virtuella maskiner, adresser och LOOPBACK-gränssnitt! Lycka till!

Som ni vet publiceras ibland artiklar av våra goda vänner på bloggen.

Idag kommer Eugene att berätta om Ciscos routervirtualisering.

Det finns ett klassiskt nätverksorganisationsschema: åtkomstnivå (SW1, SW2, SW3), distributionsnivå (R1) och WAN-anslutning (R2). På router R2 samlas statistik in och NAT konfigureras. En hårdvarubrandvägg med trafikfiltrerings- och routingfunktioner är installerad mellan R2 och R3 (Figur 1)

För inte så länge sedan var uppgiften inställd på att migrera hela nätverket till en alternativ gateway (R4). Den nya gatewayen har klusterfunktionalitet och kan skalas horisontellt genom att öka antalet klusternoder. Enligt idrifttagningsplanen krävdes att det vid en viss tidsperiod fanns två gateways i nätverket samtidigt - den gamla (R2) - för alla klientnätverk, och den nya (R4) - för de nätverk som deltar i testningen av den nya gatewayen (diagram 2).

Försök att implementera PBR (Policy-based routing) på den interna routern (R1) misslyckades - trafiken slingrades. Ledningen avslog förfrågningar om ytterligare utrustning. Tiden gick, det fanns ingen router, uppgiften halkade ...

Och så kom jag över en artikel från Internet, som talade om isoleringen av routingtabeller på Cisco-routrar.

Jag bestämde mig för att skaffa en extra router med en oberoende routingtabell baserad på den befintliga hårdvaran. För att lösa problemet utarbetades ett nytt projekt (diagram 3), vilket innebär närvaron av en extra router med PBR-kapacitet.

Sammankopplingsnätverk mellan R1 och R5:

Netto: 172.16.200.0 / 30

Gränssnitt på R1: 172.16.200.2 / 30

Gränssnitt på R5: 172.16.200.1 / 30

VLANID: 100 - gammal router

VLANID: 101 - ny router

Notera: en virtuell router skapad på basis av R3 (Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9_NPE-M), Version 15.0 (1) M1, RELEASE SOFTWARE (fc1)) används som R5.

Router R3 har tre Gigabit Ethernet-portar, Gi0/0 används för intern routing, Gi0/1 används för att ansluta till en hårdvarubrandvägg och Gi0/2 används för att ansluta till en extern leverantör.

Låt oss gå vidare till att konfigurera R5-routern.

Gå till konfigurationsläget:
R3 (config) #ip vrf zone1
detta kommando skapar en isolerad routingtabell på routern. namn zon 1 väljs av administratören självständigt. Du kan också tilldela en identifierare och beskrivning. Mer information finns i dokumentationen. När vi är klara återgår vi till konfigurationsläget med kommandot utgång.

Konfigurera nätverksgränssnitt:
R3 (config) #interface GigabitEthernet0 / 0.100

R3 (config-subif) #encapsulation dot1Q 100
R3 (config-subif) #ip-adress 172.16.100.2 255.255.255.252
R3 (config-subif) #exit
R3 (config) #interface GigabitEthernet0 / 0.101
R3 (config-subif) #ip vrf vidarebefordran zon1
R3 (config-subif) #encapsulation dot1Q 101
R3 (config-subif) #ip-adress 172.16.100.6 255.255.255.252
R3 (config-subif) #exit
R3 (config) #interface GigabitEthernet0 / 0,1000
R3 (config-subif) #ip vrf vidarebefordran zon1
R3 (config-subif) #encapsulation dot1Q 1000
R3 (config-subif) #ip-adress 172.16.200.1 255.255.255.252
R3 (config-subif) #exit
Nu måste du konfigurera PBR. För att göra detta kommer vi att komponera en ACL, styrd av följande regel: alla som kommer in i ACL dirigeras genom den gamla gatewayen och resten genom den nya.
R3 (config) # åtkomstlista 101 neka ip-värd 192.168.3.24 någon
R3 (config) # åtkomstlista 101 neka ip-värd 192.168.3.25 någon
R3 (config) # åtkomstlista 101 neka ip-värd 192.168.3.26 någon
R3 (config) # access-list 101 tillåter ip vilken som helst
Skapa ruttkarta:
R3 (config) # ruttkarta gw1 tillstånd 50
R3 (config-route-map) #match ip-adress 101
R3 (config-route-map) #set ip vrf zone1 next-hop 172.16.100.1
R3 (config-route-map) #exit
Och tillämpa det på gränssnittet:
R3 (config) #interface GigabitEthernet0 / 0,1000
R3 (config-subif) #ip policy route-map gw1
R3 (config-subif) #exit
Lägger till standardrutten i rutttabellen zon 1:
R3 (config) #ip route vrf zone1 0.0.0.0 0.0.0.0 GigabitEthernet0 / 0.101 172.16.100.5
och kontrollera routingtabellen för zon 1
R3 # visa ip-rutt vrf zone1
Rutttabell: zon1
Koder: L - lokal, C - ansluten, S - statisk, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA extern typ 1, N2 - OSPF NSSA extern typ 2
E1 - OSPF extern typ 1, E2 - OSPF extern typ 2
i - IS-IS, su - IS-IS sammanfattning, L1 - IS-IS nivå-1, L2 - IS-IS nivå-2
ia - IS-IS mellanområde, * - kandidatstandard, U - statisk rutt per användare
o - ODR, P - periodisk nedladdad statisk rutt, + - replikerad rutt

Gateway of last resort är 172.16.100.5 till nätverk 0.0.0.0

S * 0.0.0.0/0 via 172.16.100.5, GigabitEthernet0 / 0.101
172.16.0.0/16 är variabelt subnät, 6 subnät, 2 masker
C 172.16.100.0/30 är direktansluten, GigabitEthernet0 / 0.100
L 172.16.100.2/32 är direkt ansluten, GigabitEthernet0 / 0,100
C 172.16.100.4/30 är direktansluten, GigabitEthernet0 / 0.101
L 172.16.100.6/32 är direkt ansluten, GigabitEthernet0 / 0.101
C 172.16.200.0/30 är direkt ansluten, GigabitEthernet0 / 0,1000
L 172.16.200.1/32 är direktansluten, GigabitEthernet0 / 0,1000
Uppgiften att dela upp klientnätverkens trafik i olika gateways har lösts. Bland nackdelarna med det fattade beslutet skulle jag vilja notera den ökade belastningen på routerns hårdvara och försvagningen av säkerheten, eftersom routern som är ansluten till det globala nätverket har en direkt anslutning till det lokala nätverket som går förbi hårdvarubrandväggen.

Vi vill berätta om operativsystemet IOS utvecklat av företaget Cisco. Cisco IOS eller Operativsystem för Internetarbete(internetoperativsystem) är programvaran som används i de flesta Cisco-switchar och -routrar (tidigare versioner av switchar kördes på CatOS). IOS inkluderar routing, switching, internetarbete och telekommunikationsfunktioner integrerade i ett multitasking-operativsystem.

Inte alla Cisco-produkter använder IOS... Undantag är säkerhetsprodukter SOM EN som använder operativsystemet Linux och routrar-routrar som körs IOS-XR... Cisco IOS innehåller ett antal olika operativsystem som körs på en mängd olika nätverksenheter. Det finns många olika Cisco IOS-varianter: för switchar, routrar och andra Cisco-nätverksenheter, IOS-versioner för specifika nätverksenheter, IOS-funktionsuppsättningar som tillhandahåller olika paket av funktioner och tjänster.

Själva filen IOSär flera megabyte stor och lagras i ett semipermanent minnesområde som kallas blixt... Flash-minne ger icke-flyktig lagring. Detta innebär att innehållet i minnet inte går förlorat när enheten tappar ström. Många Cisco IOS-enheter kopieras från flashminne till RAM (Random Access Memory) när enheten är påslagen, sedan startas IOS från RAM när enheten körs. RAM har många funktioner, inklusive datalagring, som används av enheten för att stödja nätverksoperationer. Att köra IOS i RAM förbättrar enhetens prestanda, men RAM anses vara flyktigt minne eftersom data går förlorade under en strömcykel. En strömcykel är när en enhet avsiktligt eller oavsiktligt stängs av och sedan sätts på igen.

Enhetshantering med IOS händer med kommandoradsgränssnittet ( CLI), när den är ansluten med en konsolkabel, av Telnet, SSH antingen med hjälp AUX hamn.

Versionsnamn Cisco IOS består av tre siffror och flera symboler a.b (c.d) e, var:

• a- huvudversionsnummer
• b- mindre versionsnummer (mindre ändringar)
• c- utgåvans serienummer
• d- mellanliggande byggnummer
• e(noll, en eller två bokstäver) - Mjukvasåsom ingen (som anger huvudraden), T (Teknologi), E (Företag), S (Tjänsteleverantör), XA specialfunktionalitet, XB som annan specialfunktion etc. .

Återuppbygga- Ombyggnader släpps ofta för att åtgärda ett specifikt problem eller sårbarhet för en given version av IOS. Ombyggnader görs antingen för att snabbt åtgärda ett problem eller för att möta behoven hos kunder som inte vill uppgradera till en senare större version eftersom de kan använda kritisk infrastruktur på sina enheter och därför föredrar att minimera förändringar och risker.

Interimsrelease- Interimsreleaser, som vanligtvis produceras på veckobasis och bildar en ögonblicksbild av den aktuella utvecklingen.

Underhållssläpp- Testade versioner, som inkluderar förbättringar och buggfixar. Cisco rekommenderar att du uppgraderar programvaran till underhållsversionen när det är möjligt.

Utvecklingsstadier:

• Early Deployment (ED)- tidig implementering, nya funktioner och plattformar introduceras.
• Begränsad distribution (LD)- Originalbegränsat svep, inkluderar felkorrigeringar.
• General Deployment (GD)- Allmän OS-distribution, testning, revision och förberedelse för lanseringen av den slutliga versionen. Dessa utgåvor är i allmänhet stabila på alla plattformar.
• Underhållsimplementering (MD)- dessa utgåvor används för ytterligare support, buggfixar och löpande mjukvaruunderhåll.

De flesta Cisco-enheter som använder IOS har också en eller flera "funktionsuppsättningar" eller "paket" - Funktionsuppsättning... Till exempel är Cisco IOS-utgåvor designade för användning på Catalyst-switchar tillgängliga som "standard"-versioner (som endast tillhandahåller grundläggande IP-routning), "förbättrade" versioner som ger fullständigt IPv4-routingstöd och "förbättrade IP-tjänster"-versioner som tillhandahåller avancerade funktioner; och IPv6-stöd.

Varje individ funktionsuppsättning motsvarar en tjänstekategori utöver grunduppsättningen ( IP-bas- Statiska rutter, OSPF, RIP, EIGRP. ISIS, BGP, IMGP, PBR, Multicast):

• IP-data (Data- lägger till BFD, IP SLA, IPX, L2TPv3, Mobile IP, MPLS, SCTP)
• Röst (Unified Communications- CUBE, SRST, Voice Gateway, CUCME, DSP, VXML)
• Säkerhet och VPN (säkerhet- Brandvägg, SSL VPN, DMVPN, IPS, GET VPN, IPSec)

Är den här artikeln till hjälp för dig?

Snälla berätta varför?

Vi beklagar att artikeln inte var användbar för dig: (Snälla, om det inte gör det svårt, ange varför? Vi är mycket tacksamma för ett detaljerat svar. Tack för att du hjälper oss att bli bättre!