The collaborative open source project focused on developing a powerful, easy to use router designed for the cloud.
@astro_sutradhar_twitter we also have a guide for virtualbox here if you have not seen it https://cloudrouter.atlassian.net/wiki/display/CPD/Getting+Started#GettingStarted-Virtualbox
hi @itomkins , hello from fellow newbie land. Couple recent blog posts that might be useful: Installation on Windows 10 (https://app.console.to/article/57dc9c32f90f290f6444bbd4) and installing Cockpit - network/system mgmt interface (https://app.console.to/article/57dc9c32f90f290f6444bbd4) - Not exactly a perfect list of the best packages and tools, but maybe some things to start chewing on!
To get started, the Cloud Router images have the CRv4 RPM installed by default. Depending on whether you're using the Fedora base or the Centos base, you can install packages via dnf or yum, respectively. For the SDN controllers, you might want to have a look at packages OpenDayLight or ONOS, or you might be interested in bird, quagga or exabgp.
@itomkins: The challenge we have right now with CloudRouter is to figure out what direction makes the most sense for software-defined network technologies. At present the base platform is fairly generic, and the CloudRouter repos in their present form would serve just fine as an alternate RPM repo that contains networking-related packages. However, until we hit upon the right direction for the base platform - be it containers or unikernels or VMs, we are opting for greater flexibility. One thing I didn't realize until we were putting together this last v4.0 release was how many good networking software packages are out there that don't integrate nicely into the major Linux distros. While this is a much more limited goal for the project, meeting this need by packaging these components actually provides a useful service to the open source community. If you have any suggestions for packages we should include or ideas about what sort of platform specializations we should be looking at, by all means please raise a JIRA ticket or bring it up as a discussion point here.
@SiegristJ Thanks for that detailed answer, it was really difficult to get a feel for what this thing really is from the info on the cloudrouter.org site which presents is as much more of an OTS router distro (comparable with something like vyos for example) that what it really is which is a platform to go build your own stuff on top of with a bunch of useful tools baked in.
btw i still haven't been able to find a list of all the packages provided in CR4 over the top of stock fedora/centos
@itomkins As John pointed out, one of the key advantages of CloudRouter is that we do pull together lots of disparate SDN-related technologies and make them easily consumable. This significantly lowers the barrier to entry for individuals wishing to play around with the latest and greatest. We wanted to do this on a solid foundation, hence the decision to ship on both Fedora and CentOS.
@itomkins We will get a list posted to the site, but if you check out the package repo, you can see the list . . . https://repo.cloudrouter.org/4/centos/7/x86_64/
@itomkins Likewise for Fedora, https://repo.cloudrouter.org/4/fedora/24/x86_64/
btw don't take my comments as overly critical, i think this is really useful stuff, just coming to it as a network engineer rather than as a developer meant that the information provided was a little impenetrable
@itomkins I am fully aware that CloudRouter currently falls into the category of "not really knowing what it wants to be when it grows up"
@itomkins That having been said, we do use a stripped-down version of CloudRouter as the software router for https://console.to
@itomkins As far as I can tell, there are 4 main streams that fall under the software defined networking banner. The first is network device configuration automation which amounts to using configuration management tools/techniques to setup routers and switches before they are plugged into the network. Second is 'virtual router' technologies, where we run software on commodity PC hardware in place of specialized network devices. Third is network function virtualization, where all the fancy proprietary network black boxes are reduced to software that is able to run on commodity (or at least standardized) hardware. Fourth is programmable traffic engineering, where a programmable 'smart' software-based network controller is able to react to present network conditions and push out routing policy to all devices in a network. Of these, CloudRouter has been most focused on SDN use case #2 - performant virtual routers, but we have a strong interest in all four of these use cases.
The problem described in this guide has been fixed. I believe the install from vmdk format now works smoothly. https://app.console.to/article/57dc9c32f90f290f6444bbd4/
regarding usage trends for CloudRouter and open source on white box SDN, Jay Turner, head of the project, is a frequent writer for SDxCentral. Might be worth a look if people are thinking of kicking the tires on CloudRouter. The obvious thing is to deploy CR as something simple like a BGP4 router and then have a flexible SDN router in place ready to be activated when some of the vision for SDN starts knocking at your door. https://www.sdxcentral.com/author/jay-turner/
Hello, I very recently picked up on cloudrouter 4.0. I am trying to get quagga/ospf to work. I found some small issues with the supplied appliances, but still struggle to have vtysh: show int to show the interfaces in up status ... I attempted to follow some recipes on the web, that were not quite cloud router focused. so I worked on selinux and switched to iptables to find a more familiar fw environment ... has anybody got quagga/zebra/ospfd working with V4 ?
my main struggle is (being a quagga newby) that I do not get the eth0 interface up and I do not see any error message to achieve that
vtysh: show int
quagga-router# show int
Interface eth0 is down
vrf: 0
pseudo interface
Interface lo0 is down
vrf: 0
pseudo interface
vtysh: show int
quagga-router# show int
Interface eth0 is down
vrf: 0
pseudo interface
Interface lo0 is down
vrf: 0
pseudo interface
(not using openvswitch nor netns)
@juliettkilotango did you find the time to look at your local cloud router V4 instance? we found that we get plenty of
2016/12/06 20:12:51 ZEBRA: FPM: scheduling connect in 5 seconds
2016/12/06 20:12:51 ZEBRA: FPM: beginning state transition connecting -> active. Reason: getsockopt() after async connect failed
that IMHO is attempting to talk to the Forwarding Plane Manager and is seemingly unable to do that .. --- well I am not sure what steps I have to do to either not require a Forwarding Plane Manager or what I have to do to get one configured and running
pointer to RTFM would be useful too
@juliettkilotango some more data points:
1) I created a 1.1.0 quagga RPM (moving forward) and have interesting new functionality, but the same issue
2) I tried kicking out anything dealing with netlink communication that sounded fancy (dpdk, openvswitch etc) -> same issue
3) I backleveled quagga to 0.99 and voila: it reports the interfaces as up
1) I created a 1.1.0 quagga RPM (moving forward) and have interesting new functionality, but the same issue
2) I tried kicking out anything dealing with netlink communication that sounded fancy (dpdk, openvswitch etc) -> same issue
3) I backleveled quagga to 0.99 and voila: it reports the interfaces as up
so one train of though is that VMWare workstation/ESXi VM e1000 device drivers offer too much/false/not enough HW acceleration and GCP (kvm/virtio_net 1.0.0 ) vms have the same issue
cloud router;s quagga version worked on bare metal as well
hi @joe_the_cloud_twitter - you can find the details here: https://cloudrouter.atlassian.net/wiki/display/CPD/Getting+Started
@juliettkilotango not sure you remember my issue qwith quagga on virtualized systems on GCP and vmware being not able to talk to netlink. As I realized that the CentOS version of quagga099 did not show the netlink issue, I have been working with that version for some time, today I took some time and narrowed the issue down to 0002-zebra-raise-the-privileges-before-calling-socket.patch .. if I remove that, I even get quagga-1.1.0 working