SDA transit är ett av flera möjliga sätt att knyta ihop kontor med mjukvarubaserade nätverk (SDA). Fördelarna inkluderar en viss enkelhet och att då kan tillämpa enhetliga policies, samt att allt kan styras och automatiseras via DNA Center. I detta inlägg går Conscias Jacob Zartmann igenom hur man i ett sådant scenario kan få Direct Internet Access för kontoren. För distribuerade verksamheter kan lokal internet breakout ha många fördelar, exempelvis spara resurser genom att inte icke-kritisk trafik (gästnätverk, t.ex.) behöver gå tillbaka och ut via den centrala brandväggen.
Vissa företag är etablerade på flera platser i ett mindre geografiskt område som är sammankopplade med DWDM, svartfiber eller kanske MPLS. SDA-transit kan vara meningsfullt att konfigurera om MTU (> = 1550 byte) och latens (~ 10 ms) tillåter det. En fördel med att använda mjukvarubaserade nätverk och SDA-transit är VXLAN-enkapsulering över hela sträckan, vilket innebär att vi kan ha en end-to-end-policy för både makro- (VN) och mikro- (SGT) segmentering när vi använder SDA-transit.
I det här inlägget kommer Jacob gå igenom hur du i mjukvarubaserade nätverk kan göra för att konfigurera direkt internetåtkomst (DIA) med SDA-transit. Längs vägen visar han hur det fungerar och varför.
Topologi och Use Case
Här har vi två platser. En av dem, Site 2, har ett behov av DIA för användarnas VN. Ändpunkter i användarnas VN måste också kunna nå delade tjänster som driftas centralt i datacentret och andra ändpunkter på andra platser i samma VN.
Konfiguration av Border noder
I detta specifika nätverk har vi inget behov av att använda interna Border noder. Det finns bara en väg för all icke-SDA-trafik – allt får gå via datacenter-blocket. Vi kunde haft andra nätverksmoduler som ett WAN-block och då hade interna Border noder kunnat vara aktuella. För detta nätverk håller vi dock allt litet och enkelt.
Cisco dokumenterar alternativen för att konfigurera en Border nod så här:
Ref: Mjukvarubaserade nätverk: Add a Device as a Border Node
När vi ställer in en Border nod som en extern Border nod konfigureras följande i LISP på alla Edge noder för den platsen:
! E1-SITE-2:
router lisp
service ipv4
use-petr 100.127.2.1Här används PETR (Proxy Egress Tunnel Router) av 100.127.2.1 som en ”Gateway of last resort”. Det innebär att om ett LISP uppslag inte hittas (EID inte hittades i MS/kontrollplansnoden), så är paketet enkapsulerat med VXLAN och skickas till 100.127.2.1 (vår externa Border nod) för plats 2.
LISP på flera platser
Att använda SDA med SDA-transit skapar ett hierarkiskt LISP-nätverk i två nivåer där Border noderna åter enkapsulerar trafiken till tunnelroutrar (RTR). Logiskt kan det se ut så här:
Dessa Fabric siter är stubbnätverk och förbindelsen mellan dem underlättas med hjälp av att LISP används på ett hierarkiskt sätt. Om EID-SITE-2 vill kommunicera med EID-SITE-1, kommer Edge noden att göra ett LISP-uppslag till kontrollplanens nod på Site 2.
Om LISP-uppslaget misslyckas kommer Edge-noden enkapsulera in paketet och skickar det till Border noden för plats 2. Här görs ett liknande uppslag men för transit-kontrollplanets nod. Eftersom alla Boder noder registrerar summerade prefix för EID-utrymmet för sina respektive platser, känner transit-CP-noden den auktoritativa Border nod som registrerade prefixet och kan skicka ett LISP svar (Map-reply).
Nu kan Border noden för plats 2 enkapsulera paketet i VXLAN och skicka det till Border nod för plats 1. Här görs ytterligare ett LISP-uppslag och så småningom kommer paketet att komma till Edge noden på plats 1 där EID-SITE-1 är ansluten . Samma hierarkiska LISP-uppslagsprocess kommer att hända i omvänd riktning när EID-SITE-1 kommunicerar till EID-SITE-2.
Den relevanta konfigurationen av Border nod är denna:
! B1-SITE-2:
router lisp
!
prefix-list Global/Fabric_Site_2_Multisite_LAB_list1
10.0.2.0/24
exit-prefix-list
!
instance-id 4099
service ipv4
eid-table vrf Users
map-cache 0.0.0.0/0 map-request
route-import map-cache bgp 65002 route-map permit-all-eids
route-import database bgp 65002 route-map site-local-eids locator-set rloc_3adb4a21-230f-4f81-af6b-db2e0bc90ea6 proxy
route-import prefix-list Global/Fabric_Site_2_Multisite_LAB_list1 bgp 65002 route-map site-local-eids
itr map-resolver 100.127.0.100
itr map-resolver 100.127.2.100 prefix-list Global/Fabric_Site_2_Multisite_LAB_list1
etr map-server 100.127.0.100 key 7 <secret>
etr map-server 100.127.0.100 proxy-reply
use-petr 100.127.1.1
DNA Center konfiguration: SDA transit
Så för de prefix som är lokala på denna plats konsulteras den lokala CP-noden. Alla andra uppslag går till transit CP-noden. Här registreras också de importerade prefixen (som sammanfattas). Om ett LISP-uppslag misslyckas, enkapsuleras trafiken i VXLAN och skickas till Border noden för plats 1 – 100.127.1.1. Den här konfigurationen orsakas av bocken i nedan ruta för B1-SITE-1 i DNA Center:
Såhär ser LISP-cachen ute efter att Border noden på plats 2 gjorde ett uppslag av EID-SITE-1:
B1-SITE-2#sh lisp eid-table vrf Users ipv4 map-cache 10.0.1.11
LISP IPv4 Mapping Cache for EID-table vrf Users (IID 4099), 8 entries
10.0.1.0/24, uptime: 00:26:23, expires: 23:33:36, via map-reply, complete
Sources: map-reply
State: complete, last modified: 00:26:23, map-source: 100.127.1.2
Exempt, Packets out: 199(17212 bytes) (~ 00:01:28 ago)
Configured as EID address space
Locator Uptime State Pri/Wgt Encap-IID
100.127.1.1 00:26:23 up 10/10 -
Last up-down state change: 00:26:23, state change count: 1
Last route reachability change: 00:26:23, state change count: 1
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: 00:26:23 (rtt 1ms)
100.127.1.2 00:26:23 up 10/10 -
Last up-down state change: 00:26:23, state change count: 1
Last route reachability change: 00:26:23, state change count: 1
Last priority / weight change: never/never
RLOC-probing loc-status algorithm:
Last RLOC-probe sent: 00:26:23 (rtt 2ms)
B1-SITE-2#
En debug av LISP-uppslaget på B1-SITE-1 bekräftar också LISP-hierarkin hos en SDA transit:
May 25 09:16:30.278: [XTR] LISP: Processing data signal for EID prefix IID 4099 10.0.1.11/32
May 25 09:16:30.278: [XTR] LISP-0: Remote EID IID 4099 prefix 10.0.1.11/32, Change state to incomplete (sources: <signal>, state: unknown, rlocs: 0).
May 25 09:16:30.278: [XTR] LISP-0: Remote EID IID 4099 prefix 10.0.1.11/32, [incomplete] Scheduling map requests delay 00:00:00 min_elapsed 00:00:01 (sources: <signal>, state: incomplete, rlocs: 0).
May 25 09:16:30.278: [XTR] LISP-0: Remote EID IID 4099 prefix 10.0.1.11/32, Starting idle timer (delay 00:02:30) (sources: <signal>, state: incomplete, rlocs: 0).
May 25 09:16:30.407: LISP-0: IID 4099 Request processing of remote EID prefix map requests to IPv4.
May 25 09:16:30.407: [XTR] LISP: Send map request type remote EID prefix
May 25 09:16:30.407: [XTR] LISP: Send map request for EID prefix IID 4099 10.0.1.11/32
May 25 09:16:30.407: [XTR] LISP-0: Remote EID IID 4099 prefix 10.0.1.11/32, Send map request (1) (sources: <signal>, state: incomplete, rlocs: 0).
May 25 09:16:30.407: LISP-0: EID-AF IPv4, Sending map-request from 10.0.1.11 to 10.0.1.11 for EID 10.0.1.11/32, ITR-RLOCs 1, nonce 0x27EEB4B2-0x76D0EA93 (encap src 100.127.2.1, dst 100.127.0.100), FromPITR.
May 25 09:16:30.410: [XTR] LISP: Processing received Map-Reply(2) message on Vlan201 from 100.127.0.100:4342 to 100.127.2.1:4342
May 25 09:16:30.410: [XTR] LISP: Received map reply nonce 0x27EEB4B2-0x76D0EA93, records 1
May 25 09:16:30.410: [XTR] LISP: Processing Map-Reply mapping record for IID 4099 SVC_IP_IAF_IPv4 10.0.1.0/24 LCAF 2, ttl 1440, action none, not authoritative, 2 locators
100.127.1.1 pri/wei=10/10 lpR
100.127.1.2 pri/wei=10/10 lpR
May 25 09:16:30.410: [XTR] LISP-0: Map Request IID 4099 prefix 10.0.1.11/32 remote EID prefix[LL], Received reply with rtt 2ms.
Ett LISP-uppslag för 10.0.1.11 (EID-SITE-1) skickas till 100.127.0.100, CP-transitnoden. LISP svaret (Map-reply) listar det aggregerade prefixet 10.0.1.0/24 med 2 locators (Border noder). Var och en har samma prioritet och vikt, vilket betyder att båda kommer att användas lika. Detta liknar hur ECMP fungerar för regelbunden IP-forwarding.
Direct Internet Access – DIA
På plats 2 finns ett behov av DIA. Låt oss se vad Edge och Border noderna på plats 2 kommer att göra med ett paket till 8.8.8.8:
E1-SITE-2#sh ip cef vrf Users 8.8.8.8 detail
0.0.0.0/0, epoch 0, flags [cover dependents, subtree context, check lisp eligibility, default route]
SC owned,sourced: LISP remote EID - locator status bits 0x00000000
LISP remote EID: 32 packets 12446 bytes fwd action signal-fwd, cfg as EID space
LISP source path list
nexthop 100.127.2.1 LISP0.4099
Covered dependent prefixes: 2
notify cover updated: 2
2 IPL sources [no flags]
nexthop 100.127.2.1 LISP0.4099
E1-SITE-2#
Först Edge noden. Här visas det förväntade beteendet. LISP används för att vidarebefordra trafik till denna destination. Specifikt kommer Border noden för plats 2 att ta emot trafiken. Vad gör Border noden?
B1-SITE-2#sh ip cef vrf Users 8.8.8.8 detail
0.0.0.0/0, epoch 0, flags [cover dependents, subtree context, rib only nolabel, check lisp eligibility, default route]
SC owned,sourced: LISP remote EID - locator status bits 0x00000000
LISP remote EID: 13 packets 6482 bytes fwd action signal-fwd, cfg as EID space
LISP source path list
nexthop 100.127.1.1 LISP0.4099
Covered dependent prefixes: 5
notify cover updated: 5
2 IPL sources [no flags]
nexthop 100.127.1.1 LISP0.4099
B1-SITE-2#
Återigen ser vi att LISP används. Den här gången kommer trafiken att vidarebefordras till Border noden för plats 1 (på grund av ”internet” -rutan som är konfigurerad i DNAC som vi gick igenom i förra avsnittet kring LISP multi-site).
Så vi måste ha en viss routing mot internet för att upprätta DIA för användares VN. För att göra det enkelt, låt oss konfigurera en statisk standardroute mot brandväggen, F1-SITE-2, på Border noden:
B1-SITE-2(config)#ip route vrf Users 0.0.0.0 0.0.0.0 100.126.201.2
B1-SITE-2(config)#end
B1-SITE-2#ping vrf Users 100.126.201.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.126.201.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
B1-SITE-2#
Bara för att säkerställa att vi faktiskt vidarebefordrar trafiken till brandväggen, vi bekräftar med en debug av ICMP:
F1-SITE-2#
May 25 10:09:51.500: ICMP: echo reply sent, src 100.126.201.2, dst 100.126.201.1, topology BASE, dscp 0 topoid 0
May 25 10:09:51.501: ICMP: echo reply sent, src 100.126.201.2, dst 100.126.201.1, topology BASE, dscp 0 topoid 0
May 25 10:09:51.503: ICMP: echo reply sent, src 100.126.201.2, dst 100.126.201.1, topology BASE, dscp 0 topoid 0
May 25 10:09:51.505: ICMP: echo reply sent, src 100.126.201.2, dst 100.126.201.1, topology BASE, dscp 0 topoid 0
May 25 10:09:51.506: ICMP: echo reply sent, src 100.126.201.2, dst 100.126.201.1, topology BASE, dscp 0 topoid 0
F1-SITE-2#
För att simulera internet har ett loopback-gränssnitt skapats på brandväggen:
! F1-SITE-2
interface Loopback8
ip address 8.8.8.8 255.255.255.255
Låt oss se om det fungerar genom att pinga 8.8.8.8 från EID-SITE-2 (simulerad av en router):
SDA-EP#ping vrf Site2_Users 8.8.8.8 so vlan12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
SDA-EP#
Heureka! Låt oss verifiera att paketen kom till brandväggen igen:
F1-SITE-2#
Hmm… Inget! Jag råkar ha konfigurerat en loop tillbaka till B1-SITE-1 också:
! B1-SITE-1:
interface Loopback8
vrf forwarding Users
ip address 8.8.8.8 255.255.255.255
En Debug av ICMP körs också här, och visas härnedan:
B1-SITE-1#
May 25 10:12:45.704: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 2
May 25 10:12:45.704: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 2
May 25 10:12:45.704: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 2
May 25 10:12:45.705: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 2
B1-SITE-1#
Så varför vidarebefordras trafiken till B1-SITE-1? LISP används fortfarande och har företräde framför vanlig IP-routing när det gäller en default route:
B1-SITE-2#sh ip cef vrf Users 8.8.8.8 detail
8.0.0.0/7, epoch 0, flags [subtree context, check lisp eligibility]
SC owned,sourced: LISP remote EID - locator status bits 0x00000000
LISP remote EID: 2 packets 1152 bytes fwd action encap, cfg as EID space
LISP source path list
nexthop 100.127.1.1 LISP0.4099
2 IPL sources [no flags]
nexthop 100.127.1.1 LISP0.4099
B1-SITE-2#
Så för att faktiskt arbeta runt detta beteende kan vi konfigurera specifika non-default routes:
B1-SITE-2(config)#ip route vrf Users 8.8.8.8 255.255.255.255 100.126.201.2
B1-SITE-2(config)#end
B1-SITE-2#sh ip cef vrf Users 8.8.8.8 detail
8.8.8.8/32, epoch 0, flags [subtree context]
SC inherited: LISP remote EID - locator status bits 0x00000000
recursive via 100.126.201.2
attached to Vlan3212
B1-SITE-2#
Och pinga igen:
SDA-EP#ping vrf Site2_Users 8.8.8.8 so vlan12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
SDA-EP#
Låt oss kolla i brandväggen:
F1-SITE-2#
May 25 10:21:44.909: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 0
May 25 10:21:44.913: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 0
May 25 10:21:44.918: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 0
May 25 10:21:44.922: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 0
May 25 10:21:44.925: ICMP: echo reply sent, src 8.8.8.8, dst 10.0.2.11, topology BASE, dscp 0 topoid 0
F1-SITE-2#
Nu har vi lyckats konfigurera en Direct Internet Access!
Statisk Internet Routing Table i SDA DIA
Eftersom vår workaround med SDA DIA innebär att inte använda default route, tror du kanske att det inte är skalbart. Men om vi skapar några aggregerade routes är det inte så illa:
ip route vrf Users 1.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 2.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 4.0.0.0 252.0.0.0 100.126.201.2
ip route vrf Users 8.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 11.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 12.0.0.0 252.0.0.0 100.126.201.2
ip route vrf Users 16.0.0.0 240.0.0.0 100.126.201.2
ip route vrf Users 32.0.0.0 224.0.0.0 100.126.201.2
ip route vrf Users 64.0.0.0 224.0.0.0 100.126.201.2
ip route vrf Users 96.0.0.0 252.0.0.0 100.126.201.2
ip route vrf Users 100.0.0.0 255.192.0.0 100.126.201.2
ip route vrf Users 100.128.0.0 255.128.0.0 100.126.201.2
ip route vrf Users 101.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 102.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 104.0.0.0 248.0.0.0 100.126.201.2
ip route vrf Users 112.0.0.0 248.0.0.0 100.126.201.2
ip route vrf Users 120.0.0.0 252.0.0.0 100.126.201.2
ip route vrf Users 124.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 126.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 128.0.0.0 224.0.0.0 100.126.201.2
ip route vrf Users 160.0.0.0 248.0.0.0 100.126.201.2
ip route vrf Users 168.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 170.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 172.0.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 172.32.0.0 255.224.0.0 100.126.201.2
ip route vrf Users 172.64.0.0 255.192.0.0 100.126.201.2
ip route vrf Users 172.128.0.0 255.128.0.0 100.126.201.2
ip route vrf Users 173.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 174.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 176.0.0.0 240.0.0.0 100.126.201.2
ip route vrf Users 192.0.1.0 255.255.255.0 100.126.201.2
ip route vrf Users 192.0.3.0 255.255.255.0 100.126.201.2
ip route vrf Users 192.0.4.0 255.255.252.0 100.126.201.2
ip route vrf Users 192.0.8.0 255.255.248.0 100.126.201.2
ip route vrf Users 192.0.16.0 255.255.240.0 100.126.201.2
ip route vrf Users 192.0.32.0 255.255.224.0 100.126.201.2
ip route vrf Users 192.0.64.0 255.255.192.0 100.126.201.2
ip route vrf Users 192.0.128.0 255.255.128.0 100.126.201.2
ip route vrf Users 192.1.0.0 255.255.0.0 100.126.201.2
ip route vrf Users 192.2.0.0 255.254.0.0 100.126.201.2
ip route vrf Users 192.4.0.0 255.252.0.0 100.126.201.2
ip route vrf Users 192.8.0.0 255.248.0.0 100.126.201.2
ip route vrf Users 192.16.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 192.32.0.0 255.224.0.0 100.126.201.2
ip route vrf Users 192.64.0.0 255.192.0.0 100.126.201.2
ip route vrf Users 192.128.0.0 255.224.0.0 100.126.201.2
ip route vrf Users 192.160.0.0 255.248.0.0 100.126.201.2
ip route vrf Users 192.169.0.0 255.255.0.0 100.126.201.2
ip route vrf Users 192.170.0.0 255.254.0.0 100.126.201.2
ip route vrf Users 192.172.0.0 255.252.0.0 100.126.201.2
ip route vrf Users 192.176.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 192.192.0.0 255.192.0.0 100.126.201.2
ip route vrf Users 193.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 194.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 196.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 198.0.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 198.16.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 198.17.0.0 255.255.0.0 100.126.201.2
ip route vrf Users 198.20.0.0 255.252.0.0 100.126.201.2
ip route vrf Users 198.24.0.0 255.248.0.0 100.126.201.2
ip route vrf Users 198.32.0.0 255.240.0.0 100.126.201.2
ip route vrf Users 198.48.0.0 255.254.0.0 100.126.201.2
ip route vrf Users 198.50.0.0 255.255.0.0 100.126.201.2
ip route vrf Users 198.51.0.0 255.255.192.0 100.126.201.2
ip route vrf Users 198.51.64.0 255.255.224.0 100.126.201.2
ip route vrf Users 198.51.96.0 255.255.252.0 100.126.201.2
ip route vrf Users 198.51.101.0 255.255.255.0 100.126.201.2
ip route vrf Users 198.51.102.0 255.255.254.0 100.126.201.2
ip route vrf Users 198.51.104.0 255.255.248.0 100.126.201.2
ip route vrf Users 198.51.112.0 255.255.240.0 100.126.201.2
ip route vrf Users 198.51.128.0 255.255.128.0 100.126.201.2
ip route vrf Users 198.52.0.0 255.252.0.0 100.126.201.2
ip route vrf Users 198.56.0.0 255.248.0.0 100.126.201.2
ip route vrf Users 198.64.0.0 255.192.0.0 100.126.201.2
ip route vrf Users 198.128.0.0 255.128.0.0 100.126.201.2
ip route vrf Users 199.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 200.0.0.0 254.0.0.0 100.126.201.2
ip route vrf Users 202.0.0.0 255.0.0.0 100.126.201.2
ip route vrf Users 203.0.0.0 255.255.192.0 100.126.201.2
ip route vrf Users 203.0.64.0 255.255.224.0 100.126.201.2
ip route vrf Users 203.0.96.0 255.255.240.0 100.126.201.2
ip route vrf Users 203.0.112.0 255.255.255.0 100.126.201.2
ip route vrf Users 203.0.114.0 255.255.254.0 100.126.201.2
ip route vrf Users 203.0.116.0 255.255.252.0 100.126.201.2
ip route vrf Users 203.0.120.0 255.255.248.0 100.126.201.2
ip route vrf Users 203.0.128.0 255.255.128.0 100.126.201.2
ip route vrf Users 204.0.0.0 252.0.0.0 100.126.201.2
ip route vrf Users 208.0.0.0 240.0.0.0 100.126.201.2
Här har jag exkluderat dessa ”bogons”:
0.0.0.0 255.0.0.0
10.0.0.0 255.0.0.0
100.64.0.0 255.192.0.0
127.0.0.0 255.0.0.0
169.254.0.0 255.255.0.0
172.16.0.0 255.240.0.0
192.0.0.0 255.255.255.0
192.0.2.0 255.255.255.0
192.168.0.0 255.255.0.0
198.18.0.0 255.254.0.0
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0
224.0.0.0 240.0.0.0
240.0.0.0 240.0.0.0
Listan finns på Team Cymru
Andra referenser är:
Nu var kravet för användarnas VN att användare skulle kunna nå internet via lokal breakout och nå centrala tjänster och andra användare på de andra platserna. Låt oss se om en användare på plats 2 fortfarande kan nå en användare på plats 1:
SDA-EP#ping vrf Site2_Users 10.0.1.11 so vlan12
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.11, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.11
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
SDA-EP#
Det funkar.
