Re: [j-nsp] proxy-arp on EVPN irb

[Jackson, William via juniper-nsp]

Hi

This is what I have done, but it doesn’t appear to work.

We have had to send to the clients via DHCP a set of /32 host routes to 
circumvent this problem.

I will open a TAC case and raise with my SE to see whats what.

Thanks for the feedback.

From: Roger Wiklund 
Sent: Friday, December 8, 2023 2:25 PM
To: Aaron1 
Cc: Jackson, William ; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] proxy-arp on EVPN irb

**  WARNING: This email originates from outside of the organisation **

Hi

It seems that proxy arp is disabled by default:
proxy-arp | Junos OS | Juniper 
Networks<https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/ref/statement/proxy-arp-edit-interfaces.html>

Regarding proxy-arp for EVPN (arp suppression) it only works for the same 
subnet, not between subnets.

So that seems to match what you're seeing that you must enable proxy-arp on the 
IRB in order to reach the other subnets.

Regards
Roger


On Wed, Dec 6, 2023 at 5:04 PM Aaron1 via juniper-nsp 
mailto:juniper-nsp@puck.nether.net>> wrote:
As I recall, proxy-arp behavior is proven by looking in the local host arp 
cache and finding entries for foreign ip’s mapped to the default gateway’s mac 
address.  If that is still occurring, then it would seem that proxy arp 
functionality is still working and you can move on to tshooting something 
beyond that… like what is the upstream def gw/evpn pe doing with those packets

Aaron

> On Dec 6, 2023, at 6:16 AM, Jackson, William via juniper-nsp 
> mailto:juniper-nsp@puck.nether.net>> wrote:
>
> Hi
>
> Maybe somebody knows the answer to this one:
>
> We migrated some customers to an EVPN domain away from a legacy node that 
> used proxy-arp on its L3 interface.
>
> The downstream clients have some funky routing and they are relying on 
> proxy-arp to resolve an offnet address (don't ask me why for our sanities 
> sake)!
>
> We have a implemented EVPN bridge domain with the following config on MX PE 
> nodes running 21.1 code.
>
> instance-type virtual-switch;
> protocols {
>evpn {
>encapsulation mpls;
>default-gateway do-not-advertise;
>extended-vlan-list [ 250  ];
>}
> }
> bridge-domains {
>250 {
>domain-type bridge;
>vlan-id 250;
>interface ae68.250;
>routing-interface irb.25068;
>}
> }
>
> interfaces irb.25068 {
>  proxy-arp;
>  family inet {
>  address 172.23.248.1/22<http://172.23.248.1/22>;
>  }
>  mac 00:aa:dd:00:00:68;
> }
>
> This irb is in a L3VPN instance.
>
> Now the documentation states that proxy-arp and arp-suppression is on by 
> default yet these clients cant reach the offnet host with or without the 
> "proxy-arp" command on the irb.
>
> Any ideas?
>
> thanks
> ___
> juniper-nsp mailing list 
> juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] proxy-arp on EVPN irb

[Jackson, William via juniper-nsp]

Hi

Maybe somebody knows the answer to this one:

We migrated some customers to an EVPN domain away from a legacy node that used 
proxy-arp on its L3 interface.

