Hosting netwerk-architectuur vraagje (Cisco)

[Zoetjuh]

Beste medetweakers,

Momenteel zijn wij aan het brainstormen over onze nieuwe netwerk structuur zoals we deze op het datacentrum willen gebruiken. We hebben één connecvitity partner waar we via BGP over 2 uplinks met ze babbelen. We beschikken over een C-Class netwerk welke wij versnipperen in aparte VLANs/Subnets. Momenteel gebruiken we een C3750 stack als 'core'.

Waar willen we heen:
A: Toevoegen van NAC+IPS
B: Slimmer omgaan met IPs
C: Het netwerk IPv6 ready maken

Heel straight-forward, zou het dan zoiets worden:


Waar loop ik tegen aan:
Om probleem A te tackelen tackelen zat ik er aan te denken om twee 2811's in te zetten (mogelijk met ASA's tussen de 2811's en de netwerk switches). Deze zouden eBGP babbelen richting onze ISP en iBGP onderling.

Met de huidige 3750-stack, is het gateway IP van ieder subnet/VLAN geconfigureerd op de stack. Dat gaat in de nieuwe situatie niet op, waardoor ik er aan zit te denken om HSRP in te zetten, echter druist dat in tegen het issue B (slimmer omgaan met IPs) aangezien ik naast het Router IP nog twee IPs uit de subnets kwijt ben voor de individulere router.

Verder willen we in sommige subnets meerdere klanten van ons kunnen plaatsen, zonder dat ze elkaar zijn, maar dat ze wel via L3 met elkaar kunnen communiceren. Nu is me niet helemaal duidelijk of dit lukt met 'switchport protected'. Een alternatief zou om Private VLANs te gaan gebruiken, echter waar ga je het router IP plaatsen? Op de 2811's bedacht ik me, maar de 2811's ondersteunen volgens mij geen private VLANs, laat staan dat ze private-vlan promiscuous trunks ondersteunen. Een gateway IP per VLAN binnen subinterfaces werkt meen ik ook niet omdat hij geen private VLANs ondersteunt en dus niet weet hoe hij daartussen moet routeren.

Op zich zou 'switchport protected' wel kunnen werken (als communicatie via het VLAN IP/L3 nog wel mogelijk is), maar ik begreep dat dit commando niet tussen switches werkt, waardoor we dergelijke VLANs dus zouden moeten limiteren tot één switch. Op zich niet echt een probleem omdat deze klanten een enkele ethernetkabel naar ons netwerk hebben en dus sowieso niet redundant connected zijn. We hebben klanten met meerdere servers, maar die krijgen sowieso een eigen VLAN/subnet en kunnen spullen zonder problemen redundant aansluiten. Eventueel zou dit commando icm port ACLs nog wel voldoen.

Naast losse serververs hebben we ook ESX oplossingen met virtual rental servers. Om communicatie daar te limiten zag ik dat we daarvoor Nexus 1000v kunnen gebruiken. Een alternatief had ook hier private VLANs kunnen zijn aangezien dit door vSphere (4.0) wordt ondersteund.

Dan.. puntje C. De 2811 ondersteunt IPv6 en is normaal vlot genoeg. Ik weet alleen niet of dat ook zo is met IPS/NAC ingeschakeld. Moeten we dus echt ASA's plaatsen? Dan blijkt de 2960-series ook geen IPv6 te ondersteunen (wel op management niveau, maar niet op ACL niveau) waardoor deze switches icm 'switchport protected' niet voldoen en we naar de 3560's moeten kijken. De 3560's ondersteunen wel Private VLANs, maar geen promiscuous trunk poort (dit wordt wel weer door 4948 ondersteund)..

Hoe denk ik dit aan te gaan pakken:
Nu maar gaan 2x2811+HSRP + 2960's (of 3560's) en in de toekomst kijken naar een alternatief..

Ofwel.. langzaam maar zeker een beetje een bomen + bos verhaal. Nu vroeg ik me af of er hier geniale ideeen zijn waar ik niet aan heb gedacht.

[Predator]

Zoetjuh schreef op dinsdag 06 april 2010 @ 12:59:
Beste medetweakers,
Waar loop ik tegen aan:
Om probleem A te tackelen tackelen zat ik er aan te denken om twee 2811's in te zetten (mogelijk met ASA's tussen de 2811's en de netwerk switches). Deze zouden eBGP babbelen richting onze ISP en iBGP onderling.

