Network Automation - Interconnection tools

Interconnection tools and automationAndy Davidson <andy.davidson@allegro.net> Allegro Networks / LONAP August 2014 Peer 2.0/SFO

Interconnection tools and automationAndy Davidson <andy.davidson@allegro.net> Allegro Networks / LONAP August 2014 Peer 2.0/SFO “The next big thing…”

Com

plex

ity

Time

Com

plex

ity

Time

“Let’s use our unlimited money andtime to peer at the local IX!”

Com

plex

ity

Time

“Can you show me thatthis is saving us money?”

Com

plex

ity

Time

“Let’s add Ethernet interconnectsfor the cloud”

Com

plex

ity

Time

“Let’s buy/sell service via L2TP!”

Com

plex

ity

Time

“Please could you open a POP in France?”

Com

plex

ity

Time

“We need the network to generatehigher cost savings”

Com

plex

ity

Simple

Complex

TOOLS

Decision Making:Tools to manage the big picture

I’m not talking about the

YESor

NOdecision

CapacityDeciding how to deliver traffic

How much traffic?

Because I want to provision capacityBecause I want to handle failover/resilience

Because I want to move transit capacity to peering linksBecause I want to consider connecting an exchange

RT1 RT2

EX2EX1

PP1

PP2 PP3

Transit

6Gbit

5Gbit

2Gbit

4Gbit 4Gbit

AS2 is your largest flow - via PP2 - maybe needs a second private peer backup on RT2?AS1 via PP1, configure a backup over EX1 or EX2 for deterministic routing?

Can you move larger peers behind EX1 and EX2 onto private peering?If there is an exchange failure, where will the traffic go? How big a flow should you care about?

If you lose RT2, how will traffic to PP3 and traffic volume via EX2 be delivered?If you lose RT1, how will traffic volume via PP3 and EX1 be delivered?

4Gbit 4Gbit

AS12345AS2

AS1

Many peers Many peers

AS3

Questions about your top ‘n’ peers

Decision = Data

18/04/2023 BGP Traffic Engineering, Andy Davidson 16

Manuel Kasper - https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf

IP Address Time and date Amount of TrafficFor remote asn

Automating provisioning

Automation has been possible for decades

Tricky part is the business process tie-in

Business or customer need Network Action(Why else do an activity?)

Configure the network, not the device

This is the source of complexity

This is also where state anxiety lives

Automation is not the productAutomation is the enabler

ConsistencySpeed of Delivery

Ease of SupportSpeed to integrate

ComplianceIntegrated OSS/BSS

ConfidenceCommodity

Devolved control

What can be touched

• Adding ports (Private peering)• Adding BGP sessions (Public & Private peering)• Adding VLANs (Ethernet interconnection)• Adding access configuration (Wholesale)

NETCONF

• API to configure network devices• Manage configuration and state• XML RPC using SSH as transport• Mirrors device configuration, capabilities

Candidate configuration Running configuration

<configuration> <interfaces> <interface> <name>ge-1/0/1</name> <apply-groups>INTERFACE-PARAMETERS-EDGE</apply-groups> <description>CUST:Manchester Roller Derby (AS789)</description> <vlan-tagging/> <encapsulation>flexible-ethernet-services</encapsulation> <unit> <name>520</name> <description>CUST:Manchester Roller Derby (AS789)[SNAP-PEERING:LINX London]{ZRiEKiyK}</description> <encapsulation>vlan-vpls</encapsulation> <vlan-id>520</vlan-id> <family> <vpls></vpls> </family> </unit> </interface> </interfaces></configuration>

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R7/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“ message-id="3">

<commit-results><ok/>

</comit-results></rpc-reply>

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R7/junos" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0“ message-id="3">

<commit-results> <rpc-error>

<error-severity>error</error-severity><source-daemon>

dcd</source-daemon><error-path>

[edit interfaces ge-1/0/4]</error-path><error-info>

<bad-element>unit 0

</bad-element></error-info><error-message>

interface needs to be in a VPLS routing instance to support family VPLS

</error-message> </rpc-error>

</commit-results> <ok/>

</rpc-reply>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="2"> <lock> <target> <candidate></candidate> <target> </lock></rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="3">

<ok></ok></rpc-reply>

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="7"> <commit></commit></rpc>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="7"> <ok></ok></rpc-reply>

State – configure the network, not the device• Propose business logic• Lock running config• Lock candidate config• Edit candidate config• (repeat across network)• Commit check• Commit• Copy running config to start• Unlock configurations• Confirm business logic

Take one single boring process and automate it out of existence

Don’t worry too much about your software today. If this thing catches on, you’re binning your early code anywayYou are exclusively focussed on delivery, saving money, saving effort, removing pain, learning

andy ~ $ perl autopeer.pl 12536 LONAP Allegro

terminal monitorconf trouter bgp xxxxxneighbor 5.57.81.30 remote-as 12536neighbor 5.57.81.30 description PEER:: Allegroneighbor 5.57.81.30 inherit peer-session peer_Lonapaddress-family ipv4neighbor 5.57.81.30 activateneighbor 5.57.81.30 inherit peer-policy peer_Lonapend

Take a single, small step to gain skills and confidence

Total Plugability

Providers that you can configure automatically like you can your devices

Network provisioning at your…

Example use of auto-providers – Private peering

Automation & Self Service at the IXP

IXP Manager(software tool, browser based)

Used at LONAP and IXLeedsAdmin & Customer automation

Open Sourcehttps://github.com/inex/IXP-Manager

Hard to find good conversations about automation avoiding:

Those panning for gold in the shape of SDN

Vendors wanting to sell junk network management software

People who just want to nick your leads

“Developers” with empty OSS “projects” on GitHub

Ideally, one day we will have:

Documented wishlist & best practice

Pluggable upstream and downstream services

Reliable standards adherence from vendors

Differentiated, competitive market for automated wholesale services!

?

Andy Davidsonandy.davidson@allegro.net_______________________

CTO, Allegro NetworksDirector, LONAP Ltd.

+44 161 200 1610