The downstream clients have some funky routing and they are relying on 
proxy-arp to resolve an offnet address (don't ask me why for our sanities sake)!

We have a implemented EVPN bridge domain with the following config on MX PE 
nodes running 21.1 code.

instance-type virtual-switch;
protocols {
evpn {
encapsulation mpls;
default-gateway do-not-advertise;
extended-vlan-list [ 250  ];
}
}
bridge-domains {
250 {
domain-type bridge;
vlan-id 250;
interface ae68.250;
routing-interface irb.25068;
}
}

interfaces irb.25068 {
  proxy-arp;
  family inet {
  address 172.23.248.1/22;
  }
  mac 00:aa:dd:00:00:68;
}

This irb is in a L3VPN instance.

Now the documentation states that proxy-arp and arp-suppression is on by 
default yet these clients cant reach the offnet host with or without the 
"proxy-arp" command on the irb.

Any ideas?

thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX304 Port Layout

[Jackson, William via juniper-nsp]

>The MX204 is an MPC7E, so whatever H-QoS is on the MPC7E is what the 
>MX204 will also do.

>We have used them as an edge router on a temporary basis at new sites, 
>with an Arista switch hanging off of them via an 802.1Q trunk, until we 
>can get our standard MX480 to site. They are capable for such a 
>use-case. But usually, we use them for peering and value-added traffic.

Similar use case here but we use a QFX as a fusion satellite if port expansion 
is required.
Works well as an small site start up option.

-Original Message-
From: juniper-nsp  On Behalf Of Mark Tinka 
via juniper-nsp
Sent: Saturday, June 10, 2023 11:03 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX304 Port Layout



On 6/9/23 17:46, Andrey Kostin via juniper-nsp wrote:

>  We have two MX204s running in pair with 2x100G taken for links 
> between them and remaining BW is 6x100G for actual forwarding in/out.
> In this case it's kind of at the same level for price/100G value.

Yeah, using the MX204 like this (edge router functions) is costly on the ports 
it's already lacking.


>
> I agree, and that's why I asked about HQoS experience, just to add 
> more inexpensive low-speed switch ports via trunk but still be able to 
> treat them more like separate ports from a router perspective.

The MX204 is an MPC7E, so whatever H-QoS is on the MPC7E is what the 
MX204 will also do.

We have used them as an edge router on a temporary basis at new sites, 
with an Arista switch hanging off of them via an 802.1Q trunk, until we 
can get our standard MX480 to site. They are capable for such a 
use-case. But usually, we use them for peering and value-added traffic.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Vlan 111 on EVPN-VXLAN

[Jackson, William via juniper-nsp]

We ran into a limitation on qfx5100 where you could not define more than "8?" 
conditions

Ie:

Vlan members [ 1 2 3 4 5 6 7 8 9 ]   would fail

But

Vlan members [ 1-9 10 20-25 ] would work

Chipset limitation if I recall.  Best to open a JTAC case

-Original Message-
From: juniper-nsp  On Behalf Of Cristian 
Cardoso via juniper-nsp
Sent: 04 April 2022 14:23
To: juniper-nsp 
Subject: [j-nsp] Vlan 111 on EVPN-VXLAN

**  WARNING: This email originates from outside of the organisation **
 
 


Hi

I had a strange behavior in my environment where I use qfx5120-48y-8c switches, 
in spine/leaf topology with EVPN-VXLAN configured.

I transport the VLANs via VXLAN between the servers that are below the leafs, 
to my mx routers that are above the spines. To make my life easier, I use the 
configuration of groups in the leafs, to "standardize" the aggregation 
interfaces with the servers in the environment and apply the VLANs on all the 
servers that are below the leafs at the same time.

I use the group config like this:

> show configuration groups VLANS
interfaces {
 {
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members [ VNI830 VNI2925 VNI1819 VNI2819 VNI2829
VNI2853 VNI4018 VNI650 VNI680 VNI682 VNI750 VNI780 VNI782 VNI810 VNI815
VNI816 VNI821 VNI822 VNI826 VNI827 VNI828 VNI852 VNI854 VNI887 VNI910
VNI915 VNI916 VNI921 VNI922 VNI927 VNI928 VNI930 VNI952 VNI954 VNI987
VNI2953 VNI222 ];
}
}
}
}
}

> show configuration interfaces
apply-groups VLANS;

I just don't apply the VLANS group on the communication interfaces between the 
leafs and the spines, on the other ports where the servers are connected, the 
group is applied.

I have some VMs running OSPF with my MX routers on VLAN VNI2819, the problem 
that occurred was when I tried to insert the VLAN VNI111, where the vlan-id is 
111 and the vni is 111 in the VLANS group, when applying the configuration, the 
communication automatically OSPF on VNI2819 dropped instantly, only coming back 
after I removed VLAN 111.

Does anyone happen to know if there is any limitation on Juniper equipment, 
where VLAN or VNI 111 is reserved internally in the system, I looked for 
documentation and I didn't find anything about it.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 port 1G

[Jackson, William]

Rename the interface ge-0/1/4

admin@mx1> show interfaces xe-0/1/4  
Physical interface: xe-0/1/4, Enabled, Physical link is Up
  Interface index: 154, SNMP ifIndex: 530
  Description: TEST
  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode,
Speed: 10Gbps,

On 09/10/2020, 13:16, "juniper-nsp on behalf of Łukasz Trąbiński" 
 wrote:

Hello

In Lab I'm trying to set up 1G port on MX204.

admin@mx1> show configuration interfaces xe-0/1/4  
description TEST;
gigether-options {
speed 1g;
}
unit 0 {
family inet {
address 192.168.1.138/30;
}
}

admin@mx1> show configuration chassis fpc 0 pic 1 port 4  
speed 10g;

Port is UP, but I can’t see any MAC address from remote side or I can’t 
ping remote side.


admin@mx1> show interfaces xe-0/1/4  
Physical interface: xe-0/1/4, Enabled, Physical link is Up
  Interface index: 154, SNMP ifIndex: 530
  Description: TEST
  Link-level type: Ethernet, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 