Met de huidige 3750-stack, is het gateway IP van ieder subnet/VLAN geconfigureerd op de stack. Dat gaat in de nieuwe situatie niet op, waardoor ik er aan zit te denken om HSRP in te zetten, echter druist dat in tegen het issue B (slimmer omgaan met IPs) aangezien ik naast het Router IP nog twee IPs uit de subnets kwijt ben voor de individulere router.

Met VRRP spaar je 1 adres uit tov HSRP. Maar ik ben er zelf geen voorstander van om een interface adres als VIP te gebruiken.
Als je toch je klanten gaat isoleren, dan kan je beter je subnetten wat vergroten (minder verlies).

Ik meen te lezen dat je een soort van hoster bent ?
Anders zie ik het probleem moeilijk in.

Ik zou wel je onderlinge routing gewoon op die 3750 stack houden. (Je kan eventueel wel dan de stack wegdoen). Je 2811 routers kan je gebruiken voor de BGP routering met je ISP.

Verder willen we in sommige subnets meerdere klanten van ons kunnen plaatsen, zonder dat ze elkaar zijn, maar dat ze wel via L3 met elkaar kunnen communiceren. Nu is me niet helemaal duidelijk of dit lukt met 'switchport protected'. Een alternatief zou om Private VLANs te gaan gebruiken, echter waar ga je het router IP plaatsen? Op de 2811's bedacht ik me, maar de 2811's ondersteunen volgens mij geen private VLANs, laat staan dat ze private-vlan promiscuous trunks ondersteunen. Een gateway IP per VLAN binnen subinterfaces werkt meen ik ook niet omdat hij geen private VLANs ondersteunt en dus niet weet hoe hij daartussen moet routeren.

Ik begrijp je hier niet goed.
Je kan prima verschillende subinterface per VLAN maken en daar je HSRP groepen op zetten.
Maar zoals ik al zei, doe dat toch op een layer-3 switch, niet op een router.
Inter-vlan routing op een router is iets wat je kleinschalig kan gebruiken, maar dat is maar beperkt bruikbaar.
Routers zijn access devices.

Op zich zou 'switchport protected' wel kunnen werken (als communicatie via het VLAN IP/L3 nog wel mogelijk is), maar ik begreep dat dit commando niet tussen switches werkt, waardoor we dergelijke VLANs dus zouden moeten limiteren tot één switch. Op zich niet echt een probleem omdat deze klanten een enkele ethernetkabel naar ons netwerk hebben en dus sowieso niet redundant connected zijn. We hebben klanten met meerdere servers, maar die krijgen sowieso een eigen VLAN/subnet en kunnen spullen zonder problemen redundant aansluiten. Eventueel zou dit commando icm port ACLs nog wel voldoen.

Zorg in ieder geval dat het nog beheersbaar blijft.
Ik weet niet over welke schaal het hier gaat, maar zo'n dingen worden snel onoverzichtelijk !

Ik heb een grondige hekel aan dat soort meuk. Het doel heiligt niet altijd de middelen.
Wil je een stuk isoleren als L2 segment -> maak een VLAN met een apart subnet.
Wil je dat stuk filteren -> Zet het apart op een FW vlan subinterface.

Met switches bouw je je LAN. Met routers geef je access tot je LAN en met firewalls filter je die access.
Je kan natuurlijk prima daar hier en daar vanaf wijken, maar als je begint met alles door elkaar te halen en ACL's op bijna elke switchport te rammen, dan ben je echt verkeerd bezig.

Dan.. puntje C. De 2811 ondersteunt IPv6 en is normaal vlot genoeg. Ik weet alleen niet of dat ook zo is met IPS/NAC ingeschakeld. Moeten we dus echt ASA's plaatsen? Dan blijkt de 2960-series ook geen IPv6 te ondersteunen (wel op management niveau, maar niet op ACL niveau) waardoor deze switches icm 'switchport protected' niet voldoen en we naar de 3560's moeten kijken. De 3560's ondersteunen wel Private VLANs, maar geen promiscuous trunk poort (dit wordt wel weer door 4948 ondersteund)..

Heb je die routers al gekocht ?

