Ipv6 deployment at the university of warwick - networkshop44

Editor's Notes

• #4: A quick reminder (for me) of our network hardware We are almost entirely a Cisco site running NX-OS and IOS
• #5: And over the top of all this hardware, we are running: VRF – virtual routeing and forwarding OSPFv2 internally BGP internally for inter-vrf routeing and DNS anycast
• #6: Nothing world-shattering here We’ve had IPv6 addressing on our JANET routers for a while now, just peering with JANET We went through cycles of discovering which code versions had which features, upgrading (rebooting) and/or preparing config changes At this point we had no IPv6 internally, we were preparing the ground Everything was done under change management, and you’d be amazed what can be covered under a “non service impacting configuration change”!
• #7: We have created our test vlans and tested connectivity; of course that also involves configuring and running OSPFv3 across all of our VRFs (6) In conjunction with a colleague who is extensively revamping our DNS & DHCP, we have a test DNS/DHCP server on an IPv6 vlan in a data centre. There are a few problems under investigation… The firewall has IPv6 enabled and addressing is configured externally, but no traffic is flowing yet – ought to be straightforward! Well, so much for the plan, now for a look at rolling out
• #8: As we’re dual stacking, we’re bolting all things IPv6 on top of our existing, live, network. No pressure there. PIC1 – we were hoping for something along these lines, but it seems to resemble PIC2 more
• #9: As luck, or foresight, or budget, or some combination of the three would have it, we do have a test lab, containing one of most of our bits of hardware. It has been pillaged from time to time (campus wide power outage anyone?) for replacement parts, but most of the time it’s been there for us. In addition to the test lab, I’ve done varying amounts of testing with
• #10: If you haven’t encountered GNS3, it’s free Great for some things like testing BGP Has hardware and software limitations It hasn’t been as useful as I would have liked in this project, but this was anticipated We have also recently acquired
• #11: Virtual Internet Routeing Lab Annual cost $80 per license Supports IOS and NX-OS Only recently acquired, must investigate further
• #12: Enough said… SO, moving on to my first warning:
• #13: Well, not quite all, fortunately but when you have change management who are worried that every change might involve / cause a reboot
• #14: no sliding down in your seats or pretending to be asleep, unless of course you are asleep
• #15: We use OSPFv2 internally, as I suspect do most of you, but can I have a quick show of hands from anyone who uses IS-IS? Cisco seem to like it, so I took a look And I really really don’t like OSPF (it hurts when I have to debug it)
• #16: After some experimentation in the test lab, some reboots, quite a bit of cursing and a few emails to Cisco…
• #17: As we’re adding IPv6 on top of IPv4, scripting is definitely on the agenda Processing existing configuration files / mapping addresses Trying to avoid silly config / typing mistakes Process config -> try on test lab -> repeat…
• #18: We already do an annual code refresh with timed reboots overnight Add to that the sdm (switch database management) memory profile change to allocate memory for IPv6 address tables etc. This enables the feature, then needs a reboot to activate it And a reboot is also needed to activate jumbo frames How many stacks?
• #19: We have 35 VSS distribution pairs and we have enough trouble with software upgrades / failing hardware, so “no reboot” is most welcome Loopbacks, interfaces, port channels, VLANs, Do this from the console as all IP addressing disappears I have tried it this way (with the aid of some perl scripting) and it does work. But…
• #20: Fortunately, Cisco provide the vrf upgrade-cli command, run once per VRF, but it does delete all the IPv6 addresses configured on interfaces. This sounds a much better option, as long as you haven’t configured IPv6 addresses, or as long as you’ve saved them if they are configured! Aside. There comes a moment, probably around the long dark tea-time of the soul (4pm on a Thursday?) , when you’ve copied a live config to the test lab and made some changes. You type “reload”, look down at the CLI prompt and hope earnestly that you haven’t just done that on the live switch! Moral: change the prompts on the test network
• #21: Significantly easier to configure than on IOS Just needed to enable OSPFv3 Straightforward apart from the natural nervousness of interfering with a working network
• #22: Keeping it as simple as reasonable Biggest distribution site has around 100 vlans, most have significantly fewer. The data centres are the exception, with around 140 vlans currently 256 * 35 = 8900 allocated out of 16384 Could always request more space!
• #23: Lots of space for infrastructure addressing – all in one block so easy to block on the firewall As recommended, no small bitty subnets Conversion – tie IPv4 and IPv6 addresses together - just makes things simpler
• #24: Infrastructure addresses => public addresses but shouldn’t be generally accessible Gateway address at the bottom for simplicity and ease of typing
• #26: As mentioned before, RFC1925 comes to mind Don’t forget, resources include people!
• #27: This is just a very small portion of the IPv6 routeing table on one of our core switches – only showing the initial test vlans Note the link local addresses for next hop
• #29: We want to resolve one or two issues with our IPv4 inter-VRF routeing, then we’ll add the IPv6 Could be the scariest part of it!