[j-nsp] BGP EVPN, VXLAN and ECMP

[Vincent Bernat]

Hey!

Which version of JunOS are you running? I am on 17.4R1. I see that
18.1R1 was just released, I may try it tomorrow. Do you also have
a :vxlan.inet.0 table and does it show two paths too?

In my configuration, I have:

set routing-options forwarding-table export loadbalance
set policy-options policy-statement loadbalance then load-balance per-packet
set protocols bgp group v4-UNDERLAY multipath
set protocols bgp group v4-EVPN multipath

The PDF document is helpful. It says:

> The QFX5100/QFX5110 can only install VTEP next hops in the PFE; it
> cannot install ESI next hops. This means that, for any given overlay
> destination, only one remote VTEP can be selected. To send traffic to
> the selected VTEP, traffic can be load balanced at the underlay layer
> through the two spine nodes.

I need to do more tests, as the other provided commands may hint this is
just a display issue.
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
		-- Wm. Shakespeare, "A Midsummer Night's Dream"

 ――――――― Original Message ―――――――
 From: Nitzan Tzelniker <nitzan.tzelniker at gmail.com>
 Sent: 28 mars 2018 18:36 GMT
 Subject: Re: [j-nsp] BGP EVPN, VXLAN and ECMP
 To: bernat at luffy.cx
 Cc: juniper-nsp at puck.nether.net

> Hi,
>
> Just check with 5110 and 5100 and on both I see two next hops
> but I am using OSPF for the underlay
> I think that you have multipath under BGP from the fact that we see two
> paths under inet.0 but do you have forwarding-table policy with
> "load-balance per-packet" ?
>
> BTW take a look here
> https://www.juniper.net/documentation/en_US/release-independent/solutions/information-products/pathway-pages/lb-evpn-vxlan-tn.pdf
>
>
> Thanks
>
> Nitzan
>
>
> On Wed, Mar 28, 2018 at 5:27 PM Vincent Bernat <bernat at luffy.cx> wrote:
>
>> Hey!
>>
>> I am trying to setup a Juniper QFX5100 as a VTEP with a very classic
>> setup. Everything works as expected, but the setup is only using one
>> possible path from the underlay network.
>>
>> I have the route to the other VTEP like this:
>>
>> # run show route 10.16.39.3
>>
>> inet.0: 240 destinations, 1808 routes (240 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 10.16.39.3/32      *[BGP/140] 00:38:24, localpref 500, from 10.64.0.5
>>                       AS path: I, validation-state: unverified
>>                       to 10.64.0.23 via xe-0/0/46.181
>>                     > to 10.64.128.23 via xe-0/0/47.183
>>                     [BGP/140] 00:38:24, localpref 500, from 10.64.128.6
>>                       AS path: I, validation-state: unverified
>>                     > to 10.64.128.23 via xe-0/0/47.183
>>                     [BGP/140] 00:38:24, localpref 500, from 10.64.0.3
>>                       AS path: I, validation-state: unverified
>>                     > to 10.64.0.23 via xe-0/0/46.181
>>
>> :vxlan.inet.0: 17 destinations, 21 routes (17 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 10.16.39.3/32      *[Static/1] 00:31:10, metric2 0
>>                     > to 10.64.128.23 via xe-0/0/47.183
>>
>> So, from an IP point of view, I have two available routes to the other
>> VTEP. In the :vxlan.inet.0 table, only one route is kept. I suppose the
>> problem is at this point.
>>
>> Looking at the forwarding table, I have only one indirect next-hop too:
>>
>> # show route forwarding-table family ethernet-switching bridge-domain
>> vlan-client1-543 extensive
>>    Routing table: default-switch.bridge [Index 4]
>>    Bridging domain: vlan-client1-543.bridge [Index 3]
>>    VPLS:
>>    Enabled protocols: Bridging, ACKed by all peers,
>>
>> [...]
>>    Destination:  0a:e3:40:00:00:d9/48
>>      Learn VLAN: 0                        Route type: user
>>      Route reference: 0                   Route interface-index: 575
>>      Multicast RPF nh index: 0
>>      P2mpidx: 0
>>      IFL generation: 142                  Epoch: 0
>>      Sequence Number: 0                   Learn Mask:
>> 0x4000000000000000000000000000000000000000
>>      L2 Flags: control_dyn
>>      Flags: sent to PFE
>>      Next-hop type: composite             Index: 2045     Reference: 6
>>      Next-hop type: indirect              Index: 131317   Reference: 3
>>      Nexthop: 10.64.128.23
>>      Next-hop type: unicast               Index: 1928     Reference: 4
>>      Next-hop interface: xe-0/0/47.183
>>
>> So, how to ensure the two possible next-hops are copied to the
>> ":vxlan.inet.0" table?
>> --
>> Make input easy to prepare and output self-explanatory.
>>             - The Elements of Programming Style (Kernighan & Plauger)
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>