ipv4 to ipv6 network transformation
TRANSCRIPT
Contents
About me
My Phd
netTransformer
iMap
Demo
MultiVendor Network Discovery
Network Automation
iMap
About me & My Phd
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
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
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…
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
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.
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
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
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
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
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
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
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
Early prototypes
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..
Current Prototype - iTransformer
iTransformer – inputs/outputs
iTopoManager – the activation part
iDiscoverFulfills the dynamic inventory data population
iDiscover-Discover Network
Discovery Pre Conditions
Full Network connectivity
Common credentials
Initial device
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)
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)
Discovery Process
Once started Discovery output looks like that in debug
mode.
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
iTopoManagerTopology generation & preview
Templates generation & Automation
Integration with 3th party applications
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.
iTopoManager (some other perspective)
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)
Network Discovery Topology
Network Connectivity topology (L2)
blue – Ethernet trunks, red – MPLS core
Location Filtering applied
Network connectivity topology (L2)
Shortest path preview
Topology views based on GeoCoordinates
Reports - Device Neighbors & Cable Cuts
Device Neighbors Cable Cuts
Reports - IPv4/IPv6 Address Space Usage
IPv4 Address Space Usage IPv6 Address Space Usage
Reports - MPLS L3 VPN
NETWORK AUTOMATION
Basic configuration generation
Advanced configuration generation
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
Command Fulfillment RightClick Interface
Invoke Chose
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
Shortest Path Automation
INTEGRATION WITH 3TH PARTY
APPLICATIONS
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
PuttyInput parametes:
Device Management IP address, credentials, saved session id
Invoke Result
Service & Subscriber Management
DEMOiDiscover
iTopoManager
iMap
QUESTIONS ?/>IPv4toIPv6 Network transformation