10Gbps,
  BPDU Error: None, Loop Detect PDU Error: None, MAC-REWRITE Error: None,
  Loopback: None, Source filtering: Disabled, Flow control: Enabled,
  Speed Configuration: 1G


Junos: 18.4R3-S5.4 but also tried on 18.4R3.3. I also setup 
auto-negotiation and fec options but without success. 

SFP:
Xcvr 4   REV 01   740-011614   PJD2XXX   SFP-LX10
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QSFP+ to SFP+ adapters

[Jackson, William]

Yes 

We have used the ones from flexoptix

They tend to work correctly, but like you mentioned you lose the DOM and also 
the optic partcode may not display correctly on a show chassis hardware.

Apart from that work quite well.

Note:  don't bother trying to use these for a fusion setup on the satellite 
side as it doesn't work.
They can work on the AD device with a native 10GE port on the satellite, but 
using them on the satellite in a 40/100GE port  as a 10GE uplink, is a no go.

will



-Original Message-
From: juniper-nsp  On Behalf Of Chuck 
Anderson
Sent: 16 March 2020 21:06
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] QSFP+ to SFP+ adapters

Has anyone tried using QSFP+ to SFP+ adapters such as this one?  What software 
versions have you tried?

https://www.fs.com/products/72587.html

I'm testing these on QFX10002-36Q with 17.3R3-S7.2 and SFP+ 10G-LR modules.  
The links come up and pass LLDP and IP traffic, but DOM doesn't work:

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/30:0 Physical 
interface: xe-0/0/30:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show interfaces diagnostics optics xe-0/0/31:0 Physical 
interface: xe-0/0/31:0
Optical diagnostics   :  N/A

{master:0}
root@spine-1> show chassis hardware
Hardware inventory:
Item Version  Part number  Serial number Description
  PIC 0   BUILTIN  BUILTIN   36X40G
Xcvr 30   NON-JNPR   UNKNOWN
Xcvr 31   NON-JNPR   UNKNOWN


root@spine-1> show chassis pic fpc-slot 0 pic-slot 0 
FPC slot 0, PIC slot 0 information:
  Type 36X40G
  StateOnline
  PIC version 2.47
  Uptime 26 days, 40 minutes, 44 seconds

PIC port information:
 FiberXcvr vendor   Wave-
Xcvr
  Port Cable typetype  Xcvr vendorpart number   length   
Firmware
  30   unknown cable n/an/a  
0.0   
  31   unknown cable n/an/a  
0.0   


{master:0}
root@spine-1> show interfaces terse xe-*
Interface   Admin Link ProtoLocal Remote
xe-0/0/30:0 upup
xe-0/0/30:0.0   upup   inet 10.0.0.1/30 
xe-0/0/30:1 updown
xe-0/0/30:2 updown
xe-0/0/30:3 updown
xe-0/0/31:0 upup
xe-0/0/31:0.0   upup   inet 10.0.0.5/30 
xe-0/0/31:1 updown
xe-0/0/31:2 updown
xe-0/0/31:3 updown
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] IP Fabric EVPN/VXLAN

[Jackson, William]

Hi

Just want to throw this one out there:

What are other peoples experiences with the IP Fabric EVPN/VXLAN scenario.

I have leaf and spine on qfx5100 with 17.3R3-S3 and MX edge gateways using :

I have gone through in order
*18.3R1-S1
Disk Space consumption bug
*18.3R1-S3
EVPN BGP update BUG
*18.3R2 *
<<>>
*18.2R2-S3
Memory Leak BUG
MAC addresses don’t age out BUG

For me this has been a nightmare, bug after bug after bug.
When the IT guys migrate a VM, it breaks.  
I have had JTAC case after JTAC case.

regards

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Hyper Mode on MX

[Jackson, William]

Junos Fusion is not supported when hyper-mode is enabled.



-Original Message-
From: juniper-nsp  On Behalf Of Franz 
Georg Köhler
Sent: 07 March 2019 12:46
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Hyper Mode on MX

On Thu, Mar 07, 2019 at 12:31:48PM +0100, Olivier Benghozi 
 wrote:
> By the way HyperMode is only useful if you expect some very high 
> throughput with very small packets (none of the MPCs are linerate 
> using very small packets, but HyperMode brings it closer).

Thanks.
While we actually don't need that performance really I was wondering if would 
be a good idea to enable it on new installations preventively.

* Padding of Ethernet frames with VLAN.
Isn't that a very basic functionality and would break ethernet switching?

* Node Virtualization
This is Junos Node Slicing?



Best regards,

Franz Georg Köhler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

[Jackson, William]

So just to throw a question out there:

When I last looked at SR this was a big empty hole when it came to multicast.
As we are possibly removing mLDP and RSVP from the network in favour of SR(-TE) 
what are people doing to fill this void.

