In this blog I will show how to install an OpenNebula cluster from scratch, well almost, using an ISO that allows you to create a minimal configuration. The initial setup can be extended to have an almost functional production setup.

Continue reading “OpenNebula Cluster, ISO install, oh My!”

Hello There.

I did create a lab in which I was able to convert a minione server into a 3 node server, with the initial minione server acting as a controller. Eventually I will write how to do that.

This Blog instead is about the travails of configuring Open Nebula and the limitations of Sunstone the GUI. In particular trying to use VXLans and Virtual Routers.

Continue reading “OpenNebula, Virtual Routers, VXLan, Oh my!”

Hello there.

I has been a while. I needed to move my web site and blog. Got new servers in the cloud.

And of course had a few issues migrating them since they are on WordPress.

So buckle up and I will let you know.

Continue reading “Migrate WordPress, cloud servers, Oh My!”

Hello, there.

This blog is a follow up to my previous blog.

I decided to make it a bit more realistic. So I added another IOS router for redundancy and also use a route reflector for BGP.

Let’s go. Continue reading “SRV6, L3VPN, Route Reflector, Oh My!”

Hello there.

For something completely different now.

I have read about SRV6 and the benefits it brings. Never used it in production though.

Thus I decided give it a try, created a lab and configured it to use SRV6.

So let’s go. Continue reading “SRV6, L3VPN, No MPLS, Oh My!”

Hello there,

I thought I was done with PVE, then I noticed that some users had issues with VLANs, trunks, etc.

In principle it should be fairly straight forward to configure VLANs (not VXLANs) however, using the native Linux way could be a bit complicated sometimes.

OvS on the other hand was created with virtualization in mind and SDN in particular. A key point is that it supports Open Flow and allows for separation of the data plane and control plane.

Understanding and implementing it is easier said that done, so keep on reading.

Continue reading “PVE, VLANs, Trunks, Oh My!”

Hello,

This is a follow up to my previous blog regarding PVE SDN and NXOS .

Astute readers which all of you are, would have realized that in order to go across  VXLAN segments, the default gateway for each VNET is located at the PVE nodes.

This is not really a an efficient way of routing across an EVPN SDN layout. The default gateway should be local to the VTEPs in which your VNIs are located.

A way of accomplishing this, is to use the  “anycast-gateway” feature. To do this will create a SVI on the 9k, and assign it to the vrf (the L3 vrf we configured) and give it an IP address.

Looking at the configuration we have:

vlan 1,100,200,1000,2000
vlan 100
  vn-segment 31000
vlan 200
  vn-segment 41000
vlan 1000
  vn-segment 30000
vlan 2000
  vn-segment 40000

vrf context management
vrf context vrfvx_v100
  vni 30000
  rd auto
  address-family ipv4 unicast
    route-target both auto
    route-target both auto evpn
vrf context vrfvx_v200
  vni 40000
  address-family ipv4 unicast
    route-target both auto
    route-target both auto evpn

Thus we need to create a VLAN 100 and assign it to vrf vrfvx_100 and _200.

Before we do this we need to make note of the MAC addresses the PVE is giving to the VNETs we configured. This will be under the “sdn” file in the “interface.d” folder. This ensures that the gateways we create will have the same MAC addresses, so if you were to migrate a VM it will not have a conflict between ARP entries and MAC addresses on the different leaf it now resides.

In our case we will use the static method or manual MAC configuration. Another way is to use MAC aliasing.

Now we can configure both VLANS:

interface Vlan100
 no shutdown
 mac-address bc24.11e7.f432 
 vrf member vrfvx_v100
 ip address 10.100.1.1/24 
 fabric forwarding mode anycast-gateway

interface Vlan200
 no shutdown
 mac-address BC:24:11:58:A1:F9
 vrf member vrfvx_v200
 ip address 10.200.1.1/24
 fabric forwarding mode anycast-gateway

Notice that we defined the mac addresses for each VNET and then we use the any-cast gateway command.

The interfaces should be up and if the PVE allowed this you would be able to ping across VNIs. How to allow access across VNIs will be a topic for another blog.

Cheers,

Ciao.

 

Well after the series regarding integration with a Cisco 9k, I thought that we also needed something regarding Open-Source.

Well VyOS does not get any more open source than that, we will integrate a PVE cluster with a VyOS as a leaf. In addition we will use VyOS as an eBGP peer to access external clients. Read on! Continue reading “PVE SDN VyOS Integration Oh My!”

Introduction

In the final part of these series, we will integrate a Cisco 9k with a PVE cluster using the previous configurations we did setup.

Continue reading “PVE SDN NXOS Integration Oh My!”

Introduction

In part 2 we will continue with integration of a PVE cluster with a Cisco 9kv running NXOS.

Figure 1. shows the network diagram.

 We are using the 9000v as an eBGP peer for the PVE cluster. Any device that supports BGP can replace the Cisco 9k. Continue reading “PVE VXLAN NXOS Integration Continued Oh My!”