1. Neutron Juno ReleaseBarcelona OpenStack MeetUp Group

2. Whats New in Neutron for JunoNova Network ParityDistributed Virtual RouterL3 HAIPv6Security Group EnhancementsPlugin Specific improvementsBug-fixesFull list of release issues here2 3. Nova Network Parity3 4. 4Nova Network ParityProblem: Neutron does not offer same functionality as nova-networkdoes, and sometimes is doing worse. Quick summary: technical debt in Neutron no allowed anymore. Neutron migration DB: each plugin offers different database schema andmigration depends on services enabled. New service enabled can end up with migration error. Grenade project hates Neutron project. No way to migrate from one vendor plugin to another. Neutron does not scale (L3 bottleneck). Nova-network does. No way to migrate from nova-network to Neutron Current users in nova networks do API calls that does not exist in Neutron 5. 5Nova Network ParitySolutions Heal Script. All tables from all plugins and services added. Scalability issues improved by DVR and L3 HAdevelopments (more about this later) Tempest tests added Gate tests addedNeutron default in devstack (not yet, devstack is not part ofthe integrated release)Nova-network to Neutron migration script (not yet!)Missing API calls (get_fixed_ips, get_vifs_by_vm) (indevelopment!) 6. Distributed Virtual Router (DVR)6 7. 7Distributed Virtual Router (DVR)Problem: Neutron does not scale Until Icehouse, Network Node is unique in installation: Single point of failure Traffic bottleneck 8. 8Distributed Virtual Router (DVR)Solution: delegate DNAT floating IP/fixed private IP to computenodes Traffic to floating Ips managed directly to compute nodes 9. 9Distributed Virtual Router (DVR)Solution: Handle East-West traffic inside compute L3namespace One namespace per tenant in compute machine Router inside namespace has an ARP table of the other tenant networks MACaddresses 10. Distributed Virtual Router (DVR)No solution: SNAT North/South traffic without Floating IPs Remains as a Single Point of Failure and traffic bottleneck (without L3 HA) 11. 11Distributed Virtual Router (DVR)Summary Significant improvement in traffic bottleneckMaybe now Neutron finally scales more than nova-network Best option for new deployments Upgrades (IMHO): pain in the ass Database migration not provided from legacy to DVR ? L3 agents must be configured and installed manually Compute nodes need access to external network SNAT needs to be improved (more later in L3 HA) 12. 12Distributed Virtual Router (DVR)More info Base design document L2 agent changes L3 agent changes Atlanta Summit Slides OpenStack wiki: How to enable DVR Official Spec 13. L3 High Availability13 14. 14L3 High AvailabilityProblem: L3 SNAT con not be distributed To provide internet access to Virtual Machineswithout HA, you need a SNAT service: A single gateway per network by default (even 2gateways does not solve the problem) This gateway must keep track of outgoingconnections to redirect reverse-SNAT ingoingresponses. Single point of failure: All machines accessing tointernet lose their connections if Network Nodefails. 15. 15L3 High AvailabilitySolution: based on VRRP protocol First Hop Redundancy Protocol (FHRP) Multiple nodes working as router of the network. Work on master (active) or slave (stand-by) mode If master does not send 'hello' messages to stand-bynodes, they start an election process to definethe new master Active node maps a configured VIP MAC addressthat is the gateway of the Vms subnets 16. 16L3 High AvailabilitySolution: based on VRRP protocol 17. 17L3 High AvailabilitySolution: VRRP in Neutron An HA Network is created (tenant Network without tenant id) Keepalived traffic is sent by this network 18. 18L3 High AvailabilityMore info Assaf Muller blog Official Spec How to test OpenStack Wiki 19. IPv619 20. 20IPv6Icehouse status IPv6 networks, although posible, almost useless Only Link-Local addresses registered in Neutron RA advertiser for SLAAC support must bedeployed manually Only one attribute in the subnet: ip_version 21. 21IPv6Juno status Full support to IPv6 tenant networks RADVD and DNSMASQ services deployed depending on theattributes Current attributes: ip_version ipv6_ra_mode ipv6_address_mode These previous attributes allow provider services to pass throughthe network tenant router and offer provider hardware solutions Next slide shows all the combinations available Public networks not yet (current floating IP NAT does not makesense in IPv6) 22. 22 23. 23IPv6More info Spec: upstream SLAAC support Spec: Router Advertiser Daemon (radvd) Spec: Stateful and Stateless mode in dnsmasq Patch to deploy a devstack with IPv6 24. Security Groups Enharcements24 25. 25Security Group Enharcements*Image stolen miserably from rackspacedocumentation 26. 26Security Group EnharcementsImplementation improvements Using Ipset improves the readability and scalability of iptables chains: 27. 27Security Group EnharcementsImplementation Improvements Problem: Communication L2 Agent Neutron Server regarding securitygroups does not scale: RCP calls block communication channel Call by device Long messages from Server (20-600MB!!) Solution: Response based on security group aggregated information: Easy to fetch from Neutron Smaller messages Example 28. 28Security Group EnharcementsMore info Ipsec spec Security Group RPC calls improvement spec 29. Demo time!29 30. 30More info Release Notes Kyle Mestery notes Juno design specs Technical's Comitee Neutron Gap Coverage Launchpad report 31. Thank you31