[j-nsp] Max. Bgp routes for M10i RE-850 1536MB
Serrano Samaca, Edinson (EXT-Other - MX/Mexico City)
edinson.serrano_samaca.ext at nsn.com
Thu Apr 7 09:13:28 EDT 2011
Hello, somebody could help us to get the maximum bgp ipv4 routes for a m10i with RE850 and 1536 MB? We tried to searching at juniper website but we do not find.
Best Regards,
Edinson M. Serrano Samacá
Mobile: 5544483952
-----Mensaje original-----
De: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] En nombre de ext juniper-nsp-request at puck.nether.net
Enviado el: jueves, 07 de abril de 2011 06:28 a.m.
Para: juniper-nsp at puck.nether.net
Asunto: juniper-nsp Digest, Vol 101, Issue 17
Send juniper-nsp mailing list submissions to
juniper-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/juniper-nsp
or, via email, send a message with subject or body 'help' to
juniper-nsp-request at puck.nether.net
You can reach the person managing the list at
juniper-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of juniper-nsp digest..."
Today's Topics:
1. SNMP command: request snmp spoof-trap (Keith)
2. Re: SNMP command: request snmp spoof-trap (Andy Vance)
3. Re: SNMP command: request snmp spoof-trap (Keith)
4. Re: Juniper "firewall policer" inner workings (Martin T)
5. Re: Juniper "firewall policer" inner workings (sthaug at nethelp.no)
6. SFP-T for EX (Bj?rn Tore)
7. Re: SFP-T for EX (Daniel Roesen)
8. Re: SFP-T for EX (Paul Stewart)
9. Unable to transmit traffic after software upgrade (G?khan G?m??)
----------------------------------------------------------------------
Message: 1
Date: Wed, 06 Apr 2011 11:26:32 -0700
From: Keith <kwoody at citywest.ca>
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] SNMP command: request snmp spoof-trap
Message-ID: <4D9CB058.9040700 at citywest.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Just going through some SNMP things on the MX, 10.4.
When doing a request snmp spoof-trap <oid> does the box
actually send an SNMP trap to any configured targets?
SNMP traps are setup for rmon-alarm and chassis alerts.
I can see the SNMP trap being generated in the log file
on the MX, but using Wireshark, I do not see any traps
coming into the host I have setup to receive traps.
I just want to be sure before I start digging through the
trap host configs and PIX config in front of the NMS
to make sure I have them setup correctly.
Thanks,
Keith.
------------------------------
Message: 2
Date: Wed, 6 Apr 2011 12:37:34 -0600
From: "Andy Vance" <andy.vance at 360.net>
To: "Keith" <kwoody at citywest.ca>, <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] SNMP command: request snmp spoof-trap
Message-ID:
<A9DC5022577F7E4BBB130C8A4D90888307AC7363 at sbmtexmb03.360networks.local>
Content-Type: text/plain; charset="us-ascii"
I assume if it is in the logs as a trap, that a trap was indeed sent.
Since the trap should have originated from the RE, you should be able to
see it leave the router with 'monitor traffic interface <interface>' on
the interface that is the best route back to your NMS.
Cheers,
Andy
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Keith
Sent: Wednesday, April 06, 2011 11:27 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] SNMP command: request snmp spoof-trap
Just going through some SNMP things on the MX, 10.4.
When doing a request snmp spoof-trap <oid> does the box
actually send an SNMP trap to any configured targets?
SNMP traps are setup for rmon-alarm and chassis alerts.
I can see the SNMP trap being generated in the log file
on the MX, but using Wireshark, I do not see any traps
coming into the host I have setup to receive traps.
I just want to be sure before I start digging through the
trap host configs and PIX config in front of the NMS
to make sure I have them setup correctly.
Thanks,
Keith.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
------------------------------
Message: 3
Date: Wed, 06 Apr 2011 11:51:49 -0700
From: Keith <kwoody at citywest.ca>
To: Andy Vance <andy.vance at 360.net>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SNMP command: request snmp spoof-trap
Message-ID: <4D9CB645.5090004 at citywest.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 4/6/2011 11:37 AM, Andy Vance wrote:
> I assume if it is in the logs as a trap, that a trap was indeed sent.
>
> Since the trap should have originated from the RE, you should be able to
> see it leave the router with 'monitor traffic interface<interface>' on
> the interface that is the best route back to your NMS.
>
> Cheers,
> Andy
>
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Keith
> Sent: Wednesday, April 06, 2011 11:27 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] SNMP command: request snmp spoof-trap
>
> Just going through some SNMP things on the MX, 10.4.
>
> When doing a request snmp spoof-trap<oid> does the box
> actually send an SNMP trap to any configured targets?
>
> SNMP traps are setup for rmon-alarm and chassis alerts.
>
> I can see the SNMP trap being generated in the log file
> on the MX, but using Wireshark, I do not see any traps
> coming into the host I have setup to receive traps.
Thanks Andy. Yes using the monitor traffic command I can definitely
see the trap being sent out to the NMS.
So it is on the PIX and/or target host.
Thanks,
Keith
------------------------------
Message: 4
Date: Thu, 7 Apr 2011 12:20:29 +0300
From: Martin T <m4rtntns at gmail.com>
To: Chris Tracy <ctracy at es.net>
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper "firewall policer" inner workings
Message-ID: <BANLkTimShAV9SyhTaRugy_xZU06_yGVk1w at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Stefan,
I see. If policer counts in the IPv4 header as well, it would do
(51021*28)/(1024*1024)=1.4MB which is rather close to 71.5-69.8=1.7MB.
Could you please explain this "larger buffer to smooth things out"
argument? As I understand, in simple terms, larger buffer is able to
hold larger amount of received data in memory so in case of a burst,
more data is held in the memory buffer and processed bit later. If the
buffer is very small, buffer memory would be filled fast and even a
short burst would be noticed as a packet loss. Right?
Massimo,
platform is M10i(10.4R3.4) which has CFEB with part number
750-010465(Internet Processor II). On a software side, it's:
root> show pfe version extensive
PFED release 10.4R3.4 built by builder on 2011-03-19 21:13:59 UTC
warth.juniper.net:/volume/build/junos/10.4/release/10.4R3.4/obj-i386/junos/usr.sbin/pfed
root>
Christopher,
as in discussion with Stefan turned out, the policer indeed seems to
count the whole IP packet(including the L3 header). This "There is
also granularity in the policer. When it drops, it cannot drop a
fractional packet...." is a good point as well. Thanks!
Chris,
Iperf UDP is indeed very bursty- I ran "iperf -c 192.168.2.1 -u -fm
-t60 -d -b 10m" and at the same time did "tcpdump -w iperf_dump.pcap
host 192.168.2.1". Then printed deltas between current and previous
line on each dump line(-ttt), printed only this first deltas
column(awk '{print $1}'), sorted those deltas by numerical value(sort
-n) and finally print uniq values with the count of the number of
times the line occurred in the dumpfile. Most popular values are
following:
[root@ ~]# tcpdump -ttt -r iperf_dump.pcap | awk '{print $1}' | sed
's/.*\.//' | sort -n | uniq -c | egrep ^[0-9]{4}
reading from file iperf_dump.pcap, link-type EN10MB (Ethernet)
1082 000010
11344 000011
12154 000012
4037 000013
1902 000014
1278 000015
1056 001173
1224 001174
1465 001175
1548 001176
1398 001177
1059 001178
[root@ ~]#
However, if I ran "nuttcp -4 -u -Ri10M -v -T1m -w2m 192.168.2.1" and
at the same time did "tcpdump -w nuttcp_dump.pcap host 192.168.2.1",
the most popular delta values between packets are way higher than with
Iperf:
[root@ ~]# tcpdump -ttt -r nuttcp_dump.pcap | awk '{print $1}' | sed
's/.*\.//' | sort -n | uniq -c | less | egrep ^[0-9]{4}
reading from file nuttcp_dump.pcap, link-type EN10MB (Ethernet)
2488 000817
12746 000818
22039 000819
15433 000820
4837 000821
[root@ ~]#
As you said, in case of nuttcp UDP flood, packets are much more evenly sent :)
Could you explain this "Your interface speed appears to be GigE, so
you are bursting out at line rate and relying on the buffers in the
router to accommodate these line-rate bursts. You should have
different results if you connected the host at FastE vs GigE." a bit
further? I mean why should I see different results with 100BASE-TX or
10BASE-T?
In addition, how to start nuttcp in both directions simultaneously?
"nuttcp -4 -u -Ri10M -v -T1m -w2m 192.168.2.1" only sends from my
nuttcp client to nuttcp server.
regards,
martin
2011/4/4 Chris Tracy <ctracy at es.net>:
> Martin,
>
>> It might also be an idea to measure using different values of burst size.
>> I personally find the Juniper manuals to be somewhat lacking here...
>
> You may want to try a perf testing application which is less bursty. ?iperf UDP traffic is very bursty -- it does not go out of its way to evenly space packets. ?You can easily see this by capturing the perf traffic, then processing it with something like tcpdump -ttt -r file.pcap | ?awk '{print $1}' | sed -e 's/00:00:00.//' | sort -n | uniq -c > deltas. ?In the 'deltas' histogram that results you should see the overwhelming majority of the packets in your flow are spaced extremely close together (e.g., near the 0 end).
>
> Your interface speed appears to be GigE, so you are bursting out at line rate and relying on the buffers in the router to accommodate these line-rate bursts. ?You should have different results if you connected the host at FastE vs GigE.
>
> nuttcp is a perf testing tool which, by default, is much less bursty -- you can control whether it bursts or not. ?Go to www.nuttcp.org or grab the latest rev from http://lcp.nrl.navy.mil/nuttcp/beta/nuttcp-7.1.3.c.
>
> Use the -Ri10M option for a non-bursty 10Mbps flow. ?You can add /# to make it burst # number of packets. ?(This can be useful for seeing how "much" bursty traffic a device can take before it exhausts its buffers when there is a speed transition, for example..)
>
> ? ? ? ?-Ri#[/#] instantaneous rate limit with optional packet burst
>
> If you look closely at the CPU usage of iperf vs nuttcp, you will find nuttcp (unlike iperf) consumes 100% of the sender's CPU when running in UDP mode because it puts itself into a very tight loop to get the most precise timing.
>
> -Chris
>
> --
> Chris Tracy <ctracy at es.net>
> Energy Sciences Network (ESnet)
> Lawrence Berkeley National Laboratory
>
>
------------------------------
Message: 5
Date: Thu, 07 Apr 2011 12:05:03 +0200 (CEST)
From: sthaug at nethelp.no
To: m4rtntns at gmail.com
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Juniper "firewall policer" inner workings
Message-ID: <20110407.120503.74721454.sthaug at nethelp.no>
Content-Type: Text/Plain; charset=us-ascii
> I see. If policer counts in the IPv4 header as well, it would do
> (51021*28)/(1024*1024)=1.4MB which is rather close to 71.5-69.8=1.7MB.
> Could you please explain this "larger buffer to smooth things out"
> argument? As I understand, in simple terms, larger buffer is able to
> hold larger amount of received data in memory so in case of a burst,
> more data is held in the memory buffer and processed bit later. If the
> buffer is very small, buffer memory would be filled fast and even a
> short burst would be noticed as a packet loss. Right?
A policer will never delay packets, and will never change the interval
between packets - to do this you need shaping not policing.
The policer burst size will change the measurement interval used - thus
a bigger burst size means you will measure (average) the traffic over a
longer interval - you can potentially get more bps through the policer.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
------------------------------
Message: 6
Date: Thu, 07 Apr 2011 12:07:19 +0200
From: Bj?rn Tore <bt at paulen.net>
To: juniper-nsp <juniper-nsp at puck.nether.net>
Subject: [j-nsp] SFP-T for EX
Message-ID: <4D9D8CD7.7030207 at paulen.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
All,
I am trying to find some third-party SFP to run 100/1000BaseT on the EX.
So far I can get either 100M or 1000M - but not both in the same SFP.
Anyone have a tip on a working model?
--
Bj?rn Tore
------------------------------
Message: 7
Date: Thu, 7 Apr 2011 12:30:31 +0200
From: Daniel Roesen <dr at cluenet.de>
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SFP-T for EX
Message-ID: <20110407103031.GA11785 at srv03.cluenet.de>
Content-Type: text/plain; charset=iso-8859-1
On Thu, Apr 07, 2011 at 12:07:19PM +0200, Bj?rn Tore wrote:
> I am trying to find some third-party SFP to run 100/1000BaseT on the EX. So
> far I can get either 100M or 1000M - but not both in the same SFP. Anyone
> have a tip on a working model?
http://www.flexoptix.net/en/transceiver/compatible-transceiver/formfaktor.html
SFP-COP-0002 should fit, as long as the EX model supports multirate.
Best to drop them an email and ask for deployment experience among their
customers.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
------------------------------
Message: 8
Date: Thu, 7 Apr 2011 06:40:23 -0400
From: "Paul Stewart" <paul at paulstewart.org>
To: "=?iso-8859-1?Q?'Bj=F8rn_Tore'?=" <bt at paulen.net>, "'juniper-nsp'"
<juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] SFP-T for EX
Message-ID: <002401cbf510$37947870$a6bd6950$@org>
Content-Type: text/plain; charset="iso-8859-1"
Yes, you are looking for EX-SFP-1GE-T by official Juniper pricelist - but
sometimes there are other part numbers that will look something like
SFP-1GE-FE-E-T for example indicating tri-rate copper optic.
Would contact your 3rd party vendor and ask them though - Prolabs (which we
just began using on a trial basis) has support for them so I'm sure many
other 3rd parties do too.
Paul
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Bj?rn Tore
Sent: Thursday, April 07, 2011 6:07 AM
To: juniper-nsp
Subject: [j-nsp] SFP-T for EX
All,
I am trying to find some third-party SFP to run 100/1000BaseT on the EX.
So far I can get either 100M or 1000M - but not both in the same SFP.
Anyone have a tip on a working model?
--
Bj?rn Tore
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
------------------------------
Message: 9
Date: Thu, 7 Apr 2011 13:27:50 +0200
From: G?khan G?m?? <ggumus at gmail.com>
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Unable to transmit traffic after software upgrade
Message-ID: <BANLkTiniSogux7cTusHjW=4a8pGsspfukA at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
I need some advice.
We are currently in a process of upgrading our Juniper MX960 series routers.
Some of our customers are not able to transmit traffic after we performed
maintenance.
Circuits are connected as Layer2 circuit with ethernet-ccc configuration.
It seems circuits are hanging off. It is not a negotiation issue first of
all.
After we shut/ no shut interfaces, customers are able to transmit traffic.
This issue is not occuring on all Layer 2 ccc circuits.In order to determine
which customer is not able to transmit traffic, either we need to monitor
traffic on all interfaces or wait for customer complaints.
My question is,
Is there any other way to determine this situation?
Thanks and regards,
Gokhan Gumus
------------------------------
_______________________________________________
juniper-nsp mailing list
juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
End of juniper-nsp Digest, Vol 101, Issue 17
********************************************
More information about the juniper-nsp
mailing list