Presentation of the status of my PhD in 2012 done to ABLE group at Carnegie Mellon. Years later from that appeared https://github.com/iTransformers/netTransformer

1. IPV4 TO IPV6 NETWORK TRANSFORMATION
Nikolay Milovanov
nmilovanov@nbu.bg

2. Contents
 About me
 My Phd
 netTransformer
 iMap
 Demo
 MultiVendor Network Discovery
 Network Automation
 iMap

3. About me & My Phd

4. About me
 About 8 years of experience in Networking & Software
Engineering
 On different positions (Trainee, Engineer, Expert,
Consultant, Team Leader)
 In different Companies:
 ING (Bank & Pension Insurance) – Trainee & Part time network
administrator
 T-Systems/Deutsche Telecom – Internship in Product Management
 Globul(Mobile operator) – Service Engineer
 Intracom(Telecom Vendor and System Integrator) – Telecom
Expert/Team Leader
 Comptel(Software Vendor) - Network Solution Architect
 New Bulgarian University - Lecturer, Consultant, Phd. Student
 + Several project on pure consulting base

5. Goals and Use cases
 Single goal – to transform a network infrastructure from
one state to another in a controlled and (possibly)
automated way
 Major use case – to transform a medium to large
network infrastructure from IPv4 to IPv6
 Major driver – TCP/IP stack (TCP/IPv4) is the platform
that literally moved the network technology and society
in the last 20+ years. It’s not bad but has limitations. The
biggest one is the IPv4 address space.
 In order that growth to continue is needed a new
platform - IPv6

6. IPv6 considerations
Shell the network be migrated towards IPv6 or Shell we
introduce the new protocol next to the current one on top of the
infrastructure?
There are 3 major groups of transition mechanisms:
- Translation
- Tunneling
- Dual Stack
Each operator or a company has to choose its strategy towards
IPv6 – “An appropriate combination of transition
mechanisms based on current network state and future
network/business needs”.
Regardless of the chosen strategy that process could be
presented as a major network reconfiguration.
Potentially it could affect much more then the network itself…

7. The Problem
 It is difficult to apply the change when you are not sure
what to change
 It is difficult to reason about a network when you have
just a configuration guide and the network itself
 It is not easy to apply multiple changes on multiple
devices
 My proposal is that those problems could be significantly
mitigated if the the network engineers have a correct
software tools

8. Software
The question is what kind of software tools the network
engineers currently have?
 Command Line Interface tools like putty and secureCRT
 Vendor depended management platforms
 Open source network monitoring tools
 Software for bulk subscriber/service provisioning
 But nothing really something that could be used to
automate such a major network transition.

9. Functional requirements (1)
 The product shall be able to speak different network
protocols will various network devices from various
network vendors.
 The product shall be able to discover existing IPv4,
future IPv6 and mixed IPv4/IPv6 network infrastructures
 The product has to be able to model the network
complexity in an dynamic and easily extensible inventory
model
 The product has to be able to fill in automatically the
inventory model
 The inventory model has to be able to capture the
current network state in any possible moment

10. Functional requirements (2)
 Based on the information into the inventory the product shall
be able to visualize the existing network infrastructure and to
give clear indication are the devices IPv6 enabled
 The visualization has to support regular undirected and
directed graph
 The visualization possibly has to be able to display the
devices on a geographical map
 The product shall be able to reconfigure in a controled way
multiple network devices
 That process shall be able to happen in manual,
semiautomatic and if possible fully automated way
 That final result of the network transformation has to be
clearly demonstrated and easily verified

11. Business constrains
 New Bulgarian University does not have a real budget
and resources for such a project
 Have to work with volunteers. E.g convince experienced
people and students to support the project
 This is not my primary occupation

12. Technical constrains
 One server PC for the project needs
 Only a small network laboratory
 Very few libraries (does not matter open or comercial)
able to draw propperly large graphs
 Most of the network devices support their own Command
Line Interface (CLI)
 SNMP is the only reasoble choice for network discovery
and inventory model population
 Netconf is supported by Juniper and Cisco IOS-XR
devices but the exact implementations differ a lot
 No access to SOAP enabled devices or Network
Management Stations

13. Quality attributes
 Reliability (the product does not need to work 99.95% of
the time). However the product output data shall be
easily recoverabale.
 Portability (the product has to work on Unix and
Windows platofrms without any recompilation)
 Security (the product has to be executed from a secure
environment). The commercial version has to have user
auth support and to store sensitive data in encrypted
format

14. Quality Attributes
 Usability
 Network engineers are not really a developers
 The product has to be easy for configuration and extension from
people with good networking knowledge but without been
developers
 Extensibility
 Developers shall be able to add new functionalities in a
standartized and well documented way
 New functionalities shall not interfear or brake old one

15. Early prototypes
 Approach bottom up (e.g from the network up to where-ever
we reach) 
 First steps - Several network scripts written in perl and python
 able to login to the device, apply certain configuration and exit
 Typically they were solutions that were not really so easy for
customization and adoption in different network environemnts. They
were specific for specific context (eg. Business case, equipment,
environment).
 Some of those are still in use today by happy network operators.
 First Discovery - Written in python, based on pycopia,
 Described in: Milovanov, N., Bogomilov I., Slavinski A.,“4to6trans use case – dynamic
inventory data population”, MOTSP, 2011
 Used for: Milovanov, N., Bogomilov I., “Case Study - Internet Protocol version 4 to
version 6 Service Provider network migration for Internet of Things Devices_v0.9.doc” -
Unpublished

16. Early prototypes

