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: [email protected] [mailto:[email protected]] En nombre de ext [email protected] Enviado el: jueves, 07 de abril de 2011 06:28 a.m. Para: [email protected] Asunto: juniper-nsp Digest, Vol 101, Issue 17 Send juniper-nsp mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 ([email protected]) 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 <[email protected]> To: [email protected] Subject: [j-nsp] SNMP command: request snmp spoof-trap Message-ID: <[email protected]> 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" <[email protected]> To: "Keith" <[email protected]>, <[email protected]> Subject: Re: [j-nsp] SNMP command: request snmp spoof-trap Message-ID: <A9DC5022577F7E4BBB130C8A4D90888307AC7363@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: [email protected] [mailto:[email protected]] On Behalf Of Keith Sent: Wednesday, April 06, 2011 11:27 AM To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp ------------------------------ Message: 3 Date: Wed, 06 Apr 2011 11:51:49 -0700 From: Keith <[email protected]> To: Andy Vance <[email protected]> Cc: [email protected] Subject: Re: [j-nsp] SNMP command: request snmp spoof-trap Message-ID: <[email protected]> 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: [email protected] > [mailto:[email protected]] On Behalf Of Keith > Sent: Wednesday, April 06, 2011 11:27 AM > To: [email protected] > 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 <[email protected]> To: Chris Tracy <[email protected]> Cc: [email protected] Subject: Re: [j-nsp] Juniper "firewall policer" inner workings Message-ID: <[email protected]> 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 <[email protected]>: > 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 <[email protected]> > Energy Sciences Network (ESnet) > Lawrence Berkeley National Laboratory > > ------------------------------ Message: 5 Date: Thu, 07 Apr 2011 12:05:03 +0200 (CEST) From: [email protected] To: [email protected] Cc: [email protected] Subject: Re: [j-nsp] Juniper "firewall policer" inner workings Message-ID: <[email protected]> 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, [email protected] ------------------------------ Message: 6 Date: Thu, 07 Apr 2011 12:07:19 +0200 From: Bj?rn Tore <[email protected]> To: juniper-nsp <[email protected]> Subject: [j-nsp] SFP-T for EX Message-ID: <[email protected]> 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 <[email protected]> To: [email protected] Subject: Re: [j-nsp] SFP-T for EX Message-ID: <[email protected]> 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: [email protected] -- dr@IRCnet -- PGP: 0xA85C8AA0 ------------------------------ Message: 8 Date: Thu, 7 Apr 2011 06:40:23 -0400 From: "Paul Stewart" <[email protected]> To: "=?iso-8859-1?Q?'Bj=F8rn_Tore'?=" <[email protected]>, "'juniper-nsp'" <[email protected]> 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: [email protected] [mailto:[email protected]] 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp ------------------------------ Message: 9 Date: Thu, 7 Apr 2011 13:27:50 +0200 From: G?khan G?m?? <[email protected]> To: [email protected] Subject: [j-nsp] Unable to transmit traffic after software upgrade Message-ID: <[email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp End of juniper-nsp Digest, Vol 101, Issue 17 ******************************************** _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
