Nischal,
Should I be able to just grab latest db.py and physical_router_config.py
from github and drop it in place under
/usr/lib/python2.7/dist-packages/device_manager? Trying this but when I
restart device-manager it is logging the following and crashing over and
over:
07/21/2015 12:39:04 PM [contrail-ctrl2:DeviceManager:Config:0]: Warning!
InvalidRequestException(why='Keyspace names must be case-insensitively
unique ("config_db_uuid" conflicts with "config_db_uuid")')
07/21/2015 12:39:04 PM [contrail-ctrl2:DeviceManager:Config:0]: Warning!
InvalidRequestException(why='Cannot add already existing column family
"obj_uuid_table" to keyspace "config_db_uuid"')
07/21/2015 12:39:04 PM [contrail-ctrl2:DeviceManager:Config:0]: Warning!
InvalidRequestException(why='Cannot add already existing column family
"obj_fq_name_table" to keyspace "config_db_uuid"')
Thanks!
Dan
On Fri, Jul 17, 2015 at 11:34 AM, Nischal Sheth <[email protected]> wrote:
>
> Hi Dan,
>
> Have confirmed that EVPN VXLAN is not available in 15.1R1.
> The release notes will be fixed.
>
> -Nischal
>
> On Jul 16, 2015, at 1:40 PM, Dan Houtz <[email protected]> wrote:
>
> Ok. 15.1R1 does list it in the release notes but perhaps that's an
> error:
>
> *EVPN with VXLAN data plane encapsulation (MX Series)*—Starting in Junos
> OS Release 15.1, MX Series routers can use EVPN with VXLAN encapsulation to
> provide Layer 2 connectivity for end stations within a Virtualized Network
> (VN) created by the Contrail virtualization software. The end stations
> consist of virtual hosts connected to the virtualized server, and
> non-virtualized bare-metal servers connected to top-of-rack platforms. MX
> Series routers also function as default gateways for the inter-VN traffic
> among end stations that belong to different VNs. EVPN is used as a Layer 2
> overlay solution to provide Layer 2 connections over the IP underlay for
> the end points within a VN whenever Layer 2 connectivity is required by an
> end station.
>
>
> http://www.juniper.net/techpubs/en_US/junos15.1/information-products/topic-collections/release-notes/15.1/topic-83366.html#jd0e4018
>
> Guess I could just try it :)
>
> -Dan
>
> On Thu, Jul 16, 2015 at 11:45 AM, Nischal Sheth <[email protected]>
> wrote:
>
>>
>> I don't think 15.1R1 has the EVPN VXLAN code.
>>
>> -Nischal
>>
>> On Jul 16, 2015, at 9:41 AM, Dan Houtz <[email protected]> wrote:
>>
>> Hi Nischal,
>>
>> Thanks for this. I will try and test this today.
>>
>> On another note, I'm curious if the 15.1R1 Junos release supports latest
>> Contrail 2.2? If so, it might make sense to move from our daily build of
>> 14.2 to something that's official supported.
>>
>> -Dan
>>
>> On Wed, Jul 15, 2015 at 4:04 PM, Nischal Sheth <[email protected]>
>> wrote:
>>
>>>
>>> Hi Dan,
>>>
>>> Here's config snippets for how traffic would cross between VRF and
>>> inet.0.
>>> I haven't included the configs for virtual-switch (i.e. L2) instances
>>> for public1
>>> and public2. In the example below, irb1 and irb2 are the
>>> routing-interfaces
>>> the BDs in the virtual-switch instances.
>>>
>>> 10.1.1/24 is subnet assigned to public1
>>> 10.1.2/24 is subnet assigned to public2
>>>
>>> I've also not included detailed VRF configs for public1 and public2
>>> (e.g. vrf
>>> import and export policies), just the portions needed for routing.
>>>
>>> Let me know if you have questions.
>>>
>>> -Nischal
>>>
>>> [edit interfaces]
>>> + irb {
>>> + unit 1 {
>>> + family inet {
>>> + address 10.1.1.254/24;
>>> + }
>>> + }
>>> + unit 2 {
>>> + family inet {
>>> + address 10.1.2.254/24;
>>> + }
>>> + }
>>> + }
>>>
>>> [edit forwarding-options family inet filter]
>>> + input redirect-to-public-vrfs;
>>>
>>> [edit firewall]
>>>
>>> + filter redirect-to-public-vrfs {
>>> + /* redirect traffic to public1 */
>>> + term t1 {
>>> + from {
>>> + destination-address {
>>> + 10.1.1.0/24;
>>> + }
>>> + }
>>> + then {
>>> + routing-instance public1;
>>> + }
>>> + }
>>> + /* redirect traffic to public2 */
>>> + term t2 {
>>> + from {
>>> + destination-address {
>>> + 10.1.2.0/24;
>>> + }
>>> + }
>>> + then {
>>> + routing-instance public2;
>>> + }
>>> + }
>>> + /* continue lookup in current table (inet.0) */
>>> + term default {
>>> + then accept;
>>> + }
>>> + }
>>>
>>> [edit routing-instances]
>>> + public1 {
>>> + interface irb.1;
>>> + routing-options {
>>> + static {
>>> + route 0.0.0.0/0 next-table inet.0;
>>> + }
>>> + }
>>> + }
>>> + public2 {
>>> + interface irb.2;
>>> + routing-options {
>>> + static {
>>> + route 0.0.0.0/0 next-table inet.0;
>>> + }
>>> + }
>>> + }
>>>
>>>
>>> On Jul 14, 2015, at 12:45 AM, Dan Houtz <[email protected]> wrote:
>>>
>>> Hi Nischal,
>>>
>>> Thank you for the detailed reply. I may have a few follow up questions
>>> in the coming days but for now I only have two:
>>>
>>> 1. Do you have an example config of what you are thinking DM might push
>>> to the MX to route between VRF and inet.0? Even if I could apply that by
>>> default right now it would be helpful.
>>>
>>> 2. Any ETA on the bugs you referenced and will there be a reasonably
>>> easy to make use of these prior to official 2.21 packages being released?
>>>
>>> Thanks!
>>> Dan
>>> On Jul 14, 2015 12:29 AM, "Nischal Sheth" <[email protected]> wrote:
>>>
>>>>
>>>> On Jul 9, 2015, at 12:25 PM, Dan Houtz <[email protected]> wrote:
>>>>
>>>> Hi Nischal,
>>>>
>>>>
>>>> Hi Dan,
>>>>
>>>> Pleas see inline.
>>>>
>>>>
>>>> I'll need to re-read through the bug text a few more times to fully
>>>> grasp as I have yet to totally understand the difference between L2 and
>>>> L2/L3 networks from the Contrail perspective. It seems all networks we
>>>> create via the Contrail webui are L2/L3. I see there is an L2 option
>>>> when configured a port but this requires me to create IP/MAC mappings which
>>>> doesn't apply to us. Perhaps this is just a limitation of the UI and I
>>>> could accomplish L2 only via API calls?
>>>>
>>>>
>>>> I gather from your follow-up email on DHCP that you have a good
>>>> handle on the
>>>> difference between L2 and L2/L3 in Contrail now. In terms of DM, the
>>>> difference
>>>> should be that DM will only configure a virtual-switch routing-instance
>>>> for L2 only
>>>> VNs, whereas it would configure both virtual-switch and vrf
>>>> routing-instances for
>>>> L2+L3 VNs. Further, we're also adding a L3 only mode where DM will
>>>> create only
>>>> a vrf.
>>>>
>>>>
>>>> In our use case we are doing overlays between all bare metal servers -
>>>> we do not have any Openstack/VM elements. We will also generally be
>>>> assigning publicly routed IP's directly to all servers and will not require
>>>> NAT. There may be cases where customers need to build 'backnets' with
>>>> private IP addresses. I suspect most of these to be islands where routing
>>>> don't be required but we may need to extend these to our MXs for routing
>>>> between private networks belonging to a specific customer.
>>>>
>>>>
>>>> Please see below.
>>>>
>>>>
>>>> Based on the above thoughts I believe we will probably have 3 primary
>>>> scenarios:
>>>>
>>>> 1. Create a 'public' virtual network in Contrail, assign a public IP
>>>> block to it, and have it be publicly routable - prefixes of VN exported
>>>> into inet.0 and default from inet.0 imported into routing instance. It
>>>> seems like creating a network, marking it as external, and not creating
>>>> floating IPs would indicate this type of setup but I haven't actually
>>>> looked at how Contrail does NAT/Floating IPs/etc.
>>>>
>>>>
>>>> This should have worked, but DM currently treats external VNs as L3
>>>> only VNs and
>>>> does not create a virtual-switch routing-instance. The bug I created
>>>> earlier tracks this
>>>> issue.
>>>>
>>>> https://bugs.launchpad.net/juniperopenstack/+bug/1472699
>>>>
>>>> The bug also describes the routing configuration to allow the VN
>>>> subnet to be added
>>>> or imported into inet.0 and traffic redirection from inet.0 to the VRF.
>>>> We need to work
>>>> around some JUNOS quirks wherein 2 route tables cannot have static
>>>> routes that
>>>> point to each other. I've assumed that the VRF will have a static
>>>> default that points to
>>>> inet.0. If you're doing manual configuration, you could use rib-groups
>>>> to import default
>>>> route from BGP/OSPF into the VRF, but DM uses static default with a
>>>> table next-hop
>>>> since it doesn't want to assume anything about routing protocol being
>>>> used for inet.0.
>>>>
>>>> Traffic destined to the VRF subnet will be redirected from inet.0 to
>>>> the VRF using filter
>>>> based forwarding by applying an input filter on inet.0. This filter
>>>> matches the destination
>>>> subnet and redirects traffic to the appropriate VRF.
>>>>
>>>>
>>>>
>>>> 2. Create a 'private' virtual network in Contrail, assign a private IP
>>>> block to it and have it be routable only between other networks belonging
>>>> to the tenant it is created under. I think this would generally be an all
>>>> or nothing thing - every private network belonging to a tenant can reach
>>>> any other private network belonging to that tenant. I could see someone
>>>> wanting more fine grain control but probably not super common and would
>>>> mostly look at inline firewall chaining or policy to control this
>>>>
>>>>
>>>> This is supported today, and is finer grained than all or nothing. You
>>>> can use policy to
>>>> allow traffic between specific VNs. Matches on L4 information are not
>>>> yet supported.
>>>>
>>>> 3. Create a 'backnet' virtual network in Contrail, assign no IP's -
>>>> simply extended L2 to appropriate bare metal servers. Servers could be IP'd
>>>> adhoc without Contrail being aware at all. Network would be an island
>>>> with no config existing on MX.
>>>>
>>>>
>>>> This should work today (modulo issues you found with Praveen) if you
>>>> do not extend
>>>> such VNs to the MXs. It will be further refined as part of the fix for
>>>> bugs 1472699 and
>>>> 1471637. If a VN is L2 only, you will not need to configure a subnet
>>>> for it.
>>>>
>>>>
>>>> Let me know if the above makes any sense :)
>>>>
>>>>
>>>> Yes, the requirements sound reasonable and I think that you should be
>>>> able to achieve
>>>> what you are looking once 1472699 and 1471637 are fixed.
>>>>
>>>> -Nischal
>>>>
>>>> Thanks!
>>>>
>>>> On Wed, Jul 8, 2015 at 11:58 AM, Nischal Sheth <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi Dan,
>>>>>
>>>>> https://bugs.launchpad.net/juniperopenstack/+bug/1472699
>>>>>
>>>>> This needs some changes to the device manager.
>>>>>
>>>>> Could you please take a look and provide feedback on whether
>>>>> the solution outlined will meet your requirements?
>>>>>
>>>>> Thanks,
>>>>> Nischal
>>>>>
>>>>> On Jul 7, 2015, at 5:54 PM, Dan Houtz <[email protected]> wrote:
>>>>>
>>>>> Unless I'm overlooking something, It doesn't look like
>>>>> device-manager builds the config needed to import a default route from
>>>>> inet.0 into the VN's routing instance or to import the routing instance's
>>>>> prefix into inet.0. In our case we are assigning public IP's directly to
>>>>> the bare metal servers and do not require Is it possible for
>>>>> device-manager
>>>>> to configure the import/export policies to make these routes available?
>>>>>
>>>>> Thanks!
>>>>> Dan
>>>>>
>>>>> On Tue, Jul 7, 2015 at 4:55 PM, Nischal Sheth <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi Dan,
>>>>>>
>>>>>> This confirms that the problem is related to route target
>>>>>> filtering. It's
>>>>>> a JUNOSism that bgp.rtarget.0 routes are resolved using inet.3 by
>>>>>> default.
>>>>>>
>>>>>> Using gr-* interfaces will result in creation of inet.3 routes to
>>>>>> the CN IP
>>>>>> since DM adds CN IPs to the dynamic-tunnel destination network list.
>>>>>> In this case the gr tunnels wouldn't be used in the data plane since
>>>>>> you
>>>>>> are using VXLAN. If you also have VMs, MX will use gr tunnels for
>>>>>> data traffic to vrouters.
>>>>>>
>>>>>> If it's undesirable to create gr- tunnels, you have 2 options:
>>>>>>
>>>>>> 1) You can configure JUNOS to resolve bgp.rtarget.0 over inet.0
>>>>>> instead
>>>>>> of inet.3 using something like:
>>>>>>
>>>>>> root@a3-mx80-1# show routing-options resolution
>>>>>> rib bgp.rtarget.0 {
>>>>>> resolution-ribs inet.0;
>>>>>> }
>>>>>>
>>>>>> 2) Alternately, you can add add static routes with discard nexthop
>>>>>> to CN
>>>>>> ip addresses into inet.3.
>>>>>>
>>>>>> root@a3-mx80-1# show routing-options rib inet.3
>>>>>> static {
>>>>>> route 10.10.210.140/32 discard;
>>>>>> }
>>>>>>
>>>>>> [edit]
>>>>>>
>>>>>> I would recommend the latter.
>>>>>>
>>>>>> -Nischal
>>>>>>
>>>>>> On Jul 7, 2015, at 2:36 PM, Dan Houtz <[email protected]> wrote:
>>>>>>
>>>>>> root@gw2z0> show route table bgp.rtarget.0
>>>>>>
>>>>>> bgp.rtarget.0: 2 destinations, 4 routes (2 active, 0 holddown, 2
>>>>>> hidden)
>>>>>> + = Active Route, - = Last Active, * = Both
>>>>>>
>>>>>> 65412:65412:1/96
>>>>>> *[RTarget/5] 01:36:41
>>>>>> Type Default
>>>>>> Local
>>>>>> 65412:65412:8000001/96
>>>>>> *[RTarget/5] 01:36:41
>>>>>> Type Default
>>>>>> Local
>>>>>>
>>>>>> root@gw2z0> show route table bgp.rtarget.0 hidden
>>>>>>
>>>>>> bgp.rtarget.0: 2 destinations, 4 routes (2 active, 0 holddown, 2
>>>>>> hidden)
>>>>>> + = Active Route, - = Last Active, * = Both
>>>>>>
>>>>>> 65412:65412:1/96
>>>>>> [BGP/170] 02:26:54, localpref 100, from
>>>>>> 10.10.210.140
>>>>>> AS path: I, validation-state: unverified
>>>>>> Unusable
>>>>>> 65412:65412:8000001/96
>>>>>> [BGP/170] 02:26:54, localpref 100, from
>>>>>> 10.10.210.140
>>>>>> AS path: I, validation-state: unverified
>>>>>> Unusable
>>>>>>
>>>>>>
>>>>>> I don't believe I should have any gr interfaces as I'm doing VXLAN
>>>>>> (no MPLS/GRE/etc) correct?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 7, 2015 at 4:10 PM, Nischal Sheth <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> Since there's no routes being sent to the CNs, there may be a
>>>>>>> problem
>>>>>>> with route target filtering, which makes the MX think that the CN is
>>>>>>> not
>>>>>>> interested in the any route targets.
>>>>>>>
>>>>>>> Can you run "show route table bgp.rtarget.0" on the MX and check if
>>>>>>> there are any hidden routes in that table? If there are, we need to
>>>>>>> check (show interfaces terse gr-*) if there's any gr-* devices on the
>>>>>>> system. If there aren't any, can you add them using something like:
>>>>>>>
>>>>>>> fpc 1 {
>>>>>>> pic 0 {
>>>>>>> tunnel-services;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> -Nischal
>>>>>>>
>>>>>>> On Jul 7, 2015, at 12:47 PM, Dan Houtz <[email protected]> wrote:
>>>>>>>
>>>>>>> I was able to get updated MX code (14.2-20150704.0) and now have
>>>>>>> device-manager successfully configuring my MX80. BGP session between MX
>>>>>>> and
>>>>>>> Contrail also seems to be stable now however I am having an issue with
>>>>>>> reach-ability between MX and hosts connected to TOR switches. Based on
>>>>>>> ititial troubleshooting I don't believe Junos is announcing the EVPN
>>>>>>> route
>>>>>>> for the IRB interface:
>>>>>>>
>>>>>>> oot@gw2z0# show groups __contrail__ interfaces irb
>>>>>>> gratuitous-arp-reply;
>>>>>>> unit 4 {
>>>>>>> family inet {
>>>>>>> address 10.10.210.145/29;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> root@gw2z0# run show route advertising-protocol bgp 10.10.210.140
>>>>>>>
>>>>>>> bgp.rtarget.0: 2 destinations, 4 routes (2 active, 0 holddown, 2
>>>>>>> hidden)
>>>>>>> Prefix Nexthop MED Lclpref AS
>>>>>>> path
>>>>>>> 65412:65412:1/96
>>>>>>> * Self 100 I
>>>>>>> 65412:65412:8000001/96
>>>>>>> * Self 100 I
>>>>>>>
>>>>>>>
>>>>>>> IRB interface is up:
>>>>>>>
>>>>>>> root@gw2z0# run show interfaces routing | grep irb
>>>>>>> irb.4 Up INET 10.10.210.145
>>>>>>>
>>>>>>> root@gw2z0# run show route 10.10.210.145
>>>>>>>
>>>>>>> _contrail_l3_4_Test.inet.0: 2 destinations, 3 routes (2 active, 0
>>>>>>> holddown, 0 hidden)
>>>>>>> + = Active Route, - = Last Active, * = Both
>>>>>>>
>>>>>>> 10.10.210.145/32 *[Local/0] 00:02:51
>>>>>>> Local via irb.4
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 4, 2015 at 1:10 PM, Nischal Sheth <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> https://bugs.launchpad.net/juniperopenstack/+bug/1465070
>>>>>>>>
>>>>>>>> -Nischal
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jul 4, 2015, at 11:04 AM, Dan Houtz <[email protected]> wrote:
>>>>>>>>
>>>>>>>> Great! Next question...
>>>>>>>>
>>>>>>>> Are there plans to add in ability to apply the
>>>>>>>> 'virtual-gateway-address' knob when configuring IRBs? I believe this
>>>>>>>> is the
>>>>>>>> recommended way to configure redundant MX gateways correct?
>>>>>>>>
>>>>>>>> -Dan
>>>>>>>>
>>>>>>>> On Sat, Jul 4, 2015 at 9:15 AM, Vedamurthy Ananth Joshi <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Yes…this should be addressed too.
>>>>>>>>>
>>>>>>>>> Vedu
>>>>>>>>>
>>>>>>>>> From: Dan Houtz <[email protected]>
>>>>>>>>> Date: Saturday, July 4, 2015 at 7:38 PM
>>>>>>>>> To: Vedamurthy Ananth Joshi <[email protected]>
>>>>>>>>> Cc: OpenContrail Users List - 2 <[email protected]>
>>>>>>>>> Subject: Re: [Users] Problem with Device Manager's VXLAN config
>>>>>>>>> in Contrail 2.2
>>>>>>>>>
>>>>>>>>> Vedu,
>>>>>>>>>
>>>>>>>>> Thank you for the information. I have reached out to our SE to
>>>>>>>>> see about getting updated code. I am also seeing the following with
>>>>>>>>> BGP
>>>>>>>>> sessions between Contrail and MX since moving to 2.2:
>>>>>>>>>
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]:
>>>>>>>>> RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.10.210.140 (Internal AS
>>>>>>>>> 65412)
>>>>>>>>> changed state from OpenConfirm to Established (event RecvKeepAlive)
>>>>>>>>> (instance master)
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]: bgp_read_v4_update:10535:
>>>>>>>>> NOTIFICATION sent to 10.10.210.140 (Internal AS 65412): code 3 (Update
>>>>>>>>> Message Error) subcode 9 (error with optional attribute), Data: c0
>>>>>>>>> 16 09
>>>>>>>>> 10 fc 00
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]: RPD_BGP_NEIGHBOR_STATE_CHANGED:
>>>>>>>>> BGP peer 10.10.210.140 (Internal AS 65412) changed state from
>>>>>>>>> Established
>>>>>>>>> to Idle (event RecvUpdate) (instance master)
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]: Received malformed update from
>>>>>>>>> 10.10.210.140 (Internal AS 65412)
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]: Family evpn, prefix
>>>>>>>>> 3:10.10.210.140:1::4::10.10.214.65/152
>>>>>>>>> Jul 4 14:06:47 gw2z0 rpd[86503]: Malformed Attribute PMSI(22)
>>>>>>>>> flag 0xc0 length 9.
>>>>>>>>> Jul 4 14:06:52 gw2z0 rpd[86503]: bgp_parse_open_options: peer
>>>>>>>>> 10.10.210.140+50620 (proto): unsupported AF 1 SAFI 243
>>>>>>>>>
>>>>>>>>> Is this something that will also be fixed with the new MX code?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>> On Sat, Jul 4, 2015 at 8:02 AM, Vedamurthy Ananth Joshi <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Dan,
>>>>>>>>>> Ingress-node-replication was not pushed by Device Manager on
>>>>>>>>>> purpose.
>>>>>>>>>> The corresponding MX image could be any daily build equal to or
>>>>>>>>>> greater than 14.2-20150627.0.
>>>>>>>>>>
>>>>>>>>>> Vedu
>>>>>>>>>>
>>>>>>>>>> From: Dan Houtz <[email protected]>
>>>>>>>>>> Date: Saturday, July 4, 2015 at 1:47 PM
>>>>>>>>>> To: OpenContrail Users List - 2 <[email protected]>
>>>>>>>>>> Subject: [Users] Problem with Device Manager's VXLAN config in
>>>>>>>>>> Contrail 2.2
>>>>>>>>>>
>>>>>>>>>> Has anyone else tried configuring EVPN VXLAN on an MX using
>>>>>>>>>> device manager in Contrail 2.2? In my testing the configuration being
>>>>>>>>>> pushed my netconf is not valid:
>>>>>>>>>>
>>>>>>>>>> root@gw2z0# commit check
>>>>>>>>>> [edit routing-instances _contrail_l2_4_Test bridge-domains bd-4]
>>>>>>>>>> 'vxlan'
>>>>>>>>>> multicast-group or ovsdb-managed or ingress-node-replication
>>>>>>>>>> should be enabled
>>>>>>>>>> error: configuration check-out failed: (statements constraint
>>>>>>>>>> check failed)
>>>>>>>>>>
>>>>>>>>>> To fix this you must manually configure
>>>>>>>>>> ingress-node-replication:
>>>>>>>>>>
>>>>>>>>>> root@gw2z0# set groups __contrail__ routing-instances
>>>>>>>>>> _contrail_l2_4_Test bridge-domains bd-4 vxlan
>>>>>>>>>> ingress-node-replication
>>>>>>>>>>
>>>>>>>>>> root@gw2z0# commit check
>>>>>>>>>> configuration check succeeds
>>>>>>>>>>
>>>>>>>>>> Is this possibly MX junos version specific? I am using a daily
>>>>>>>>>> build given to me by my SE as I don't believe any released versions
>>>>>>>>>> support
>>>>>>>>>> VXLAN:
>>>>>>>>>>
>>>>>>>>>> root@gw2z0# run show version
>>>>>>>>>> Hostname: gw2z0
>>>>>>>>>> Model: mx80-48t
>>>>>>>>>> Junos: 14.2-20150527_rpd_v2_evpn_vnid.0
>>>>>>>>>>
>>>>>>>>>> I doubt it matters but it's also odd that device manager is
>>>>>>>>>> applying this since I'm using VXLAN:
>>>>>>>>>>
>>>>>>>>>> root@gw2z0# show groups __contrail__ protocols mpls
>>>>>>>>>> interface all;
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>> http://lists.opencontrail.org/mailman/listinfo/users_lists.opencontrail.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
_______________________________________________
Users mailing list
[email protected]
http://lists.opencontrail.org/mailman/listinfo/users_lists.opencontrail.org
