This document discusses the evolving role of network engineering and how automation is becoming increasingly important. It provides examples of how Cloudflare automates various network tasks like monitoring transit links, configuring peering sessions, and provisioning new equipment in a standardized way using tools like SaltStack. Templates with Jinja allow dynamic configuration that can be deployed globally and in parallel to many devices simultaneously, improving efficiency compared to manual configuration. The role of network engineers is shifting towards greater use of programmability and automation to manage increasingly large and complex networks.

1. Jimmy Lim IDNOG 5
jhalim@cloudflare.com Jakarta, 26 July 2018
The bond between automation and
network engineering

2. What is Cloudflare?

3. Protect and accelerate any website online
● Direct visitors to the nearest entry point
○ Fast!
■ Lesser hops
■ Reduced latency
● Save bandwidth!
○ Lesser requests to origin
○ Mitigate DDoS
● Resiliency
○ 150+ locations!

5. The evolving role of network engineering

6. NOC
Provisioning
Operations
Change management
Design/architect
Peering
Tools/automation
Network engineering role

7. Evolving role of network engineering
● Towards greater automation and programmability
○ Networks grow rapidly
○ More complex design
● Keep upgrading skills
○ Make yourself comfortable
○ Keep your worth
● Automation is a must and blend towards network
engineering

8. NOC
Provisioning
Operations Tools/Automation
Change management
Design/architect
Peering
The evolution and bonding

9. What is Cloudflare doing?

10. Large distributed anycast network
150+ locations
500+ transit/exchange ports
500+ network equipments
22000+ eBGP sessions!

11. Brief history in IDNOG3

12. Some automation/tools that we do
● Monitoring of stability of our transits globally and
takes action accordingly
● IXPs lookup in peeringdb and automatic peers
configuration
● Automated provisioning configuration
● Dynamic configuration templating and push

13. How do most of us do usually?

14. Probes configuration example

15. Salt probes configuration example

16. PoP to PoP packet loss monitoring

17. PoP to PoP packet loss monitoring

18. PoP to PoP packet loss monitoring

19. How do we usually check for peering info?

20. Salt runner to get peering information

21. Salt runner to push BGP peering configuration

22. Salt runner to check BGP peer session

23. Traditional provisioning

24. Runner to get the next available IP address

25. Traditional configuration
● Copy and paste from other production equipment
○ Prone to typo error
○ Different IP addressing
○ Different parameter
● How about global pushing of configuration?
○ 100 equipments means login to 100 equipments 1 at a time
○ Prone of issues especially if you are running anycast!
■ Need to push configuration to all at the same time

26. Jinja2 formating for provisioning template

27. Runner to generate configuration

28. Global configuration push
● salt [target_device] net.load_template [config_template]
○ Configuration template with Jinja2 format
○ Dynamic configuration loader
■ Flexible
○ Allow dry-run
○ Parallel deployment
○ Example: salt -N junos-cdn-edges net.load_template cf_testing

29. Configuration template example

30. Configuration template push example

31. Configuration template example

32. Configuration template push example

33. Conclusion

34. Automation is an integral part of
network engineering

35. Q&A