# Practical Implementation of a Blockchain-Enabled SDN for Large-Scale Infrastructure Networks
## 4 Implementation and Validation Steps
Mininet allows the simulation of an SDN network deployed by a service provider, bringing us closer to the requisite validation criteria. Mininet can also integrate and use SDN controller solutions, such as the POX controller. Having the POX controller connected to the Mininet network, a blockchain node is run via Geth on the controller. This was needed to confirm the possibility of running a blockchain node on the SDN network controller and that a node is able to join the other nodes within the deployed blockchain private network. Having the blockchain node running on the POX controller, it is possible to confirm that the node is able to join the private network and interact with the other blockchain nodes that are running on the other systems (virtual machines). Thus, it was validated with this step that it is possible to have multiple systems/autonomous systems that are able to integrate and use blockchain nodes to join and form a blockchain nodes network. Furthermore, it was validated that blockchain nodes can be integrated over SDN networks using the SDN controller, which brings us to the proposed solution. In order to implement the details mentioned in the previous section, the functionality of the POX SDN controller was expanded to support the execution of the Ethereum implementation, namely Geth. The host_tracker module of POX was enhanced with additional source code designed to start the Geth process in the underlying operating system which is running the Mininet. It is important to note here that the POX SDN controller running in the Linux OS is actually starting an executable that is available to any other process in the operating system, POX being responsible only for the lifetime of this process and not for the implementation details of this process that was being run. Thus, the operating system is responsible for ensuring the blockchain communication between the Geth nodes running on different computers. Since this experiment was run on different computers located at different locations in the WAN behind different routers, the port forwarding option needed to be configured on the routers to allow connection redirection to the respective POX instances. The POX instances are bound to a specific IP address and a specific port number. The IP address is configured statically on the Linux OS, and the port number is manually chosen during the implementation and testing phases. Given that each blockchain node will use designated ports during operation and utilize both TCP and UDP protocols for communication, it may be imperative to configure permissive rules on the operating system's firewall to facilitate external communication with other nodes. The blockchain nodes need to be created locally before being used (have their folder where information like address and access password is kept). The configuration file (genesis.json) pertinent to the blockchain network, within which the nodes are operational, must be made available to these nodes. The nodes' hexadecimal addresses need to be added to the configuration file along with their balance. The bootnodes should also be specified. As a note, the balance of a node should be high enough in order to be able to generate transactions. If this condition is not met, the behavior may be unexpected and the provided information unclear and misleading. The following set of instructions comprises the main operations essential for the initiation of Mininet, POX, and Geth instances (these procedures represent a subset rather than the exhaustive compilation of commands, encompassing only the most relevant commands):  
1. Start POX
2. Start Mininet
3. Setup Geth:  
* The establishment of a Geth blockchain node can be achieved through the following procedure:  
```
>_geth init -datadir node1 genesis.json_, where node1 is the specified node, and genesis.json is the configuration file.