NFD9 - Dinesh Dutt, Data Center Architectures

v

DC Network Architectures

Dinesh G Dutt

Feb 9, 2015

cumulusnetworks.com

IP Fabric

§  CLOS topology enables scalale, flexible networks

§  High Capacity, fine-graned failure domain

Spine

Leaf

IP Fabric

§  L2 active/active with MLAG

§  Drop in existing architecture

L2 Fabric

Aggregation

Access

L3

L2

§  Agile, scalable, dynamic networking over stable, scalable infrastructure

Network Virtualization Over IP Fabric

Spine

Leaf

VNI Blue & Red

cumulusnetworks.com 2

Network Architectures Prevalent in Datacenters

Networking For The Modern DC

§ Make networking a first class citizen in the data center §  Simplify networking §  Allow innovation with networks, not around it



• Simplify Networking

• Switch as a Platform

Network As Legoland

§ Simple building blocks has several emergent properties: §  Network operations become simpler §  Failures become simpler §  Networks become more scalable, flexible and agile


Simplify L2 Networking: Reduce Clutter

§ MLAG is the base technology §  Simplify STP to be failstop mechanism

•  No need for MSTP, PVRSTP etc. •  Simple, interoperable RSTP is good enough

§  Use standard, defensive techniques

•  Enable Bridge Assurance on all links

§  FHRP becomes trivial •  Virtual IP/MAC, ARP to keep MAC table hot •  Eliminate complex FHRP protocols


Simplify L3 Networking: Simplify Configuration

§ IP is the base technology (sometimes MPLS) §  Mature, sophisticated, scalable

•  Proven ideas, basis for all large DC I know of

§  Based on standard technologies

§  Primary challenge is that its considered hard to configure •  Understand IP address and subnets

§  Easy to configure does not mean “single point of

management”


Principles of Simplifying Configuration

§ Cookie cutter configuration a.k.a substitutability §  As little node-specific variation as possible

•  Nothing more than a single IP address, node name, for example

§  As little duplication of information as possible •  Specifying IP addresses of interfaces AND in OSPF/BGP network statements

§  As much configuration as necessary, not more

§ If its simple, its automatable §  Why do boring stuff


Prescriptive Topology Manager (PTM): Verify Connectivity

§  Define expected topology using DOT language §  Verify connectivity per topology plan using LLDP §  Take dynamically defined actions based on mis/match of expected & actual §  https://github.com/CumulusNetworks/ptm


Graph G { S1:p1 – M1:p3; S1:p2 – M2:p3; S1:p3 – M3:p3; S1:p4 – M4:p3; S2:p3 – M3:p4; S2:p4 – M4:p4; M1:p1 – T1:p1;

... M4:p2 – T4:p2;

}

Topology Graph

S1 S2

M1 M2 M3 M4

T1 T2 T3 T4

Simplify Routing Config (eg. OSPF)


S1 S2

M1 M2 M3 M4

T1 T2 T3 T4

Area 0.0.0.1. Area 0.0.0.1.

Area 0.0.0.0

router ospf log-‐adjacency-‐changes detail ospf router-‐id 10.0.0.11 ! interface swp1 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point ! interface swp2 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point ! interface swp3 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point ! interface swp4 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point !

router ospf log-‐adjacency-‐changes detail ospf router-‐id 10.0.0.16 ! interface swp1 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point ! interface swp2 ip ospf area 0.0.0.0 ip ospf network point-‐to-‐point ! interface swp3 ip ospf area 0.0.0.1 ip ospf network point-‐to-‐point ! interface swp4 ip ospf area 0.0.0.1 ip ospf network point-‐to-‐point

S1 M1 Easy to replicate–-

Only difference is router-id

If PTM can verify connectivity, OSPF unnumbered can reduce use of IP address

Simplify BGP Configuration – Interface-based Configuration


S1 S2

M1 M2 M3 M4

T1 T2 T3 T4

! Config on M1 router bgp 64501 bgp log-‐neighbor-‐changes bgp router-‐id 10.1.1.1 ! Spine connections neighbor swp1 remote-‐as 64500 neighbor swp2 remote-‐as 64500 ! TOR connections neighbor swp3 remote-‐as 64512 neighbor swp4 remote-‐as 64513 !

