Networking in OpenStack for non-networking people: Neutron, Open vSwitch and friends

  • 16,934 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
16,934
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
666
Comments
2
Likes
24

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. DAVE NEARY1 Networking in OpenStack for non- networking people: Neutron, OVS and friends Dave Neary dneary@redhat.com Open Source and Standards Red Hat
  • 2. REDHAT OPENSTACK |2013DOC144908-20130513r1 AGENDA ● Networking review: the OSI model ● Networking in a virtual world ● Neutron and OVS ● Debugging and fixing networking issues
  • 3. DAVE NEARY3 Networking: The OSI model Layer 1 Layer 7
  • 4. DAVE NEARY4 Networking: The OSI model Layer 1 Layer 7 Cables Switching Routers Hardware Software TCP/IP SMTP
  • 5. DAVE NEARY5 Switches and routers
  • 6. DAVE NEARY6 Networking in a virtual world CC BY from OpenStack Operations Guide: http://bit.ly/OpenStackNetworking
  • 7. DAVE NEARY7 Networking in a virtual world: Open vSwitch
  • 8. DAVE NEARY9 Networking in a virtual world: Neutron ● Abstracts away internals of switching and SDN provider ● Provides high-level abstractions (router, subnet, network, gateway) ● “Law of Leaky Abstractions” applies
  • 9. DAVE NEARY10 Neutron: Creating a subnet ● neutron router-create router1 ● neutron net-create net1 ● neutron subnet-create net1 172.17.0.0/24 --name subnet1 ● neutron router-interface-add router1 subnet1
  • 10. DAVE NEARY11 Neutron: Attaching a public subnet ● neutron net-create net2 --router-external=True ● neutron subnet-create net2 192.168.0.0/24 --name subnet2 --enable_dhcp=False --allocation-pool start=192.168.0.32,end=192.168.0.63 --gateway=192.168.0.1 ● neutron router-gateway-set router1 net2
  • 11. DAVE NEARY12 Neutron: Floating IPs ● To connect from an external machine to an instance, you need a routable IP address ● Floating IP addresses are public aliases for private IP addresses ● They survive changes in private IPs, enable load balancing, etc. ● Equivalent to Elastic IPs in AWS
  • 12. DAVE NEARY13 Neutron: Floating IPs ● neutron floatingip-create net2 ● neutron floatingip-list ● neutron port-list ● neutron floatingip-associate <floating-ip> <port>
  • 13. DAVE NEARY14 Debugging network issues: Devices ● ip a shows status of all physical and virtual devices ● ovs-vsctl show shows interfaces and bridges in the virtual switch ● ovs-dpctl show shows datapaths on the switch
  • 14. DAVE NEARY15 Debugging network issues: Tracking packets ● tcpdump is your friend ● tcpdump -n -i <interface> -w <filename> ● Set interface to vnet device, instance eth0, bridge device, or host ethernet device to see where packets are not getting through ● -i any for all interfaces ● iptables -L to check iptables rules
  • 15. DAVE NEARY16 Debugging network issues: Network namespaces ● Network namespaces allow VLANs to share overlapping address space – important for bigger deployments, and to provide multi-tenant networks ● ip netns list – lists all known network namespaces ● ip netns exec <namespace id> route -n ● Shows routing table inside specific namespace ● Execute arbitrary commands (incl. ssh, ping)
  • 16. DAVE NEARY17 Debugging networking issues: DHCP ● Scenario: Instance is not getting IP address ● Step 1: nova console-log <instance name> ● DHCP request sent, no reply received ● Step 2: Verify neutron-dhcp-agent is running ● Step 3: Check host logs (/var/log/messages and /var/log/neutron/*) ● Step 4: If host is not seeing DHCP traffic: tcpdump -i all | grep -i dhcp
  • 17. DAVE NEARY18 Debugging networking issues: Access/routing ● Scenario: I can't SSH into an instance ● Step 1: Security groups: port 22 TCP & all ICMP allowed? ● Step 2: Is floating IP address routable from client? ● route -n on client ● Verify that public subnet in OpenStack is accessible from client (eg. for local LAN, that it matches 192.168.0.0/24) ● Step 3: Bridges OK?
  • 18. DAVE NEARY19 Debugging networking issues: Access/routing ● Bridge issues: ● ovs-vsctl show – is ethernet card attached to same bridge as public network? ● neutron router show router1 – are the private subnet and public subnet connected to the router? ● ip netns exec <public namespace id> ping <floating IP> - does the public network match the local LAN exactly? ● ip netns exec <private namespace id> route -n – is traffic being correctly routed from the instance out?
  • 19. DAVE NEARY20 Resources ● OpenStack Network troubleshooting: http://bit.ly/OpenStackNetworking ● OpenStack Networking: L3 workflow: http://bit.ly/L3Workflow ● RDO Networking: http://bit.ly/RDONetworking ● RDO: Neutron with an external network: http://bit.ly/RDONeutronExtNet ● OpenStack Tales from the Crypt: http://bit.ly/OpenStackCrypt
  • 20. REDHAT OPENSTACK |2013DOC144908-20130513r1 QUESTIONS?