Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP
Hi Nitzan!
I already had the second bit. I've removed the
"ingress-node-replication" from "vlans", like you suggested and it works
as expected. Thanks!
--
A banker is a fellow who lends you his umbrella when the sun is shining
and wants it back the minute it begins to rain.
-- Mark Twain
――― Original Message ―――
From: Nitzan Tzelniker
Sent: 11 avril 2018 21:02 GMT
Subject: Re: [j-nsp] VXLAN, BGP EVPN, remote VTEP
To: Vincent Bernat
Cc: juniper-nsp@puck.nether.net
> Try to remove the "ingress-node-replication" from the vlans and add " set
> protocols evpn multicast-mode ingress replication "
> few months ago a TAC engineer told it to me
>
> "This knob will add all the remote VTEPs under the VNIs on local device
> even though the remote devices do not have these VNIs configured. This
> causes unnecessary flooding from local device to the remote."
>
> But to be honest I didn't check it yet
>
> Thanks
>
> Nitzan
>
> On Tue, Apr 10, 2018 at 12:42 PM Vincent Bernat wrote:
>
>> Hey!
>>
>> I am noticing an odd behaviour when using BGP EVPN on a vQFX: it assumes
>> that all VTEP have all the local VNIs. For example, on the local system,
>> I have VNI 654, 655 and 656. However, on the remote VTEP, I have only
>> 654 and 655. However, the local system still assumes VNI 656 should be
>> present:
>>
>> juniper@QFX1> show version
>> fpc0:
>> --
>> Hostname: QFX1
>> Model: vqfx-1
>> Junos: 17.4R1.16 limited
>> JUNOS Base OS boot [17.4R1.16]
>> JUNOS Base OS Software Suite [17.4R1.16]
>> JUNOS Crypto Software Suite [17.4R1.16]
>> JUNOS Online Documentation [17.4R1.16]
>> JUNOS Kernel Software Suite [17.4R1.16]
>> JUNOS Packet Forwarding Engine Support (qfx-10-f) [17.4R1.16]
>> JUNOS Routing Software Suite [17.4R1.16]
>> JUNOS jsd [i386-17.4R1.16-jet-1]
>> JUNOS SDN Software Suite [17.4R1.16]
>> JUNOS Enterprise Software Suite [17.4R1.16]
>> JUNOS Web Management [17.4R1.16]
>> JUNOS py-base-i386 [17.4R1.16]
>> JUNOS py-extensions-i386 [17.4R1.16]
>>
>> {master:0}
>> juniper@QFX1> show ethernet-switching vxlan-tunnel-end-point remote
>> Logical System Name Id SVTEP-IP IFL L3-Idx
>> 0 192.0.2.11 lo0.00
>> RVTEP-IP IFL-Idx NH-Id
>> 192.0.2.13 570 1749
>> VNID MC-Group-IP
>> 656 0.0.0.0
>> 655 0.0.0.0
>> 654 0.0.0.0
>>
>> {master:0}
>> juniper@QFX1> show route table default-switch.evpn.0
>>
>> default-switch.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown,
>> 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 1:192.0.2.11:1::010101010101010101::0/192 AD/EVI
>>*[EVPN/170] 00:03:49
>> Indirect
>> 2:192.0.2.11:1::654::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:02:43
>> Indirect
>> 2:192.0.2.11:1::655::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:01:20
>> Indirect
>> 2:192.0.2.11:1::656::50:54:33:00:00:0f/304 MAC/IP
>>*[EVPN/170] 00:03:54
>> Indirect
>> 2:192.0.2.13:1::654::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:41, localpref 100, from 192.0.2.100
>> AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 2:192.0.2.13:1::655::50:54:33:00:00:11/304 MAC/IP
>>*[BGP/170] 00:02:04, localpref 100, from 192.0.2.100
>> AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 3:192.0.2.11:1::654::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:08
>> Indirect
>> 3:192.0.2.11:1::655::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>> Indirect
>> 3:192.0.2.11:1::656::192.0.2.11/248 IM
>>*[EVPN/170] 00:04:07
>> Indirect
>> 3:192.0.2.13:1::654::192.0.2.13/248 IM
>>*[BGP/170] 00:03:55, localpref 100, from 192.0.2.100
>> AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>> 3:192.0.2.13:1::655::192.0.2.13/248 IM
>>*[BGP/170] 00:03:55, localpref 100, from 192.0.2.100
>> AS path: I, validation-state: unverified
>> > to 203.0.113.13 via xe-0/0/0.0
>>
>> The remote system, 192.0.2.13 (also a vQFX), never send anything that
>> would hint it can handle VNI 656. I have also verified by sniffing on
>> the wire that the remote system is in fact receiving VXLAN packets for
>> VNI 656:
>>
>> Frame 807: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
>> Ethernet II, Src: MS-NLB-PhysServer-05_86:71:7e:03 (02:05:86:71:7e:03),
>> Dst: MS-NLB-PhysServer-05_86:71:69:03 (02:05:86:71:69:03)
>> Inter
Re: [j-nsp] Going Juniper
On 11/04/2018 10:51, James Bensley wrote: > I would agree with > you that low port coun't, good, and reasonably priced mixed 1G/10G > devices aren't plentiful in choice from vendors. We open a lot of > small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for > us but each with their own caveats. Particularly if you include the requirement for temperature hardening - we deploy a lot of street cabinet sites, and MX104s and ASR902s are basically the only boxes in town that have reasonable 10G density and a sensible temperature range for external boxes. We don't need the full capability of a 104 (and feature-wise the 920 and 902s are chock full of unfortunate compromises) but sadly the higher bandwidth stuff based around x86 and BRCM silicon isn't yet entering the temp-hardened space. We have a few 104s out in prod doing fairly basic bits of EVPN and they're very capable boxes - just pricey for the ports we need. -- Cheers, James Harrison ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
>>> On 11 April 2018 at 13:43, Ola Thoresen wrote: >>> Granted at least JNPR offering allows you to run same device as pure >>> L2, with Cisco offering it is satellite-only box, cannot be used as >>> L2. >> >> I know what you mean, but I must say that this time it seems like they have >> more or less managed to do it right. They use pretty standard protocols for >> everything, it is just "packaged" so you don't need to think about it. >> >> But as you say, you can easily use the exact same hardware in a regular L2 >> setup, the thing you gain from the satellite setup is central management of >> only the routers, which can be a time and management saver. I have to say, I completely disagree. On 11 April 2018 at 13:12, Alexandre Guimaraes wrote: > Last notice that I have about Junos fusion, some features doesn’t work in to > satellite ports, like ethernet ccc. ^ This is the reason why. Fusion is a layer 1 extension, my 1st question to Juniper is why is there a DC version and a Service Provider version? https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000523-en.pdf: "Junos Fusion Provider Edge is a technology enabler that overcomes optical pluggable p hysical limitations by delegating low-speed optical interfaces to a cost-appropriate switch, virtually expanding connectivity to thousands of ports from a single Juniper Networks MX Series 3D Universal Edge Router." "Junos Fusion Data Center provides automated network configuration and operational simplicity for medium to large data centers with up to four QFX1 switches deployed in the spine layer and any combination of up to 64 QFX5100, QFX5110-48S, QFX5200-32C, and EX4300 top-of-rack switches deployed as satellite devices." Basically the same justification for both technology variants - more ports for less money with zero touch deployment. Both scenarios can benefit from those proposed advantages so no need to make them separate products. Obviously they will to make more money, but it looked back it you have an Ethernet based layer 1 extension technology and there is more than one variant of it, in 2018 we're only using one kind of Ethernet here. OK, 2nd question, and this is my real annoyance, and why I believe Juniper haven't done it right; Why are certain features, e.g. Inter-AS MPLS Option B connections, not support over the Service Provider version? We're heavy users of OptB interconnects and these devices are supposed to be layer 1 extensions. Can they pass an Ethernet frame, yes or no? The answer is yes so anything higher level should be ignored in my opinion. After pressing Juniper they said that certain traffic types aren't support because when they release new Fusion version, they test the most common traffic types and they "can't test everything", and MPLS OptB's are on the "no time for testing" list. It is possible that it would work just fine, but if any issues arise they won't support it. Surely they should test that Ethernet frames pass OK and then support anything that runs over Ethernet? If you're selling a layer 1 extension service for Ethernet and a certain kind of traffic isn't support that runs over the top of Ethernet - that is a great big red flag to me. We only have Fusion because they wanted more people to run it - they sold it to us for cheaper than vanilla layer 2 switches. I feel dirty. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11. april 2018 14:12, Alexandre Guimaraes wrote: Hello everyone! Last notice that I have about Junos fusion, some features doesn’t work in to satellite ports, like ethernet ccc. Did you guys that use, can confirm that, or all features are available? I did set up a l2circuit between a vlan (interface xe-100/0/0.100, vlan 100 on a MX204 with a QFX5100 as satellite) and a remote MX80 a few days ago, and it worked flawlessly. Rgds. Ola Thoresen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