Nogmaals gebruik een layer-3 switch (bv die 3750 stack) voor de interne statische routering.
Of wil je onderling tussen elke connectie binnen jouw datanetwerk ook IPS doen ? Dan doe je dat beter op een FW. Of neem je een inline IPS.
Hoe wil je eigenlijk NAC doen met jouw klanten
Ga je NAC op je server access ports gebruiken

Hoeveel bandbreedte ga je kopen bij je provider ?

PS: een 4948 kan geen IPV6 in hardware (een 4900M wel).
http://www.cisco.com/en/U...heet0900aecd8017a72e.html

[Zoetjuh]

Excuses voor de enorme lap tekst.. Tis een beetje een brain.dmp op het moment..

@Predator
We zijn inderdaad een soort hoster met nu 2 volle racks in Telecity (ja, we zijn een redelijk kleine club).
Veelal voor klanten waar we systeem- en netwerkbeheer doen, soms ook in combinatie met gehoste RDP oplossingen. In die gevallen zijn de DSL lijnen van de klant geknoopt aan de servers binnen het datacentrum; dit dmv een IPVPN en een stukje VLAN.
Voor andere klanten draaien we webapps op single servers (virtueel of fysiek) of webclusters.

Momenteel hebben we een Publiek C-class verdeelt in /27, /28 en /29's en beschikken we over een dubbele 100Mbps BGP-link naar onze provider (met in feiten de beschikking over 100Mbps).
Hierbij bemerken we dat we soms een klant met één server nog in een /28 hebben zitten, wat uiteraard bijzonder inefficient is.

In verband met isolatie hebben we destijds klanten altijd in een eigen VLAN/subnet geplaatst.
Zoals je je kan voorstellen, een /30 zou bijzonder inefficient zijn wanneer men één server heeft hangen. Wil ik HSRP gaan doen, zou een /30 al niet meer afdoende zijn (immers, drie IPs voor het gateway verhaal; 2 fysieke en één virtueel + broadcast + network + server = 6). Zo hebben we meer klanten met slechts één of twee servers.

Vergroten van subnets gaat niet 'zomaar'. Je kan je voorstellen dat ik verschillende klanten niet in het zelfde broadcast domain wil hebben.

Een ander issue is het verhaal dat we het gebruik van ACLs als security willen vervangen door iets dat daar inderdaad meer geschikt voor is.
IPS is iets dat we daadwerkelijk direct kunnen implementeren. NAC zou ik per klant mogelijk wel/niet willen kunnen inzetten; dit is nog optioneel, maar die mogelijkheid zou ik wel direct willen inbouwen
(theoretisch: stel een klant zou willen dat hij dmv een vpn verbinding daarna toegang wil kunnen krijgen tot zijn fileserver).

Verder komt er overigens nog eens bij dat we servers via 1Gbps aangesloten willen hebben om communicatie tussen servers van de zelfde klant verder te boosten.
Onze insteek is dus: veilig, vlot, op de toekomst gericht, redundant en stabiel (maar voor ons uiteraard nog wel 'betaalbaar').

De routers/switches moeten overigens verder nog gekocht worden. We hebben nu in princiepe een 2960G (48p), 2x een 3750 (24p).

Ik begrijp je punt verder rond routers en switches. Het zal een gevoelsmatig iets zijn geweest dat een router routeert (L3) en een switch switcht (L2).
Ik denk dat ik de Cisco switches misschien meer op hun waarde op schatten.

---
Ik loop vooral te dubben: is gebruik van Private VLANs iets wat ik moet willen? Voordeel is me absoluut duidelijk: één groot subnet terwijl ik het toch kan opdelen in verschillende broadcastdomains en nagenoeg geen verlies van IP-adresjes.
Nadeel: hoe is dit technisch "fatsoenlijk" en "betaalbaar" te implementeren. Veel apparatuur ondersteunt het niet en; hoe loopt communicatie tussen de secundary VLANs (dit zou dan naar het router IP moeten lopen en dan terug het subnet in). Dit terwijl je internal routing eigenlijk liever op je switches zou laten doen; wat weer als nadeel heeft dat het niet door je firewalls heen loopt. En: gaat dit werken met het IPVPN verhaal dat we hiernaast hebben lopen (een trunk richting de provider waarover de VLANs van de klanten lopen; hierdoor zijn de klantlocaties en servers in een eigen netwerk geplaatst).

