openstack team mailing list archive

[David Kang <dkang@xxxxxxx>]

  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