IPv6 deployment at Warwick

Mark Charlton

IPv6 deployment at WarwickMark Charlton

A quick recap from Leeds (1)Core – Nexus 7018 – NX-OS 6.2.12Data centres – Nexus 7010 – NX-OS 6.2.12 & Nexus 5k/2k – NX-OS 5.1(3) / 7.1(1)Distribution – 6500 VSS pairs – IOS 15.1(2)Service layer – 6513 – IOS 15.1(2)Access – 3750 (15.0(2)) & 3850 (03.06.03)

A quick recap from Leeds (2)JANET routers – Cisco 7604 – 15.2(4)Firewalls – Fortinet

Currently running VRFs with OSPFv2 & BGP on IPv4

The grand plan (1)Dual stackAdd IPv6 addressing to JANET routersUpgrade / prepare– Access switches– Distribution switches– Core switches

The grand plan (2)Create test vlansCheck connectivityDNS /DHCPv6 testingFirewall rules“sign off” IPv6 connectivityEveryone takes advantage!

What have we done?The nuts and bolts

The test lab (1)As luck would have it:– 7018– 6506– 6513– Access switches – 3750 / 3850

The virtual test lab – GNS3www.gns3.com

The virtual test lab - Cisco VIRLvirl.cisco.com

The test lab (2)If humanly possible, get oneBeg, borrow, steal itIf all else fails, buy it!Apart from the obvious reasons, see later…

Be prepared for

Audience participation (1)A small detour

Audience participation (1)Does anyone use IS-IS?Suggested by CiscoTested in the lab – straightforward to implement(and I hate OSPF )But…

It doesn’t workAt least, the combination of– IS-IS– VRF– IPv6So, back to OSPFv3

perl is your friendOr your favourite scripting languageIdeal for munging configuration filesMap existing IPv4 addresses to IPv6Automate to avoid errorsUseful to have a test lab

Access layer painReboot for new code (annual event)Reboot for sdm memory profile– Can be bundled with software update if timings

allowReboot for jumbo framesAnd we have 350 access stacks!

Distribution layer painGood news – no reboot necessaryBad news – config changes for IPv6:– from ip vrf <VRF> to vrf definition <VRF>– Delete & re-add VRFs (six) loses ALL IPv4 config– Re-add IPv4 addresses to every interface– Re-add all OSPF info, static routes, pim, mroute

Distribution layer pain reliefCisco have the vrf upgrade-cli command– Deletes all IPv6 addresses configured on interfaces

Only done when IPv6 is required in that areaScript: collect all relevant info to be re-instatedBut it is service impacting (06:00 start, anyone?)Test lab was (almost) invaluable to ensure config changes were correct

Core and data centre (NX-OS)More good news:– NX-OS is IPv6 ready– Very little reconfiguration– Just add IPv6 addressing and routeing

Addressing plan35 Distribution sitesMaximum currently ~100 vlans (140 in DC)256 contiguous /64s per site(~55% allocated)16384 /64s for wirelessStill only 50% allocated (not used!)

Addressing plan31 /64s for infrastructureNothing smaller than /64 except /126 & /128Converted IPv4 to IPv6 where necessary, e.g.– 172.31.4.55 2001:630:1c3:ss:172:31:4:55

Addressing planOnly using public and link-local addressingInfrastructure addresses blocked on firewall and by inter-VRF routeingGateway address always bottom of range:– 2001:630:1c3:ssss::1 rather than

2001:630:1c3:ssss:ffff:ffff:ffff:ffff

Summary so farWe do have a clearer understandingNot as bad as fearedNeedn’t be disruptive apart from access switch rebootsConcentrating on just the networkBut what about those pesky servers?

RFC1925 – The twelve networking truths

…(9) For all resources, whatever it is, you need more.

(9a) (corollary) Every networking problem always takes longer to solve than it seems like it should.…

Routeing tables like this…CORE-SWITCH# sh ipv6 route vrf CAMPUS-VRFIPv6 Routing Table for VRF "CAMPUS-VRF"'*' denotes best ucast next-hop'**' denotes best mcast next-hop'[x/y]' denotes [preference/metric]

2001:630:1c3:5577::/64, ubest/mbest: 2/0 *via fe80::4255:39ff:fe04:d041, Po268.1381, [110/41], 7w0d, ospfv3-601, intra *via fe80::4255:39ff:fe26:aa41, Po266.1371, [110/41], 7w0d, ospfv3-601, intra2001:630:1c3:6363::/64, ubest/mbest: 1/0 *via fe80::208:e3ff:feff:fd94, Po200.1101, [110/3], 2w2d, ospfv3-601, intra

Other issues to investigateDHCPv6– Would like it everywhere– Can’t for wireless / residences / Android– Ongoing investigation– Stateless?Traffic shaping

Other issues to investigateJumbo frames– Wanted / needed? (reboot access switches)– Just needs enabling on cores / distributionSecurity / logging– Update existing logging scripts?Inter-VRF routeing

The rest of the universityStill no demand to speak of– One genuine enquiry – really!Some areas migrating to RFC1918 spaceNeed to get server teams started– Windows / UNIX / VMWare / desksideTrying to be prepared

Any reboots questions?

Contact

Mark Charlton