...
The last ip address of the VPC level super-cidr will be used as the loopback id of the ospf enabled VPC-VR.
Some of the operators may want their users to have public IP assigned to their VPC-VMs. To facilitate that management server will allow both private and public class super-cidrs to be specified for the zone. There will be provision to add more super-CIDRs of private public kind at later stages.
The above super-cidr partitioning scheme is an example only. The selection of super-CIDR and subsequent partitioning of it is user driven. The admin is able to provide a super-cidr for the ospf enabled zone. The users then further partitions it by specifying netmast for their VPC and its tiers. As shown below:
There will be two default service offerings that will be created for dynamically routed VPCs one corresponding to public class ips and another corresponding to private class ips. These will be "DefaultPublicRoutedVPCNetworkOffering" and "DefaultPrivateRoutedVPCNetworkOffering" respectively. Depending on what offering a user chooses cloudstack will assign ips from the respective range to user's VPC or flag an error if no ips of that particular class exists.
These offerings A new default service offering "DefaultRoutedVPCNetworkOffering" for routed networks will be added in the management server. This will show up with other default network offerings. When a Routed VPC is created it will spin of the VPC-VR with pre-configured ranges and quagga service running on it. This will require that the system vm template have quagga installed on them.
...
Quagga will be pre-installed on the VPC-VR template and will be activated and configured if DefaultRoutedVPCNetworkOffering network Default<Private/Public>RoutedVPCNetworkOffering network offering is used. (Using cloud-early-config.sh). Quagga will advertise the VPC routing table across to other VPC routers.
[ APPENDIX - Quagga configuration]
A md5 encoded password is used for inter quagga communication.
Creating Routed VPC
In the network tab when VPC is selected then UI will show a additional button to create routed VPCs as
The user while creating a VPC can select the DefaultRoutedVPCNetworkOffering the Default<Private/Public>RoutedVPCNetworkOffering that will enforce the Super IPv4 CIDR to be in the Super IPv4 CIDR of the zone. If the user does not provide any value then the cloudstack will automatically pick a /24 CIDR as the super CIDR for this VPCprovides a netmask and the management server carves out a equivalent ip range form the zone super cidr.. An appropriate error will be given if the zone has exhausted all /24 CIDRs. [ Check netmask to cidr translation table below ]
When a VPC tier is created, the user shall configure an IPv4 CIDR and the IPv4 gateway. The tier IPv4 CIDR should be within the super IPv4 CIDR configured for its VPC. In this case it would be /27 prefix. If the user does not configure any value, Cloudstack automatically picks an unused /27 CIDR and assigns it to the VPC tier.
In general for selecting CIDRs for the VPC user will enter the netmask for his VPS and various tiers. Management server will verify the mask and will look for a available range corresponding to that mask. If a range is available MS will use that or else will flag an error.
The workflow for VPC creation will look as below:
The Routed VPC creation and configuration will be similar to the creation of a regular VPC, only that the Super CIDRs of various tiers are carved from the zone's configured Super CIDR for dynamically routed VPCs.
...
Following schema objects will be added to the MS schema:
network_details: The zone level dynamic routing parameters for public network will be saved in network details table.
network_offering: the table will be modified and a new field dynamic_routing will be added to it.
user_vm_details: for capturing priority of the OSPF router in order to facilitate selection of designated router.
zebra.conf (minimal)
hostname Quagga Router VPC-VR1 (hostname: r-6-VM)
#
interface eth0
description link to link local network
ip address 169.254.3.148/24
link detect
interface eth1
description link to public network
ip address password zebra
enable password zebra
!
! Interface's description.
!
interface eth1
description link to area 0
ip address 192.168.100.68/24
link
link-detect
interface eth2
description link to VPC tier1
ip address 200.100.100.0/27
interface eth3
description link to VPC tier 2
ip address 200.100.100.32/27
interface lo
ip address 200.100.100.255
link detect
hostname r-6-VM
router ospf
network 200.100.100.0/27 area 0
network 200.100.100.32/27 area 0
network 169.254.0.0/24 area 0
network 182.168.100.0/24 area 0
line vty
no login
enable password <password>
Static Routes:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
## Not set 200.100.100.0 0.0.0.0 255.255.255.224 U 0 0 0 eth2
## Not set 200.100.100.32 0.0.0.0 255.255.255.224 U 0 0 0 eth3
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
!
log file /var/log/quagga/zebra.log
ospf.conf (minimal)
#
hostname r-4-VM
password zebra
!enable password please-set-at-here
!
!
interface eth1
!
router ospf
ospf router-id 192.168.100.67
redistribute connected
no passive-interface eth1
network 192.168.100.0/24 area 0
network 200.200.1.0/24 area 67
network 200.200.2.0/24 area 67
!
log file /var/log/quagga/ospfd.log
---
vtysh -c "show ip ospf neighbor"
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
192.168.100.68 1 Full/DR 34.090s 192.168.100.68 eth1:192.168.100.67 0 0 0
---
Sample command output:
vtysh -c "show ip ospf route"
============ OSPF network routing table ============
N 200.200.1.0/24 [10] area: 0.0.0.67
directly attached to eth2
N 200.200.2.0/24 [10] area: 0.0.0.67
directly attached to eth3
N IA 200.200.5.0/24 [20] area: 0.0.0.0
via 192.168.100.68, eth1
N IA 200.200.6.0/24 [20] area: 0.0.0.0
via 192.168.100.68, eth1
N 200.200.100.0/24 [10] area: 0.0.0.0
directly attached to eth1
============ OSPF router routing table =============
R 192.168.100.68 [10] area: 0.0.0.0, ABR, ASBR
via 192.168.100.68, eth1
============ OSPF external routing table ===========
Netmask /CIDR translation table:
Netmask Binary CIDR Notes
255.255.255.255 11111111.11111111.11111111.11111111 /32 1 useable
255.255.255.254 11111111.11111111.11111111.11111110 /31 0 useable
255.255.255.252 11111111.11111111.11111111.11111100 /30 2 useable
255.255.255.248 11111111.11111111.11111111.11111000 /29 6 useable
255.255.255.240 11111111.11111111.11111111.11110000 /28 14 useable
255.255.255.224 11111111.11111111.11111111.11100000 /27 30 useable
255.255.255.192 11111111.11111111.11111111.11000000 /26 62 useable
255.255.255.128 11111111.11111111.11111111.10000000 /25 126 useable
255.255.255.0 11111111.11111111.11111111.00000000 /24 class C
255.255.254.0 11111111.11111111.11111110.00000000 /23
255.255.252.0 11111111.11111111.11111100.00000000 /22
255.255.248.0 11111111.11111111.11111000.00000000 /21
255.255.240.0 11111111.11111111.11110000.00000000 /20
255.255.224.0 11111111.11111111.11100000.00000000 /19
255.255.192.0 11111111.11111111.11000000.00000000 /18
255.255.128.0 11111111.11111111.10000000.00000000 /17
255.255.0.0 11111111.11111111.00000000.00000000 /16 class B
255.254.0.0 11111111.11111110.00000000.00000000 /15
255.252.0.0 11111111.11111100.00000000.00000000 /14
255.248.0.0 11111111.11111000.00000000.00000000 /13
255.240.0.0 11111111.11110000.00000000.00000000 /12
255.224.0.0 11111111.11100000.00000000.00000000 /11
255.192.0.0 11111111.11000000.00000000.00000000 /10
255.128.0.0 11111111.10000000.00000000.00000000 /9
255.0.0.0 11111111.00000000.00000000.00000000 /8 class A
254.0.0.0 11111110.00000000.00000000.00000000 /7
252.0.0.0 11111100.00000000.00000000.00000000 /6
248.0.0.0 11111000.00000000.00000000.00000000 /5
240.0.0.0 11110000.00000000.00000000.00000000 /4
224.0.0.0 11100000.00000000.00000000.00000000 /3
192.0.0.0 11000000.00000000.00000000.00000000 /2
128.0.0.0 10000000.00000000.00000000.00000000 /1
0.0.0.0 00000000.00000000.00000000.00000000 /0