There were some drafts being worked on last year and if I recall one that 
seemed more "developed" was "Bit Index Explicit Replication", but I haven't 
heard anything more about this topic and it hasn't been mentioned in the thread 
so far.

Any comments?

Thanks

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 vs ACX5048

[Jackson, William]

> colton.co...@gmail.com>
> wrote:
>
>  Gustavo,
>
> We you say " Another problem was upgrading to the lastest Junos JTAC
> recommended that made the ACX5048 unusable... ( Junos was unable 
> to find
> the physical ports..)  We had to downgrade to get it back working 
> again.."

How the hell does that type of problem even get past QA?

I had the same issue with a qfx5100, upgraded to 17.x version and when booted 
didn’t detect the ports.  After a 30 minute wait we downgraded.

Insane.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Equipment Labelling

[Jackson, William]

Looks good, I get one made up and give some feedback.

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Chuck Anderson
Sent: 07 May 2018 02:25
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Equipment Labelling

We think a M3.5-.07 is the right screw, but a 6-32 fits well enough as well.

On Sat, May 05, 2018 at 10:31:23PM +, Sweetser, Frank E wrote:
> So after a few rounds of design, Chuck and I came up with this simple bracket 
> that mounts onto the threaded stud in the middle of the mounting brackets for 
> many (all?) of the 1U EX and QFX switches:
> 
> 
> https://www.thingiverse.com/thing:2893741
> 
> 
> If you've got a 3D printer handy, this should give you an 18mm by 40mm 
> space for labelling.  If you don't have a 3D printer handy, now's your 
> chance to convince your boss to buy one for work purposes 
> 
> 
> Frank Sweetser
> Director of Network Operations
> Worcester Polytechnic Institute
> "For every problem, there is a solution that is simple, elegant, and 
> wrong." - HL Mencken
> 
> 
> 
> From: juniper-nsp  on behalf of 
> Sweetser, Frank E 
> Sent: Thursday, May 3, 2018 10:07 PM
> To: Anderson, Charles R; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Equipment Labelling
> 
> That should be pretty straightforward to slap together something simple.  
> Anyone know the actual size of the threaded hole?
> 
> 
> Frank Sweetser
> Director of Network Operations
> Worcester Polytechnic Institute
> "For every problem, there is a solution that is simple, elegant, and 
> wrong." - HL Mencken
> 
> 
> 
> From: juniper-nsp  on behalf of 
> Chuck Anderson 
> Sent: Thursday, May 3, 2018 9:39 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Equipment Labelling
> 
> Nice.  That screw hole on the front of the rack ear is screaming for 
> someone to make a 3D printed label tag.
> 
> On Thu, May 03, 2018 at 08:19:59AM -0500, Chris Wopat wrote:
> > Our current QFX5100 label method:
> >
> > https://i.imgur.com/kRVojXk.jpg
> >
> > We have a label on both the left and right side, sticking out as a 
> > tab on left and folded over on right. in both cases the label was 
> > adhered prior to putting the ears on.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Equipment Labelling

[Jackson, William]

Hi

I have noticed that with more modern pieces of equipment, such as qfx switches, 
that there is very little real estate to place tags/labels to identify the 
equipment.

We have multiple qfx switches stacked in a rack and they have different uses ( 
IP Fabric, Fusion Satellites ).  At the moment we are having to provide either 
rack elevation diagrams or flash the location LED just so remote hands can 
identify the unit, as they all look the same.

What are other people doing for equipment that has no front or rear space to 
place a label?

Many thanks


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX240 (orMX960) with QFX5100 in Fusion

[Jackson, William]

Been looking at fusion edge with qfx5100 and ex4300.
Using 16.X code and so far so good.



On 19/07/2017, 21:03, "juniper-nsp on behalf of Alain Hebert" 
 wrote:

 Hi,

 Anyone has feedback about Fusion when MX240-MX960 and QFX5100 are 
