On Wed, 29 Jan 2014 11:27:05 +0900
Satoshi Kobayashi <satosh...@stratosphere.co.jp> wrote:
> Do we have any document for how to use VRRP RPC API? I want to try it.
Thanks for interest!
I'll write docs about VRRP but there is no VRRP docs for now. Here's
simple instructions (of course, after reading, writing and sending a
patch to add VRRP docs is very appreciated ;)
Ryu VRRP code supports VRRP version 2 and 3 (I don't know other VRRP
OSS supporting v3 and that's why we implemented our own to use ipv6).
The VRRP code can be used to make an OpenFlow switch speak VRRP (that
is, the code makes a switch send and recieve via packet_in/out). Also
the code can run as a VRRP daemon on Linux sending and recieving VRRP
packets via Linux devices (e.g. eth0). The latter is not related with
OpenFlow at all. Ryu is an SDN framework :)
Note that the RPC code supports only the latter for now.
I'm lazy so I run two VRRP instances on a _single_ machine but
probably you want to run VRRP on two machines.
First, I do configuration for a single machine:
$ sudo ip link add veth0 type veth peer name veth1
$ sudo ifconfig veth0 up
$ sudo ifconfig veth1 up
$ sudo ifconfig veth0 192.168.1.2 netmask 255.255.255.0
$ sudo ifconfig veth1 192.168.1.3 netmask 255.255.255.0
Now ready to run VRRP:
$ sudo ryu-manager ryu/services/protocols/vrrp/rpc_manager.py
loading app ryu/services/protocols/vrrp/rpc_manager.py
loading app ryu.services.protocols.vrrp.manager
instantiating app ryu/services/protocols/vrrp/rpc_manager.py of RpcVRRPManager
instantiating app ryu.services.protocols.vrrp.manager of VRRPManager
I manage VRRP locally via RPC but you can manage remotely:
$ rpc-cli --peers=vrrp=localhost:50004
Then rpc-cli waits for your input like:
(Cmd)
First, I check out the current config:
(Cmd) request vrrp vrrp_list []
RESULT []
As expected, no instance is configured. Let's create the first VRRP
instance on veth0:
(Cmd) request vrrp vrrp_config [{'primary_ip_address':'192.168.1.2',
'device_name': 'veth0', 'vrid':4, 'ip_addresses': ['192.168.1.1']}]
You get the following ryu-manager log:
instantiating app None of VRRPInterfaceMonitorNetworkDevice
instantiating app None of VRRPRouterV3
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.2,
None, veth0>-4-ipv4: None -> Initialize
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.2,
None, veth0>-4-ipv4: Initialize -> Backup
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.2,
None, veth0>-4-ipv4: Backup -> Master
As you can see, VRRP instance on veth0 (192.168.1.2) starts as backup
then became master because no other VRRP instance didn't respond to
VRRP packets that the first sent.
Also you see the following rpc-cli log:
NOTIFICATION from vrrp ['notify_status', [{'old_state': None, 'vrid': 4,
'new_state': 'Initialize'}]]
NOTIFICATION from vrrp ['notify_status', [{'old_state': 'Initialize', 'vrid':
4, 'new_state': 'Backup'}]]
NOTIFICATION from vrrp ['notify_status', [{'old_state': 'Backup', 'vrid': 4,
'new_state': 'Master'}]]
Everytime the state of a VRRP instance changes, you get an RPC
notification. So you could do appropriate tasks (e.g. sending GARP).
Let's check out the current config:
(Cmd) request vrrp vrrp_list []
RESULT [{'instance_name':
'VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.2, None,
veth0>-4-ipv4', 'vrid': 4, 'priority': 100, 'advertisement_interval': 1,
'version': 3, 'virtual_ip_address': '192.168.1.1'}]
Now I create the second instance on veth1:
(Cmd) request vrrp vrrp_config [{'primary_ip_address':'192.168.1.3',
'device_name': 'veth1', 'vrid':4, 'ip_addresses': ['192.168.1.1'],
'priority':200}]
Then check the ryu-manager log:
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.3,
None, veth1>-4-ipv4: None -> Initialize
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.3,
None, veth1>-4-ipv4: Initialize -> Backup
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.3,
None, veth1>-4-ipv4: Backup -> Master
handle EventVRRPStateChanged
VRID:4 VRRP-Router-VRRPInterfaceNetworkDevice<00:00:00:00:00:00, 192.168.1.2,
None, veth0>-4-ipv4: Master -> Backup
As you can see, the new instance on veth1 (192.168.1.3) was
created. The last two lines are important. The second instance (veth1)
has the higher priority (200 vs 128) so the first instance (veth0)
became backup from master and the second (veth1) became master from
backup. And of course, you got RPC notifications about them.
I don't exmplain here but the RPC API supports one more method
'vrrp_config_change' for changing the configuration of a running VRRP
instance (e.g. lowering its priority).
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
