Configure Corefig as a free managament tool for Hyper-V 2012

Configure Corefig as a free managament tool for Hyper-V 2012

Reading a lot of articles online I have found that Hyper-V 2012 has some cool new features that are free to use. Some of them are in battle with VMware, like HA and the new SMB 3.0 protocol. I have installed a nested Hyper-V 2012 under the VMware setup to test the management tools. 

One tool I have found as a useful collection of PowerShell scripts is the Corefig. Here are some steps to use with this management tool and how to configure it.

On a fresh install of the Hyper-V Hypervisor one should enable the Remote Managament under the initial powershell options. To copy the files from the downloaded Corefig site firewall should be disabled on the Hyper-V 2012. This can be done via a simple command using netsh.

The next step is to download the Corefig.zip file and copy it to the Hyper-V hypervisor. One can copy the files using the Netbios protocol, and simply typing the \\hyper-vsrv location and creating a folder under the root of the Hypervisor called Corefig.

The link for the Corefig installation can be found here.

After extracting the files , we should start the Powershell script to initialize the Corefig installation process and to make it as a startup service. This can be done via a simple command:

CD C:\COREFIG

POWERSHELL .\COREFIG.PS1

Soon after that we have an instance of the Corefig started and can use all of the managament functions it offers us. A simple screenshot will show the GUI of the tool.

We can easily change the network settings, a small Control Panel utilities, and general Hyper-V settings. One great security tool is to manage the firewall via the GUI is easy for creating the first initial rules. I have disabled the firewall for testing purposes.

Acording to Microsoft this tools is verified to work with these setups:

• Verified: Microsoft Windows Server 2012 (Core Installation)
• Verified: Microsoft Windows Server 2012 (Complete GUI Installation)
• Verified: Microsoft Hyper-V Server 2012

Feel free to use the tool and comment on it.

Virtual Routing and Forwarding

Use VRF-Lite in a SDN model networks

Nowadays we are surrounded in a simplified networking models that have abstracted approach to network management and operations. This abstracted approach is called Software Defined Networking and can simplify every network design. 

Every routing node would be useless if it did not operate in separate processes for every task we configure it to su. Virtual routing and forwarding allows multiple instances of routing table to exist on the same physical device at the same time. This allows us to create VPNs that use the same address space. It also allows us to logically separate subnets inside these virtual tables. We can try do describe the VRFs as similar to the VLAN technology under the Layer 2. Every prefix is isolated in a separate VRF. In this blog I will demonstrate the VRF-Lite feature , that most certain every router can use. Te following topology uses a two customer relationship with an ISP. Each of those customers has two sites.

Subnets on each of the customer sites are in a separate prefix , but the each of the customers is using the same RFC1918 ip address space. First we need to define the links between the customers and define the VRF tables. 

Virtual routing and forwarding can be easily created on the SP router with the IP VRF <name> command.

We will use the OSPF protocol to forward routes between the sites and the Service provider network. Now let us look at the configs of the SP routers.

SERVICE_PROVIDER

ip vrf CE_1

!

ip vrf CE_2

!

interface Loopback0

 ip address 100.100.100.1 255.255.255.255

!

interface Ethernet0/0

 description LINK_TO_CE1_1

 ip vrf forwarding CE_1             >> to turn on VRF table forwarding on the router use ip vrf

 ip address 10.0.0.1 255.255.255.252

 half-duplex

!

interface Ethernet0/1

 description LINK_TO_CE2_2

 ip vrf forwarding CE_2

 ip address 10.0.0.1 255.255.255.252

 half-duplex

!

interface Ethernet0/2

 description LINK_TO_CE1_1

 ip vrf forwarding CE_1

 ip address 10.0.1.1 255.255.255.252

 half-duplex

!

interface Ethernet0/3

 description LINK_TO_CE2_1

 ip vrf forwarding CE_2

 ip address 10.0.1.1 255.255.255.252

 half-duplex

!

router ospf 1 vrf CE_1

 log-adjacency-changes

 network 10.0.0.0 0.0.0.3 area 0

 network 10.0.1.0 0.0.0.3 area 0

!

router ospf 2 vrf CE_2

 log-adjacency-changes

 network 10.0.0.0 0.0.0.3 area 0

 network 10.0.1.0 0.0.0.3 area 0

Every link to the CE_1 and CE_2 has a command IP vrf forwarding included. This tells the SP router to settle in every advertised prefix routing protocol information from that link to a particular VRF table.

We have created two VRF tables: VRF CE_1 and CE_2. With that in mind we associate every interface to its corresponding VRF table. VRF table keeps a logically separated routing prefix information, that is not known to the global table. We can see that the global table knows only the connected routs. As for the OSPF , every process can be associated with a particular VRF so OSPF calculations are kept in a VRF tables, not interleaving with other tables. This is also a good security feature.

SERVICE_PROVIDER#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     100.0.0.0/32 is subnetted, 1 subnets

C       100.100.100.1 is directly connected, Loopback0