concerned.

 Our foray into QFX5100/VCF only was not very successful. :(

-- 
-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG on QFX5100

[Jackson, William]

We are running VRRP in all VLANS that require L3.
We also have the static ARP entries setup so they can ping between peers.
We have floating static routes so that if a MC-LAG peer loses its upstream 
routing, it will forward all traffic to the other MC-LAG peer over the ICL.
**if we don’t do this it black holes all traffic that hits it, bearing in mind 
that in active/active both peers process traffic.

Thus, what we are seeing is that when traffic comes in from the upstream link, 
if it goes downstream on the same node it works
, if it needs to traverse the ICL to use the downlink on the peer it fails.

But not in all the vlans on the downstream MC-AE interface.
On some it works and others it doesn’t, very inconsistent.

TAC want to create a PR.

I must say I’m quite surprised with the number of people whom have responded 
that they have problems with MC-LAG though, would have thought it would have 
been a mature technology by now.


On 10/07/2017, 19:08, "juniper-nsp on behalf of William McLendon" 
 wrote:

I can’t remember the exact version offhand.  it was in the 14.1X53 range I 
believe.  It’s been live for a while though.

I think we may have run into issues with some MC-LAG on ex4600s (mostly the 
same as qfx5100…) in the 14.1X53-D30 range maybe?  I think they were resolved 
with D35?  I’m sorry I can’t provide clearer detail, it was a while back.

the L2-only QFX5100 MC-LAG pair we had the arp issue for the management 
vlan was I think on a slightly older version of 14.1X53 — D20 or 21 maybe?  But 
as I say once we configured VRRP the issues resolved in that scenario.

Thanks,

Will

> On Jul 10, 2017, at 1:04 PM, Vincent Bernat  wrote:
> 
> ❦ 10 juillet 2017 12:36 -0400, William McLendon  :
> 
>> if you are running a routing protocol over the particular VLAN on the
>> MC-LAG peers (which is a supported config in Junos MC-LAG
>> implementation) make sure you are running VRRP between the MC-LAG
>> peers, even though it seems unnecessary.  VRRP seems required for any
>> ARP sync to occur for a given IRB interface.  Without it one side can
>> learn the ARP entry but not the other.  Clearing arp cache seems to
>> fix it temporarily but then it pops up again after ARP ages out.
>> 
>> We ran into this issue in a similar scenario with MC-LAG L2-only
>> switches where you could only ping the default gateway from one node
>> unless you issued a clear arp, and then it would work until ARP timer
>> ran out again.  Once we configured VRRP that issue was resolved.
> 
> Which version do you use? I specifically configured VRRP for this reason
> but still ran into ARP problems.
> -- 
> There's small choice in rotten apples.
>   -- William Shakespeare, "The Taming of the Shrew"

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MC-LAG on QFX5100

[Jackson, William]

VCF

My experiences with this so far have not been so good……….

So not on the radar at all.

I could use VC but I don’t want the shared control plane.  And MC-LAG “should” 
be very mature…….


From: Matt Freitag [mailto:mlfre...@mtu.edu]
Sent: Monday, July 10, 2017 1:13 AM
To: Vincent Bernat <ber...@luffy.cx>
Cc: Juniper List <juniper-nsp@puck.nether.net>; Jackson, William 
<william.jack...@gibtele.com>
Subject: Re: [j-nsp] MC-LAG on QFX5100

Is there something preventing you from using VCF or qfabric?

On Jul 9, 2017 7:25 AM, "Vincent Bernat" 
<ber...@luffy.cx<mailto:ber...@luffy.cx>> wrote:
 ❦  9 juillet 2017 09:07 GMT, "Jackson, William" 
<william.jack...@gibtele.com<mailto:william.jack...@gibtele.com>> :

> We have been testing an MC-LAG active/active setup on qfx5100 using the 
> latest 14.1x53 code.
> We are seeing issues when using L3 in the MC-LAG.
> We are using IRB with VRRP on a number of vlans that face the downstream 
> client.
> It seems that in active/active both nodes process traffic even if they
> are not the VRRP master, so we have taken that into account.
>
> The issue we are seeing seems to be that the ARP sync is not working on the 
> ICCP between the peers.
> We can reach downstream nodes via one peer but not the other.
> And it works correctly on some vlans but not others so isn’t related to the 
> downstream client.
>
> JTAC is on it albeit at snail’s pace.
>
> Has anyone got this working on qfx5100 and can share some config
> examples?

I ran into similar limitations with the same version. I have tried both
MAC synchronization and VRRP. When packets hit the "wrong" node (the one
that didn't learn the neighbor information), they are not
forwarded. See:

 https://lists.gt.net/nsp/juniper/60956#60956

I got additional private feedback from people with similar issues
(MC-LAG and L3 forwarding). I didn't try to involve JTAC.
--
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MC-LAG on QFX5100

[Jackson, William]

Hi

We have been testing an MC-LAG active/active setup on qfx5100 using the latest 
14.1x53 code.
We are seeing issues when using L3 in the MC-LAG.
We are using IRB with VRRP on a number of vlans that face the downstream client.
It seems that in active/active both nodes process traffic even if they are not 
the VRRP master, so we have taken that into account.

The issue we are seeing seems to be that the ARP sync is not working on the 
ICCP between the peers.
We can reach downstream nodes via one peer but not the other.
And it works correctly on some vlans but not others so isn’t related to the 
downstream client.

JTAC is on it albeit at snail’s pace.

Has anyone got this working on qfx5100 and can share some config examples?

Many thanks



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN -VXLAN in production

[Jackson, William]

Yes I have two small pods setup using VXLAN/EVPN with IP Fabric. ( eBGP 
underlay/iBGP overlay )

D40 is the place to be on code and seems to have fixed most of the problems I 
had.
Seems to work well now.

Can get me off list for more details.

On 22/11/2016, 15:02, "juniper-nsp on behalf of Amos Rosenboim" 
 wrote:

Hi Everybody,


We are working on a new DC design for a relatively large deployment (start 
at 20 racks and grow to about 60).
We are considering EVPN-VXLAN for extending L2 between rows (we failed 
convincing the server guys that they don’t need this).

We are wondering if anyone has any experience with this technology in 
production yet ?

Specifically with QFX5100 and with QFX10002.

Thanks 

Amos


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX series BGP config macros ?

[Jackson, William]

The parameter feature in IOS-XR is very nice, although there are other parts 
that aren’t so great.
I havent seen anything like this on Junos.

I must say I believe that this part of Junos has been abandoned somewhat and 
could do with some developer time.

On 05/11/2016, 21:24, "juniper-nsp on behalf of John Brown" 
 wrote:

Hi,

I'm trying to build a BGP policy config that will advertise routes based on 
how
a subscriber tags a route towards us.

If they send a route with community 65010:XXX  with XXX = an ASN
then we will not announce it towards that ASN.

In a small configuration this is pretty easy to do, but I'm looking at
trying to
see if there is a more elegant and scaleable solution.

With hundreds of peers on a router, it doesn't make sense to have a bunch of
community members for each ASN

It would be nice to have code that did


protocol bgp
group  eBGP-Some-Peer
peer-as 1234
export [Dont-Export]


policy-statement  Dont-Export
term
from
 protocol bgp
 community 65010:$PEERASN
then
 reject



Where $PEERASN gets expanded to 1234 because of the BGP session
it is associated with.

Then I can just apply Dont-Export to multiple peers and not have to 
customize
it for each one



Hopefully this explains it well enough.

Thank you
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Junos Fusion Provider Edge

[Jackson, William]

Hi all

Any one used Junos Fusion Provider Edge?

I was wondering if the aggregation device can be an MX virtual Chassis rather 
than a single standalone MX?

And if using qfx units as satellites, do you need any fancy licenses on them if 
the smarts are on the MX?

Many thanks

William Jackson
NGN Engineering

Gibtelecom
Tel: +350 58007229
Fax: +350 2004



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Which BOGON filter strategy you would recommend IPv4 and IPv6

[Jackson, William]

Bogons still do a BGP feed with many deaggregated prefixes.

http://www.team-cymru.org/bogon-reference.html ( FULLBOGONS )

William Jackson

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Alexander Marhold
Sent: 16 February 2016 08:50
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Which BOGON filter strategy you would recommend IPv4 and IPv6

Hi !

 

My customer is a bigger company with customers around the world, which recently 
connected directly to 4 upstream providers and 1 IX via MX router and BGP

 

Now by searching the internet and googling  I do not know which method to use 
to have up-to date BOGON filtering for IPv4 AND IPV6  (yes IPv6 is
necessary)

 

I found things like spamhaus, team-cymru.org .

 

It seems that IPv6 is still less treated than IPv4

 

What do you recommend, and which way to get the lists and how often is an 
update needed

Or is it better to try a dynamic solution via bgp-peering ?

 

With best regards

 

alexander

 

 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Acx5048 vpls vlan-id

[Jackson, William]

Ran into same limitation, started using the limited vlan remapping capabilities 
to push a dummy outer vlan ID to make all services share the vpls instance, but 
there are issues with this so been using separate routing-instances.  Ball ache.
 




On 05/02/2016, 21:59, "juniper-nsp on behalf of Giuliano Medalha" 
 wrote:

>Aaron
>
>Thanks a lot
>
>Our problem is related to pass more than one vlan to the same vpls instance.
>
>We have some projects here that depends of it
>
>We will talk with juniper TAC and PLM to see the software roadmap of this box
>
>There is no chance to use this box in projects with this limitation, because 
>other vendors with the same chipset have this feature running ok.
>
>It looks like to be a junos feature missing not a technical limitation ... 
>Hope so !!!
>
>Thanks a lot anyway
>
>Att
>
>Giuliano
>
>
>
>Sent from my iPhone
>
>> On Feb 5, 2016, at 02:07, Aaron  wrote:
>> 
>> Hi Giuliano, 
>> 
>> I'm new to Juniper and learning as I gobut I'll at least show you what
>> is in my lab.  I have a functioning vpls routing-instance that is working
>> with ... ACX5048, MX104, Cisco ASR9006, Cisco ME3600...
>> 
>> My acx5048 looks like this... here's some bits from the config...
>> 
>> gvtc@eng-lab-acx5048-1> show version
>> fpc0:
>> --
>> Hostname: eng-lab-acx5048-1
>> Model: acx5048
>> Junos: 15.1X54-D20.7
>> 
>> set interfaces ge-0/0/1 speed 100m
>> set interfaces ge-0/0/1 encapsulation ethernet-vpls
>> set interfaces ge-0/0/1 unit 0 family vpls
>> 
>> (not shown here is the required, IGP (ospf), MPLS, ldp... that was simple)
>> 
>> set protocols bgp group ibgp type internal
>> set protocols bgp group ibgp local-address 10.101.12.245
>> set protocols bgp group ibgp family inet-vpn unicast
>> set protocols bgp group ibgp family l2vpn auto-discovery-only
>> set protocols bgp group ibgp neighbor 10.101.0.254 local-as 64512
>> 
>> gvtc@eng-lab-acx5048-1> show configuration | display set | match
>> "routing-instances vlan100"
>> set routing-instances vlan100 instance-type vpls
>> set routing-instances vlan100 interface ge-0/0/1.0
>> set routing-instances vlan100 route-distinguisher 10.101.12.245:32768
>> set routing-instances vlan100 l2vpn-id l2vpn-id:65535:10100
>> set routing-instances vlan100 vrf-target target:65535:10100
>> set routing-instances vlan100 protocols vpls no-tunnel-services
>> 
>> gvtc@eng-lab-acx5048-1> show vpls connections brief
>> Layer-2 VPN connections:
>> 
>> Instance: vlan100
>>  L2vpn-id: 65535:10100
>>  Local-id: 10.101.12.245
>>Remote-id Type  St Time last up  # Up trans
>>10.101.0.254  rmt   Up Feb  5 05:59:29 2016   1
>>10.101.12.246 rmt   Up Feb  5 05:59:29 2016   1
>>10.101.12.248 rmt   Up Feb  5 05:59:29 2016   1
>>10.101.12.250 rmt   Up Feb  5 05:59:29 2016   1
>>10.101.12.251 rmt   Up Feb  5 05:59:29 2016   1
>> 
>> Aaron
>> 
>> -Original Message-
>> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
>> Giuliano Medalha
>> Sent: Thursday, February 4, 2016 9:17 PM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] Acx5048 vpls vlan-id
>> 
>> People
>> 
>> We are trying to configure vpls routing-instance in a ACX5048 box
>> 
>> But the following command does not work after commit ...
>> 
>> Routing-instances {
>>   VPLS-1 {
>>   instance-type vpls;
>>   ##
>>   ## Warning: statement ignored: unsupported platform (acx5048)
>>   ##
>>   vlan-id all;
>>   ##
>>   ## Warning: vlan-id-range is specified for this logical interface;
>> 'vlan-id all' should also be enabled
>>   ##
>>   interface ae0.50;
>>   route-distinguisher 
>> 
>> 
>> Is there another way to configure this feature ?
>> 
>> Because on MX works OK and it is pretty simple
>> 
>> Thanks a lot
>> 
>> Giuliano
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>___
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Continuous SNMP traps for ospfTxRetransmit alarms

[Jackson, William]

Hi

Trying to get some other opinions here on a problem I have.

We have an ex4300 switch which is running ospf on an irb.
On the same vlan there are multiple other ospf routers, thus we have a DR/BDR 
and DROTHER nodes.
We are seeing a constant flow of traps for ospf retransmits from the ex.  This 
is not traffic affecting just management/monitoring effecting.

It would seem that due to the way that Juniper have implemented this part of 
the RFC.  I was wondering if other people have run into this situation and what 
any mitigation steps were apart from redesigning the network :)

JTAC have stated the following ( that is working as by design )



Update: Juniper's implementation of the OSPF flooding mechanism can 
occasionally result in unnecessary LSA retransmissions. This has no operational 
impact, and does not affect convergence times. Read below analysis and 
explanation given below.



Explanation/Analysis: Please refer to PR 35491 for more details:



Both DR-OTHER and DR ROUTER receive this LSA from other neighbors and flood the 
LSA. DR-OTHER floods to all

AllDRouters(224.0.0.6) and DR ROUTER floods to AllSPFRouters(224.0.0.5).



Thus DR-OTHER and DR ROUTER add the LSA to Neighbor BDR ROUTER's retransmit 
list as well as each other's retransmission list.

DR-OTHER receives the update from DR ROUTER and treats it as an implied 
acknowledgement. RFC2328 Section 13 Step (7).



Similarly DR ROUTER receives the update from DR-OTHER and treats it as an 
implied acknowledgement. RFC2328 Section 13 Step (7).



BDR ROUTER receives both the updates and processes the update from DR-OTHER 
first since it is acting as BDR on the subnet should add the LSA

to the retransmits lists of all neighbors on that interfaces(which in this case 
are DR-OTHER and DR ROUTER) but will not flood that LSA back out. RFC2328

Sections 13.3 Step (1d) and 13.3 Step (4)



BDR ROUTER then processes the update from DR ROUTER and it sends a direct ack  
to DR ROUTER.



*Note that a direct ack is sent to the unicast address and is addressed to 
DR ROUTER (Not expected behavior and this leads to OSPF re-transmissions).

*The section 13.5 and table 19 in RFC 2328 describes what BDR ROUTER should 
do in this case.

*The expected behavior is to send a delayed acknowledgment to 
AllSPFRouters, which removes the LSA from the retransmit lists of both

*DR-OTHER and DR ROUTER.



Root cause:   Juniper sends a direct ack instead of a delayed ack and that is 
the reason for the

retransmissions. The direct ack is sent to the unicast address of DR ROUTER 
where as a delayed ack would have been addressed to

AllSPFRouters and would have removed the LSA from the retransmission lists of 
both DR-OTHER and DR ROUTER.

DR ROUTER receives the direct ack from BDR ROUTER and removes the entry from 
the retransmit list for BDR ROUTER, where as DR-OTHER ends up retransmitting 
the LSA when the retransmit timer fires.





The following was taken from RFC 2328 which clearly explains the above 
situation:




 Action taken in state
   CircumstancesBackupAll other states
   _
   LSA  has No  acknowledgmentNo  acknowledgment
   been  flooded back   sent. sent.
   out receiving  in-
   terface  (see Sec-
   tion 13, step 5b).
   _
   LSA   is Delayed acknowledg-   Delayed   ack-
   more  recent  than   ment sent if adver-   nowledgment sent.
   database copy, but   tisement   received
   was   not  flooded   fromDesignated
   back out receiving   Router,  otherwise
   interfacedo nothing
   _
   LSA is a Delayed acknowledg-   No  acknowledgment
   duplicate, and was   ment sent if adver-   sent.
   treated as an  im-   tisement   received
   plied  acknowledg-   fromDesignated
   ment (see  Section   Router,  otherwise
   13, step 7a).do nothing
   _
   LSA is a Direct acknowledg-Direct acknowledg-
   duplicate, and was   ment sent.ment sent.
   not treated as  an
   implied   ack-
   nowledgment.
   _
   LSA's LS Direct acknowledg-Direct acknowledg-
   age is equal to  ment sent.ment sent.
   MaxAge, and there is
   no current instance
   of the LSA
   in the link state
   database, and none
   of router's neighbors
   are in states Exchange



I would have thought there might have been a cli statement to switch between 
strict RFC and the juniper implementation??
Any comments?

thanks

William

[j-nsp] Segment Routing ( SPRING )

[Jackson, William]

Hi



have been reading cisco documentation on this topic.

I was wondering if anyone knew the JUNOS status for this was?



Cant find much on the website etc etc.



many thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4300 and full-duplex-only

[Jackson, William]

The ex3300 does not have this limitation.


William Jackson

Gibtelecom 
Email: william.jack...@gibtele.com 

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Frank Sweetser
Sent: 23 September 2015 18:05
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX4300 and full-duplex-only

On 09/23/2015 09:47 AM, Phil Mayers wrote:
> If you mean "why it's only duplex limitations", I'm guessing the 
> device is missing the collision-detect/retransmit hardware for cost 
> reasons. 10/half is pretty rare these days and, in theory, they're 
> pitched as a datacentre device (though we have an IBM tape library which is 
> 10/half on it's management port).

When I first saw the details about the EX4300, my initial reaction was that it 
was built as a low cost 1Gb dongle for QFabric.

> You can force the link up by disabling autoneg, but that comes up 
> duplex-mismatched - 10/full at the EX end, 10/half at the device end.
>
> All very disappointing; we did not think to specify "must comply with 
> IEEE 802.3" in the RFP :o/


Even putting it in wouldn't have helped unless you verified it yourself anyway
- they list 802.3 support on page 19 of the data sheet:

http://www.juniper.net/assets/us/en/local/pdf/datasheets/1000467-en.pdf

That said, does anyone know if the EX3300 switches suffer from this same design 
decision?

-- 
Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken
___
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp