It seems that you're using OpenvSwitch, which is not my case... Also, I forgot to say, I'm on Ubuntu Trusty with Juno Cloud Archive on top of it...
But thanks anyway! :-) On 8 July 2015 at 03:22, italy1 <[email protected]> wrote: > Try this > > root@build network-scripts]# more ifcfg-eno1 > TYPE=Ethernet > ONBOOT=yes > DEVICE=eno1 > TYPE=OVSPort > DEVICETYPE=ovs > OVS_BRIDGE=mgmt-br > PROMISC=yes > > > > Remo > > > > On Tue, Jul 7, 2015 at 10:57 PM -0700, "Martinx - ジェームズ" < > [email protected]> wrote: > > Hello Remo, >> >> Yes, I checked it. No ebtables or iptables rules here (no security >> groups, no firewalls)... I have "ACCEPT" for everything. >> >> Also, I disabled "rp_filter" and all files under "/proc/sys/net/bridge" >> subdir have "0". >> >> I did not find the root of this problem... I'm about to gave up on >> LinuxBridges (shot in the dark)... >> >> - The packets arrives at the "brq44b54ac7-c4" bridge but not at the >> "tap0b5eb746-ed" tap. >> >> Instance #2 have (doesn't work): >> >> ---- >> <interface type='bridge'> >> <mac address='fa:16:3e:d8:81:b6'/> >> <source bridge='brq44b54ac7-c4'/> >> <target dev='tap0b5eb746-ed'/> >> .... >> </interface> >> ---- >> >> - The packets arrives at the "brqfac384d5-cd" bridge AND at the >> "tap47417a6d-3b" tap. >> >> Instance #1 have (works as expected): >> >> ---- >> <interface type='bridge'> >> <mac address='fa:16:3e:5f:9b:8d'/> >> <source bridge='brqfac384d5-cd'/> >> <target dev='tap47417a6d-3b'/> >> .... >> </interface> >> ---- >> >> The only difference between "Instance #1" and "Instance #2", is the VLAN >> tag, nothing less, nothing more. I don't know why it works for #1, but not >> for #2. >> >> Also, I'm using a Heat template to start those environments, and of >> course, the only difference is the VLAN tag inside of each Heat template. >> So, I'm sure that both "stacks" have the very same setup. >> >> BTW, the "brctl showmacs" have the Instance's MAC listed there as >> expected. >> >> Thank you for your reply! >> >> Best, >> Thiago >> >> On 8 July 2015 at 00:56, Remo Mattei <[email protected]> wrote: >> >>> did you check your br iptables? >>> (they are called etables) here is a link it may help you. >>> >>> http://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html >>> >>> Remo >>> >>> Martinx - ジェームズ <[email protected]> >>> July 7, 2015 at 19:30 >>> I don't know if it will help but, tcpdump shows: >>> >>> NOTE: I re-created the "stack", so, the IDs have changed but, the >>> problem remains... >>> >>> For "brq44b54ac7-c4": >>> >>> --- >>> time tcpdump -c 100 -eni brq44b54ac7-c4 >>> >>> ...... NORMAL TRAFFIC (I guess).... >>> ...... >>> 02:12:38.415680 1c:df:0f:ef:bd:1b > 1c:df:0f:ef:b9:1b, ethertype IPv4 >>> (0x0800), length 363: 192.168.4.66.62521 > 192.168.13.16.18457: Flags [P.], >>> seq 439562052:439562361, ack 3427842886, win 22919, length 309 >>> 02:12:38.417826 1c:df:0f:ef:b9:1b > 1c:df:0f:ef:bd:1b, ethertype IPv4 >>> (0x0800), length 235: 192.168.13.16.18457 > 192.168.4.101.63781: Flags >>> [P.], seq 54:235, ack 1727, win 513, length 181 >>> ...... >>> >>> real 0m0.874s >>> user 0m0.004s >>> sys 0m0.000s >>> --- >>> >>> For its "tap0b5eb746-ed": >>> >>> --- >>> .... >>> 02:14:06.915717 1c:df:0f:ef:b9:1b > 01:00:5e:00:00:05, ethertype IPv4 >>> (0x0800), length 134: 192.168.25.2 > 224.0.0.5: OSPFv2, Hello, length 84 >>> 02:14:08.505713 f4:ac:c1:ba:7b:83 > 01:00:0c:cc:cc:cd, 802.3, length 64: >>> LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui >>> Cisco (0x00000c), pid PVST (0x010b): STP 802.1w, Rapid STP, Flags [Learn, >>> Forward], bridge-id 6a4d.f4:ac:c1:ba:7b:80.8003, length 42 >>> ... >>> >>> real 2m20.069s >>> user 0m0.004s >>> sys 0m0.016s >>> --- >>> >>> "brctl show" returns: >>> >>> --- >>> ... >>> brq44b54ac7-c4 8000.ecf4bbd0417b no eth2.101 >>> tap0b5eb746-ed >>> ... >>> --- >>> >>> >>> The first tcpdump takes about 1 second, the second, more than 2 minutes! >>> And the lines are very different... >>> >>> I'm stucked... Since the "Instance #1" works, and its "duplicated >>> configuration - Instance #2", doesn't... I'm only changing the vlan id! >>> :-/ >>> >>> Switch configurations are okay, since I can see the packets arriving @ >>> eth2 normally. >>> >>> Maybe it is time to go back to OVS instead of Linux Bridges... :-( >>> >>> Thanks, >>> Thiago >>> >>> >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : [email protected] >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >>> >>> !DSPAM:1,559c8f3943821478921271! >>> Martinx - ジェームズ <[email protected]> >>> July 7, 2015 at 17:37 >>> On 7 July 2015 at 21:00, Martinx - ジェームズ <[email protected]> >>> wrote: >>> >>> Also, I'm not using any kind of Security Groups or Firewall, my >>> "ml2_conf.ini" looks likes this: >>> >>> --- >>> ....... >>> [ml2_type_flat] >>> flat_networks = external >>> >>> [ml2_type_vlan] >>> network_vlan_ranges = physvlan2 >>> >>> [securitygroup] >>> enable_security_group = False >>> enable_ipset = False >>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver >>> >>> [agent] >>> tunnel_types = vxlan >>> >>> [vxlan] >>> enable_vxlan = True >>> local_ip = 10.0.1.31 >>> l2_population = True >>> >>> [l2pop] >>> agent_boot_time = 180 >>> >>> [linux_bridge] >>> physical_interface_mappings = external:eth1,vxlan:dummy0,physvlan2:eth2 >>> --- >>> >>> Nova also doesn't make use of any firewall driver. So, the iptables >>> rules here are just the bare minimal. >>> >>> My eth0 is the first network interface, it is the default gateway of the >>> host itself (Horizon, APIs, etc, runs on top of eth0). >>> >>> The vxlan on top of a dummy0 interface works fine for this "all-in-one" >>> deployment. >>> >>> The Instances attached to the "physvlan2:100:101" have two interfaces, >>> vritual eth0 is vxlan, virtual eth1 is attached to physvlan2 (100 or 101), >>> they can ping the Internet without problems. >>> >>> Thanks, >>> Thiago >>> !DSPAM:1,559c73b7319121044113558! >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : [email protected] >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >>> >>> !DSPAM:1,559c73b7319121044113558! >>> Martinx - ジェームズ <[email protected]> >>> July 7, 2015 at 17:00 >>> >>> BTW, the symptoms are weird... After a reboot (and starting the Intance >>> #2 with bigger txqueue from the beginning), I'm not seeing the packets >>> being dropped @ the tap interface but, they to not arrive anyway... >>> >>> I would love to know what can cause the packets arriving the "brqXXX-yy" >>> interface but not its "tapXXX-YY"... Very weird... >>> >>> Thanks in advance! >>> !DSPAM:1,559c69fe301462031411247! >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : [email protected] >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >>> >>> !DSPAM:1,559c69fe301462031411247! >>> Martinx - ジェームズ <[email protected]> >>> July 7, 2015 at 16:51 >>> Guys, >>> >>> I have an "all-in-one" OpenStack Juno setup, with LinuxBridges, where >>> I'm planning to use it with two tagged networks. >>> >>> Like this: >>> >>> For "Instance #1", "brctl show" returns: >>> >>> ---- >>> root@openstack-1:~# brctl show >>> bridge name bridge id STP enabled interfaces >>> >>> brqfac384d5-cd 8000.ecf4bbd0417a no eth2.100 >>> >>> tap47417a6d-3b >>> ---- >>> >>> For "Instance #2", "brctl show" returns: >>> >>> ---- >>> bridge name bridge id STP enabled interfaces >>> >>> brq50721b16-1c 8000.ecf4bbd0417a no eth2.101 >>> >>> tap15f2960f-54 >>> ---- >>> >>> "Instance #1" works as expected, I can see the the packets arriving >>> inside the Instance attached to the TAP "tap15f2960f-54". >>> >>> Also, I can run "tcpdump -c 100 -eni tap15f2960f-54" or "tcpdump -c 100 >>> -eni brq50721b16-1c" to see the packets. >>> >>> BUT, my second "Instance #2" doesn't receive the packets!! >>> >>> >>> # "Wire" >>> >>> If I run "tcpdump -c 100 -eni eth2", I can see both "vlan 100" and "vlan >>> 101" packets arriving. >>> >>> # vlan 100 - okay >>> If I run "tcpdump -c 100 -eni brqfac384d5-cd", as I said before, I can >>> see the packets. >>> >>> If I run "tcpdump -c 100 -eni tap47417a6d-3b", as I said before, I can >>> see the packets. >>> >>> # vlan 101 - not okay >>> If I run "tcpdump -c 100 -eni brq50721b16-1c", I can see the packets. >>> >>> If I run "tcpdump -c 100 -eni tap15f2960f-54", BOOM! I am unable to see >>> the packets!! >>> >>> -- >>> >>> >>> Why the packets are being dropped between "brq50721b16-1c" and >>> "tap15f2960f-54" ??? >>> >>> "ifconfig tap15f2960f-54" shows packets being dropped. >>> >>> "ifconfig tap47417a6d-3b" shows 0 packets being dropped. >>> >>> >>> I already double checked everything!! Also, I tried to raise txqueue, >>> checked ebtabled, iptables... I have no clue about whats going on here... >>> >>> I really appreciate any help! >>> >>> Thanks! >>> Thiago >>> !DSPAM:1,559c69f7301311341913631! >>> _______________________________________________ >>> Mailing list: >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> Post to : [email protected] >>> Unsubscribe : >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>> >>> >>> !DSPAM:1,559c69f7301311341913631! >>> >>> >>> >> !DSPAM:1,559cbbac122991591116980! >> >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
