Difference between revisions of "Blueprint-ipam-policy-extensions-for-neutron"
Rudrarugge (talk | contribs) (Created page with "Juniper JunosVContrail(JVC) plugin supports Neutron Core V2 APIs alongwith L3, Security Groups, VPC, IPAM and Policy extensions on a system running Juniper's Contrail based Vi...") |
Rudrarugge (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | + | === <span>Overview</span>=== | |
| − | |||
| − | |||
| − | The plugin itself is stateless and transforms Neutron resource request/responses | + | Juniper JunosVContrail(JVC) plugin supports Neutron Core V2 APIs alongwith L3, Security Groups, VPC, IPAM and Policy extensions on a system running Juniper's Contrail based Virtual Network System. The plugin itself is stateless and transforms Neutron resource request/responses into the form required by the JVC controller. The JVContrailPlugin.py file has classes interfacing with Neutron plugin/extension classes and the config_db.py has files that deal with data transformation and talking with JVC controller. |
| − | into the form required by the JVC controller. | ||
| − | + | === <span>IPAM Resource </span>=== | |
| − | |||
| − | |||
| − | + | Information common to a set of subnets on a network will be present in this | |
| − | + | resource. Following information will be stored in the resource: | |
| − | Information common to a set of subnets on a network will be present | ||
| − | resource. | ||
* Address allocation scheme (DHCP or unmanaged) | * Address allocation scheme (DHCP or unmanaged) | ||
* DNS server information | * DNS server information | ||
| Line 19: | Line 12: | ||
* List of DHCP option, value tuples | * List of DHCP option, value tuples | ||
| − | Network Policy Resource | + | === <span>Network Policy Resource </span>=== |
| − | |||
Network policy is mechanism by which a declarative way is provided to the clients to decided how Neutron virtual networks are connected and what traffic is allowed over those connections. Clients do not have to worry about how exactly the connectivity is achieved and how/where the rules are applied. This is to simplify deployments of multitier applications | Network policy is mechanism by which a declarative way is provided to the clients to decided how Neutron virtual networks are connected and what traffic is allowed over those connections. Clients do not have to worry about how exactly the connectivity is achieved and how/where the rules are applied. This is to simplify deployments of multitier applications | ||
| + | ====Network Policy Example==== | ||
For example as application developer user wants to put | For example as application developer user wants to put | ||
web servers in network called front-end network. | web servers in network called front-end network. | ||
| Line 34: | Line 27: | ||
In above example user creates policy called | In above example user creates policy called | ||
front-end-to-back-end: | front-end-to-back-end: | ||
| − | + | * pass front-end any <> back-end MySQL | |
This policy is attached to both the networks. Multiple policies can be attached to the network. Policies can be templatized with parameters as attached networks. Admin can provide precooked policy templates | This policy is attached to both the networks. Multiple policies can be attached to the network. Policies can be templatized with parameters as attached networks. Admin can provide precooked policy templates | ||
| + | ====Network Policy and FWaaS==== | ||
Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way | Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way | ||
| − | + | * pass front-end any <> back-end any any apply-service Firewall_instance_1 | |
| − | + | ||
| + | ====Network Policy and Security Groups==== | ||
Network policy is not replacement for security groups either. Security groups are protecting the interfaces to VM(s). Network policy is between virtual networks. Have policies at various levels actually increases flexibility and reduces need for NxN matrix like rule explosion. | Network policy is not replacement for security groups either. Security groups are protecting the interfaces to VM(s). Network policy is between virtual networks. Have policies at various levels actually increases flexibility and reduces need for NxN matrix like rule explosion. | ||
| + | ====Network Policy Bind Points==== | ||
In traditional networking gear ACL were always applied at various levels. | In traditional networking gear ACL were always applied at various levels. | ||
| − | + | * Ports ACL(s) à Security groups | |
| − | + | * VLAN ACL(s) and Router ACL(s) à network policy | |
Network policy can be expressed in terms of network ID(s) rather than IP prefixes (CIDRs) | Network policy can be expressed in terms of network ID(s) rather than IP prefixes (CIDRs) | ||
| − | |||
Information given in such a resource can be used to derive | Information given in such a resource can be used to derive | ||
| − | + | *Connectivity between networks. i.e whether at a L3 network level routes need to be exchanged. e.g. allow traffic from web-network to db-network. | |
| − | + | * Packet filters on traffic crossing two networks. e.g. allow only mysql traffic between web-network to db-network | |
| − | |||
| − | |||
| − | A policy is composed of a set of entries which have the following fields | + | ====Network Policy Fields==== |
| − | (snort-like format): | + | A policy is composed of a set of entries which have the following fields (snort-like format): |
| − | |||
* direction - uni/bi-directional | * direction - uni/bi-directional | ||
* protocol - tcp/udp/icmp/any | * protocol - tcp/udp/icmp/any | ||
| Line 64: | Line 56: | ||
* dst-addresses - list in terms of subnets/networks/security-groups | * dst-addresses - list in terms of subnets/networks/security-groups | ||
* dst-ports - list of port numbers | * dst-ports - list of port numbers | ||
| − | * action-list - list of actions like apply-service, mirror-to, referencing | + | * action-list - list of actions like apply-service, mirror-to, referencing an already defined service or simple actions [pass|deny|log|reject|drop|alert] |
| − | |||
Latest revision as of 17:45, 4 October 2013
Contents
Overview
Juniper JunosVContrail(JVC) plugin supports Neutron Core V2 APIs alongwith L3, Security Groups, VPC, IPAM and Policy extensions on a system running Juniper's Contrail based Virtual Network System. The plugin itself is stateless and transforms Neutron resource request/responses into the form required by the JVC controller. The JVContrailPlugin.py file has classes interfacing with Neutron plugin/extension classes and the config_db.py has files that deal with data transformation and talking with JVC controller.
IPAM Resource
Information common to a set of subnets on a network will be present in this resource. Following information will be stored in the resource:
- Address allocation scheme (DHCP or unmanaged)
- DNS server information
- CIDR to be used by the network (in which all subnet definitions should belong)
- List of DHCP option, value tuples
Network Policy Resource
Network policy is mechanism by which a declarative way is provided to the clients to decided how Neutron virtual networks are connected and what traffic is allowed over those connections. Clients do not have to worry about how exactly the connectivity is achieved and how/where the rules are applied. This is to simplify deployments of multitier applications
Network Policy Example
For example as application developer user wants to put web servers in network called front-end network. Appservers in network called back-end network Allocate floating ip from public network. Floating ip is assigned as VIP to web servers Only MySQL traffic is allowed from front-end to backend
This information should be enough for the network plugin to add routing between front-end and back-end and ACLs for MySQL between these two networks. Users (application developers and deployers) need not worry about routers and firewall rules etc. Basically network policy provides this declarative way for user to simplify application deployment.
In above example user creates policy called front-end-to-back-end:
- pass front-end any <> back-end MySQL
This policy is attached to both the networks. Multiple policies can be attached to the network. Policies can be templatized with parameters as attached networks. Admin can provide precooked policy templates
Network Policy and FWaaS
Network Policy is in no way a replacement for FWaaS. In this context traditional FW is still valid. Rules provided in Network Policy are simple and limited in comparison to traditional firewall. Though they complement each other. For application deployers firewall rules and configuration might be too overwhelming. Users may have REST interface between front-end and backend. They might want to take all traffic between front-end and back-end via a firewall instance. In this case above rule changes in following way
- pass front-end any <> back-end any any apply-service Firewall_instance_1
Network Policy and Security Groups
Network policy is not replacement for security groups either. Security groups are protecting the interfaces to VM(s). Network policy is between virtual networks. Have policies at various levels actually increases flexibility and reduces need for NxN matrix like rule explosion.
Network Policy Bind Points
In traditional networking gear ACL were always applied at various levels.
- Ports ACL(s) à Security groups
- VLAN ACL(s) and Router ACL(s) à network policy
Network policy can be expressed in terms of network ID(s) rather than IP prefixes (CIDRs)
Information given in such a resource can be used to derive
- Connectivity between networks. i.e whether at a L3 network level routes need to be exchanged. e.g. allow traffic from web-network to db-network.
- Packet filters on traffic crossing two networks. e.g. allow only mysql traffic between web-network to db-network
Network Policy Fields
A policy is composed of a set of entries which have the following fields (snort-like format):
- direction - uni/bi-directional
- protocol - tcp/udp/icmp/any
- src-addresses - list in terms of subnets/networks/security-groups
- src-ports - list of port numbers
- dst-addresses - list in terms of subnets/networks/security-groups
- dst-ports - list of port numbers
- action-list - list of actions like apply-service, mirror-to, referencing an already defined service or simple actions [pass|deny|log|reject|drop|alert]