! Config on M2 router bgp 64501 bgp log-‐neighbor-‐changes bgp router-‐id 10.1.1.2 ! Spine connections neighbor swp1 remote-‐as 64500 neighbor swp2 remote-‐as 64500 ! TOR connections neighbor swp3 remote-‐as 64512 neighbor swp4 remote-‐as 64513 !

! Config on T1 router bgp 64512 bgp log-‐neighbor-‐changes bgp router-‐id 10.1.2.1 ! Spine connections neighbor swp1 remote-‐as 64501 neighbor swp2 remote-‐as 64501 redistribute connected !

! Config on T2 router bgp 64513 bgp log-‐neighbor-‐changes bgp router-‐id 10.1.2.2 ! Spine connections neighbor swp1 remote-‐as 64501 neighbor swp2 remote-‐as 64501 redistribute connected !

Simplifying BGP Configuration Further


S1 S2

M1 M2 M3 M4

T1 T2 T3 T4

router bgp 64501 bgp log-‐neighbor-‐changes bgp router-‐id lo ! neighbor swp1 remote-‐as external neighbor swp2 remote-‐as external neighbor swp3 remote-‐as external neighbor swp4 remote-‐as external !

router bgp 64501 bgp log-‐neighbor-‐changes bgp router-‐id lo ! neighbor swp1 remote-‐as external neighbor swp2 remote-‐as external neighbor swp3 remote-‐as external neighbor swp4 remote-‐as external !

router bgp 64512 bgp log-‐neighbor-‐changes bgp router-‐id lo ! neighbor swp1 remote-‐as external neighbor swp2 remote-‐as external redistribute connected !

router bgp 64513 bgp log-‐neighbor-‐changes bgp router-‐id lo ! neighbor swp1 remote-‐as external neighbor swp2 remote-‐as external redistribute connected !

Reuse Server Management Toolkit

13 cumulusnetworks.com

Network Automation Orchestration Monitoring

Make Networking Like Any Server App

§ Modifications to existing configuration are done by updating a configuration file and reloading service §  Only differences are applied to running service

§ ifreload and quagga support similar constructs now (as does clagd, switchd etc.) §  ifreload is part of ifupdown2, for configuring interfaces

and L2 §  Quagga is used to configure routing


Fitting Existing Applications: Network Virtualization

§ With network virtualization technologies such as VxLAN, you can create L2 overlays over the L3 fabric §  Separating virtual network from physical network provides

for agile network management

§  Can run both new applications such as Hadoop and memcached along with more traditional apps on the same network: flexibility

§  Solutions from various ecosystem partners, LNV



• Simplify Networking

• Switch as a Platform

Switch As a Platform, Not a Blackbox

§ Open network up to innovation again §  This was a key reason why IP overcame competing

technologies

§ Network operating system as an enabler, not gatekeeper §  Support “no assembly required” networking §  Allow customization if customer/partner desire §  Enable rich ecosystem



Technology Ecosystem Partners: Solutions Exchange

Routing Network Automation Orchestration Network

Virtualization Monitoring Security Storage & Hyper-Converged Big Data

Cumulus Linux

Industry Standard Hardware

NSX Identity Manager

Hoplite

Example 1: Partner’s Crafting an ACL REST API


Example 2 – Enable Easy Integration (Midokura)


Jan 16th Jan 24th Feb 6th Jan 25th Jan 28th Feb 3rd Jan 29th

Midokura meeting with Cumulus

Trident II switch on workbench made available to Midokura

Core Code Working , Discussed option to open ports , get a VM setup and connected to switch port

First Demo Recording Done

Demo shown to Cumulus staff by Midokura Team

Got activation and service access to all documentation and support portal

Midokura Demo with Cumulus Integration showcased at Open Daylight

Initial Integration Lifecycle executed in 22 days

Example 3: Anybody Can Build A Cumulus API


A Summing Up

§ Three datacenter architectures

§ Simplifying networking is key to agility, flexibility, scalability

§ A network operating system needs to be an enabler, not a gatekeeper


© 2014 Cumulus Networks. CUMULUS, the Cumulus Logo, CUMULUS NETWORKS, and the Rocket Turtle Logo (the “Marks”) are trademarks and service marks of Cumulus Networks, Inc. in the U.S. and other countries. You are not permitted to use the Marks without the prior written consent of Cumulus Networks. The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis. All other marks are used under fair use or license from their respective owners.

§ Thank You!


NFD9 - Dinesh Dutt, Data Center Architectures

Software

Transcript of NFD9 - Dinesh Dutt, Data Center Architectures