Confluence workbench mirror

3. Logische netwerk opbouw (L2 + L3)

Guarded rendering from the committed top-level `confluence/` mirror. No live source, personal data, or write action is available.

Kind
PAGE
Version
12
Labels
0
Children
0
On this page
  1. Unsupported Confluence macro: tocUnsupported macro placeholder; source behavior is intentionally inert.No displayable parameters.
  2. Tenants
  3. SSVC Tenant (zie 6. Shared Services (SSVC) )
  4. DMZ Tenant
  5. DCBB Tenant (zie hoofdstuk .. )
  6. VRF/ Context
  7. L3out FW
  8. BGP Next-hop
  9. BGP ASN
  10. Failure
  11. Succes
  12. BGP Graceful restart

Verkeerstromen moeten op een efficiënte manier van elkaar gescheiden worden. Het uitgangspunt is altijd om een “verantwoordelijkheidsbubbel” te maken waarbinnen een specifiekere segmentering mogelijk is op meerdere niveaus.

De hoofdscheiding bestaat uit een Cisco ACI Tenant met daaraan één of meerdere firewall instanties die verkeer tussen datacenter resources en de buitenwereld filteren en inspecteren. Binnen deze Tenant kunnen meerdere route tabellen (VRF/ MPLS VPN) gecreëerd worden om binnen deze tenant ook af te dwingen dat verkeer door een firewall gefilterd + geïnspecteerd kan worden.

Vervolgens is er in elke routing instantie een Application Delivery Controller (ADC) aanwezig die functies al Loadbalancing, SSL off-loading, reverse proxy etc. kan faciliteren. De ADC zou voor connecties van buiten het datacenter kunnen zorgen voor de verplichte sessie onderbreking en andere veiligheidsmaatregelen.

In de Tenant worden verschillende EndPoint Groups gecreëerd waarbinnen endpoints geplaats kunnen worden die met elkaar moeten kunnen communiceren (Nog bepalen Hoe specifiek).

 

Tenants

