[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