[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 12:10:26 EDT 2011
Hello Tarike thanks for your response.
But I want to be more specific:
***I have a m10i Route-reflector with 2'090.000 Internet routes.
>show route summary
inet.0: 6187 destinations, 6187 routes (6187 active, 0 holddown, 0 hidden)
Direct: 4 routes, 4 active
Local: 4 routes, 4 active
IS-IS: 6179 routes, 6179 active
inet.3: 6179 destinations, 6179 routes (6179 active, 0 holddown, 0 hidden)
LDP: 6179 routes, 6179 active
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Direct: 1 routes, 1 active
mpls.0: 6128 destinations, 6128 routes (6128 active, 0 holddown, 0 hidden)
LDP: 6128 routes, 6128 active
bgp.l3vpn.0: 1046055 destinations, 2092108 routes (1046055 active, 0 holddown, 0 hidden)
BGP: 2092143 routes, 1046072 active
***With that amount of routes my RE is 97% of memory utilization
master}
Routing Engine status:
Slot 0:
Current state Master
Election priority Master
Temperature 32 degrees C / 89 degrees F
CPU temperature 35 degrees C / 95 degrees F
DRAM 1536 MB
Memory utilization 97 percent
CPU utilization:
User 1 percent
Background 0 percent
Kernel 4 percent
Interrupt 0 percent
Idle 95 percent
Model RE-850
Serial ID 9009052601
Start time 2011-03-15 13:02:43 CST
Uptime 21 days, 13 hours, 57 minutes, 31 seconds
Last reboot reason Router rebooted after a normal shutdown.
Load averages: 1 minute 5 minute 15 minute
0.23 0.12 0.07
**And I have many outputs of log messages
rpd[1943]: %DAEMON-3-RPD_OS_MEMHIGH: Using 1549648 KB of memory, 103 percent of available
**And about system process, the rpd is using 1275M of 1594M :(
show system processes extensive | no-more
last pid: 31903; load averages: 0.18, 0.18, 0.14 up 22+18:23:02 08:26:55
114 processes: 10 running, 88 sleeping, 16 waiting
Mem: 1238M Active, 108M Inact, 104M Wired, 43M Cache, 69M Buf, 2320K Free
Swap: 2048M Total, 666M Used, 1382M Free, 32% Inuse
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
11 root 1 171 52 0K 12K RUN 517.6H 89.60% idle
1216 root 2 8 -88 34096K 2300K nanslp 16.8H 2.29% chassisd
9 root 1 -16 0 0K 12K psleep 10:14 1.90% pagedaemon
1943 root 1 96 0 1594M 1275M RUN 393:10 1.12% rpd
1966 root 2 8 0 13416K 1812K nanslp 53:25 0.00% pfed
About this issue is my question about amount the IPv4 Bgp routes.
Best Regards,
Edinson M. Serrano Samacá
Mobile: 5544483952
-----Mensaje original-----
De: ext Tarique A. Nalkhande - BMC [mailto:t.nalkhande.bmc at mobily.com.sa]
Enviado el: jueves, 07 de abril de 2011 10:46 a.m.
Para: Serrano Samaca, Edinson (EXT-Other - MX/Mexico City); juniper-nsp at puck.nether.net
Asunto: RE: Max. Bgp routes for M10i RE-850 1536MB
AFAIK, RIB capacity (IPv4) for RE-850-1536 is ~6M.
Thanks & Regards
Tarique Abbas Nalkhande
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Serrano Samaca, Edinson (EXT-Other - MX/Mexico City)
Sent: 07 April, 2011 4:13 PM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Max. Bgp routes for M10i RE-850 1536MB
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
********************************************
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only.
More information about the juniper-nsp
mailing list