can see that BGP is a good protocol of choice to segment your network at a logical location and start your migration process. What if you have a more complicated BGP setup, such as MP-BGP, MPLS, or VxLAN? Would Ryu or other OpenFlow-based BGP speaker be able to provide enough base code so you do not need to re-write lots of code?
We mentioned that Ryu BGP is one of OpenStack's Neutron networking BGP plugins. . At the time of writing in Spring of 2017, you can see the BGP speaker comparison of the Neutron project. The Ryu BGP speaker supports MP-BGP, IPv4 and IPv6 peering and VPN.

The proceeding picture demonstrated the BGP speaker and dynamic routing comparison. Neutron project uses JSON RPC over WebSocket to communicate with Ryu BGP speaker. Let us take a look at example. In our setup, let us place the speaker at the spine level this time, with the ToR switches being NX-OSv and IOSv devices, as shown here:

Note that even though the flat network is separated as Ryu-flat and Ryu-flat-1, they are both connected to VMnet2 on 172.16.1.0/24. The differentiation in naming is a limitation on VIRL. On the NX-OS, we will add the BGP neighbor:

nx-osv-1# sh run | section bgp
feature bgp
router bgp 1
 router-id 192.168.0.3
 address-family ipv4 unicast
 network 192.168.0.3/32
 neighbor 172.16.1.174 remote-as 1
 description iBGP peer Ryu
 address-family ipv4 unicast
 neighbor 192.168.0.1 remote-as 1
 description iBGP peer iosv-1
 update-source loopback0
 address-family ipv4 unicast

The IOSv neighbor has similar configuration with slightly different syntax:

iosv-1#sh run | section bgp
router bgp 1
 bgp router-id 192.168.0.1
 bgp log-neighbor-changes
 neighbor 172.16.1.174 remote-as 1
 neighbor 192.168.0.3 remote-as 1
 neighbor 192.168.0.3 description iBGP peer nx-osv-1
 neighbor 192.168.0.3 update-source Loopback0
 !
 address-family ipv4
 network 192.168.0.1 mask 255.255.255.255
 neighbor 172.16.1.174 activate
 neighbor 192.168.0.3 activate
 exit-address-family

For our example, we will install the websocket-client package on the SNDHub virtual machine:

$ sudo pip install websocket-client

We can re-use the same Mininet topology and router example as well; however, let's focus on the BGP speaker for this exercise. Remember, we are de-coupling the two functions.

We can use the sample code provided with the Ryu package ryu/services/protocols/bgp/api/jsonrpc.py, written by Fujita Tomonori (https://sourceforge.net/p/ryu/mailman/message/32391914/). On a separate window, launch the BGP application with the jsonrpc.py component:

$ sudo ryu-manager ryu/services/protocols/bgp/api/jsonrpc.py ryu/services/protocols/bgp/application.py

By default, the websocket-client package will install or put a link for wsdump.y under /usr/local/bin.

$ wsdump.py ws://127.0.0.1:8080/bgp/ws
Press Ctrl+C to quit

We can launch it for our speaker via the websocket call:

> {"jsonrpc": "2.0", "id": 1, "method": "core.start", "params" : {"as_number":1, "router_id":"172.16.1.174"}}

We will be able to add the two BGP neighbors, where 172.16.1.109 is the NX-OSv neighbor IP and 172.16.1.110 is the IOSv neighbor IP:

> {"jsonrpc": "2.0", "id": 1, "method": "neighbor.create", "params" : {"ip_address":"172.16.1.109", "remote_as":1}}
> {"jsonrpc": "2.0", "id": 1, "method": "neighbor.create", "params" : {"ip_address":"172.16.1.110", "remote_as":1}}

We can verify the two BGP neighbor relationship:

# NX-OSv
nx-osv-1# sh ip bgp summary 

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.174 4 1 964 1005 63 0 0 00:00:14 1 
192.168.0.1 4 1 51 85 0 0 0 00:44:13 Active 

# IOSv
iosv-1#sh ip bgp summary 

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.174 4 1 5 7 30 0 0 00:00:35 1
192.168.0.3 4 1 0 0 1 0 0 00:43:28 Idle

Cool! We have used the JSON RPC over WebSocket to configure our BGP speaker. Note that by default, the auto-configuration tries to have the two routers become BGP speakers over the loopback interface. This is normally done over OSPF as the IGP that advertises the loopback. However, in our scenario, OSPF is not enabled on our connection toward the flat network. This offers us a great opportunity to look underneath the hood of the jsonrpc.py file.