De eerste security laag in het datacenter is de scheiding in compartimenten op basis van de Tenant construct in het datacenter netwerk. Een Tenant is een verzameling van policies, routering en diensten voor een specifiek compartiment. Een RWS-bedrijfsonderdeel zal meestal een eigen tenant krijgen, in sommige gevallen zal een extra tenant aangemaakt worde met een specifiek doel (i.v.m. Nora classificatie of extra afscherming). Hieronder een lijst met Tenants voor endpoints:

  • CIV
  • CIV-DCM
  • CIV-LAB
  • DMZ
  • HVWN
  • HWN
  • HWS
  • RWS
  • RWS-KA
  • VICNET
  • SSVC (Shared (infra) Services
  • DCBB (DC Backbone)


Voor CIV bestaat een tenant waarin alle CIV-applicaties en -diensten kunnen landen, maar daar past het DataCenter Management niet in i.v.m. vertrouwelijkheid en toegang tot beheer interfaces van de infrastructuur.

Voor elke tenant wordt standaard een firewall uitgerold die het Noord-Zuid verkeer filtert, hierover meer in Hoofdstuk 6

SSVC Tenant (zie 6. Shared Services (SSVC) )

De Shared SerViCes tenant zal gebruikt worden voor zowel datacenter INFRA diensten zoals DNS/ NTP/ AD als voor applicaties en diensten die voor vele afnemers centraal beschikbaar gesteld moeten worden. In hoofdstuk 8 meer over deze tenant.

DMZ Tenant

De DMZ-tenant is een tenant waar internet facing systemen in staan, deze tenant heeft standaard een deny policy in de firewall en coimmunicatie tussen verschillende EPG's is standaard niet mogelijk.

  • Geen contract voor verkeer tussen EPGs, alleen naar firewall
  • Intra EPG-isolatie waar mogelijk

DCBB Tenant (zie hoofdstuk .. )

De DCBB-tenant verbindt alle buitenkant interfaces van de ODC-firewalls met het RWS:RWS VPN (dat wordt in de toekomst een Backbone Transit netwerk). Het doel van deze tenant is om doormiddel van templates nieuwe firewalls snel aan te sluiten en verkeer tussen tenants in het datacenter netwerk te houden. In deze Tenant worden geen endpoints aangesloten.


VRF/ Context

Binnen een tenant kunnen meerdere routering domeinen opgezet worden, dit zijn in principe gescheiden route tabellen over het hele netwerkfabric. In de eerste instantie is gekozen om alle VPN namen te gebruiken voor tenant:vrf benaming. Voor VPN benamingen die niet volgens de Hoofdnetwerken/ afdelingen naamgeving opgezet zijn zal een vertaling gemaakt worden binnen de eerder genoemde tenants.

Binnen de VRF worden Bridgedomain's gemaakt waarin subnets en clients gekoppeld worden. Binnen een VRF is in principe open communicatie mogelijk in de opgezette structuur.

Het communiceren met resources in de wereld buiten het fabric loopt over een Laag 3 gerouteerde verbinding, op deze verbinding is het zeer gewenst om filtering/ inspectie te doen met een security device omdat de wereld buiten het fabric niet altijd vertrouwd kan worden. Voor RWS is gekozen om per tenant een firewall op te bouwen die de filtering (en later inspectie) kan doen voor het verkeer de tenant in en uit (Noord-Zuid).

De Firewalls worden aan de “Noord-zijde” gekoppeld aan de Datacenter Backbone (DC BB) waar al het Noord-Zuid verkeer terecht komt. Op deze manier blijft ook het verkeer tussen twee verschillende tenants binnen het datacenter netwerk en kan er filtering gedaan worden op de firewalls van beide tenants (verschillende verantwoordelijkheid).


L3out FW

Vanuit de DCBB vrf wordt een L3out opgezet waar de firewall aan gekoppeld kan worden, de L3out wordt met een /29 subnet ingesteld zodat er voldoende ruimte is voor een adres voor firewall, twee voor switches en een virtueel voor switches. Er zijn een aantal uitdagingen die het firewall en netwerk ontwerp met zich meebrengen:

  1. Lange BGP-uitvaltijden vanwege hoge BGP-timers of intensieve korte timers
  2. Failover vanuit firewalls naar andere neighbor
  3. Routes vanuit de tenant naar de DCBB en andersom zullen niet geleerd worden i.v.m. BGP-gedrag.

Voor beide uitdagingen is een van de vele oplossingen gekozen om deze op een eenvoudige veilige manier op te lossen, dit is beschreven in de volgende paragrafen.


BGP Next-hop

In het firewall ontwerp is gekozen om de standaard BGP-timers te gebruiken, dat zorgt ervoor dat een fout aan de “overkant” pas na 180 seconden erkent wordt en dat dan pas convergentie zal plaats vinden van beschikbare paden. Vooral voor de firewall is dit een probleem als er een switch uitvalt, deze mist dan een van zijn neighbors en zal er 3 minuten over doen om de routes naar deze neighbor uit zijn tabellen te verwijderen.

De gekozen oplossing om te zorgen dat verkeer afgeleverd kan worden in een fout situatie is gekozen om een virtueel adres op de switches bij te zetten waar de firewall verkeer naartoe kan routeren. De twee switches zullen bij elke route die zij naar de firewall adverteren de next-hop aanpassen naar het virtuele adres. De firewall zal zo alleen het virtuele adres in zijn route tabel installeren en is ervan gegarandeerd dat deze verkeer kan afleveren.

De configuratie die die op de switch geïnstalleerd wordt is de volgende:

BGP ASN

De tweede uitdaging is het leren van routes waar het eigen AS in voorkomt. Het BGP-routingprotocol is bedoeld voor zeer grote netwerken waar verschillende partijen koppelingen met elkaar kunnen maken waardoor routing loops kunnen ontstaan. De basis van BGP voor het beschermen tegen routing loops is dat als het eigen AS in het AS path staat dat de route niet opgenomen wordt in de route tabel. Nu heeft de firewall aan de noord- EN de zuidzijde een koppeling met hetzelfde netwerk, dat zou betekenen dat als er een netwerk aan de zuidzijde doorgegeven wordt aan de firewall dat aan de noordzijde van de firewall een route binnenkomt met het eigen ASN in het pad.

Failure

  1. Route geadverteerd vanuit tenant
    AS path: 4242894005
  2. Route geleerd in firewall tabel
  3. Route geadverteerd naar RWS:RWS vrf
    AS path: 4242894050 4242894005
  4. Route NIET geleerd in RWS:RWS want eigen AS in PATH
  5. Route NIET geleerd op backbone

Succes

  1. Route geadverteerd vanuit tenant
    AS path: 4242894051
  2. Route geleerd in firewall tabel
  3. Route geadverteerd naar RWS:RWS vrf
    AS path: 4242894050 4242894051
  4. Route geleerd in RWS:RWS Route geadverteerd naar RWS:RWS vrf
    AS path: 4242894005 4242894050 4242894051
  5. Route WEL geleerd op backbone

Voor het oplossen van dit schijnbare loop probleem zijn meerdere oplossingen, in dit ontwerp is gekozen op het Local-AS te gebruiken zodat in route tabellen en duidelijk is waar de origine van een route ligt en welk pad de advertising gevolgd heeft.

De volgende AS nummers zullen worden gebruikt om een standaard structuur op te zetten:

Doel

AM2 BGP AS FW (ACI-VRFs)

AM4 BGP AS FW (ACI-VRFs)

CE-routers (backbone)

42894

42894

Standaard ACI Fabric

4242894005

4242894006

DCBB_VRF to FW

4242894008

4242894108

AS voor RWS-KA

4242894040 (4242894041-9)

4242894140 (4242894041-9)

AS voor RWS

4242894051 (4242894051-9)

4242894151 (4242894051-9)

AS voor SSVC

4242894062 (4242894061-9)

4242894162 (4242894061-9)

AS voor DMZ

4242894073 (4242894071-9)

4242894173 (4242894071-9)

 

 

 

BGP Graceful restart

In verband met upgrades en firewall failover wordt gebruik gemaakt van de Graceful restart feature die zowel op checkpoint als op Cisco-apparatuur ondersteund wordt.

  1. De graceful restart kan aan een peer aangeven dat het apparaat in shutdown gaat waardoor aan beide zijden tijd is voor convergentie van route tabellen voordat een reboot wordt ingezet.
  2. Een tweede functie zorgt ervoor dat route tabellen tijdelijk bevroren kunnen worden zodat een herstart van het BGP-proces kan plaatsvinden, dit is vooral nodig in geval van een firewall failover.

De gebruikte timers zijn als volgt:



BGP route-maps


Summarization

Bridgedomain

Mirror provenance
Mirror source
confluence/spaces/INFRAARCH/pages/203228213/page.metadata.json
Storage source
confluence/spaces/INFRAARCH/pages/203228213/page.storage.xhtml
Access
Committed snapshot only