En, als het dan geen PVLANs worden; wat dan wel, zonder dat ik subnets zou moeten vergroten om de reden dat ik HSRP zou gaan gebruiken.

[ Voor 4% gewijzigd door Zoetjuh op 06-04-2010 19:46 ]

[pablo_p]

Eerst een inkoppertje: koop geen 2811 routers, maar 2901 of 2911 routers. Dan heb je 3x zoveel performance voor hetzelfde geld. Een 2911 is wel 2U

Switchport protected heeft het voordeel dat de configuratie alleen lokaal binnen een switch is en er dus geen afhankelijkheid is van support van andere devices. Ik weet alleen niet of de 1000V ook switchport protected ondersteunt, dat zou je moeten uitzoeken.

Private-VLANs met een router die default gateway is (los van de discussie of je dat wel of niet wil vanwege performance), betekent dat de de trunk naar je router als promiscuous poort definieert op je switch. Vervolgens maakt het voor de router niet uit, behalve dat deze dus op de interface een ACL moet plaatsen die verkeer van het aangesloten subnet, naar het aangesloten subnet filtert. Dit is je scheiding tussen de geisoleerde broadcast domains met de mogelijkheid er gecontroleerd gaten in te boren.

Switchport/protected of private VLANs met communicatie tussen de gescheiden broadcast domeinen vind ik geen wenselijke oplossing. Dit vereist extra statische routering op de servers om IP addressen binnen een subnet als /32 te routeren naar de default gateway. Introduceert dus veel extra ellende. ACLs op een netwerkpoort vind ik ook geen wenselijke situatie, plus dat ze niet stateful zijn. Je hebt eigenlijk een L2 firewall met 5+ interfaces nodig, maar ik weet niet of die bestaan.
Een andere optie is dat als servers wel onderling moeten praten, je private VLANs gebruikt en ze binnen dezelfde community plaatst. Dat is wel zwart/wit 'access control, ze mogen alles of niets. Maar met een beetje pech eindig je dan met alle systemen in hetzelfde community VLAN.

Voor communicatie met de de provider router, snap ik niet hoe de situatie is. Als er dedicated ADSL lijnen van de klant binnen komen aangesloten op een eigen VPN, dan lijkt het me dat je de servers aansluit met twee interfaces, een in het klanten-IP-VPN stuk in een eigen VPN en een in de gesharede omgeving. Dan wordt de routering gescheiden op de servers en heb je niets te maken met private vlan techniek voor de kalnten vlans. Of snap ik het niet goed?

Ik kan je verhaal over NAC niet plaatsen. Voor Cisco is NAC bedoeld om de fysieke aansluiting van clients te beschermen. Als ik het goed begrijp, host je alleen servers. Voor toegang van remote gebruikers, richt je gewoon netjes een SSL VPN in, clientless of full-blown. De ACLs staan dan gewoon in de ACL doos en hangen aan het userid (via groepen ed) en dat werkt prima op een ASA is mijn ervaring.

IPS op een router zonder losse IPS module zie ik (en dat is een persoonlijke visie) als een marketing oplossing en niet als een serieuze IPS. Als je toegang netjes filtert tot het noodzakelijke met een firewall, heb je vooral applicatie intelligentie in je IPS nodig en dat is een stap te ver voor gewoon IPS op een IOS router. Maar als je het zelf als marketing naar klanten wil verkopen, kan dat wel.

Nog een paar toevoegingen:
- kan kan best de 3750 stack als router on a stick gebruiken, met acl's maar die zijn dan niet stefaul. Schaalbaarheid van access-switches is wel beperkt als je non-G 3750's hebt.
- een 3750 ondersteunt alleen private valns als je ip-services software/licentie hebt. Op de non-E is dat een papieren licentie en dwingt de HW de licentie niet af. Voor testen kan dat een optie zijn.

[ Voor 6% gewijzigd door pablo_p op 06-04-2010 22:40 . Reden: Toevoegingen 3750 stack ]

[Zoetjuh]

We hebben hier inderdaad een licentie voor; was ook nodig om BGP te kunnen babbelen.

Om ook het verhaal met klanten en IP VPNs duidelijker te maken, hierbij een tekeningtje:


In feiten is alleen de link (trunk) tussen onze router en de ISP router onderdeel van het klant-VLAN; daarna wordt alles getagged en gerouted om zodoende een klant-netwerk te creëren (tis dus eigenlijk een 'gescheiden routed netwerk').
Connectivity vanaf internet naar onze C-class en andersom wordt via de eBGP afgehandeld.

Wat ik me voor kan stellen is dat we een volgende setup zouden krijgen:
- 3750 stack gebruiken voor L3 switching en BGP router (doet hij nu ook en load is nooit een probleem geweest)
- ASA in bridging mode en filteren wat ik wil filteren + te gebruiken als VPN-inbeldoos voor remote dialin
- Switches van het model 3560 met IP Advanced software; of de 4900M in geval van Private VLANs

Waar ik dan toch nog niet uit ben / wat ik waarschijnlijk nogsteeds verkeerd begrijp:
- Geen gebruik maken van Private VLANs aangezien de 3750 sowieso geen promiscious trunk ondersteund (of hoeft dat ook niet, maar als de switches richting de ASA het maar ondersteunen; want dan zou Private VLANs wel perfect werken?)
- Wordt het echt geen Private VLANs, dan 'switchport protected' gebruiken. Reden waarom ik daar alsnog Port ACLs op wilde plaatsen zou zijn om te voorkomen dat twee klanten binnen het zelfde VLAN een zelfde IP op hun server 'zouden kunnen instellen'.

[pablo_p]

Over transparent mode:

• transparent mode ondersteunt maar 2 interfaces (VLANs) per context, simpel gezegd een inside en een outside. Dit is erg ruw voor deze omgeving
• in transparent mode is VPN alleen mogelijk voor management verkeer (dus voor management van de FW zelf, concreet op bv syslog of SNMP secure te verzenden)
• je wint in deze situatie geen performance door de routering op de 3750 switches te doen en de firewall er transparent tussen te zetten. De firewall moet al het verkeer door zich heen inspecteren en er is weinig performance verschil tussen routeren en bridgen
• ik zou transparent mode alleen gebruiken als je een firewall nieuw inzet in een bestaande omgeving en het door afhankelijkheden niet mogelijk is om de firewall er gerouteerd (met een extra routeringsnetwerkje) tussen te zetten. Concreet in dit geval: niet doen

De 3750 switches als BGP router gebruiken vind ik als een erg goed idee klinken, maakt de migratie makkelijker en gegarandeerd geen performance problemen. Indien je geen NAT of hele grote routetabellen hebt, kan er weinig op tegen een multilayer switch voor routering.

De switches die promiscuous trunk ondersteunen zijn: C4500, C4948 and ME4900. Voor het device dat daarop is aangesloten zijn er geen requirement voor ondersteuning, want die ziet alleen de primary VLANs.

Toevoeging over ASA's: ASA's gebruiken 2 adressen voor hoogbeschikbare gateway, dat scheet er weer eentje tov HSRP. Je kan volgens mij zelfs het secundairy IP adres weglaten, maar dat is geen best practive bij Cisco. Bij Juniper ben ik dat wel vaker tegengekomen.

[ Voor 8% gewijzigd door pablo_p op 07-04-2010 22:58 . Reden: Toevoeging ASA hoogbeschikbaar. ]

[Bl@ckbird]

IPS in IOS geeft redelijke bagger performance. Bovendien heb je niet de volledige features.
Er zijn twee IPS modules voor routers, maar de snelste hiervan doet slechts 75 Mbps.

De beste performance haal je met twee ASA's met twee AIP IPS modules.
( Zie: "Maximum Firewall and IPS Throughput" )

Op de ASA kan je ook Security Contexts draaien (virtuele firewall) die je dan weer aan klanten kan aanbieden als firewall die ze zelf kunnen beheren. Hou er wel rekening mee dat als je Security Contexts draait, je geen VPN meer kan doen op de ASA.

De Nexus 1000v draait NX-OS. Dit is hetzelfde OS als wat op de data center switches draait. ( Nexus 5000 / 7000 ) De Nexus 1000v kan je net zo beheren als de andere data center switches. Counters van virtuele interfaces blijven gewoon doorlopen als je een VMotion uitvoert. Daarnaast kan je duidelijke scheiding aanbrengen tussen het beheer van vSphere en netwerk beheer. Voor de Nexus 1000v heb je overigens wel Enterprise Plus licentie van vSphere nodig, aangezien het de distributed switch van vSphere vervangt.