17. Current Prototype - iTransformer
 Inventory object model is still the same
 Discovery algorithm – much more customizable and powerfull
but still pretty similar to the initial one
 People did not want to install a bunch of packets and compile
C
 Java came into the picture
 Configuration is nothing different then a text document so xslt
transformation came into an action
 Simple, yet powerfull and pretty configurable
 Still no full automation (no workflow engine)
 Split to two independed components
 iDiscover (discovery and inventory data population)
 iTopoManager (topology reasoning plus ability to apply configurable
templates)
 the “i” came form information not from interim..

18. Current Prototype - iTransformer

19. iTransformer – inputs/outputs

20. iTopoManager – the activation part

21. iDiscover
Fulfills the dynamic inventory data population

22. iDiscover-Discover Network

23. Discovery Pre Conditions
 Full Network connectivity
 Common credentials
 Initial device

24. Discovery Algorithm
 Discovery will fire up against an initial device
 Then it will discover its neighbors through a set of
discovery methods
 Then will discover their neighbors … and so on until the
whole network is revealed
 Discovery could be configured to discover or not to
discover specific devices, specific IP ranges, sites etc.
 Discovery could be executed in a network or in a node
mode (single node discovery)

25. Discovery Methods
Discovery algorithm is based on the following discovery
methods/protocols:
 Cisco Discovery Protocol (CDP)
 Local Link Discovery (LLDP)
 Address Resolution Protocol (ARP)
 Media Access Control (MAC)
 IPv4/IPv6 addressing
 IP routing/IP forwarding
 Open Shortest Path First (OSPF) neighbors
 Border Gateway Protocol (BGP)

26. Discovery Process
 Once started Discovery output looks like that in debug
mode.

27. Discovery Results
 Network Inventory information including:
 Vendor and Model
 Interfaces (Type, Speed, Status)
– Interface IPv4/v6 address
– Interface Neighbors
 VLAN table information
 Logical Device Neighbors
 Services (MPLS VRFs, MPLS L2 VPN)
 Traffic Engineering tunnels
 +Additional information available on the network device
that might be needed

28. iTopoManager
Topology generation & preview
Templates generation & Automation
Integration with 3th party applications

29. Architectute Decomposition
Modules
 TopologyViewer – MVC, topology display
 ResourceManager - communication prtocol parameters &
credentials management
 ParameterFactory – paramter multiplexing
 FulfillmentFactory – templates definition, template application
 RighClick Interface – Generic interface for node rightclicks
implementation and execution. RightClicks became the standard
interface for addition of new extensions and for integration of/with
third party systems and applications.

30. iTopoManager (some other perspective)

31. TopologyViewer
 Network Discovery topology
 Network Connectivity topology
 Data link connectivity
 IP link connectivity
 Each topology view supports filtering by a number of
criteria such as:
 Protocol (CDP,LLDP, BGP, OSPF, ISIS and many more)
 Location (site id)
 Connectivity (L2/L3)
 Status (discovered, undiscovered)
 Network geo topology
 View your network on the geographical map (for example Google
Maps)

32. Network Discovery Topology

33. Network Connectivity topology (L2)
blue – Ethernet trunks, red – MPLS core

34. Location Filtering applied
Network connectivity topology (L2)

35. Shortest path preview

36. Topology views based on GeoCoordinates

37. Reports - Device Neighbors & Cable Cuts
Device Neighbors Cable Cuts

38. Reports - IPv4/IPv6Address Space Usage
IPv4 Address Space Usage IPv6 Address Space Usage

39. Reports - MPLS L3 VPN

40. NETWORKAUTOMATION
Basic configuration generation
Advanced configuration generation

41. What is needed to automate network
configuration process?
 Knowledge about your network topology
 Knowledge about your device location
 Knowledge about your current resource availability
 Have a set of standard configuration templates
 Have an automated configuration interface
 Have the ability to apply configuration on certain network
path
 Have the ability to integrate with third party applications

42. Command Fulfillment RightClick Interface
Invoke Chose

43. Then pass parameters to it
Parameters could be
• Manual
• Location driven
• Device driven
• Resource driven
And apply a template
Crating telnet cli interface. host: 10.151.16.33, port: 23, user:
pbc, pass: Pass, timeout: 1000, prompt: null#
Open telnet connection to: 10.151.16.33:23
looking for : (login:|user:|Username:)
User Access Verification
### Found match: Username:
user
looking for : (Password:|password:)
### Found match: Password:
Pass125
looking for : .*#
### Found match: C72021#
configure terminal
looking for : .*#
configure terminal
Enter configuration commands, one per line. End with
CNTL/Z.
### Found match: C72021(config)#
looking for : .*#
### Found match: C72021(config)#
ip vrf xxx
### Found match: C72(config-vrf)#
rd 100:100
looking for : .*#
### Found match: C72(config-vrf)#
route-target both 100:100
looking for : .*#
### Found match: C72(config-vrf)#
end
looking for : .*#
### Found match: C72021#
exit

44. Shortest Path Automation

45. INTEGRATION WITH 3TH PARTY
APPLICATIONS

46. Flexibility
 iDiscover could dig out almost any parameter from your
network
 iTopoManager could pass it to your custom application
as an input parameter
 Examples for such parameters could be:
– Credentials
– IP addresses
– First free port on a device from (e.g First 1 Gig Port)
– Port descriptions
– Manual input parameters

47. Putty
Input parametes:
Device Management IP address, credentials, saved session id
Invoke Result

48. Service & Subscriber Management

49. DEMO
iDiscover
iTopoManager
iMap

50. QUESTIONS ?/>
IPv4toIPv6 Network transformation