Initail ARP is broadcast packet. We support Broadcast and Multicast. I recommend that you should not enable unknown unicast flooding even if you go for 2.2.
Regards -Harshad On Jun 18, 2015, at 6:36 AM, Dan Houtz <[email protected]> wrote: > Hi Harshad, > > This is good info and in line with what I had concluded reading through > recent git commits. It definitely sounds like we'll need 2.2 in our > environment as it is all bare metal and not provisioned by Openstack in any > way - we are really just looking to use Contrail as a controller for hardware > VETPs. > > I will be honest that I don't fully understand how I ever learn ARP entries > initially if unknown unicast flooding isn't supported but I definitely have > intermittent ARP on my end hosts. > > -Dan > > On Thu, Jun 18, 2015 at 8:02 AM, Harshad Nakil <[email protected]> wrote: > Hi Dan, > > There is problem of ARP time out in bare metal. Since we do not support > flooding of unknown unicast. MAC age out in QFX can happen before ARP > timeout in Baremetal. This will result in blackhole of traffic for that MAC. > > Work around is to set QFX MAC age out time to be larger than ARP age out in > Baremetal. See if this works and then you don’t have to upgrade. > > IN 2.2 we have per VN knob to support flooding for unknown unicast in > Baremetal case. > > Regards > -Harshad > > On Jun 17, 2015, at 7:17 PM, Dan Houtz <[email protected]> wrote: > >> Hi Jakub, >> >> Thank you for the reply. To clarify a bit, we are currently running Contrail >> 2.1 however we're seeing issues with unknown unicast for bare metal servers >> with ARP often failing. I'm curious if we need to move to something newer >> then 2.1 as I see a lot of recent commits that look to improve this. It's >> all proof of concept at this point so I don't mind running unrelaesed code. >> >> We are using: >> QFX5100-48S running 14.1X53-D15.2. >> MX80 running a daily build of 14.2 to get VXLAN/EVPN support. >> >> On Wed, Jun 17, 2015 at 1:46 AM, Jakub Pavlík <[email protected]> >> wrote: >> Hi Dan, >> >> if you want to deploy OpenContrail 2.1 with Juno, you need to do several >> steps: >> >> 1) install contrail-nova-vif together with nova-api >> >> 2) modify /usr/lib/python2.7/dist-packages/nova_contrail_vif/contrailvif.py >> >> https://raw.githubusercontent.com/pupapaik/contrail-nova-vif-driver/R2.1/nova_contrail_vif/contrailvif.py >> >> 3) After you have to set contrail api class at nova.conf >> >> network_api_class = nova_contrail_vif.contrailvif.ContrailNetworkAPI >> >> The reason is that between icehouse and juno was replaced nova_vif_driver >> for network_api_class. >> >> Jakub >> Odesílate: Dev [[email protected]] za uživatele Dan Houtz >> [[email protected]] >> Odesláno: 16. června 2015 21:56 >> Komu: [email protected] >> Předmět: [opencontrail-dev] BMS / Unknown Unicast issues >> >> Hi, >> >> Couple questions regarding Contrail and BMS support... >> >> We are currently in the POC stages of a build-out that would be primarily >> bare metal based using Contrail to configure interfaces on QFX switches >> acting as hardware VETPs and building the proper EVPN routing instances on >> MX routers. The use case is to provision on demand L2 networks between bare >> metal dedicated servers throughout our datacenter (tied together via L3 >> leaf/spine underlay) for customers. >> >> Currently we have Contrail 2.1 deployed and it is properly configuring >> switch ports via OVSDB and seems to be distributing known macs properly >> between TOR switches and MX gateways. However, we are seeing a ton of issues >> with ARP/unknown unicast. It some cases it seems to work but not in any >> reliable manner. >> >> Reading through commits on github it looks like there has been a lot of work >> done recently on this front which leads me to a few questions: >> >> 1. Is our setup supported at all in 2.1 or will we need 2.2? >> 2. If 2.2 is required, does anyone have any pointers on successfully >> installing from master branch along with Juno? I've been able to >> successfully install this combo but am seeing the following errors in >> nova-compute logs when spinning up a VM instance: >> "NovaException: Unexpected vif_type=vrouter". I imagine this is due to the >> changing in architecture with Neutron plugins when moving to Juno. I also >> tried doing a devstack install with Icehouse but ran into other issues >> causing openstack to not even install as shown here: >> http://pastebin.com/5MQU6zJF >> 3. Ultimately I'm curious if we're on the right track and if anyone has any >> pointers on getting a more recent build running. Or, should we just wait for >> 2.2 official release assuming it's still planned for this month? >> >> Thanks! >> Dan H. >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org > >
_______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
