Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
On 07/23/2013 11:41 PM, David Kang wrote: A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Can you elaborate on what it doesn't work means? Do any of those rules show increased packet/byte counts, indicating they've been matched? Is IP forwarding enabled? Is there a mis-configuration in your bridge config? Use 'brctl show' to see where all the tap and other devices are attached. Deleting that one FORWARD rule causing all the trouble is going to be a much quicker solution. -Brian - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be put in place for anti-spoofing. Since this is the network node you won't see them here. -Brian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
If I remove the following REJECT rules, it works perfectly. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With them, it looks like that the packets are dropped at the bridge before they can be forwarded. I ran the iptables commands recommended by RedHat. When I ping 10.12.182.13 from a VM (192.168.3.3), I cannot see any packets from qr-32411859-c0, but I can see packets are dropped at brqf56b3f53-d3. The outputs of tcpdump is shown below. $ brctl show bridge name bridge id STP enabled interfaces brq69f480ab-06 8000.001e675ba339 no eth2.82 tapd8bd73c9-3a brqf56b3f53-d3 8000.001e675ba338 no eth1.2001 tap32411859-c0 tapfa6a1d01-16 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ns-fa6a1d01-16 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-32411859-c0 10.12.182.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2.182 10.12.82.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-d8bd73c9-3a 0.0.0.0 10.12.82.1 0.0.0.0 UG 0 0 0 qg-d8bd73c9-3a $ tcpdump -i qr-32411859-c0 -nn // nothing special $ tcpdump -i brqf56b3f53-d3 -nn icmp tcpdump: WARNING: brqf56b3f53-d3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on brqf56b3f53-d3, link-type EN10MB (Ethernet), capture size 65535 bytes 13:48:46.892785 IP 192.168.3.3 10.12.182.13: ICMP echo request, id 46605, seq 1855, length 64 13:48:46.892825 IP 192.168.3.2 192.168.3.3: ICMP host 10.12.182.13 unreachable - admin prohibited, length 92 - Original Message - On 07/23/2013 11:41 PM, David Kang wrote: A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Can you elaborate on what it doesn't work means? Do any of those rules show increased packet/byte counts, indicating they've been matched? Is IP forwarding enabled? Is there a mis-configuration in your bridge config? Use 'brctl show' to see where all the tap and other devices are attached. Deleting that one FORWARD rule causing all the trouble is going to be a much quicker solution. -Brian - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be put in place for anti-spoofing. Since this is the network node you won't see them here. -Brian -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
On 07/24/2013 10:42 AM, David Kang wrote: If I remove the following REJECT rules, it works perfectly. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With them, it looks like that the packets are dropped at the bridge before they can be forwarded. So I'll keep asking - why can't you just remove them? It gets you running and if you're just kicking the tires it's a valid workaround. I ran the iptables commands recommended by RedHat. When I ping 10.12.182.13 from a VM (192.168.3.3), I cannot see any packets from qr-32411859-c0, but I can see packets are dropped at brqf56b3f53-d3. The outputs of tcpdump is shown below. $ brctl show bridge name bridge id STP enabled interfaces brq69f480ab-06 8000.001e675ba339 no eth2.82 tapd8bd73c9-3a brqf56b3f53-d3 8000.001e675ba338 no eth1.2001 tap32411859-c0 tapfa6a1d01-16 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 00 ns-fa6a1d01-16 192.168.3.0 0.0.0.0 255.255.255.0 U 0 00 qr-32411859-c0 Overlapping IP ranges? That could be a problem. 10.12.182.0 0.0.0.0 255.255.255.0 U 0 00 eth2.182 10.12.82.0 0.0.0.0 255.255.255.0 U 0 00 qg-d8bd73c9-3a 0.0.0.0 10.12.82.1 0.0.0.0 UG0 00 qg-d8bd73c9-3a Why is your default route going out this interface and not eth2.182? $ tcpdump -i qr-32411859-c0 -nn // nothing special What about ns-fa6a1d01-16? That overlapping IP range looks suspicious. $ tcpdump -i brqf56b3f53-d3 -nn icmp tcpdump: WARNING: brqf56b3f53-d3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on brqf56b3f53-d3, link-type EN10MB (Ethernet), capture size 65535 bytes 13:48:46.892785 IP 192.168.3.3 10.12.182.13: ICMP echo request, id 46605, seq 1855, length 64 13:48:46.892825 IP 192.168.3.2 192.168.3.3: ICMP host 10.12.182.13 unreachable - admin prohibited, length 92 This is the reject iptables rule firing, so those other rules are not matching. You need to look at 'iptables -L -v -n -x' to see if their packet/byte counts are increasing or not. If not, start using things like 'ip route get $dest' to figure out what interfaces the kernel is using for output, which will help you fix those rules to be correct. -Brian - Original Message - On 07/23/2013 11:41 PM, David Kang wrote: A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Can you elaborate on what it doesn't work means? Do any of those rules show increased packet/byte counts, indicating they've been matched? Is IP forwarding enabled? Is there a mis-configuration in your bridge config? Use 'brctl show' to see where all the tap and other devices are attached. Deleting that one FORWARD rule causing all the trouble is going to be a much quicker solution. -Brian - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Thanks, Brian. My answers are put in your email with --. David - Original Message - On 07/24/2013 10:42 AM, David Kang wrote: If I remove the following REJECT rules, it works perfectly. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With them, it looks like that the packets are dropped at the bridge before they can be forwarded. So I'll keep asking - why can't you just remove them? It gets you running and if you're just kicking the tires it's a valid workaround. -- My sponsor STRONGLY wants to have the rules for security purpose. I ran the iptables commands recommended by RedHat. When I ping 10.12.182.13 from a VM (192.168.3.3), I cannot see any packets from qr-32411859-c0, but I can see packets are dropped at brqf56b3f53-d3. The outputs of tcpdump is shown below. $ brctl show bridge name bridge id STP enabled interfaces brq69f480ab-06 8000.001e675ba339 no eth2.82 tapd8bd73c9-3a brqf56b3f53-d3 8000.001e675ba338 no eth1.2001 tap32411859-c0 tapfa6a1d01-16 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ns-fa6a1d01-16 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-32411859-c0 Overlapping IP ranges? That could be a problem. -- Those are generated by quantum-linuxbridge-agent. If a quantum network is associated to a quantum l3 router, qr-xxx interface is added. 10.12.182.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2.182 10.12.82.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-d8bd73c9-3a 0.0.0.0 10.12.82.1 0.0.0.0 UG 0 0 0 qg-d8bd73c9-3a Why is your default route going out this interface and not eth2.182? -- I didn't show it. Another default router of eth2.182 also exist below 10.12.82.1. Quantum automatically made qg-d8bd73c9-3a as a default router. It is the interface to the gateway of the external network where floating IP is assigned. $ tcpdump -i qr-32411859-c0 -nn // nothing special What about ns-fa6a1d01-16? That overlapping IP range looks suspicious. -- It was made by quantum-linux-bridge. $ tcpdump -i brqf56b3f53-d3 -nn icmp tcpdump: WARNING: brqf56b3f53-d3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on brqf56b3f53-d3, link-type EN10MB (Ethernet), capture size 65535 bytes 13:48:46.892785 IP 192.168.3.3 10.12.182.13: ICMP echo request, id 46605, seq 1855, length 64 13:48:46.892825 IP 192.168.3.2 192.168.3.3: ICMP host 10.12.182.13 unreachable - admin prohibited, length 92 This is the reject iptables rule firing, so those other rules are not matching. You need to look at 'iptables -L -v -n -x' to see if their packet/byte counts are increasing or not. If not, start using things like 'ip route get $dest' to figure out what interfaces the kernel is using for output, which will help you fix those rules to be correct. -- Thanks, I will try it. -Brian - Original Message - On 07/23/2013 11:41 PM, David Kang wrote: A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Can you elaborate on what it doesn't work means? Do any of those rules show increased packet/byte counts, indicating they've been matched? Is IP forwarding enabled? Is there a mis-configuration in your bridge config? Use 'brctl show' to see where all the tap and other devices are attached. Deleting that one FORWARD rule causing all the trouble is going to be a much quicker solution. -Brian - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Just some more notes. It looks like you're running this system as both a network node and compute node, I think the pdf you found from Redhat assumed the system was a dedicated network node, i.e. it only had qr- and qg- interfaces, and not ns- as created by plug() when an instance is booted. Multiple routes for the same destination, going out two different interfaces not connected to the same network, are going to cause you trouble. It's non-deterministic where a packet will go without ip rules. I'm going to let you go and debug this some more on your own, as it looks like it's your iptables config causing it, you just need to get the correct rules in there. -Brian On 07/24/2013 11:34 AM, David Kang wrote: Thanks, Brian. My answers are put in your email with --. David - Original Message - On 07/24/2013 10:42 AM, David Kang wrote: If I remove the following REJECT rules, it works perfectly. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With them, it looks like that the packets are dropped at the bridge before they can be forwarded. So I'll keep asking - why can't you just remove them? It gets you running and if you're just kicking the tires it's a valid workaround. -- My sponsor STRONGLY wants to have the rules for security purpose. I ran the iptables commands recommended by RedHat. When I ping 10.12.182.13 from a VM (192.168.3.3), I cannot see any packets from qr-32411859-c0, but I can see packets are dropped at brqf56b3f53-d3. The outputs of tcpdump is shown below. $ brctl show bridge name bridge id STP enabled interfaces brq69f480ab-06 8000.001e675ba339 no eth2.82 tapd8bd73c9-3a brqf56b3f53-d3 8000.001e675ba338 no eth1.2001 tap32411859-c0 tapfa6a1d01-16 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ns-fa6a1d01-16 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-32411859-c0 Overlapping IP ranges? That could be a problem. -- Those are generated by quantum-linuxbridge-agent. If a quantum network is associated to a quantum l3 router, qr-xxx interface is added. 10.12.182.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2.182 10.12.82.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-d8bd73c9-3a 0.0.0.0 10.12.82.1 0.0.0.0 UG 0 0 0 qg-d8bd73c9-3a Why is your default route going out this interface and not eth2.182? -- I didn't show it. Another default router of eth2.182 also exist below 10.12.82.1. Quantum automatically made qg-d8bd73c9-3a as a default router. It is the interface to the gateway of the external network where floating IP is assigned. $ tcpdump -i qr-32411859-c0 -nn // nothing special What about ns-fa6a1d01-16? That overlapping IP range looks suspicious. -- It was made by quantum-linux-bridge. $ tcpdump -i brqf56b3f53-d3 -nn icmp tcpdump: WARNING: brqf56b3f53-d3: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on brqf56b3f53-d3, link-type EN10MB (Ethernet), capture size 65535 bytes 13:48:46.892785 IP 192.168.3.3 10.12.182.13: ICMP echo request, id 46605, seq 1855, length 64 13:48:46.892825 IP 192.168.3.2 192.168.3.3: ICMP host 10.12.182.13 unreachable - admin prohibited, length 92 This is the reject iptables rule firing, so those other rules are not matching. You need to look at 'iptables -L -v -n -x' to see if their packet/byte counts are increasing or not. If not, start using things like 'ip route get $dest' to figure out what interfaces the kernel is using for output, which will help you fix those rules to be correct. -- Thanks, I will try it. -Brian - Original Message - On 07/23/2013 11:41 PM, David Kang wrote: A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Can you elaborate on what it doesn't work means? Do any of those rules show increased packet/byte counts, indicating they've been matched? Is IP forwarding enabled? Is there a mis-configuration in your bridge config? Use 'brctl show' to see where all the tap and other devices are attached. Deleting that one FORWARD rule causing all the trouble is going to be a much quicker solution. -Brian - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4.
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
It is strange.
The node is only for Quantum-{linuxbridge, dhcp, l3}-agent.
As far as I know, the quantum private network that is not associated with a
quantum router
has only ns-xxx interface.
The quantum private network otherwise have both ns-xxx and qr-xxx interfaces.
Thanks,
David
- Original Message -
Just some more notes.
It looks like you're running this system as both a network node and
compute
node, I think the pdf you found from Redhat assumed the system was a
dedicated
network node, i.e. it only had qr- and qg- interfaces, and not ns- as
created by
plug() when an instance is booted.
Multiple routes for the same destination, going out two different
interfaces not
connected to the same network, are going to cause you trouble. It's
non-deterministic where a packet will go without ip rules.
I'm going to let you go and debug this some more on your own, as it
looks like
it's your iptables config causing it, you just need to get the correct
rules in
there.
-Brian
On 07/24/2013 11:34 AM, David Kang wrote:
Thanks, Brian.
My answers are put in your email with --.
David
- Original Message -
On 07/24/2013 10:42 AM, David Kang wrote:
If I remove the following REJECT rules, it works perfectly.
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
With them, it looks like that the packets are dropped at the
bridge
before they can be forwarded.
So I'll keep asking - why can't you just remove them? It gets you
running and
if you're just kicking the tires it's a valid workaround.
-- My sponsor STRONGLY wants to have the rules for security
purpose.
I ran the iptables commands recommended by RedHat.
When I ping 10.12.182.13 from a VM (192.168.3.3),
I cannot see any packets from qr-32411859-c0,
but I can see packets are dropped at brqf56b3f53-d3.
The outputs of tcpdump is shown below.
$ brctl show
bridge name bridge id STP enabled interfaces
brq69f480ab-06 8000.001e675ba339 no eth2.82
tapd8bd73c9-3a
brqf56b3f53-d3 8000.001e675ba338 no eth1.2001
tap32411859-c0
tapfa6a1d01-16
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 ns-fa6a1d01-16
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 qr-32411859-c0
Overlapping IP ranges? That could be a problem.
-- Those are generated by quantum-linuxbridge-agent.
If a quantum network is associated to a quantum l3 router, qr-xxx
interface is added.
10.12.182.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2.182
10.12.82.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-d8bd73c9-3a
0.0.0.0 10.12.82.1 0.0.0.0 UG 0 0 0 qg-d8bd73c9-3a
Why is your default route going out this interface and not
eth2.182?
-- I didn't show it. Another default router of eth2.182 also exist
below 10.12.82.1.
Quantum automatically made qg-d8bd73c9-3a as a default router.
It is the interface to the gateway of the external network where
floating IP is assigned.
$ tcpdump -i qr-32411859-c0 -nn
// nothing special
What about ns-fa6a1d01-16? That overlapping IP range looks
suspicious.
-- It was made by quantum-linux-bridge.
$ tcpdump -i brqf56b3f53-d3 -nn icmp
tcpdump: WARNING: brqf56b3f53-d3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full
protocol
decode
listening on brqf56b3f53-d3, link-type EN10MB (Ethernet), capture
size 65535 bytes
13:48:46.892785 IP 192.168.3.3 10.12.182.13: ICMP echo request,
id
46605, seq 1855, length 64
13:48:46.892825 IP 192.168.3.2 192.168.3.3: ICMP host
10.12.182.13
unreachable - admin prohibited, length 92
This is the reject iptables rule firing, so those other rules are
not
matching.
You need to look at 'iptables -L -v -n -x' to see if their
packet/byte
counts
are increasing or not. If not, start using things like 'ip route
get
$dest' to
figure out what interfaces the kernel is using for output, which
will
help you
fix those rules to be correct.
-- Thanks, I will try it.
-Brian
- Original Message -
On 07/23/2013 11:41 PM, David Kang wrote:
A Redhat manual suggests the following rule to enable
forwarding
packets
among VMs and external network.
https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf
iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT
iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT
iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT
But it doesn't work for me.
Can you elaborate on what it doesn't work means?
Do any of those rules show increased
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? I'll appreciate your help. David -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? I'll appreciate your help. David -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
that will not show the rules for the instance. try this ip netns exec yourrouter-uuid iptables -nxvL On Jul 23, 2013, at 09:59 , David Kang dk...@isi.edu wrote: Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? I'll appreciate your help. David -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp !DSPAM:2,51eeb6bc294852088044995! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
We use CentOS 6.4, which does not support network namespace. So ip netns .. fails. Thanks, David - Original Message - that will not show the rules for the instance. try this ip netns exec yourrouter-uuid iptables -nxvL On Jul 23, 2013, at 09:59 , David Kang dk...@isi.edu wrote: Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? I'll appreciate your help. David -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp !DSPAM:2,51eeb6bc294852088044995! -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Hi, This is very interesting..:) I am using openstack grizzly allinone with quantum/neutron. Look what I am observing. -before starting an instance on the server root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:22:55 2013 *filter :INPUT ACCEPT [62981:17142030] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [62806:17138989] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:22:55 2013 root@ubuntu1204:~# -after starting an instance on the host root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:24:42 2013 *filter :INPUT ACCEPT [90680:24989889] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [90482:24984752] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-compute-FORWARD - [0:0] :nova-compute-INPUT - [0:0] :nova-compute-OUTPUT - [0:0] :nova-compute-inst-35 - [0:0] :nova-compute-local - [0:0] :nova-compute-provider - [0:0] :nova-compute-sg-fallback - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-compute-INPUT -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-compute-FORWARD -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-compute-OUTPUT -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-compute-FORWARD -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-INPUT -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-inst-35 -m state --state INVALID -j DROP -A nova-compute-inst-35 -m state --state RELATED,ESTABLISHED -j ACCEPT -A nova-compute-inst-35 -j nova-compute-provider -A nova-compute-inst-35 -s 172.24.17.2/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A nova-compute-inst-35 -s 172.24.17.0/24 -j ACCEPT -A nova-compute-inst-35 -p tcp -m tcp --dport 22 -j ACCEPT -A nova-compute-inst-35 -p icmp -j ACCEPT -A nova-compute-inst-35 -j nova-compute-sg-fallback -A nova-compute-local -d 172.24.17.1/32 -j nova-compute-inst-35 -A nova-compute-sg-fallback -j DROP -A nova-filter-top -j nova-compute-local -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:24:42 2013 It seams that the rule that accepts dhcp packets is created once an instance is spawned. I will try the same thing on an centos64. Regards, Gabriel From: David Kang dk...@isi.edu To: Staicu Gabriel gabriel_sta...@yahoo.com Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:59 PM Subject: Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? I'll appreciate your help
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
What I have observed so far is... 1. nova-compute sends dhcp request 2. dhcp-server running on the Quantum node does not receive the request because of the firewall setting. I don't understand why quantum-dhcp-agent does not set up firewall properly. (Yes, all the openstack components are running on CentOS6.4 in our system.) Thanks, David - Original Message - Hi, This is very interesting..:) I am using openstack grizzly allinone with quantum/neutron. Look what I am observing. -before starting an instance on the server root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:22:55 2013 *filter :INPUT ACCEPT [62981:17142030] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [62806:17138989] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:22:55 2013 root@ubuntu1204:~# -after starting an instance on the host root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:24:42 2013 *filter :INPUT ACCEPT [90680:24989889] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [90482:24984752] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-compute-FORWARD - [0:0] :nova-compute-INPUT - [0:0] :nova-compute-OUTPUT - [0:0] :nova-compute-inst-35 - [0:0] :nova-compute-local - [0:0] :nova-compute-provider - [0:0] :nova-compute-sg-fallback - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-compute-INPUT -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-compute-FORWARD -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-compute-OUTPUT -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-compute-FORWARD -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-INPUT -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-inst-35 -m state --state INVALID -j DROP -A nova-compute-inst-35 -m state --state RELATED,ESTABLISHED -j ACCEPT -A nova-compute-inst-35 -j nova-compute-provider -A nova-compute-inst-35 -s 172.24.17.2/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A nova-compute-inst-35 -s 172.24.17.0/24 -j ACCEPT -A nova-compute-inst-35 -p tcp -m tcp --dport 22 -j ACCEPT -A nova-compute-inst-35 -p icmp -j ACCEPT -A nova-compute-inst-35 -j nova-compute-sg-fallback -A nova-compute-local -d 172.24.17.1/32 -j nova-compute-inst-35 -A nova-compute-sg-fallback -j DROP -A nova-filter-top -j nova-compute-local -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:24:42 2013 It seams that the rule that accepts dhcp packets is created once an instance is spawned. I will try the same thing on an centos64. Regards, Gabriel From: David Kang dk...@isi.edu To: Staicu Gabriel gabriel_sta...@yahoo.com Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:59 PM Subject: Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net ( openstack@lists.launchpad.net ) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:22 PM Subject: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
I think I found the solution. https://bugzilla.redhat.com/show_bug.cgi?id=889868 It was reported as a bug by RedHat. It also suggests a work-around. Thank you everyone. David - Original Message - What I have observed so far is... 1. nova-compute sends dhcp request 2. dhcp-server running on the Quantum node does not receive the request because of the firewall setting. I don't understand why quantum-dhcp-agent does not set up firewall properly. (Yes, all the openstack components are running on CentOS6.4 in our system.) Thanks, David - Original Message - Hi, This is very interesting..:) I am using openstack grizzly allinone with quantum/neutron. Look what I am observing. -before starting an instance on the server root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:22:55 2013 *filter :INPUT ACCEPT [62981:17142030] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [62806:17138989] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:22:55 2013 root@ubuntu1204:~# -after starting an instance on the host root@ubuntu1204:~# iptables-save -t filter # Generated by iptables-save v1.4.12 on Tue Jul 23 20:24:42 2013 *filter :INPUT ACCEPT [90680:24989889] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [90482:24984752] :nova-api-FORWARD - [0:0] :nova-api-INPUT - [0:0] :nova-api-OUTPUT - [0:0] :nova-api-local - [0:0] :nova-compute-FORWARD - [0:0] :nova-compute-INPUT - [0:0] :nova-compute-OUTPUT - [0:0] :nova-compute-inst-35 - [0:0] :nova-compute-local - [0:0] :nova-compute-provider - [0:0] :nova-compute-sg-fallback - [0:0] :nova-filter-top - [0:0] -A INPUT -j nova-compute-INPUT -A INPUT -j nova-api-INPUT -A INPUT -p gre -j ACCEPT -A FORWARD -j nova-filter-top -A FORWARD -j nova-compute-FORWARD -A FORWARD -j nova-api-FORWARD -A OUTPUT -j nova-filter-top -A OUTPUT -j nova-compute-OUTPUT -A OUTPUT -j nova-api-OUTPUT -A nova-api-INPUT -d 10.200.10.10/32 -p tcp -m tcp --dport 8775 -j ACCEPT -A nova-compute-FORWARD -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-INPUT -s 0.0.0.0/32 -d 255.255.255.255/32 -p udp -m udp --sport 68 --dport 67 -j ACCEPT -A nova-compute-inst-35 -m state --state INVALID -j DROP -A nova-compute-inst-35 -m state --state RELATED,ESTABLISHED -j ACCEPT -A nova-compute-inst-35 -j nova-compute-provider -A nova-compute-inst-35 -s 172.24.17.2/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT -A nova-compute-inst-35 -s 172.24.17.0/24 -j ACCEPT -A nova-compute-inst-35 -p tcp -m tcp --dport 22 -j ACCEPT -A nova-compute-inst-35 -p icmp -j ACCEPT -A nova-compute-inst-35 -j nova-compute-sg-fallback -A nova-compute-local -d 172.24.17.1/32 -j nova-compute-inst-35 -A nova-compute-sg-fallback -j DROP -A nova-filter-top -j nova-compute-local -A nova-filter-top -j nova-api-local COMMIT # Completed on Tue Jul 23 20:24:42 2013 It seams that the rule that accepts dhcp packets is created once an instance is spawned. I will try the same thing on an centos64. Regards, Gabriel From: David Kang dk...@isi.edu To: Staicu Gabriel gabriel_sta...@yahoo.com Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Tuesday, July 23, 2013 7:59 PM Subject: Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server Thank you for your suggestion. We are using Quantum/Neutron not nova-network. So, we don't use br100. (I believe you are using nova-network.) And the firewall rules that cause problem reside on the Quantum node not on the nova-compute node. I cannot find any rule for --dport 67 on my Quantum node. I used service iptables status command to check the firewall rules. Thanks, David - Original Message - Hi, Please can you look up in the iptables? Normally on a working openstack host the packets comming in the filter table in the input chain are directed to the nova-network-INPUT which has a rule to accept dhcp packets. On my setup is something like: -A INPUT -j nova-network-INPUT . . . -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT So I think you have to look somewhere else for your issue. Regards, Gabriel From: David Kang dk...@isi.edu To: openstack@lists.launchpad.net ( openstack@lists.launchpad.net
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be put in place for anti-spoofing. Since this is the network node you won't see them here. -Brian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
Thank you, Brian. David - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be put in place for anti-spoofing. Since this is the network node you won't see them here. -Brian -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server
A Redhat manual suggests the following rule to enable forwarding packets among VMs and external network. https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/2/pdf/Release_Notes/Red_Hat_OpenStack-2-Release_Notes-en-US.pdf iptables -t filter -I FORWARD -i qr-+ -o qg-+ -j ACCEPT iptables -t filter -I FORWARD -i qg-+ -o qr-+ -j ACCEPT iptables -t filter -I FORWARD -i qr-+ -o qr-+ -j ACCEPT But it doesn't work for me. Any suggestion? Thanks, David - Original Message - On 07/23/2013 12:22 PM, David Kang wrote: Hi, We are running OpenStack Folsom on CentOS 6.4. Quantum-linuxbridge-agent is used. By default, the Quantum node has the following entries in its /etc/sysconfig/iptables file. -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited With those two lines, VM cannot get IP address from the DHCP server running on the Quantum node. More specifically, the first line prevents a VM from getting IP address from DHCP server. The second line prevents a VM from talking to other VMs and external worlds. Is there a better way to make the Quantum network work well than just commenting them out? Since Quantum isn't adding them, and you want the system to act as a DHCP server and gateway, I think you have two choices: 1. Delete them 2. Craft rules to sit above them (using -I) to allow certain packets #2 gets tricky as you'll need to account for DHCP, metadata, etc. in the INPUT chain, and in the FORWARD chain you could maybe start by allowing all traffic from your bridge. You would need to do some more work there. I believe any DHCP iptables rules will be on the compute hosts, and will be put in place for anti-spoofing. Since this is the network node you won't see them here. -Brian -- -- Dr. Dong-In David Kang Computer Scientist USC/ISI ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum /Neutron
Imagining that nova creates that new instance in a different compute node, how quantum/neutron deal's with connectivity? Not sure what you are asking exactly. How connectivity between machines technically work depend on the configuration. e.g. you can setup Neutron to use/configure vlan's on the physical network or use GRE tunnels. Usually you can define a network within OpenStack and Neutron will handle setting up up the required components. I am reading a lot about Quantum /Neutron and i know that probably I need to use a load balancer like Atlas-LB, etc... Load-balancers are only needed when you scale out one application for regular communication between machines you won't need it. Cheers, Robert van Leeuwen ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum /Neutron
Hi RobertThank you for your help. I was a bit confused! Cheer's Claudio Marques claudio@onesource.pthttp://www.onesource.pt/ From: robert.vanleeu...@spilgames.com To: openstack@lists.launchpad.net Date: Mon, 8 Jul 2013 07:32:02 + Subject: Re: [Openstack] Quantum /Neutron Imagining that nova creates that new instance in a different compute node, how quantum/neutron deal's with connectivity? Not sure what you are asking exactly. How connectivity between machines technically work depend on the configuration. e.g. you can setup Neutron to use/configure vlan's on the physical network or use GRE tunnels. Usually you can define a network within OpenStack and Neutron will handle setting up up the required components. I am reading a lot about Quantum /Neutron and i know that probably I need to use a load balancer like Atlas-LB, etc... Load-balancers are only needed when you scale out one application for regular communication between machines you won't need it. Cheers, Robert van Leeuwen ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] quantum/neutron plugin development tutorial/guide
Hi Peter, So far I think this is your best bet: http://docs.openstack.org/developer/quantum/ There might be other documents, but none that I'm aware of. There's plenty of awesome people writing on their own blogs about openstack, and possibly about developing for Neutron. planet.openstack.org collects most of these resources. Nevertheless, I am working on some plugin development tutorials - as this is a question that is coming quite often. Hopefully I will have them read in a week or something like that. Salvatore On 26 June 2013 11:32, Peter Cheung mcheun...@hotmail.com wrote: Hi all Any good quantum/neutron plugin development tutorial/guide ? Thanks from Peter ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