NAC gebruik je om je om je netwerk te beschermen, zodat je kan scannen of PC's van gebruikers aan bepaalde policies voldoen. ( Draait de virus scanner? Is deze up to date? Zijn bepaalde service packs gedraaid? etc. ) NAC wordt niet gebruikt in het data center, maar in combinatie met access switches, wireless controllers en VPN Head-ends. ( Zoals ASA's ) En dan in een enterprise omgeving waar je controle hebt over je eigen PC's.

Ik weet niet wat je budget is en hoeveel groei je verwacht. Maar je zou ook naar één of twee 6500 switches kunnen kijken met firewall en IPS blades en ACE loadbalance modules. ( Dit is vooral handig als je virtuele firewalls / loadbalancers aan je klanten wil aanbieden. En dan hoef je nog niet eens naar het grootste chassis te kijken... )

Qua kosten zou je kunnen kijken naar Cisco Refurb. Dit zijn vaak overtollige voorraden van bijvoorbeeld Cisco TAC (Om Smartnets te dekken) en distributeurs. Op officiële Cisco refurb mag je ook Smartnet support contracten afsluiten. ( Eventueel met 2 uur responce tijd. )

De nieuwste hardware vindt je niet als refurb (zoals een Sup720-3C supervisor), maar 6500 met Sup720-3B supervisor is denk ik wel te krijgen. ( Meer heb je toch niet nodig. )

Verder is er nog een lease programma, zodat je de investeringskosten kan uitsmeren over max. 36 maanden.

Specifieke features van IOS (zoals PVLAN), kan je checken met de Feature Navigator:
http://www.cisco.com/go/fn

[TrailBlazer]

Met 2800/2900 routers kan je denk ik nooit de hele Internet routing table in hardware cef switchen. 2 jaar geleden hebben wij ook zo'n setup als dit gebouwt en onze sup720 gingen allerlei foutmeldingen geven toen we meer dan 256K routes inleerden. Uiteindelijk geupgrade naar de sup720 bxl geloof ik die gaan tot een miljoen.

[Bl@ckbird]

Mja... idd. Je kan met een 2900 BGP routen, maar alleen met een beperkt aantal routes.
Voor de hele Internet routing tabel heb je een 6500 nodig met een supervisor SUP720-3BXL of S720-10G-3CXL. En je hebt 3BXL / 3CXL Distributed Forwarding Cards nodig op alle lijnkaarten die dat ondersteunen.

Je zou ook kunnen kijken naar een ASR1002F. Deze router heeft een 1RU form factor en ondersteund max. 1 miljoen IPv4 routes. Daarnaast heeft het aardige firewalling en VPN performance. De performance van de modulaire versies van de AS1000 zijn nog wat hoger, maar denk ik niet nodig in dit geval.

De ASR1000 is een router. Dus voor switching en IPS moet je dan nog een aparte setup verzinnen.
Bij de 6500 is dit met service modules meer te integreren, wat weer stroom en rackspace scheelt.

[Zoetjuh]

We hebben van het weekend fysiek een verplaatsing uitgevoerd. Duurde langer dan geschat, maar verliep toch redelijk vlekkeloos. Voor wat betreft de definitieve architectuur, tja, dat is nogsteeds puzzlen. Ik bemerk echter dat investeren in een full IPv6-netwerk nu, toch redelijk kostbaar is. Vergeet niet, we draaien slechts twee racks met apparatuur.

Voor wat betreft routing tables.. Tijdens de verhuizing: ik sluit onze 3750-stack op de nieuwe locatie aan. Ik krijg en zie netjes m'n twee BGP neighbours up komen en de BGP werkt. Ecthter begon de stack behoorlijk te reageren op commando's en ook het browsen op internet ging behoorlijk traag... Na controle bleek ik een CPU load van 80-100% te hebben in een BGP-service.. Toen ik een 'show ip bgp' deed zag ik niet m'n normale 0.0.0.0 route, maar inderdaad 1000+ routes naar noem-het-maar. Na een stukje reconfiggen bij de ISP was de rust weer terug..