Re: [j-nsp] GRE interfaces doesn't show up

. Regards, Wojciech czw., 29 sie 2019 o 23:40 Jeff Meyers mailto:jeff.mey...@gmx.net>> napisał(a): Hi Jim, thanks for the quick reply! However, unfortunately that did not do the job and the interface still doesn't show up, neither with 1g nor 10g for the bandwidth:

Re: [j-nsp] GRE interfaces doesn't show up

pic tunnel-services bandwidth <10g - 100g> Be advised that this will burn a 10 gig port for each 10 gigs you assign to tunnel-services. Regard, Clay Haynes Sent from my iPhone On 29 Aug 2019, at 10:50, Jeff Meyers wrote: Hi list, I'm trying to setup a GRE tunnel interface on a

[j-nsp] GRE interfaces doesn't show up

Hi list, I'm trying to setup a GRE tunnel interface on a MX480 with DPCE linecards. I want to use xe-5/4/0 and have therefore configured this interface under 'edit chassis' for tunnel-services. The interface vanishes as expected. I have then configured the interface gr-5/4/0 with unit 0 but is

Re: [j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

Thanks, worked! Am 21.12.2018 um 02:05 schrieb Olivier Benghozi: PR1270686 restart statistics-service Le 21 déc. 2018 à 01:23, Jeff Meyers a écrit : Dec 21 01:20:40 fra4-cr2 mib2d[67435]: SNMP_EVLIB_FAILURE: PFED ran out of transfer credits with PFE.Failed to get stats. ifl index: 373 I

[j-nsp] SNMP_EVLIB_FAILURE - snmp not working anymore

Hi, we had a faulty DPCE-R in an older MX240 a few days ago and replaced it during operation. Since inserting the spare module, we cannot snmp query the device anymore and seeing those entries a lot: Dec 21 01:20:25 fra4-cr2 mib2d[67435]: SNMP_EVLIB_FAILURE: PFED ran out of transfer

Re: [j-nsp] [c-nsp] LACP between router VMs

Hi Adam, LACP packets (so called slow packets in the linux kernel) are never forwarded by the bridging code. If it didn't change in the last ~2 years, you will have to hack your kernel in order to let them pass. It's actually only a minor change in a couple of lines. The same applies btw to

Re: [j-nsp] FIB size at CFEB-E M7i

show chassis cfeb0 (or alike) is the most interesting info since it shows the SRAM usage on this very, very old machine. This is what actually limits the number of routes in the FIB. But 96% on the RE is not funny either and a replacement should be scheduled on short notice. Best is to skip

Re: [j-nsp] R: EX4550: storm-control on commit

Hi, I also have 2 x EX4550 in VC with storm-control enabled, but it never happens to me to get that message on commit; I have this configuration for storm-control: set ethernet-switching-options storm-control interface all I am wondering what is your configuration for the ae2.0 interface:

[j-nsp] EX4550: storm-control on commit

Hello everybody, we are having a kind of strange haviour here. It's not really an issue but at least a curiousity. On a couple of EX4550 in VC we have storm-control enabled. This works fine so far. But on every commit, we see a "storm-control in effect" message in our logs: Jan 26 11:50:45

Re: [j-nsp] EX4550: LACP channels short lost after commit

by default), it will probably work around it efficiently... Suggestion for your ae config: aggregated-ether-options { link-speed 10g; lacp { active; periodic slow; } } Le 30 oct. 2015 à 14:38, Jeff Meyers <jeff.mey...@gmx.net <mailto:jeff.mey...@gmx.net>

[j-nsp] EX4550: LACP channels short lost after commit

Hi everybody, yesterday we had a very small hickup on a bunch of EX4550 doing Layer2 only in a Virtual-Chassis. According to the logfiles, there were some LACP changes on multiple independent channels on various fpcs so I couldn't spot just one VC member as a source. Now, just 1 hour ago, I

Re: [j-nsp] jtree0 Memory full on MX480?

Thank's for clearification, that helps. So the SCB itself is only responsible for the available bandwidth per slot but is not and will never be a memory limitation? Best, Jeff Am 22.07.2015 um 23:51 schrieb Chris Kawchuk: On 23/07/2015, at 1:30 AM, Jeff Meyers jeff.mey...@gmx.net wrote

Re: [j-nsp] jtree0 Memory full on MX480?

Hi, I see you're running DPC cards, have you considered shifting those links onto an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda yadda yadda =)..) DPC was EOL a while ago, and everything has been Trio (and now Trio-NG on the new -NG cards coming out now). As the FIB is pushed

Re: [j-nsp] jtree0 Memory full on MX480?

Hi, thanks for the hint, didn't know about that option. This will certainly safe us if we are running in to limits. We don't have too many filters, mostly the basic stuff to protect the RE and a few filters on some vlans with basic white- and/or blacklisting. So really nothing fance although

Re: [j-nsp] jtree0 Memory full on MX480?

? Best Regards, -Phil On Jul 21, 2015, at 7:23 PM, Jeff Meyers jeff.mey...@gmx.net wrote: Hi Phil, sure: {master} jeff@cr0 show configuration | display set | match rpf-check {master} nico@FRA4.cr0 show version Hostname: cr0 Model: mx480 JUNOS Base OS boot [11.4R9.4] JUNOS Base OS Software Suite

[j-nsp] jtree0 Memory full on MX480?

