Re: [Openstack] [Quantum/Neutron] VM cannot get IP address from DHCP server

2013-07-24 Thread Brian Haley 
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

2013-07-24 Thread Brian Haley 
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

2013-07-24 Thread Brian Haley 
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

2013-07-23 Thread Brian Haley 
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] l3-agent iptables-restore: line 23 failed

2013-06-03 Thread Brian Haley 
On 06/01/2013 10:45 AM, Martin Mailand wrote:
 Hi List,
 
 if I add my routers gateway to an external network, I get an error in
 the l3-agent.log, about a failure in iptables-restore.
 As far as I know iptables-restore gets the information on stdin, how
 could I see the iptable rules which do not apply?
 How could I debug this further?

Have seen this in testing myself, not sure there's an easy solution besides
modifying the code to print the resultant filter after it's been modified,
something like this in the iptables_manager _apply() code:

 new_filter = self._modify_rules(current_lines,
 tables[table])
+for f in enumerate(new_filter):
+print f
 args = ['%s-restore' % (cmd)]

You'll get a lot of extra output in the logs but should be able to find the bad
line.

-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] Windows 2012 Server

2012-12-18 Thread Brian Haley 
On 12/18/2012 01:41 PM, Joe Warren-Meeks wrote:
 Hi guys,
 
 I've created a windows 2012 image and uploaded it ok. Pretty much following 
 this
 example:
 
 http://docs.openstack.org/trunk/openstack-compute/admin/content/creating-a-windows-image.html
 
 When I go to launch an instance, it works ok and nova list and nova show look
 healthy.
 
 If I VNC to it as soon as it starts to boot, I get to see the BIOS and then 
 the
 new Windows logo, but then the screen goes black and nothing seems to happen.
 Sending ctrl-alt-del elicits no response and it doesn't look like the network
 has DHCP'ed either.
 
 Has anyone else seen this and if so, any idea what I can do to fix it?

When you say it hasn't DHCP'ed, do you mean you never see the request from the
VM on the bridge when you run tdpcump?

-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] iptables rule missing in multi node setup

2012-10-25 Thread Brian Haley 
On 10/24/2012 06:55 PM, Qin, Xiaohong wrote:
 Hi All,
 
 In one of my lab setups, I found the following iptable rules are missing on 
 the
 controller node,
 
 Chain nova-compute-inst-3 (1 references)
 
 target prot opt source   destination
 DROP   all  --  anywhere anywhere state INVALID
 ACCEPT all  --  anywhere anywhere state
 RELATED,ESTABLISHED
 nova-compute-provider  all  --  anywhere anywhere
 ACCEPT udp  --  usxxcoberbmbp1.corp.emc.com  anywhere udp
 spt:bootps dpt:bootpc

All these are getting defined in virt/libvirt/firewall.py:instance_rules() - I'd
recommend looking at that function, but it should always get called at instance
startup.  That last one for the DHCP server might not get added if the DB
doesn't have the info though.

 ACCEPT all  --  10.0.0.0/24  anywhere

FLAGS.allow_same_net_traffic=true is probably not set, I think that defaults to
false for security reasons.

 ACCEPT icmp --  anywhere anywhere
 ACCEPT tcp  --  anywhere anywhere tcp dpt:ssh

Did you create a security group and add icmp and ssh using 'nova
secgroup-add-rule ...' ?

-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] floating IPs not routed from inside

2012-10-25 Thread Brian Haley 
On 10/25/2012 10:27 AM, Christian Parpart wrote:
 Hey all,
 
 we're having quite a few compute nodes with Essex installed and one central
 nova-network gateway.
 
 We now have a few floating IPs set up to route from the world through the
 gateway to these VMs.
 
 However, accessing these floating (public) IPs from inside a *tenant's VM*
 results into timeouts,
 but accessing the very same IP from a compute node (hypervisor) hosting those
 VMs actually does work.

Is the floating IP assigned to the VM trying to access itself?  I know there was
a change to fix that (search for hairpin_mode) and pretty sure it was in Essex.

 Now I'm a bit confused, it seems like a routing issue or iptables NAT thing 
 and
 would be really greatful
 if anyone can help me out with a hint. :)

