* Find a the enum type by its integer value, as defined in the Thrift IDL.
* @return null if the value is not found.
*/
- public static peer_status_type findByValue(int value) {
+ public static peer_status_type findByValue(int value) {
switch (value) {
case 0:
return PEER_UP;
//
// the label argument in pushRoute can use these consts
const i32 LBL_NO_LABEL = 0
-
+
/*
* mpls explicit null isn't 3, but this is not meant
* to be put in a packet but is used only between odl
* 'LBL_NO_LABEL'. besides, if this should accdientally
* leak into a packet header, it will at least be an
* implicit null
- */
+ */
const i32 LBL_EXPLICIT_NULL = 3
-
+
// FIB entry type
const i32 BGP_RT_ADD = 0
const i32 BGP_RT_DEL = 1
-
+
// FIB table iteration op
const i32 GET_RTS_INIT = 0
const i32 GET_RTS_NEXT = 1
-
+
/*
- * error codes.
+ * error codes.
* 0 is success.
* ERR_FAILED because something bad happens deeper
- * inside BGP, such as deleting a route that
+ * inside BGP, such as deleting a route that
* doesn't exist.
- * ERR_PARAM when params don't validate
- * ERR_ACTIVE when routing instance is already
+ * ERR_PARAM when params don't validate
+ * ERR_ACTIVE when routing instance is already
* running but ODL calls startBgp() anyway
- * ERR_INACTIVE when an RPC is invkoed but there
+ * ERR_INACTIVE when an RPC is invkoed but there
* is no session.
- * ERR_NOT_ITER when GET_RTS_NEXT is called without
- * initializing with GET_RTS_INIT
+ * ERR_NOT_ITER when GET_RTS_NEXT is called without
+ * initializing with GET_RTS_INIT
*/
-
- const i32 BGP_ERR_FAILED = 1
+
+ const i32 BGP_ERR_FAILED = 1
const i32 BGP_ERR_ACTIVE = 10
const i32 BGP_ERR_INACTIVE = 11
const i32 BGP_ERR_NOT_ITER = 15
const i32 BGP_ERR_PEER_EXISTS = 19
const i32 BGP_ERR_PARAM = 100
const i32 BGP_ERR_NOT_SUPPORTED = 200
-
+
const i32 BGP_ETHTAG_MAX_ET = 0xfffffff
- // supported afi-safi combinations
+ // supported afi-safi combinations
enum af_afi {
AFI_IP = 1,
AFI_IPV6 = 2,
AFI_L2VPN = 3
}
-
+
enum af_safi {
SAFI_IP_LABELED_UNICAST = 4,
SAFI_MPLS_VPN = 5,
SAFI_EVPN = 6
}
-
+
// supported encapsulation types - RFC 5512
enum encap_type {
L2TPV3_OVER_IP = 1,
}
// layer type
- // used to mention to which layer a VRF belongs to.
+ // used to mention to which layer a VRF belongs to.
enum layer_type {
LAYER_2 = 1,
LAYER_3 = 2
11: string nexthop,
12: string routermac,
}
-
+
/*
* a sequence of FIB updates, valid only if errcode
- * is zero. returned by getRoutes(). more=0 means end
+ * is zero. returned by getRoutes(). more=0 means end
* of iteration.
*/
-
+
struct Routes {
1: i32 errcode, // one of the BGP_ERR's
2: optional list<Update> updates,
service BgpConfigurator {
/*
- * startBgp() starts a bgp instance on the bgp VM. Graceful
- * Restart also must be configured (stalepathTime > 0). if
+ * startBgp() starts a bgp instance on the bgp VM. Graceful
+ * Restart also must be configured (stalepathTime > 0). if
* local dataplane remains undisturbed relative to previous
- * invocation, announceFbit tells neighbors to retain all
- * routes advertised by us in our last incarnation. this is
- * the F bit of RFC 4724.
+ * invocation, announceFbit tells neighbors to retain all
+ * routes advertised by us in our last incarnation. this is
+ * the F bit of RFC 4724.
*/
- i32 startBgp(1:i64 asNumber, 2:string routerId, 3: i32 port,
- 4:i32 holdTime, 5:i32 keepAliveTime,
+ i32 startBgp(1:i64 asNumber, 2:string routerId, 3: i32 port,
+ 4:i32 holdTime, 5:i32 keepAliveTime,
6:i32 stalepathTime, 7:bool announceFbit),
i32 stopBgp(1:i64 asNumber),
i32 createPeer(1:string ipAddress, 2:i64 asNumber),
* IPv6 is not supported.
* 'p_type' is mandatory
* 'nexthop' cannot be null for VPNv4 and LU.
- * 'rd' is null for LU (and unicast).
+ * 'rd' is null for LU (and unicast).
* 'label' cannot be NO_LABEL for VPNv4 MPLS and LU.
* 'ethtag stands 32 bit value. only 24 bit value is used for now (VID of vxlan).
* 'esi' is a 10 byte hexadecimal string. 1st byte defines the type. Only '00' is supported for now.
11:string routermac, 12:af_afi afi),
/*
* 'p_type' is mandatory
- * kludge: second argument is either 'rd' (VPNv4) or
+ * kludge: second argument is either 'rd' (VPNv4) or
* label (v4LU) as a string (eg: "2500")
* af_afi: indicates whether prefix is IPv4 or IPv6
*/
* if PROTOCOL_LU chosen ( no VRF RIBs implemented), global RIB will be dumped)
* optype is one of: GET_RTS_INIT: start the iteration,
* GET_RTS_NEXT: get next bunch of routes. winSize is
- * the size of the buffer that caller has allocated to
+ * the size of the buffer that caller has allocated to
* receive the array of routes. qbgp sends no more than
- * the number of routes that would fit in this buffer,
+ * the number of routes that would fit in this buffer,
* but not necessarily the maximum number that would fit
* (we currently use min(winSize, tcpWindowSize) ).
* calling INIT when NEXT is expected causes reinit.
i32 disableBFDFailover(),
peer_status_type getPeerStatus(1:string ipAddress, 2:i64 asNumber),
}
-
+
service BgpUpdater {
// 'p_type' is mandatory. indicates the origin of data
- oneway void onUpdatePushRoute(1:protocol_type p_type, 2:string rd, 3:string prefix,
- 4:i32 prefixlen, 5:string nexthop,
+ oneway void onUpdatePushRoute(1:protocol_type p_type, 2:string rd, 3:string prefix,
+ 4:i32 prefixlen, 5:string nexthop,
6:i64 ethtag, 7:string esi, 8:string macaddress,
9:i32 l3label, 10:i32 l2label,
11:string routermac, 12:af_afi afi),
- oneway void onUpdateWithdrawRoute(1:protocol_type p_type, 2:string rd, 3:string prefix,
+ oneway void onUpdateWithdrawRoute(1:protocol_type p_type, 2:string rd, 3:string prefix,
4:i32 prefixlen, 5:string nexthop,
6:i64 ethtag, 7:string esi, 8:string macaddress,
9:i32 l3label, 10:i32 l2label, 11:af_afi afi),
// tell them we're open for business
oneway void onStartConfigResyncNotification(),
- // relay to odl a bgp Notification we got from peer
- oneway void onNotificationSendEvent(1:string prefix,
+ // relay to odl a bgp Notification we got from peer
+ oneway void onNotificationSendEvent(1:string prefix,
2:byte errCode, 3:byte errSubcode),
oneway void peerDown(1:string ipAddress, 2:i64 asNumber),
oneway void peerUp(1:string ipAddress, 2:i64 asNumber)
-}
+}
interested listeners of the particular multicast group address.
The main benefit of IGMP Snooping is to eliminate the flooding of packets by listening to IGMP messages between
-hosts and multicast routers, and build a database that will be used to forward multicast packets selectively
+hosts and multicast routers, and build a database that will be used to forward multicast packets selectively
to interested hosts and multicast routers.
This feature will implement IGMPv3 Snooping, as defined in RFC 4541.
Highlights of RFC 4541 that will be addressed by this feature:
-- A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.
+- A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.
- The switch supporting IGMP snooping must maintain a list of multicast routers and the ports on which they are attached.
- Packets with a destination IP address outside 224.0.0.X which are not IGMP should be forwarded according to group-based port membership tables and must also be forwarded on router ports.
- Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports.
This feature will not IPv6 MLD Snooping.
-A global flag will be supported to enable/disable IGMP Snooping. Initially, this value will be read with ODL starts.
+A global flag will be supported to enable/disable IGMP Snooping. Initially, this value will be read with ODL starts.
Support for dynamic changes of this flag may not be initially supported.
IGMP Packet Processing and Forwarding
=====================================
We need to keep track of where the multicast listeners and multicast routers are located.
-The switch learns about interfaces by monitoring IGMP traffic. If an interface receives IGMP queries, this will indicate that a
-multicast router is attached to that interface, and the port will be added to the multicast forwarding table as a multicast-router
+The switch learns about interfaces by monitoring IGMP traffic. If an interface receives IGMP queries, this will indicate that a
+multicast router is attached to that interface, and the port will be added to the multicast forwarding table as a multicast-router
interface (querier).
If an interface receives membership reports or igmp join for a multicast group, this will indicate that a multicast listener (host)
-is attached to that interface, and the port will be added to the multicast forwarding table as a group-member interface.
+is attached to that interface, and the port will be added to the multicast forwarding table as a group-member interface.
If an interface receives igmp leave for a multicast group, remove the port from the multicast forwarding table as a group-member interface.
Multicast traffic that is not IGMP:
-An unregistered packet is defined as an IPv4 multicast packet with a destination address which does not match
-any of the groups announced in earlier IGMP Membership Reports. A registered packet is defined as an IPv4 multicast
-packet with a destination address which matches one of the groups announced in earlier IGMP Membership Reports.
+An unregistered packet is defined as an IPv4 multicast packet with a destination address which does not match
+any of the groups announced in earlier IGMP Membership Reports. A registered packet is defined as an IPv4 multicast
+packet with a destination address which matches one of the groups announced in earlier IGMP Membership Reports.
- destination address of 224.0.0.0/24 is flooded to all ports in domain
As you can see above, when port security is disabled, multicast packets are flooded. When port security
is enabled, multicast packets are dropped by ACL rules.
-This IGMP Snooping feature, when enabled, will learn about multicast hosts and multicast routers from the IGMP
+This IGMP Snooping feature, when enabled, will learn about multicast hosts and multicast routers from the IGMP
conversation. These learned entries will be used to build a multicast forwarding database to forward IPv4
multicast packets as described in the Multicast Forwarding Rules section above.
of the compute nodes is connected to L2GW. This will ensure
IGMP Snooping works across external tunnels.
-UC6
+UC6
Multicast router on physical network (querier)
Proposed change
===============
-IGMP Snooping feature will send IGMP Packets to the ODL Controller. The IGMP messages will be parsed, and a multicast database will be built, consisting of multicast goup member ports and multicast router ports. This database will be used to populate Multicast Broadcast Groups, that will
+IGMP Snooping feature will send IGMP Packets to the ODL Controller. The IGMP messages will be parsed, and a multicast database will be built, consisting of multicast goup member ports and multicast router ports. This database will be used to populate Multicast Broadcast Groups, that will
then be used to forward IPv4 multicast packets per the Multicast Forwarding Rules section above.
New Multicast Broadcast Groups (BC)
===================================
-There will be a total of 3 broadcast groups/network needed for IGMP Snooping. These broadcast groups will be very similar to existing
-L2 BC groups. There would be a Local BC group per network (local ports only - packet ingress on tunnel port) and a Full BC group per
+There will be a total of 3 broadcast groups/network needed for IGMP Snooping. These broadcast groups will be very similar to existing
+L2 BC groups. There would be a Local BC group per network (local ports only - packet ingress on tunnel port) and a Full BC group per
network (local ports and tunnel ports - packet ingress on vm port).
- Multicast Router L/F - This group has the multicast router ports for the network.
- sudo ovs-ofctl add-flow -OOpenflow13 br-int table=43,priority=100,dl_type=0x0800,nw_proto=0x02,actions=goto_table:61
- sudo ovs-ofctl add-flow -OOpenflow13 br-int "table=43,priority=90,dl_type=0x0800,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00,actions=goto_table:61"
-NOTE: The 2 rules above would also have to be added to Internal Tunnel Table (36) and External Tunnel Table (38).
+NOTE: The 2 rules above would also have to be added to Internal Tunnel Table (36) and External Tunnel Table (38).
Flows to get Multicast packets to Multicast Table(61) from Internal Tunnel Table (36)
-------------------------------------------------------------------------------------
cookie=0x6900000, duration=82.942s, table=240, n_packets=8, n_bytes=432, priority=61010,ip,reg6=0xa00/0xfffff00,dl_dst=01:00:5e:00:00:16,nw_dst=224.0.0.22 actions=goto_table:241
-ODL Security groups do not currently support IGMP. As such, some small code changes are required to support IGMP. For example, in
+ODL Security groups do not currently support IGMP. As such, some small code changes are required to support IGMP. For example, in
ODL Oxygen, if you issue the command:
- openstack security group rule create goPacketGo --ingress --ethertype IPv4 --protocol igmp
Pipeline changes
================
-Add rules to ARP Table (43) to send IPv4 multicast packets to new IPv4 Multicast Table(61). Currently, ARP Table (43) sends packets to L2 Pipeline (48) if not ARP. We do not want IPv4 multicast packets to be processed in L2 Pipeline (and flooded to all ports in the network).
+Add rules to ARP Table (43) to send IPv4 multicast packets to new IPv4 Multicast Table(61). Currently, ARP Table (43) sends packets to L2 Pipeline (48) if not ARP. We do not want IPv4 multicast packets to be processed in L2 Pipeline (and flooded to all ports in the network).
In table 43:
:depth: 5
============================
-Enhance Robustness of L3VPN
+Enhance Robustness of L3VPN
============================
https://git.opendaylight.org/gerrit/#/q/topic:l3vpn-robustness
===================
Witnessing issues faced in L3VPN with production
-deployments of OpenDaylight, it was gradually occurring
+deployments of OpenDaylight, it was gradually occurring
that piecemeal fixing issues in L3VPN (and all its
related modules) unfortunately wouldn't scale.
UC 3: An Extra-route serviced by one or more VMs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-This use-case is to ensure ECMP handling robustness within L3VPN Engine.
+This use-case is to ensure ECMP handling robustness within L3VPN Engine.
This mimics an ipv4 address being reachable from multiple nexthops (or multiple vpninterfaces).
Has the following sub-cases:
UC 3.1 - Append a nexthop to an existing IPv4 extra-route
VRFEntry handling by the VPNEngine. The VRFEntry would become an artifact instead of a trigger source.
This type of design also enables use of DJC to enforce IP Serialization within a given VPNInstance.
This change additionally provides elimination of backpulls from the FIBEngine towards VPNEngine and other
- modules for non-BGP-imported-rows
+ modules for non-BGP-imported-rows
5. Other than imported BGP routes, all other types of route processing (VM ports, exported VM ports, extra-routes, MIPs), will
be done in the way quoted in point 4 above. The BGP imported routes from other neighbours will continue to be
driven from within the VRFEntryListener.
6. Re-use as much existing handlers within the engines of L3VPN Service in order to contain the robustness effort
-
+
7. All the VPN Datastores will continued to be made available the same way for other external interfaces and consumers of
external interfaces to remain unaffected. Most specifically implementing this area will not effect NATEngine,
InterVPNLinksEngine and BGPEngine.
As the current L3VPN service stands end-of-Oxygen release,
it is able to realize a VPN orchestrated by Neutron BGPVPN API.
-However, this orchestration is subjected heavily to timing
+However, this orchestration is subjected heavily to timing
and nature of how the orchestration was performed.
-To explain, piecemeal creating a Neutron BGPVPN using
+To explain, piecemeal creating a Neutron BGPVPN using
Openstack BGPVPN REST API (or) CLI and making
sure it is realized and then deleting the same Neutron BGPVPN
(via RESTAPI or CLI) would succeed.
-However, when the orchestration pattern on Openstack BGPVPN
+However, when the orchestration pattern on Openstack BGPVPN
API is turned to be driven through an automation script (or)
if the script uses Heat templates to automate and manage BGPVPNs,
the runs will expose failure to properly realize such orchestrated
VPNs in the OpenDaylight control plane (and thence data plane too).
-The failures themselves will go unnoticed to the Openstack
+The failures themselves will go unnoticed to the Openstack
Orchestrator (or user) since the Openstack Neutron will
provide a consistent view of available (or active) VPNs
while the VPNs being realized in OpenDaylight would be
Out of scope
------------
-a. Network-associated EVPNs
+a. Network-associated EVPNs
b. Router-associated EVPNs
Use Case Summary
----------------
This deals with making BGPVPN workflows inside ODL more robust when used with Neutron
-BGPVPN APIs. To add, when such Neutron BGPVPN APIs are applied through HOT templates,
+BGPVPN APIs. To add, when such Neutron BGPVPN APIs are applied through HOT templates,
the VPNs have to be realized consistently in both the control-plane datastores and
data-plane flows/routes.
RIB - Routing Information Base - Represents the routes held inside the ODL controller Quagga BGP.
-FIB - Forwarding Information Base - Represents the routes held inside ODL controller.
+FIB - Forwarding Information Base - Represents the routes held inside ODL controller.
For all the router-driven BGPVPNs below, please assume that two subnets (one IPv4 and one IPv6) are
associated to the router.
For the template types and their contents, please see CSIT section.
-UC 1: A net-driven BGPVPN creation with Network association
+UC 1: A net-driven BGPVPN creation with Network association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
template 1 - Create a VPN1 with RD1
Also make sure all of the VM IPs (and their secondaries) must be realized into VPN1.
Delete stack with template 1, make sure VPN1 disappears from the ODL controller.
-UC 2: A net-driven BGPVPN cycled through multiple Networks association
+UC 2: A net-driven BGPVPN cycled through multiple Networks association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1
template 3 - Create Network2, Create Subnet2, Boot VMs on the Network2, Associate Network2 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
template 3 - Create Network2, Create Subnet2, Boot VMs on the Network2, Associate Network2 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
template 2 - Create Network1, Create Subnet1, Boot VMs on the Network1, Associate Network1 into VPN1
template 3 - Create Network2, Create Subnet2 (same CIDR as Subnet1), Boot VMs on the Network2, Associate Network2 into VPN1
-template 1 type - TYPE B
-template 2 type - TYPE C
-template 3 type - TYPE C
+template 1 type - TYPE B
+template 2 type - TYPE C
+template 3 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
must be realized into VPN1.
-Delete stack with template 2
+Delete stack with template 2
All of the VM IPs (and their secondaries) on Network1 must be removed from VPN1.
Create stack with template 3
UC 2.5: Two net-driven BGPVPNs cycled through with same RouteDistinguisher and same Network
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create Network1, Create Subnet1, Boot VMs on the Network1
-template 2 - Create a VPN1 with RD1 and associate Network1 to VPN1
+template 2 - Create a VPN1 with RD1 and associate Network1 to VPN1
template 3 - Create a VPN2 with RD1 and associate Network1 to VPN2
-template 1 type - TYPE D
-template 2 type - TYPE E
-template 3 type - TYPE E
+template 1 type - TYPE D
+template 2 type - TYPE E
+template 3 type - TYPE E
Create stack with template 1, make sure all the VMs appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
Delete stack with template 3, make sure that Network1 must be removed from VPN2.
Delete stack with template 1, make sure all the VMs disappear from the ODL controller.
-UC 2.6: A net-driven BGPVPN ordering VPN deletion before network deletion
+UC 2.6: A net-driven BGPVPN ordering VPN deletion before network deletion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create a VPN1 with RD1
template 2 - Create Network1, Create Subnet1, Boot VMs on the Network1, Associate Network1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE C
+template 2 type - TYPE C
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
All of the VM IPs (and their secondaries) on Network1 must be removed from VPN1.
Make sure ELAN traffic continues to work.
-Delete stack with template 2
+Delete stack with template 2
Make sure all the VMs, Networks disappear from the ODL controller.
UC 2.7: A net-driven BGPVPN ordering network deletion before VPN deletion without disassociating the network
template 3 - Associate Network1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE D
-template 3 type - TYPE F
+template 2 type - TYPE D
+template 3 type - TYPE F
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Create stack with template 3, and ensure all of the VM IPs (and their secondaries)
on Router1 must be realized into VPN1.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
Delete stack with template 3, the stack deletion must fail and this is normal.
-UC 2.8: A router-driven BGPVPN creation with SingleStack Router association
+UC 2.8: A router-driven BGPVPN creation with SingleStack Router association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
-template 1 - Create a VPN1 with RD1. Create Network1, Create Subnet1, Boot VMs on the Network1,
+template 1 - Create a VPN1 with RD1. Create Network1, Create Subnet1, Boot VMs on the Network1,
Create Router1, Add Subnet1 to Router1 and Associate Router1 into VPN1
template 1 type - TYPE M
Delete stack with template 1, make sure VPN1 disappears from the ODL controller along with
removal of VM IPs from the VPN1.
-UC 2.9: A router-driven BGPVPN creation with DualStack Router association
+UC 2.9: A router-driven BGPVPN creation with DualStack Router association
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (single HOT template)
template 1 - Create a VPN1 with RD1. Create Network1, Create IPv4 Subnet11, Create IPv6 Subnet12
Also make sure all of the VM IPv4 and IPv6s (and their secondaries) on the Router1 must be realized into VPN1.
Delete stack with template 1, make sure VPN1 disappears from the ODL controller.
-UC 2.10: A router-driven BGPVPN cycled through with association and disassociation
+UC 2.10: A router-driven BGPVPN cycled through with association and disassociation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1
template 3 - Associate Router1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
Delete stack with template 2, Router1 must disappear from the ODL controller.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
-UC 2.10 variation 2 - A router-driven BGPVPN cycled through with association and disassociation
+UC 2.10 variation 2 - A router-driven BGPVPN cycled through with association and disassociation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The steps for this use-case (multiple HOT templates)
template 1 - Create a VPN1 with RD1.
template 3 - Associate Router1 into VPN1
template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
template 2 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1, Associate Router1 into VPN1
-template 1 type - TYPE B
+template 1 type - TYPE B
template 2 type - TYPE P
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Delete stack with template 2, make sure that Router2 must be removed from VPN1.
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1
template 3 - Associate Router1 into VPN1
-template 1 type - TYPE B
-template 2 type - TYPE O
-template 3 type - TYPE Q
+template 1 type - TYPE B
+template 2 type - TYPE O
+template 3 type - TYPE Q
Create stack with template 1, make sure VPN1 appears in the ODL controller.
-Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, ensure all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Create stack with template 3, and ensure all of the VM IPs (and their secondaries)
on Router1 must be realized into VPN1.
Delete stack with template 1, VPN1 must disappear from the ODL controller.
Delete stack with template 3, the stack deletion must fail and this is normal.
-UC 2.12: A router-driven BGPVPN ordering VPN deletion before router deletion
+UC 2.12: A router-driven BGPVPN ordering VPN deletion before router deletion
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create a VPN1 with RD1
template 2 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1, Associate Router1 to VPN1
template 1 type - TYPE B
-template 2 type - TYPE P
+template 2 type - TYPE P
Create stack with template 1, make sure VPN1 appears in the ODL controller.
Create stack with template 2, all of the VM IPs (and their secondaries) on Network1
All of the VM IPs (and their secondaries) on Router1 must be removed from VPN1.
Make sure ELAN traffic and Router1 traffic continues to work.
-Delete stack with template 2
+Delete stack with template 2
Make sure all the VMs, Routers disappear from the ODL controller.
-UC 2.13: Two router-driven BGPVPNs cycled through with same RouteDistinguisher and same Router
+UC 2.13: Two router-driven BGPVPNs cycled through with same RouteDistinguisher and same Router
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
template 1 - Create Network1, Create IPv4 Subnet1, Create IPv6 Subnet2, Boot VMs on the Network1
Create Router1, Add Subnet1 to Router1, Add Subnet2 to Router1
template 2 - Create a VPN1 with RD1 and Associate Router1 into VPN1
template 3 - Create a VPN2 with RD1 and Associate Router1 into VPN2
-template 1 type - TYPE O
-template 2 type - TYPE R
-template 3 type - TYPE R
+template 1 type - TYPE O
+template 2 type - TYPE R
+template 3 type - TYPE R
Create stack with template 1, make sure all the VMs appears in the ODL controller.
-Create stack with template 2, all of the VM IPs (and their secondaries) on Router1
+Create stack with template 2, all of the VM IPs (and their secondaries) on Router1
must be realized into VPN1.
Delete stack with template 2.
b. VPN Engine (VpnInstanceListener and VpnInterfaceManager)
c. BGP Engine (BGPManager)
d. VRF Engine (FIBManager)
-e. NAT Engine (NATService)
+e. NAT Engine (NATService)
f. EVPN Engine (EVPN in ELANManager)
All of the above engines enhancement is to enable safe parallel processing of multiple vpn-instances
---------------
VPN Engine:
^^^^^^^^^^^
-Currently Oper/VpnInstanceOpData is keyed by vrf-id (aka Route Distinguisher) and this kind
+Currently Oper/VpnInstanceOpData is keyed by vrf-id (aka Route Distinguisher) and this kind
of keying was all OK as we serviced only one VPNInstance at a time that would carry this vrf-id.
As we move to public cloud, the customers will start to use the neutron bgpvpn api
This specific VpnInstanceOpData datastore is referred by many services within ODL and so such services
must be updated on their consumption/production of information into this datastore.
-One more new model that maps a given RD (route-distinguisher) to an Active VpnInstance will be
+One more new model that maps a given RD (route-distinguisher) to an Active VpnInstance will be
required for use by the BGPEngine.
VRF Engine:
^^^^^^^^^^^
The VRFEngine does not use vpn-instance-uuid at all and uses only vrfTables as the
primary datastore for representing the FIB. This vrfTables has vrf-id (route-distinguisher)
-as the key, to maintain the FIB.
+as the key, to maintain the FIB.
This engine will be enhanced such that vrfTables become a child to a vpn-instance-uuid keyed
container thereby enabling multiple vpninstances to be managed regardless of whether such vpn-instances
^^^^^^^^^^^
The BGP Engine within ODL is primarily responsible for:
a. Pushing a route from its external neighbor into ODL
-b. Removing a route from its external neighbor from ODL
+b. Removing a route from its external neighbor from ODL
c. Advertising an ODL managed route to its external neighbor
d. Withdrawing an ODL managed route to its external neighbor
Since there can be more than one VpnInstance that can use a given route-distinguisher at a time within
Opendaylight (a situation where previous vpn-instance is being deleted while a new vpn-instance with same
RD being created), BGP Engine needs to know which of the vpn-instances out of the
-these to choose to import a route when it comes from an external neighbor (case a).
+these to choose to import a route when it comes from an external neighbor (case a).
-This is because, BGP Engine (and Quagga which has real BGP logic) within ODL operates only with
+This is because, BGP Engine (and Quagga which has real BGP logic) within ODL operates only with
route-distinguishers and not with vpn-instances. This is the same case with the other
-BGP neighbors too that talk to ODL BGP Engine.
+BGP neighbors too that talk to ODL BGP Engine.
As a result the BGP Engine will continue to work only with route-distinguishers but it will make a call
to the VpnEngine to figure out to which all vpn-instances an incoming route must be written to (case a).
^^^^^^^^^^^^^^^^^^
There are race conditions within the NeutronVPN that gets triggered when HOT templates are executed primarily in the
Neutron BGPVPN management path. These race conditions are around the Neutron Router, Neutron BGPVPN, Neutron Subnet
-and Neutron Network resources access and their management within NeutronVPN. So this engine will be enhanced to
+and Neutron Network resources access and their management within NeutronVPN. So this engine will be enhanced to
close out these race-conditions.
Pipeline changes
Yang changes
------------
-Changes will be needed in ``fib-rpc.yang`` , ``odl-fib.yang``
+Changes will be needed in ``fib-rpc.yang`` , ``odl-fib.yang``
to address this feature.
Changes will be needed in ``odl-l3vpn.yang`` and ``odl-fib.yang``
Usage
=====
-The feature can be excited by Openstack Neutron BGPVPN REST APIs (or) by
+The feature can be excited by Openstack Neutron BGPVPN REST APIs (or) by
Openstack Neutron BGPVPN CLIs.
As part of this spec implementation, we will actually be exciting Neutron BGPVPN
TYPE A
^^^^^^^
.. code-block:: none
- :caption: TYPE A
+ :caption: TYPE A
description: BGPVPN networking example TYPE A (admin)
heat_template_version: '2013-05-23'
TYPE C
^^^^^^^
.. code-block:: none
- :caption: TYPE C
+ :caption: TYPE C
description: BGPVPN networking example TYPE C (admin)
heat_template_version: '2013-05-23'
TYPE D
^^^^^^^
.. code-block:: none
- :caption: TYPE D
+ :caption: TYPE D
description: BGPVPN networking example TYPE D (admin)
heat_template_version: '2013-05-23'
type: OS::Neutron::BGPVPN-NET-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- network_id: "default Net1"
+ network_id: "default Net1"
TYPE F
^^^^^^^
type: OS::Neutron::BGPVPN-NET-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- network_id: "default Net1"
+ network_id: "default Net1"
TYPE M
^^^^^^^
bgpvpn_id: { get_resource: BGPVPN1 }
router_id: { get_resource: Router }
-TYPE N
+TYPE N
^^^^^^^
.. code-block:: none
:caption: TYPE M
properties:
network: { get_resource: Net2 }
cidr: 30.1.1.0/24
-
+
SubNet22:
type: OS::Neutron::Subnet
properties:
TYPE O
^^^^^^^
.. code-block:: none
- :caption: TYPE 0
+ :caption: TYPE 0
description: BGPVPN networking example (admin)
type: OS::Neutron::BGPVPN-ROUTER-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- router_id: "default Router"
+ router_id: "default Router"
TYPE R
^^^^^^^
.. code-block:: none
- :caption: TYPE R
+ :caption: TYPE R
description: BGPVPN networking example TYPE P (tenant)
heat_template_version: '2013-05-23'
type: OS::Neutron::BGPVPN-ROUTER-ASSOCIATION
properties:
bgpvpn_id: "default VPN"
- router_id: "default Router"
+ router_id: "default Router"
Documentation Impact
leaf detect-mult {
type uint32;
default 3;
- description "The number of packets that have to be missed
+ description "The number of packets that have to be missed
in a row to declare the session to be down.";
}
leaf min-rx {
::
- config 1:
- +----+
+ config 1:
+ +----+
| VM | +-------------+ +-----------+
+----+-----| Subnet A(v6)|--|router-id-1|
+-------------+ | Router 1 |-----+--------------------+
+-------------+ |Router 4(IPv4)|-+ +------------------+
|router-id-3 |
+--------------+
-
+
Discussion of the various setups solutions
******************************************
| Dispatcher table (17) ``l2vpn service: set elan-tag=vxlan-net-tag`` =>
| ELAN base table (48) =>
| ELAN SMAC table (50) ``match: elan-tag=vxlan-net-tag,src-mac=vm1-mac`` =>
- | ELAN DMAC table (51) ``match: elan-tag=vxlan-net-tag,dst-mac=external-vm-mac set tun-id=vxlan-net-tag group=next-hop-group``
+ | ELAN DMAC table (51) ``match: elan-tag=vxlan-net-tag,dst-mac=external-vm-mac set tun-id=vxlan-net-tag group=next-hop-group``
| Next Hop Group ``bucket0 :set reg6=tunnel-lport-tag bucket1 :set reg6=tunnel2-lport-tag``
| Egress table (220) ``match: reg6=tunnel2-lport-tag`` output to ``tunnel2``
the packet down the rest of the pipeline. Since the SFC service (SFF)
will most likely not be bound to this same Neutron port, the packet
wont be processed by the SFF on the ingress pipeline. If the classifier
-and first SFF are in the same node, when the packet is processed by
+and first SFF are in the same node, when the packet is processed by
the egress SFC classifier, it will be resubmitted back to the Ingress SFC
service (SFC SFF) for SFC processing. If not, the packet will be sent to
the first SFF.
+ * ERR_NOT_SUPPORTED when the server does not support
+ * the operation.
*/
-
+
const i32 BGP_ERR_FAILED = 1
@@ -38,6 +40,7 @@ const i32 BGP_ERR_ACTIVE = 10
const i32 BGP_ERR_INACTIVE = 11
const i32 BGP_ERR_NOT_ITER = 15
const i32 BGP_ERR_PARAM = 100
+const i32 BGP_ERR_NOT_SUPPORTED = 200
-
+
// these are the supported afi-safi combinations
enum af_afi {
@@ -122,6 +125,33 @@ service BgpConfigurator {
Problem description
===================
-If QoS bandwidth policy is applied on a neutron port, all packets exceeding the rate limit are
-dropped by the switch. This spec proposes a new service to monitor the packet drop ratio and log
+If QoS bandwidth policy is applied on a neutron port, all packets exceeding the rate limit are
+dropped by the switch. This spec proposes a new service to monitor the packet drop ratio and log
the alert message if packet drop ratio is greater than the configured threshold value.
Use Cases
- Proposed service uses the direct-statistics RPC instead of OpenflowPlugin statistics-manager. This
is lightweight because only node-connector statistics are queried instead of all statistics.
-- Polling frequency is quite slow. Default polling interval is **two minutes** and minimum allowed
+- Polling frequency is quite slow. Default polling interval is **two minutes** and minimum allowed
value is 1 minute.
Targeted Release
CSIT
----
-Following new CSIT tests shall be added
+Following new CSIT tests shall be added
1. Verify that alerts are generated if drop packets percentage is more than the configured threshold
value.
[1] `Neutron QoS <http://docs.openstack.org/developer/neutron/devref/quality_of_service.html>`__
-[2] `Spec for NetVirt QoS <http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/specs/qos.html>`__
+[2] `Spec for NetVirt QoS <http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/specs/qos.html>`__
[3] `Openflowplugin port statistics
<https://github.com/opendaylight/openflowplugin/blob/master/model/model-flow-statistics/src/main/yang/opendaylight-direct-statistics.yang>`__
Problem description
===================
-Currently any packet originating from an unknown source MAC address is punted to the controller from the ELAN service (L2 SMAC table 50).
+Currently any packet originating from an unknown source MAC address is punted to the controller from the ELAN service (L2 SMAC table 50).
This behavior continues for each packet from this source MAC until ODL properly processes this packet and adds an explicit source MAC rule to this table.
/**
* Copyright (c) 2016, 2017 Red Hat, Inc. and others. All rights reserved.
- *
+ *
* This program and the accompanying materials are made available under the
* terms of the Eclipse Public License v1.0 which accompanies this distribution,
* and is available at http://www.eclipse.org/legal/epl-v10.html
/**
* Definitions of complex objects expected in tests.
- *
+ *
* These were originally generated {@link AssertDataObjects#assertEqualBeans}.
*/
@SuppressWarnings("all")
public class ExpectedObjects {
public static String ELAN1 = "34701c04-1118-4c65-9425-78a80d49a211";
-
+
public static Long ELAN1_SEGMENT_ID = Long.valueOf(100L);
-
+
public static Interface newInterfaceConfig(final String interfaceName, final String parentName) {
InterfaceBuilder _interfaceBuilder = new InterfaceBuilder();
final Procedure1<InterfaceBuilder> _function = (InterfaceBuilder it) -> {
};
return XtendBuilderExtensions.<Interface, InterfaceBuilder>operator_doubleGreaterThan(_interfaceBuilder, _function);
}
-
+
public static Object createElanInstance() {
throw new Error("Unresolved compilation problems:"
+ "\nElanInstancesBuilder cannot be resolved."
+ "\n>> cannot be resolved"
+ "\n>> cannot be resolved");
}
-
+
public static Object createElanInstance(final String elan, final Long segmentId) {
throw new Error("Unresolved compilation problems:"
+ "\nElanInstanceBuilder cannot be resolved."
+ "\nThe method macTimeout(long) is undefined"
+ "\n>> cannot be resolved");
}
-
+
public static Object createElanInstance(final String elan, final Long segmentId, final Long tag) {
throw new Error("Unresolved compilation problems:"
+ "\nElanInstanceBuilder cannot be resolved."
+ "\nThe method macTimeout(long) is undefined"
+ "\n>> cannot be resolved");
}
-
+
public static Flow checkSmac(final String flowId, final InterfaceInfo interfaceInfo, final /* ElanInstance */Object elanInstance) {
throw new Error("Unresolved compilation problems:"
+ "\ngetElanTag cannot be resolved");
}
-
+
public static Flow checkDmacOfSameDpn(final String flowId, final InterfaceInfo interfaceInfo, final /* ElanInstance */Object elanInstance) {
throw new Error("Unresolved compilation problems:"
+ "\ngetElanTag cannot be resolved");
}
-
+
public static Flow checkDmacOfOtherDPN(final String flowId, final InterfaceInfo interfaceInfo, final TunnelInterfaceDetails tepDetails, final /* ElanInstance */Object elanInstance) {
throw new Error("Unresolved compilation problems:"
+ "\ngetElanTag cannot be resolved");
}
-
+
public static Object checkEvpnAdvertiseRoute(final Long vni, final String mac, final String tepip, final String prefix, final String rd1) {
throw new Error("Unresolved compilation problems:"
+ "\nNetworksBuilder cannot be resolved."
+ "\nPROTOCOLEVPN cannot be resolved"
+ "\nVXLAN cannot be resolved");
}
-
+
public static /* Networks */Object checkEvpnWithdrawRT2DelIntf() {
return null;
}
{
- "id": "855f06f8-9128-1a19-faf2-3af865f04061",
- "name": "localhost",
- "timestamp": 1396964904677,
+ "id": "855f06f8-9128-1a19-faf2-3af865f04061",
+ "name": "localhost",
+ "timestamp": 1396964904677,
"values": [
{
- "key": "controllerHost",
- "type": "text",
+ "key": "controllerHost",
+ "type": "text",
"value": "localhost"
- },
+ },
{
- "key": "controllerPort",
- "type": "text",
+ "key": "controllerPort",
+ "type": "text",
"value": "8080"
}
]
print indent + f
# WIP
# flow = indent + f
-# if len(flow) <= MAX_LINE:
+# if len(flow) <= MAX_LINE:
# print flow
# return
-#
+#
# cut = flow.find('ACTIONS')
# match = flow[0:cut - 1]
# action = indent + indent + flow[cut:]
# print action
# break
# cut = action.rfind(',', 0, MAX_LINE)
-# if cut < 2:
+# if cut < 2:
# print action
# break
# print action[0:cut + 1]
table = ''
rules_by_prio = defaultdict(list)
for line in sys.stdin:
- for (mac, ip) in addresses:
+ for (mac, ip) in addresses:
line = re.sub(mac, '%s(%s)' % (mac, ip), line)
line = re.sub('=%s(\D)' % ip, '=%s(%s)\\1' % (ip, mac), line)
line = re.sub('tun_id=0x(?P<num>[0-9a-fA-F]*)', tun_match_to_decimal, line)
line = re.sub('0x(?P<num>[0-9a-fA-F]*)->tun_id', tun_set_to_decimal, line)
match = re.match(LINE_PATTERN, line)
- if not match:
+ if not match:
print '[Not a flow line?]: ' + line,
continue
https://github.com/alagalah/gbpsfc-env
```
-The initial installation may take some time, with vagrant and docker image downloads.
+The initial installation may take some time, with vagrant and docker image downloads.
After the first time it is very quick.
-1. Set up Vagrant.
+1. Set up Vagrant.
* Edit env.sh for NUM_NODES. (Keep all other vars the same for this version)
Also set 'ODL_ROOT_DIR' to point to the directory ./openstack/net-virt-sfc/karaf/target/assembly
source ./env.sh
vagrant up
```
- * This takes quite some time initially.
+ * This takes quite some time initially.
3. Start controller.
* Currently it is expected that that controller runs on the machine hosting the vagrant VMs.
compute.vm.network "private_network", ip: "#{vm_ip}"
compute.vm.provider :virtualbox do |vb|
vb.memory = 512
- vb.customize ["modifyvm", :id, "--ioapic", "on"]
+ vb.customize ["modifyvm", :id, "--ioapic", "on"]
vb.cpus = 1
end
end
vagrant ssh $hostname -c "sudo ovs-vsctl del-br $switchname; sudo ovs-vsctl del-manager; sudo /vagrant/vmclean.sh"
done
-
+
./rest-clean.py
if [ -f "demo.lock" ] ; then
ip link set $GUEST_IFNAME netns $NSPID
if [ "$VLANTAG" ]
then
- ovs-vsctl add-port $BRIDGE $LOCAL_IFNAME tag=$VLANTAG
- echo $LOCAL_IFNAME
+ ovs-vsctl add-port $BRIDGE $LOCAL_IFNAME tag=$VLANTAG
+ echo $LOCAL_IFNAME
else
- ovs-vsctl add-port $BRIDGE $LOCAL_IFNAME
+ ovs-vsctl add-port $BRIDGE $LOCAL_IFNAME
echo $LOCAL_IFNAME
fi
# Step 5: Configure netwroking within the container
ip netns exec $NSPID ip link set $GUEST_IFNAME name eth0
ip netns exec $NSPID ip addr add $IPADDR broadcast $BROADCAST dev eth0
-ip netns exec $NSPID ifconfig eth0 hw ether $MAC
+ip netns exec $NSPID ifconfig eth0 hw ether $MAC
ip netns exec $NSPID ip addr add 127.0.0.1 dev lo
ip netns exec $NSPID ip link set eth0 up
ip netns exec $NSPID ip link set lo up
-ip netns exec $NSPID ip route add default via $GWADDR
+ip netns exec $NSPID ip route add default via $GWADDR
echo $hostname
vagrant ssh $hostname -c "sudo cp /vagrant/utils/hosts /etc/hosts"
done
-
+
vb.customize ["modifyvm", :id, "--cpus", 4]
vb.customize "post-boot",["controlvm", :id, "setlinkstate1", "on"]
end
-
+
config.vm.define vm_name = "odl" do |config|
config.vm.hostname = "odl"
config.vm.network "private_network", ip: "192.168.0.5"
-This directory contains all the associated scripts and configuration files that can be used by developers and
+This directory contains all the associated scripts and configuration files that can be used by developers and
administrators working on openstack and devstack.
Contents
Script used in OpenStack Deployments/devstack in order to initialize openvswitch/ovsdb-server
in order to work with the OpenDaylight's OVSDB southbound plugin effectively.
This scripts sets up ovsdb-server manager to listen to the Passive TCP socket open on 6640.
- It also configures the Open_vSwitch table in OVSDB with local-ip for the Overlay Tunnel end-point.
+ It also configures the Open_vSwitch table in OVSDB with local-ip for the Overlay Tunnel end-point.
-2. local.conf.controller : A sample development local.conf used on the devstack Controller node with Neutron ML2 mechanism driver for OpenDaylight.
+2. local.conf.controller : A sample development local.conf used on the devstack Controller node with Neutron ML2 mechanism driver for OpenDaylight.
-3. local.conf.compute : A sample development local.conf used on the devstack Compute node with Neutron ML2 mechanism driver for OpenDaylight.
+3. local.conf.compute : A sample development local.conf used on the devstack Compute node with Neutron ML2 mechanism driver for OpenDaylight.
4. DevStack.json.postman_collection : Relevant POSTMAN OpenDaylight REST-APIs that can be used for testing Openstack / Devstack deployments.
disable_all_services
#enable_service n-cpu quantum q-agt n-novnc qpid
enable_service neutron nova n-cpu quantum q-agt n-novnc qpid
-
+
HOST_NAME=fedora2
HOST_IP=192.168.56.102
SERVICE_HOST_NAME=fedora1
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST
-
+
MYSQL_PASSWORD=mysql
RABBIT_PASSWORD=rabbit
QPID_PASSWORD=rabbit
LOG_COLOR=False
#OFFLINE=True
RECLONE=yes
-
+
disable_service rabbit
enable_service qpid
-
+
enable_service n-cond
disable_service n-net
enable_service q-svc
enable_service q-l3
enable_service q-meta
enable_service quantum
-
+
# ODL WITH ML2
# #enable_service odl
Q_PLUGIN=ml2
HOST_NAME=fedora1
SERVICE_HOST_NAME=${HOST_NAME}
SERVICE_HOST=192.168.56.101
-
+
FLOATING_RANGE=192.168.100.0/24
#PUBLIC_NETWORK_GATEWAY=192.168.75.254
MYSQL_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=$SERVICE_HOST:9292
KEYSTONE_AUTH_HOST=$SERVICE_HOST
KEYSTONE_SERVICE_HOST=$SERVICE_HOST
-
+
MYSQL_PASSWORD=mysql
RABBIT_PASSWORD=rabbit
QPID_PASSWORD=rabbit
this.fixFirefoxAnchorBug();
this.highlightSearchWords();
this.initIndexTable();
-
+
},
/**
*/
-/* Non-minified version JS is _stemmer.js if file is provided */
+/* Non-minified version JS is _stemmer.js if file is provided */
/**
* Porter Stemmer
*/
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="odltools examples" href="examples.html" />
<link rel="prev" title="odltools Documentation" href="index.html" />
-
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<div class="section" id="contributing-to-odltools">
<h1><a class="toc-backref" href="#id1">Contributing to odltools</a><a class="headerlink" href="#contributing-to-odltools" title="Permalink to this headline">¶</a></h1>
<div class="contents topic" id="contents">
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
|
<a href="_sources/contributing.rst.txt"
rel="nofollow">Page source</a>
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Building a new release of odltools" href="new-release.html" />
<link rel="prev" title="Contributing to odltools" href="contributing.html" />
-
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<div class="section" id="odltools-examples">
<h1><a class="toc-backref" href="#id1">odltools examples</a><a class="headerlink" href="#odltools-examples" title="Permalink to this headline">¶</a></h1>
<div class="contents topic" id="contents">
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
|
<a href="_sources/examples.rst.txt"
rel="nofollow">Page source</a>
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
<script type="text/javascript" src="_static/doctools.js"></script>
<link rel="index" title="Index" href="#" />
<link rel="search" title="Search" href="search.html" />
-
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<h1 id="index">Index</h1>
<div class="genindex-jumpbox">
-
+
</div>
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Contributing to odltools" href="contributing.html" />
-
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<div class="section" id="odltools-documentation">
<h1>odltools Documentation<a class="headerlink" href="#odltools-documentation" title="Permalink to this headline">¶</a></h1>
<p>odltools needs some documentation.</p>
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
|
<a href="_sources/index.rst.txt"
rel="nofollow">Page source</a>
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="prev" title="odltools examples" href="examples.html" />
-
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<div class="section" id="building-a-new-release-of-odltools">
<h1><a class="toc-backref" href="#id1">Building a new release of odltools</a><a class="headerlink" href="#building-a-new-release-of-odltools" title="Permalink to this headline">¶</a></h1>
<div class="contents topic" id="contents">
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
|
<a href="_sources/new-release.rst.txt"
rel="nofollow">Page source</a>
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
<script type="text/javascript">
jQuery(function() { Search.loadIndex("searchindex.js"); });
</script>
-
+
<script type="text/javascript" id="searchindexloader"></script>
-
-
+
+
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
-
-
+
+
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
</head><body>
-
+
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
-
+
<h1 id="search-documentation">Search</h1>
<div id="fallback" class="admonition warning">
<script type="text/javascript">$('#fallback').hide();</script>
<input type="submit" value="search" />
<span id="search-progress" style="padding-left: 10px"></span>
</form>
-
+
<div id="search-results">
-
+
</div>
</div>
</div>
<div class="footer">
©2018, Sam Hague.
-
+
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 1.7.4</a>
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-
+
</div>
-
-
+
+
</body>
</html>
\ No newline at end of file
This script creates a docker container running a OVS configured
with the exact ports, flows, and groups captured from a running
-netvirt environment. Once the containerized OVS is running you
-can debug via
+netvirt environment. Once the containerized OVS is running you
+can debug via
* ovs-appctl ofproto/trace (you need to manually specify the vswitchd socket file...need to fix this)
* send packets from the port namespaces created (see them by typeing `ip netns`)
-* run tcpdump on a port (don't forget -n)
+* run tcpdump on a port (don't forget -n)
* run tcpdump on a flow using: https://github.com/jhershberg/WIP/blob/master/ovs-flow-snoop
## Usage
-Just once do:
+Just once do:
`sudo docker pull jhershbe/fedora-ovs-replay`
```
type boolean;
}
}
- }
+ }
}
Code Review / netvirt.git / commitdiff