A couple of months ago I attended an event organized by Cisco called a Tech Huddle. It was a full day of presentations, in this case of products and technologies of the service provider variety. Mostly.
I recently revisited the slides and my notes from the day, and this is what I think about them (disclaimer: I was invited to the event because my employer is a Cisco customer, but this post is my own independent initiative).
The agenda for the day was as follows:
- ACI + Nexus 9000
- SDN/NFV
- How to write an IPv6 addressing plan
- ASR9K Product Update
- Metro Ethernet Platform Update
- Service Control Engine Product Update
- BGP
- Cisco Modeling Labs
The ASR9K, ME and SCE product updates were a bit dry (module this, speed that etc.), but that was expected and it's something I don't see the point in writing about (check with your Cisco SE if you want to know more).
Cisco Modeling Labs (aka VIRL) was a quick update about what it is and how its licensing will work: a base license, plus other add-ons for more software support (like NX-OS) and scalability (number of nodes). Not so cool, but I liked the fact that you get full TAC support in the price - I take this to mean that the virtualized images are expected to work very well (maybe I'm a bit too optimistic?) and that some of the testing could be done in CML with results carrying more weight than those coming out of emulators such as GNS3.
How to write an IPv6 addressing plan
This was a condensed version of the Cisco Live presentation (by Veronika McKillop), which you can find and watch online (BRKRST-2667). It made a lot of sense and there were some nice tips there, with examples targeted mostly at broadband service providers.
TLDR: it's important to get it right (just look at the current mess we have in IPv4). Important enough that I've written a separate post about it.
ACI + Nexus 9000
Not very service-providery, but it's new and Cisco's quite keen to push it out there. It's a Data Centre fabric based on new Nexus hardware that aims to deliver a scalable and programmable platform.
The presentation was quite high-level and these are some of the features:
- Based on Nexus 9000 + APIC (Application Policy Infrastructure Controller)
- Spine/leaf architecture
- Routed fabric (ISIS), forwarding is based on LISP principles
- VxLAN/NVGRE/VLAN at scale
- HW based gateway in every leaf
- Full visibility of virtual and physical traffic
- Cisco + Broadcom ASICs
- Cisco provides advanced features - caching, v4/v6, flow prioritization, telemetry, service insertion, flood elimination
- Broadcom provides port density, L2/L3 forwarding, buffering
This sounds very nice (to my limited DC knowledge) and it looks like some of the technologies used are starting to stabilize between vendors. BUT. Is this something I can use now in the SP domain? Not so much, unless it's in the IT services infrastructure (and that's really beside the point). I wrote about resisting the temptation and this is a perfect example.
UPDATE: If you want more details though, there's a very detailed write-up over on Come Route With Me! with notes from a Cisco ACI bootcamp.
SDN/NFV
Now we're getting more closer to SP and Mobile Operator territory. Of course it had to start with the same SDN story about why it is so good and amazing (I'm sure y'all know it by heart :).
They call the solution EPN (Evolved Programmable Networks) and it's a combination of:
- Unified MPLS/Segment routing
- The network maintains segments, not application state
- Fewer protocols, no need for RSVP, LDP
- Forwarding based on labels with simple OSPF/ISIS extension
- 50ms FRR
- Virtualization
- Multi-hypervisor, but KVM preferred
- OpenStack, OpenDaylight
- Virtual RR (CSR 1000v)
- IP/Optical integration (Cisco nLight)
To make things less academic, a few examples were presented:
- Use-case: Radio cSON controller (Quantum)
- Use-case: WAN controller
- Re-routing of traffic to avoid congested links (either user-triggered or policy triggered by a premium customer)
- Classification via OpenFlow, traffic engineering via SegmentRouting
- Use-case: SP WAN to SP DC infrastructure (VRF to virtualized resources mapping between two different controllers) with service chaining through multiple virtualized network functions
The last use-case I think is the most relevant, as right now there's no easy way to bridge between a VRF-centric infrastructure and a virtualized domain (DC fabric). If there is a way, I'd love to hear about it (hint: comments below).
BGP
I saved the best for last. For me this was the most interesting presentation and sparked some great conversations afterwards (to the point where we were the last to leave).
It all starts with WAN optimization, where there's a big need for constant improvement. The example was talking about a move from thousands of engineered auto BW RSVP-TE tunnels to tens of SR (SegmentRouting) tunnels (with two unnamed customers as success stories).
To achieve this, you've guessed it, you need a controller. But that's not enough, a brain without any knowledge is powerless, so it must feed on topology information (IGP, links, BGP), load/capacity (SNMP, Netflow, NETCONF/YANG) and then control the network using PCEP.
Getting topology information from an IGP is not a trivial matter - you need to have adjacencies with routers in all areas (otherwise you have an incomplete view of the network) and perhaps different VRFs etc.
A better way to advertise such information is via BGP LinkState, which is a new address-family that can carry LSDBs from ISIS and OSPF. Pretty cool, huh? You essentially redistribute the LSDB into BGP and then advertise it to the controller via a multi-hop BGP peering (no need for direct adjacencies anymore).
BGP LS is available starting from IOS XR 5.1.1 and you can even download a VM image from Cisco to take it for a spin!
Another BGP extension that's worth mentioning is BGP FlowSpec (RFC 5575). It allows the originator of a BGP NLRI to advertise a flow filter to its neighbors. Its most immediate and obvious application is in the field of DDoS attack mitigation, allowing more granularity than straight black-holing of traffic.
Match criteria is quite what you'd expect (L3-4 centric): src/dst IP, protocol, TCP/UDP ports, ICMP type/code, TCP flags, DSCP, length and fragmentation bits.
Vendor support is growing, with Cisco touting IOS XR 5.2.0 and interoperability with exaBGP (IPv4 controller), Arbor (IPv4 controller), Juniper (IPv4 client) and Alcatel (IPv4 & IPv6 client).
Lastly, BGP Monitoring Protocol was introduced as a better way of getting routing information from BGP's Adj-RIB-In (screen scraping is bad, OK?).
That's it!
Phew. This turned out to be longer than I thought - but I now have a few technologies I'm going to investigate in the near future (BGP-LS, FlowSpec, BMP) and I'm sure you'll hear more about them here.
And, as always, thanks for reading.