Now let us finish the other configs on the clients routing. I will redistribute the loopacks of the CE routers with subnets shown in the graphic topology. Every CE router will also have a OSPF protocol designed to exchange routes between the CE sites.

CE1_1

interface Loopback0

 ip address 172.16.1.1 255.255.255.0

!

interface Ethernet0/0

 ip address 10.0.0.2 255.255.255.252

 half-duplex

!

router ospf 1

 log-adjacency-changes

 redistribute connected metric 10 subnets

 network 10.0.0.0 0.0.0.3 area 0

CE2_2

interface Loopback0

 ip address 172.16.1.1 255.255.255.0

!

interface Ethernet0/0

 ip address 10.0.0.2 255.255.255.252

 half-duplex

!

router ospf 1

 log-adjacency-changes

 redistribute connected metric 10 subnets

 network 10.0.0.0 0.0.0.3 area 0

CE2_1

interface Loopback0

 ip address 192.168.1.1 255.255.255.0

!

interface Ethernet0/0

 ip address 10.0.1.2 255.255.255.252

 half-duplex

!

router ospf 1

 log-adjacency-changes

 redistribute connected metric 10 subnets

 network 10.0.1.0 0.0.0.3 area 0

CE1_2

interface Loopback0

 ip address 192.168.1.1 255.255.255.0

!

interface Ethernet0/0

 ip address 10.0.1.2 255.255.255.252

 half-duplex

!

router ospf 1

 log-adjacency-changes

 redistribute connected metric 10 subnets

 network 10.0.1.0 0.0.0.3 area 0

The client routers have now stored the OSPF routes from their sites in the routing table. So every customer has connected their sites and exchanged the routes. We can test this.

CE1_2#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets

O E2    172.16.1.0 [110/10] via 10.0.1.1, 00:14:19, Ethernet0/0

     10.0.0.0/30 is subnetted, 2 subnets

O       10.0.0.0 [110/20] via 10.0.1.1, 00:14:19, Ethernet0/0

C       10.0.1.0 is directly connected, Ethernet0/0

C    192.168.1.0/24 is directly connected, Loopback0

CE1_1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets

C       172.16.1.0 is directly connected, Loopback0

     10.0.0.0/30 is subnetted, 2 subnets

C       10.0.0.0 is directly connected, Ethernet0/0

O       10.0.1.0 [110/20] via 10.0.0.1, 00:14:51, Ethernet0/0

O E2 192.168.1.0/24 [110/10] via 10.0.0.1, 00:14:51, Ethernet0/0

Let us now ping a CE_1 site to site loopback LAN address.

CE1_1#ping 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/48 ms

We have a working data plane over the Service provider infrastructure. Our routes with same private address space are stored in seprate VRFs and they can communicate via the same physical router. 

We can still verify the VRF routing table on the SP routers.

SERVICE_PROVIDER#sh ip route vrf CE_1

Routing Table: CE_1

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets

O E2    172.16.1.0 [110/10] via 10.0.0.2, 00:17:10, Ethernet0/0

     10.0.0.0/30 is subnetted, 2 subnets

C       10.0.0.0 is directly connected, Ethernet0/0

C       10.0.1.0 is directly connected, Ethernet0/2

O E2 192.168.1.0/24 [110/10] via 10.0.1.2, 00:17:10, Ethernet0/2

This is routing Layer virtualization of routing information. It is a cool feature and heavily used under the production hood. There is much to write on this subject in complex scenarios. So more to come.

Feel free to comment.

Create and recover a snapshot under ESXi hypervisor

Restore virtual Ubuntu server using snapshots

For this short blog I am using an ESXi 4.1 hypervisor on an actual hardware and a virtualized Ubuntu server. I will try do demonstrate a quick and easy restore procedure of the VMs that the free version of the vSphere 4.1 package let's us use. The steps are followed with in an screen shot terms.

Firs let us see the inital setup of the vClient for the ESXi 4.1 free version.

From this screen we can see a couple of VMs that are running on one ESXi host. In the root of the file structure I have created a folder called TEST. After this I will create a snapshot of the virtual machine. 

After a while the process of snapshot creation is finished.

On the next step I will SSH to the Ubuntu server and delete the created TEST under the root of the file structure. This folder is important to us , so I will delete it.

Now, with the folder lost I have to revert to the previous state of the VM. This can be done via the Snapshot manager consoled under the current VM options.

And after a couple of second we can verify in the console log that the machine has been successfully restored.

Now what is left , is to check if the folder and a single file are back where they belong.

The folder TEST is reverted to its former location without any errors. This is a very cool feature vSphere technologies let's us use but it cannot be a true backup system. Snapshots are not meant to be a robust method of backup and recovery. If the files containing a virtual machine are lost, its snapshot files are also lost. 

We can look at this technology similar to the Microsoft VSS, that is used for ESXi VMs. One should always store the .VHD files on another location for a true backup system.

Feel free to comment.

Thanks.