This document discusses tools for automating network interconnection and capacity planning decisions. It describes the complexity of manual processes and how automation can help by providing consistency, speed, ease of support, and compliance. NETCONF is presented as a standard for automating device configuration. Automating common tasks like adding ports and BGP sessions can help provision capacity based on traffic data. Total pluggability of providers is suggested to further streamline automation.
14. How much traffic?
Because I want to provision capacity
Because I want to handle failover/resilience
Because I want to move transit capacity to peering links
Because I want to consider connecting an exchange
15. 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
AS12345
AS2
AS1
Many peers Many peers
AS3
Questions about your top ‘n’ peers
16. Decision = Data
15/08/2014 BGP Traffic Engineering, Andy Davidson 16
Manuel Kasper - https://neon1.net/as-stats/as-stats-presentation-swinog16.pdf
19. 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
20. Automation is not the product
Automation is the enabler
Consistency
Speed of Delivery
Ease of Support
Speed to integrate
Compliance
Integrated OSS/BSS
Confidence
Commodity
Devolved control
21. What can be touched
• Adding ports (Private peering)
• Adding BGP sessions (Public & Private peering)
• Adding VLANs (Ethernet interconnection)
• Adding access configuration (Wholesale)
22. NETCONF
• API to configure network devices
• Manage configuration and state
• XML RPC using SSH as transport
• Mirrors device configuration, capabilities
Candidate configuration Running configuration
27. 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
28. 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 anyway
You are exclusively focussed on delivery, saving money, saving effort, removing pain, learning
29. andy ~ $ perl autopeer.pl 12536 LONAP Allegro
terminal monitor
conf t
router bgp xxxxx
neighbor 5.57.81.30 remote-as 12536
neighbor 5.57.81.30 description PEER:: Allegro
neighbor 5.57.81.30 inherit peer-session peer_Lonap
address-family ipv4
neighbor 5.57.81.30 activate
neighbor 5.57.81.30 inherit peer-policy peer_Lonap
end
Take a single, small step to gain skills and confidence
34. Automation & Self Service at the IXP
IXP Manager
(software tool, browser based)
Used at LONAP and IXLeeds
Admin & Customer automation
Open Source
https://github.com/inex/IXP-Manager
35. 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!