Hello list, we seem to be running into limits with a MX480 with RE-2000 and 2x DPCE-4XGE-R since we are seeing these new messages in the syslog: Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree0-seg0 Type:free-dwords Available:83072 is less than LWM limit:104857,

Re: [j-nsp] jtree0 Memory full on MX480?

contribute to the problem. Best Regards, -Phil Rosenthal On Jul 21, 2015, at 6:56 PM, Jeff Meyers jeff.mey...@gmx.net wrote: Hello list, we seem to be running into limits with a MX480 with RE-2000 and 2x DPCE-4XGE-R since we are seeing these new messages in the syslog: Jul 22 00:50:36 cr0

Re: [j-nsp] Proxmox with Multicast Juniper EX

Hi Tore, However these intial IGMP membership reports are not forwarded to the EX4550, as it is not a multicast-router interface (from the EX4200s' points of view, at least). So the EX4550 won't be able to learn of the existence of the multicast group at all. Also, since the uplink to the

[j-nsp] Proxmox with Multicast Juniper EX

Hi list, I hope to get some experience and tips from you regarding the usage of a Proxmox cluster using Multicast in a (juniper-based) network. Since our multicast experience is quite low and was never required before Proxmox became quickly popular and is meanwhile widely used by our

Re: [j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hi Alex, I think we are missing some important details here. AFAIK, in order to detect MAC moves, the port must be in a bridge-domain/VPLS instance. So Your MX480 ae0 must be a L2/bridged port, not a L3/routed one. yes, that is the case - historically actually. In the past we migrated from

Re: [j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hi Patrick, The problem is that any broadcast packets across the loop get amplified pretty quickly and this propagates across the entire broadcast domain (all related switches that have trunks containing affected vlans for transit). of course, I always forget the 3rd party broadcasts when

Re: [j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hi Matt, conf t fault-finder broadcast-storm sorry should be fault-finder broadcast-storm sensitivity high I think the ProCurve-proprietary loop-protect on the downstream port of the 2824 might be a better fit here. See eg

Re: [j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hi Michele, So STP didn't protect you and you faced the loop. okay, but how is this a loop from the perspective of the switches in the higher levels? The Procurve sees packets coming in from the same port where they were sent out. Isn't that by definition not a loop? When the loop

Re: [j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hi David, Once you draw your diagram correctly you'll see what you're up against (and it ain't pretty). Juniper MX480 no RSTP || ae0 || Juniper EX4550 VC RSTP bridge id 0 || ae0 || Juniper EX4200 VC RSTP

[j-nsp] Network, trouble after customer created a loop *inside* a VM host

Hello everybody, I'm writing to this list because I can't seem to find the reason for what we saw twice meanwhile. Here is the setup: Juniper MX480no RSTP || ae0 || Juniper EX4550 VC RSTP bridge id 0 || ae0 || Juniper

[j-nsp] Weird behaviour in network after customer created a bridge inside a Windows VM

Hi everybody, recently we saw a strange bahviour in our network. A customer with a Proxmox server had a Windows 2k8 VM with 2 virtual NICs (both bridged to eth0 of the server which faces the internet) and bridged them together INSIDE the VM. This caused immediately high latency and partial

Re: [j-nsp] Weird behaviour in network after customer created a bridge inside a Windows VM

I'm not aware of any inherent loop protection when running a VC setup that substitutes for STP. This is not the case. VC is being used as well as RSTP. VC for the 3 virtual-chassis configuration (seperate from each other, one VC with 2x EX4550 and 2x VC with 2x EX4200) and RSTP for the

[j-nsp] Network design problem in a bridged setup with 2x Juniper MX and some Brocade SuperX

Hello list, I'm currently a little stuck and might need some help in order to decide how to improve the current setup. We are running a network where all customer vlans are bridged because the same Vlan is usually required in different areas in the network. This is the setup: Room A:

Re: [j-nsp] MPLS for management VPN question

Truman Boyes schrieb: Hi, thanks for your answer so far. You then need to define a route-distinguisher, and route targets (or simply vrf-target under the VRF) to import/export the routes for this VPN from other PEs. Can you provide an example for that? That would be a L3VPN, right? Why

[j-nsp] MPLS for management VPN question

Hi, we currently have a small number of PoPs, each equippped with a Juniper M-series router. On each PoP we use a local Vlan 100 for the management with RFC1918 ip adresses - 192.168.0.0/16. Unfortunately, this results in scalability problems as the network grows since it's not possible to

Re: [j-nsp] VRRP with Juniper, what is needed around?

Prasanna Kumar A.S schrieb: Hi, I guess your topology with two m10s will look this Uplink1 - +---+ - +-+ Uplink2 - | M10 1 |ae0| Core-Switch | - Customers +---+ - + | | | Uplink1 - +---+ - + |

Re: [j-nsp] VRRP with Juniper, what is needed around?

Pekka Savola schrieb: Hi, Strictly speaking, you don't need full tables from upstream. For example, a default route or default + some more specifics is also OK. of course, yes. But for a little traffic engineering we prefere full-tables here :-) In your simple setup, you don't

[j-nsp] VRRP with Juniper, what is needed around?

Hello list, we operate a relatively small network with one Juniper M10 router for everything. Since availability becomes more and more important, we want to raise this by installing a second M10 with VRRP. Our current setup is pretty simple: Uplink1 - +-+ - +-+ Uplink2 - |