What does tcpdump on the bridge show?  Are the packets going out and coming
back?  If not you need to start looking on other interfaces for it (or use -i
any), and if that doesn't help start looking at the iptables counters for the
rules associated with the instance.

 Is this known to not work or what do you need from me to actually understand 
 my
 issue a bit more?

It should work assuming there is a security group rule allowing it, which is
something else to look at.

-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] VM can't ping self floating IP after a snapshot is taken

2012-07-19 Thread Brian Haley 
On 07/17/2012 05:56 PM, Sam Su wrote:
 Hi,
 
 Just This always happens in Essex release. After I take a snapshot of my VM ( 
 I
 tried Ubuntu 12.04 or CentOS 5.8), VM can't ping its self floating IP; before 
 I
 take a snapshot though, VM can ping its self floating IP.
 
 This looks closely related to https://bugs.launchpad.net/nova/+bug/933640, but
 still a little different. In 933640, it sounds like VM can't ping its self
 floating IP regardless whether we take a snapshot or not.
 
 Any suggestion to make an easy fix? And what is the root cause of the problem?

It might be because there's a missing _enable_hairpin() call in the reboot()
function.  Try something like this...

nova/virt/libvirt/connection.py, _hard_reboot():

 self._create_new_domain(xml)
+self._enable_hairpin(instance)
 self.firewall_driver.apply_instance_filter(instance, network_info)

At least that's what I remember doing myself recently when testing after a
reboot, don't know about snapshot.

Folsom has changed enough that something different would need to be done there.

-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] Dhcp lease errors in vlan mode

2012-05-14 Thread Brian Haley 
On 05/14/2012 01:46 PM, Vishvananda Ishaya wrote:
 TL;DR
 
 To fix issues with failed dhcp leases in vlan mode, upgrade to dnsmasq 
 2.6.1[1]

+1 to upgrading (being the one that was bitten by the problem last year).

-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] [Netstack] nova-manage network creation question

2012-03-15 Thread Brian Haley 
On 03/15/2012 11:51 AM, David Lapsley wrote:
 On Mar 15, 2012, at 11:43 AM, Yapeng Wu wrote:
 
 Hello,

 I followed the quantum-admin-guide document to create the network by using: 
 nova-manage network create --label=tenant-private
 --fixed_range_v4=192.168.1.0/24 --project_id= --priority=1
 --gateway=192.168.1.254

 I got error caused by:
 https://github.com/openstack/nova/blob/master/nova/network/quantum/manager.py#L194


 Could some one confirm that if Quantum network ONLY supports gateway address:
 x.x.x.1 format?
 
 Hi Yapeng:
 
 That is correct. We explicitly check in 
 nova.network.quantum.manager.QuantumManager
 
 if gateway is not None and len(gateway)  0:  
   
 if gateway.split('.')[3] != '1':  
   
 raise Exception(_(QuantumManager requires a valid (.1)  

gateway address.))  

Can you just delete that check?  I'm running a Diablo cluster with a /27 where
.129 is the gateway (it's the lowest address in the subnet), which is a
perfectly valid IP address :)

-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] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same

2012-03-14 Thread Brian Haley 
On 03/14/2012 01:50 PM, Justin Santa Barbara wrote:
 We recently changed the MAC address assigned to guests so that they started 
 with
 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses 
 changing
 on the bridge device as machines are shut down (because supposedly the bridge
 grabs the lowest MAC address numerically):
 https://bugs.launchpad.net/nova/+bug/921838

I believe the bridge changing it's MAC address is a known issue, fixed in later
versions of libvirt, see https://bugzilla.redhat.com/show_bug.cgi?id=609463

Absent of that fix, the best solution I've found is:

- Create a dummy tap device, and attach it to the bridge

$ ip tuntap add dev tap_brfoo mode tap
$ brctl addif brfoo tap_brfoo

- Set it's MAC to $MAC_FOO (whatever you choose)

$ ip link set tap_brfoo address $MAC_FOO

- And the bridge's MAC too

$ ip link set brfoo address $MAC_FOO

This should anchor the bridge's MAC address to $MAC_FOO for the life of the 
bridge.

You could set the bridge in promisc mode if you don't like the above, but then
you'll start seeing packets duplicated, yuck.

-Brian

 However, it looks we bumped into some similar behavior done by libvirt: It 
 also
 sets the first byte to 0xfe for the host network device, in the hope of 
 avoiding
 the same bug.  Thus, with the patch, the host vnetX and the guest eth0 have 
 the
 same MAC address.  I think this breaks FlatManager, but I don't know why, and 
 I
 really don't know why it wouldn't break other modes, and I'm hoping a network
 guru can explain/confirm.
 
 When they have the same MAC address, ARP resolution isn't working: the guest
 issues an ARP request for the gateway, on the host I can see the ARP request 
 and
 response, but the guest doesn't appear to see/accept the ARP response and so 
 it
 just keeps retrying.
 
 This message appears in dmesg:
 [ 2199.836114] br100: received packet on vnet1 with own address as source 
 address
 
 I'm guessing that 'address' means 'MAC address', and this is why ARP is 
 failing,
 it sounds like the bridge might be dropping the packet.
 
 Changing to 0x02, or 0xfc does fix it (although my arithmetic was wrong, and
 vishy points out we should use 0xfa instead of 0xfc).
 
 Networking guru questions:
 
 * Does this explanation make sense?
 * Why didn't other networking modes break?
 * Should we simply revert the change and go back to 0x02?
 * Should we switch to 0xfa to try to avoid the bridge interface problems?
Or does it simply not matter if libvirt is changing the MAC for us?
 * Can anyone explain https://bugs.launchpad.net/nova/+bug/908194 ?  Is 
 that
   bug because there was no 'real' device on the bug reporter's bridge?
 
 
 Vishy has proposed this patch, which looks good to me:
 https://review.openstack.org/#patch,sidebyside,5351,1,nova/utils.py
 
 
 Justin
 
 
 
 ___
 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] Duplicate ICMP due to public interface bridge being placed in promiscus mode

2011-10-14 Thread Brian Haley 
On 10/14/2011 08:59 AM, Shyam Kaushik wrote:
 *Hi Vish,* 
 
 In our openstack deployment we observe this:
 
 Since linux_net.py/initialize_gateway_device()
 http://linux_net.py/initialize_gateway_device() does this
 
 # NOTE(vish): If the public interface is the same as the
 # bridge, then the bridge has to be in promiscuous
 # to forward packets properly.
 
 if(FLAGS.public_interface == dev):
 _execute('ip', 'link', 'set',
  'dev', dev, 'promisc', 'on', run_as_root=True)
 
 
 Any VM spawned on the cloud controller node if it sends an ICMP ping to an
 external network gets duplicate replies (i.e. there are 2 replies for the same
 ICMP request). For VM’s spawned on any other non-cloud controller this doesn’t
 happen.
 
 If we turn of promiscus mode on the bridge, the VM on cloud controller doesn’t
 see the duplicate replies, but VM’s on non-cloud controller cannot reach
 external network.
 
 Question to you is, is this duplicate ICMP replies expected for VM’s running 
 on
 cloud controller due to above logic?

I've seen duplicate packets in one of our configs, if I explain how maybe it
will help here.

1. Create a bridge, and set the MAC with /sbin/ip, for example:

'ip link set dev br123 address 00:00:00:00:11:11'

2. Start a VM and attach it to that bridge.  Try to communicate with it, but you
can't, since the MAC of the bridge doesn't match the MAC of any device attached
to it.

3. Set the bridge in promiscuous mode - 'ip link set dev br123 promisc on'.
Things work, but the side-effect is duplicated packets.

There's a RHEL but against libvirt that talks about it, and I believe there's a
patch upstream that fixes it by adding a dummy tap device (so the bridge and one
device share the same MAC), which lets you turn-off promisc.

https://bugzilla.redhat.com/show_bug.cgi?id=609463

So I think the answer is that if you want a stable MAC on a bridge that doesn't
match an existing tap device, turning-on promisc is a bad idea to make things 
work.

Hope that helps,

-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