[j-nsp] Visio Stencil with MX104

[Brad Fleming]

Does anyone have a Visio stencil that includes the MX104 series and the
various hardware options (PSUs, REs, etc)? The ones most easily found on
the Juniper website don't include that platform as near as I can tell.

Thanks for any help or suggestions!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] IPv6 flow routes

[Brad Fleming]

Does Junos support creation of IPv6 flow routes?

This taken from an MX10 in our lab running 16.1R1.7:

root@lab# show routing-options flow
route junk {
then discard;
match destination 2001:49d0::1/128;
}
[edit]
root@lab# commit check
[edit routing-options flow route junk]
  'match'
RTFLOW: invalid address


I don't see an option to create a flow route under any other protocol
family so I'm assuming they're all supposed to go under
routing-options>flow (?).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Origin Validation on MX80

[Brad Fleming]

Seems to drop a little (not as much as I thought). What I found a little
odd is that simply disabling the import policy on the BGP peer didn't
result in decreased CPU after 15mins. I rebooted the MX80 and after the
~15mins of BGP flooding and convergence the CPU has calmed down a little.

The RPKI you guys have enabled; is it just to test building the validation
database?

On Wed, Aug 17, 2016 at 9:54 AM, Mark Tinka <mark.ti...@seacom.mu> wrote:

>
>
> On 17/Aug/16 16:46, Brad Fleming wrote:
>
> Hello all,
>
> We’ve been playing around a bit with BGP origin validation on a lab MX80.
> While everything seems to work CPU load is pretty high. We’ve observed this
> elevated CPU with both 14.3R and 16.1R1.7. Just wondering if
> anyone else experienced similar or whether we’ve configured something
> sideways and caused a problem.
>
>
> We have RPKI enabled on our MX routers (including the MX80), but not
> performing any policy.
>
> Does your CPU utilization reduce if you disable the policies that work on
> RPKI?
>
> Mark.
>



-- 
Brad Fleming
bdfle...@gmail.com
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Origin Validation on MX80

[Brad Fleming]

Hello all,

We’ve been playing around a bit with BGP origin validation on a lab MX80.
While everything seems to work CPU load is pretty high. We’ve observed this
elevated CPU with both 14.3R and 16.1R1.7. Just wondering if
anyone else experienced similar or whether we’ve configured something
sideways and caused a problem.

lab-mx80> show version
Junos: 16.1R1.7


lab-mx80> show validation session
Session  State   Flaps Uptime
#IPv4/IPv6 records
   Up  0   00:31:03 24360/3555


lab-mx80> show bgp summary
  97906 66   0   0
29:44 615844/615844/615844/0 0/0/0/0


lab-mx80> show chassis routing-engine
Load averages: 1 minute   5 minute  15 minute
   0.94   1.00   0.92

lab-mx80> show system processes summary
  PID USERNAME   THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
 2016 root 3  760   476M   385M RUN 29:23 93.99% rpd


set policy-options policy-statement rpki-validation term valid from
protocol bgp
set policy-options policy-statement rpki-validation term valid from
validation-database valid
set policy-options policy-statement rpki-validation term valid then
validation-state valid
set policy-options policy-statement rpki-validation term valid then
community set valid
set policy-options policy-statement rpki-validation term valid then accept
set policy-options policy-statement rpki-validation term invalid from
protocol bgp
set policy-options policy-statement rpki-validation term invalid from
validation-database invalid
set policy-options policy-statement rpki-validation term invalid then
validation-state invalid
set policy-options policy-statement rpki-validation term invalid then
community set invalid
set policy-options policy-statement rpki-validation term invalid then accept
set policy-options policy-statement rpki-validation term else then
community set unknown
set policy-options policy-statement rpki-validation term else then accept


We don’t have a bigger MX chassis spare so MX240-480-960 boxes might have
enough horsepower to get through this. Anyone else tried playing with
origin validation on Juniper gear yet? If so, did you get similar results?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Core network design for an ISP

[Brad Fleming]

Might reach out to your Juniper SE.. I believe they have some internal “gold 
configs” for different sized ISPs that have been well tested internally. One of 
their configs might make a good base to start from.


> On Mar 24, 2016, at 6:57 PM, Matthew Crocker  wrote:
> 
> 
> 
> Hello,
> 
> What is the current best practice for carrying full tables in MX series 
> routers?   I have 3 new MX480s coming soon and will use them to rebuild my 
> core network (currently a mix of MX240 & MX80 routers).  MPC-NG (w/ 20x1g & 
> 10x10g MICS )& RE-S-X6-64G-BB.
> 
> I’m running MPLS now and have full tables in the default route instance.   
> Does it make more sense (i.e. more secure core) to run full tables in a 
> separate virtual-router?  I’ve been doing this small ISP thing for 20+ years, 
> Cisco before, Juniper now, I’ve always bashed my way through.
> 
> Looking for a book, NANOG presentation or guide on what is current best 
> practice with state of the art gear.
> 
> MPLS?  BGP? IS-IS? LDP? etc.
> 
> The network is a triangle  (A -> B -> C -> A),  MX480 at each POP,  10g 
> connections between POPs,  10g connections to IX & upstreams.  Most customers 
> are fed redundantly from A & B
> 
> Thanks
> 
> -Matt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Slow performance of the KRT queue

[Brad Fleming]

Welcome to running a full table on the MX104. This is exactly what we found 
when lab testing the devices. After months of working with JTAC we never found 
a workaround. After several software updates and major configuration changes 
there was never a way to resolve the issues. During a major convergence event 
impacting a significant amount of the routes in a full table it took many 
minutes to get RIB and FIB sync’d. In the meantime traffic was getting 
blackholed. In the end we had to give up and roll bigger MX gear with much 
bigger REs (and much more expensive).



> On Feb 3, 2016, at 3:21 PM, Vincent Bernat  wrote:
> 
> Hey!
> 
> I have a pair of MX104. Each one is receiving a full view and a default
> through an external BGP session. They share an iBGP session. They
> redistribute the default in OSPF (with a higher metric when the default
> comes through the iBGP session). Nothing fancy.
> 
> If I shut the upstream port of one of the MX, the session goes down and
> the RIB is quickly updated. Unfortunately, the KRT is quite slow to be
> updated. A "show krt queue" shows there are many
> deletion/addition/changes queued and they take about 2 minutes to be
> processed.
> 
> Unfortunately, during this time, I have a lot of more specific routes
> still pointing to a non-existant hop:
> 
> vbe@net-edge004.dk2# run show route 138.231.136.1 extensive table 
> public.inet.0 | no-more
> 
> public.inet.0: 571546 destinations, 996364 routes (425305 active, 321183 
> holddown, 571058 hidden)
> 138.231.0.0/16 (2 entries, 1 announced)
> TSI:
> KRT queued (pending) change
>  138.231.0.0/16 -> {1.1.1.1}=>{indirect(1048578)}
> Page 0 idx 1, (group v4-IBGP type Internal) Type 3 val 22b9ccb8 (grp rto)
>   Advertised metrics:
> No metrics
> (Queued)
>   Enqueued metrics 1: (for peers 0001 3.3.3.3)
> Flags: Nexthop Change
> Nexthop: Self
> MED: 10
> Localpref: 100
> AS path: [61098] 25091 2200 2426 I
> Communities: 25091:22413 25091:24115
> [...]
> Path 138.231.0.0 from 159.100.255.231 Vector len 4.  Val: 1
>*BGPPreference: 140/-101
>Next hop type: Indirect
>Address: 0x177743a0
>Next-hop reference count: 877603
>Source: 3.3.3.3
>Next hop type: Router, Next hop index: 1048577
>Next hop: 2.2.2.2 via xe-2/0/3.100
>Session Id: 0x18
>Next hop: 2.2.2.0 via xe-2/0/2.100, selected
>Session Id: 0x17
>Protocol next hop: 3.3.3.3
>Indirect next hop: 0x19ec4b2c 1048578 INH Session ID: 0x1b
>State: 
>Age: 16:57  Metric: 10  Metric2: 0
>Validation State: unverified
>Task: BGP_61098_61098.3.3.3.3+50640
>Announcement bits (3): 2-KRT 3-BGP_RT_Background 4-Resolve 
> tree 2
>AS path: 8218 2200 2426 I
>Communities: 8218:102 8218:2 8218:20110
>Accepted
>Localpref: 100
>Router ID: 3.3.3.3
>Indirect next hops: 1
>Protocol next hop: 3.3.3.3
>Indirect next hop: 0x19ec4b2c 1048578 INH Session ID: 
> 0x1b
>Indirect path forwarding next hops: 2
>Next hop type: Router
>Next hop: 2.2.2.2 via xe-2/0/3.100
>Session Id: 0x18
>Next hop: 2.2.2.0 via xe-2/0/2.100
>Session Id: 0x17
>3.3.3.3/32 Originating RIB: public.inet.0
>  Node path count: 1
>  Forwarding nexthops: 2
>Nexthop: 2.2.2.2 via xe-2/0/3.100
> 
> So, I have three questions:
> 
> Is it expected for a route to be flagged "active" while it is still
> queued to KRT?
> 
> Is there a way to delete those invalid routes in a more speedier manner
> to let packets use the default route during the convergence time?
> 
> Is there some way to not advertise the default route in OSPF during the
> convergence time? Like a criteria: don't advertise this route when the
> KRT queue has 1000+ elements and until it reaches 0 (to avoid flapping).
> 
> I am running 13.3R8.7.
> 
> Thanks!
> -- 
> Treat end of file conditions in a uniform manner.
>- The Elements of Programming Style (Kernighan & Plauger)
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX performance

[Brad Fleming]

In our testing ~3years ago the SRX240H1 with RAM upgrade it seemed the device 
performed fine at 180Kpps total. After that point we started seeing jitter. At 
~190Kpps we started seeing out-of-orders and even some completely dropped 
packets. Our test was using a single firewall policy passing traffic between 
two connected ports in different security zones. We connected a JDSU to each 
and inched traffic up. We used 64Byte packets so we could hammer the forwarding 
plane as hard as possible. As we increased the packet size we eventually ran 
out of port capacity but the 180Kpps seemed to hold no matter the size of the 
packets.

As stated previously performance will take a pretty big hit if your policy 
enacts any of the UTM or other advanced featuresets. We’ve never done any hard 
bench testing looking for absolute breakpoints on the more advanced features 
but Junipers guidelines seem to be fairly accurate in that regard (in our 
experience). A/V and IPSec hit the branch boxes fairly hard while IPS and web 
filtering are a little more manageable.

If you go down the path of an SRX240 I’d suggest using the screen features and 
tuning it for your needs. It can really save the device from dealing with junk 
/ attack traffic at higher levels. Can’t help you with a 100Gbps DDoS but can 
help deal with SYN floods and other junk.


> On Dec 20, 2015, at 8:16 AM, harbor235  wrote:
> 
> Can anyone share real world SRX performance? ?I am looking at the SRX220
> or SRX240 for a small website ~150-200Mbps in a co-location environment.
> The performance charts state the SRX220 can do 300Mbps with a mix of
> traffic and  up to 900Mbps with mostly large packet sizes.
> 
> 
> thanks in advance,
> 
> 
> Mike
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ifa generation mismatch

[Brad Fleming]

Responding to my own post in case others stumble across this post in the 
future. After working with TAC we finally found our root problem.

We had accidentally misconfigured the DSC interface with two IPs. Like so…
unit 0 {
family inet {
filter {
output v4-out-discard;
}
address 192.168.192.189/32
address 192.168.192.190/32 {
destination 192.168.192.189;
}
}
}

The presence of that top address also being the destination for the address 
below caused a mess. The moment we removed the top address all errant logs 
stopped and everything on the system went back to normal.

So if you happen to get hit with log entries like those below check very 
closely your interface address address configurations.

> On Oct 5, 2015, at 10:13 AM, Brad Fleming <bdfle...@gmail.com> wrote:
> 
> Has anyone seen anything like this before?
> 
> Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Starting 
> interface state recovery
> Oct  5 09:49:50   rpd[3200]: %DAEMON-5-RPD_KRT_IFA_GENERATION: ifa 
> generation mismatch -- ifl dsc.0 rpd 130 kernel 132
> <<>>
> Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: 
> Interface state recovery completed.
> 
> Our log file is filling up every 10mins or so with junk messages from RPD 
> similar to this:
> 
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/2/0 index 
> 249  address #0 28.8a.1c.c7.c3.69
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/3/0 index 
> 250  address #0 28.8a.1c.c7.c3.92
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
> 2001:db8:1:386::2 on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
> fe80::2a8a:1cff:fec7:bc7b on ifl xe-0/3/0.0. Flag:0.
> Oct  5 09:49:50   rpd[3200]: %DAEMON-6: L2circuit IFF Change: IFL 
> xe-11/2/0.1170 flags 0x0, nbr-id 0.0.0.0 vc-id 0
> 
> I see an old post to this list from RAS from 2004 but that’s about all I can 
> find. We’ve been working with JTAC for about a month trying to figure out 
> what’s going on an it just doesn’t seem there’s going to be a simple answer.
> 
> So far we’ve:
> + Disabled and re-enabled all GRES+NSR/NSB
> + Rebooted both REs ("request system reboot both-routing-engines”)
> + Upgraded software from 13.3R6.5 to 14.2R4.9
> + Removed all interfaces getting logged (roughly 30 IFLs) from the device 
> configuration
> 
> None of these steps have stopped the log messages from piling up. Just kinda 
> hoping some others have seen something similar and might be willing to share 
> what you did to resolve the issue. Thanks in advance for any insights!

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ifa generation mismatch

[Brad Fleming]

Has anyone seen anything like this before?

Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Starting 
interface state recovery
Oct  5 09:49:50   rpd[3200]: %DAEMON-5-RPD_KRT_IFA_GENERATION: ifa 
generation mismatch -- ifl dsc.0 rpd 130 kernel 132
<<>>
Oct  5 09:49:50   rpd[3200]: %DAEMON-3: krt_ifcheck_chunk: Interface 
state recovery completed.

Our log file is filling up every 10mins or so with junk messages from RPD 
similar to this:

Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/2/0 index 
249  address #0 28.8a.1c.c7.c3.69
Oct  5 09:49:50   rpd[3200]: %DAEMON-6: EVENT  lt-11/3/0 index 
250  address #0 28.8a.1c.c7.c3.92
Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
2001:db8:1:386::2 on ifl xe-0/3/0.0. Flag:0.
Oct  5 09:49:50   rpd[3200]: %DAEMON-6-KRT: Received IPv6 address 
fe80::2a8a:1cff:fec7:bc7b on ifl xe-0/3/0.0. Flag:0.
Oct  5 09:49:50   rpd[3200]: %DAEMON-6: L2circuit IFF Change: IFL 
xe-11/2/0.1170 flags 0x0, nbr-id 0.0.0.0 vc-id 0

I see an old post to this list from RAS from 2004 but that’s about all I can 
find. We’ve been working with JTAC for about a month trying to figure out 
what’s going on an it just doesn’t seem there’s going to be a simple answer.

So far we’ve:
+ Disabled and re-enabled all GRES+NSR/NSB
+ Rebooted both REs ("request system reboot both-routing-engines”)
+ Upgraded software from 13.3R6.5 to 14.2R4.9
+ Removed all interfaces getting logged (roughly 30 IFLs) from the device 
configuration

None of these steps have stopped the log messages from piling up. Just kinda 
hoping some others have seen something similar and might be willing to share 
what you did to resolve the issue. Thanks in advance for any insights!


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] purpose of "commit check"?

[Brad Fleming]

I use it to make sure another admin hasn’t made changes overtop of mine. Also, 
I believe commit check can help in situations where you are using “edit 
private”.


> On Sep 28, 2015, at 4:24 PM, Martin T  wrote:
> 
> Hi,
> 
> when I commit the candidate configuration in Junos, I tend to execute
> "commit check" and if configuration check succeeds, then I execute
> "commit comment ". However, when I think about it, "commit
> (comment)" itself should perform those very same checks that "commit
> check" does. If yes, then what is the point of "commit check"? Only
> purpose I could see is to check the validity of the candidate
> configuration in the middle of the configuration process, i.e. to
> check if the changes made in candidate configuration so far are fine
> but the candidate configuration is not ready to be committed.
> 
> 
> thanks,
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 10G Interfaces

[Brad Fleming]

Supports? Or has 10G interfaces currently installed? If you’re looking for 
installed 10G interfaces your can use the “show interface terse | match xe-“ 
command to find only the 10G interfaces currently installed in the box. NOTE: 
If you have SFP+ ports they will not show as ge- or xe- until the optic slot is 
populated since their personality can change with the module.


 On Jan 13, 2015, at 8:28 AM, Mohammad Khalil eng.m...@gmail.com wrote:
 
 Hi all
 How can I know if My device supports 10G interfaces?
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX104 with full BGP table problems

[Brad Fleming]

I wanted to close the loop on this thread.

JTAC was able to determine the root cause.. and as more often then not it was 
user error.

I had a default route configured to resolve all BGP next-hops for our 
test/lab/staging configuration and didn’t realize the default was evaluated 
last in this process. So as the box learned more specific routes RPD was 
working overtime to keep up.

We now have a full mesh of 11 iBGP sessions talking to the MX104; total of 890K 
paths and 500K active routes with no problems. CPU load is in the 98% idle even 
with general, constant Internet BGP table churn. We’re seeing good behavior 
using Junos 13.2R2 and 13.3R1.

Thanks to everyone for your suggestions. And thanks to Dave from JTAC for 
listening, asking the correct questions, then finding the stupid user’s problem.



On May 16, 2014, at 2:28 PM, Brad Fleming bdfle...@gmail.com wrote:

 Thanks for the response; answers inline...
 
 
 On May 16, 2014, at 1:58 PM, Tyler Christiansen tyler.christian...@adap.tv 
 wrote:
 
 I don't have experience with the MX104s but do with the rest of the line 
 (MX80 to MX2010 [excluding MX104, of course]).  MX80 isn't dual RE, but the 
 CPUs are the same family between MX80 and MX104 IIRC--the MX104 is just 500 
 or 600 Mhz faster.  And the MX80 kind of chokes when receiving a full feed 
 (even just one at a time can easily send it up to ~40% during the initial 
 feed consumption).  ;)
 
 The MX80 and MX104 being sold as edge BGP routers is pretty much only 
 because it has enough memory to do it...not because it's a good idea.
 
 It's pretty odd for the backup RE to have CPU utilization (based on 
 experience with the other dual RE MX devices).  Some, yes, but not 100% 
 utilization as you show there.  I would buy 100% utilization during initial 
 feed consumption on the master.  After you have some stability in the 
 network, though, the CPU should be back down to ~5-15% (depending on what 
 you have going on).
 
 I agree; we’ve run a few M10is and never had this issue, but.. totally 
 different platform, and much older version of Junos made me generally 
 discount it. These are the first multi-RE boxes we’ve had running any Junos 
 newer then 10.0. Thanks for pointing it out, it’s something I missed in my 
 previous email. As the previous output shows, 15min load averages for each RE 
 are ~1.20 so the load remains elevated. I just confirmed that the 15min load 
 average after about 2hours of “sitting” remains ~1.22.
 
 How aggressive are your BGP timers?  You may want to consider BFD instead of 
 BGP timers for aggressive keepalives.
 
 BGP timers are default; however, we’ve tried relaxing them with no change in 
 behavior.
 
 Are you doing just plain IPv4 BGP, or are you utilizing MBGP extensions?  
 MBGP extensions can inflate the size of the BGP tables and make the router 
 do more work.
 
 We’ve tried both with no difference in performance. The example outputs in my 
 original message were with MBGP extensions enabled but doing only IPv4 
 unicast on the session produces the same result.
 
 In all scenarios, you really should probably have loopback IPs in the IGP 
 and have the nexthop set to the loopback IPs for iBGP sessions.  I'm not 
 sure why you have /30 P2P links as the next-hops as they're potentially 
 unstable (even if they're not now, they can easily become unstable once in 
 production).  I assume that since you mentioned you know it's not 
 recommended, you're going to be changing that.
 
 This is a bit of a legacy issue within our network. We’ve operated for nearly 
 12 years using the actual PtP in our IGP and retaining it in BGP 
 advertisements. It is something we plan to resolve with the deployment of 
 this gear (as well as several new MX960s that were part of the same PO).
 
 In scenario #2, how many RRs does the MX104 peer with?  And are they sending 
 full routes or full routes + more?
 
 The box was only peering with a single RR. The RR was only sending the 
 standard, full table (~496K routes), no VPN, no mcast, etc.
 
 Finally, in scenario #3, if you're trying to do a full mesh with 11 other 
 peers, the MX104 will choke if they're all trying to load full tables.  
 There are about 500,000 routes in the global table, so you're trying to load 
 5,500,000 routes into a box with a 1.8Ghz CPU and 4GB RAM.
 
 In scenario #3 the total number of routes entering the RE was ~867K with 
 ~496K active.
 
 Regardless, I would think that the MX104 should be perfectly capable of 
 scaling to at least five or six full feeds.  I would suspect either a bug in 
 the software or very aggressive timers.
 
 On Fri, May 16, 2014 at 11:00 AM, Brad Fleming bdfle...@gmail.com wrote:
 We’ve been working with a handful of MX104s on the bench in preparation of 
 putting them into a live network. We started pushing a full BGP table into 
 the device and stumbled across some CPU utilization problems.
 
 We tried pushing a full table into the box three different ways:
 1) via

[j-nsp] MX104 with full BGP table problems

[Brad Fleming]

We’ve been working with a handful of MX104s on the bench in preparation of 
putting them into a live network. We started pushing a full BGP table into the 
device and stumbled across some CPU utilization problems.

We tried pushing a full table into the box three different ways:
1) via an eBGP session
2) via a reflected session on an iBGP session
3) via a full mesh of iBGP sessions (11 other routers)

In situation #1: RE CPU was slightly elevated but remained ~60% idle and 1min 
load averages were around 0.3.

In situation #2: RE CPU is highly elevated. We maintain actual p-t-p /30s for 
our next-hops (I know, not best practice for many networks) which results in a 
total of about 50-65 next-hops network-wide.

In situation #3: RE CPU is saturated at all times. In this case we configured 
the mesh sessions to advertise routes with “next-hop-self” so the number of 
next-hops is reduced to 11 total.

It appears that RPD Is the process actually killing the CPU; nearly always 
running 75+% and in a “RUN” state. If we enable task accounting it shows 
“Resolve Tree 2” as the task consuming tons of CPU time. (see below) There’s 
plenty of RAM remaining, we’re not using any swap space, and we’ve not exceed 
the number of routes licensed for the system; we paid for the full 1Million+ 
route scaling. Logs are full of lost communication with the backup RE; however, 
if we disable all the BGP sessions that issue goes away completely (for days on 
end).

Has anyone else tried shoving a full BGP table into one of these routers yet? 
Have you noticed anything similar?

I’ve opened a JTAC case for the issue but I’m wondering if anyone with more 
experience in multi-RE setups has seen similar. Thanks in advance for any 
thoughts, suggestions, or insights.


Incoming command output dump….

netadm@test-MX104 show chassis routing-engine
Routing Engine status:
  Slot 0:
Current state  Master
Election priority  Master (default)
Temperature 39 degrees C / 102 degrees F
CPU temperature 42 degrees C / 107 degrees F
DRAM  3968 MB (4096 MB installed)
Memory utilization  32 percent
CPU utilization:
  User  87 percent
  Background 0 percent
  Kernel11 percent
  Interrupt  2 percent
  Idle   0 percent
Model  RE-MX-104
Serial ID  CACH2444
Start time 2009-12-31 18:05:43 CST
Uptime 21 hours, 31 minutes, 32 seconds
Last reboot reason 0x200:normal shutdown
Load averages: 1 minute   5 minute  15 minute
   1.06   1.12   1.23
Routing Engine status:
  Slot 1:
Current state  Backup
Election priority  Backup (default)
Temperature 37 degrees C / 98 degrees F
CPU temperature 38 degrees C / 100 degrees F
DRAM  3968 MB (4096 MB installed)
Memory utilization  30 percent
CPU utilization:
  User  62 percent
  Background 0 percent
  Kernel15 percent
  Interrupt 24 percent
  Idle   0 percent
Model  RE-MX-104
Serial ID  CACD1529
Start time 2010-03-18 05:16:34 CDT
Uptime 21 hours, 45 minutes, 26 seconds
Last reboot reason 0x200:normal shutdown
Load averages: 1 minute   5 minute  15 minute
   1.22   1.19   1.20

netadm@test-MX104 show system processes extensive
last pid: 20303;  load averages:  1.18,  1.14,  1.22  up 0+21:33:3503:03:41
127 processes: 8 running, 99 sleeping, 20 waiting
Mem: 796M Active, 96M Inact, 308M Wired, 270M Cache, 112M Buf, 2399M Free
Swap: 1025M Total, 1025M Free
  PID USERNAME THR PRI NICE   SIZERES STATETIME   WCPU COMMAND
 3217 root   1 1320   485M   432M RUN120:56 72.85% rpd

netadm@test-MX104 show task accounting
Task accounting is enabled.

Task   StartedUser Time  System Time  Longest Run
Scheduler322940.9240.1480.000
Memory  260.0010.0000.000
RT58760.9470.1620.003
hakr 60.0000.0000.000
OSPF I/O./var/run/ppmd_co  1170.0020.0000.000
BGP rsync  1920.0070.0010.000
BGP_RT_Background   780.0010.0000.000
BGP_Listen.0.0.0.0+17926961.1010.218

Re: [j-nsp] MX104 with full BGP table problems

[Brad Fleming]

On May 16, 2014, at 1:58 PM, Saku Ytti s...@ytti.fi wrote:

 On (2014-05-16 13:00 -0500), Brad Fleming wrote:
 
 We’ve been working with a handful of MX104s on the bench in preparation of 
 putting them into a live network. We started pushing a full BGP table into 
 the device and stumbled across some CPU utilization problems.
 
 What JunOS if 13.3R2 you're probably seeing /var/db/alarm.db recreated every
 20, it's 80MB zero filled file.
 The file is synchronized over em0 to RE1, causing em congestion and various
 other problems, such as loss of connectivity to backup RE1, loss of fan, etc.
 And indeed high CPU.
 
 Your em0 traffic should be like 100pps, so the issue is quite obvious if you
 graph em0.
 
 I'm using this as workaround:
 set system processes alarm-management disable
 
 I dpn't know if it's safe, and JTAC has not yet been able to tell confirm if I
 can continue using it. Regardless I'm running it in production in some 12
 boxes.
 If it's same issue, you might want to refer JTAC to 2014-0430-0067.
 
 I did explain all this when opening the case, asked this week if there is any
 progress, and they now told they've found that it's caused by rcp process
 causing high I/O load.
 I attempted to explain that I don't believe that is the culprit, that is just
 symptom of synchronizing the changed file from RE0 to RE1, and perhaps they
 should focus on figuring out why the file keeps being recreated.
 
Thanks for the response!

We’ve been testing this with Junos 13.3R1.8 and 13.3R2.7. I’ll see if your 
workaround mitigates or alleviates our problem. Thanks for sharing your 
experience!


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Interface group based on description

[Brad Fleming]

Thanks very much Nikita! I think I can make this work for our situation now 
that you’ve done all the work! :D


On Oct 31, 2013, at 12:00 AM, Nikita Shirokov ns.ha...@gmail.com wrote:

 The closest thing which could do what you want is commit script + apply 
 macro. Something like this:
 https://github.com/tehnerd/juniper_scripts/blob/master/commit/com_test.slax
 —
 Sent from Mailbox for iPhone
 
 
 On Thu, Oct 31, 2013 at 2:57 AM, Brad Fleming bdfle...@gmail.com wrote:
 
 Does anyone know any tricks for creating a grouping of interfaces based on 
 the description attached? 
 For example: Any logical interface with the label “BACKBONE to far-node” goes 
 into a group that could then be referenced in OSPF, LDP, RSVP, etc. 
 
 An interface-range is close but doesn’t allow you to reference a tagged link; 
 it expands it’s members only to ge-0/0/0.0 even if other units are configured 
 within the range. Interface-sets are not allowed to be referenced in protocol 
 configuration as near as I can tell. 
 
 I’d really love a way to provision an interface, label it with “BACKBONE” or 
 “CPE”, and have that label automatically configure the interface for the 
 proper protocols. It’d really eliminate mistakes when turning up new tail 
 circuit locations. Any suggestions or pointers would be greatly appreciated! 
 ___ 
 juniper-nsp mailing list juniper-nsp@puck.nether.net 
 https://puck.nether.net/mailman/listinfo/juniper-nsp 
 
 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Interface group based on description

[Brad Fleming]

Does anyone know any tricks for creating a grouping of interfaces based on the 
description attached?
For example: Any logical interface with the label “BACKBONE to far-node” goes 
into a group that could then be referenced in OSPF, LDP, RSVP, etc.

An interface-range is close but doesn’t allow you to reference a tagged link; 
it expands it’s members only to ge-0/0/0.0 even if other units are configured 
within the range. Interface-sets are not allowed to be referenced in protocol 
configuration as near as I can tell.

I’d really love a way to provision an interface, label it with “BACKBONE” or 
“CPE”, and have that label automatically configure the interface for the proper 
protocols. It’d really eliminate mistakes when turning up new tail circuit 
locations. Any suggestions or pointers would be greatly appreciated!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper dead J series?

[Brad Fleming]

We had this happen several times over the past 3 years or so. In all cases 
there's no console output, all LEDs on solid, and fans spin up and remain spun 
up until power is removed from the device. We tried some Redneck Engineering on 
one failed box that wasn't under maintenance and replaced RAM and CF cards with 
no luck. We've moved to SRX gear for nearly all locations; however, I believe 
the J's had some internal diag lights that failed to indicate any problems (at 
least in our cases).



On Aug 1, 2013, at 12:19 PM, David Gee d...@infiltr8.com wrote:

 Hi all,
 
 
 
 Second post from me in the same month! Scary.
 
 
 
 So, long story short. Router went offline after a power outage. Didn't come
 back. Remote hands consoled in and reported back:
 
 
 
 All four LED's are on permanently. We've unplugged, plugged it back in,
 rebooted and rebooted some more. No console output.
 
 
 
 I've had a quick look around but can't find anything specific. I'm thinking
 at this point it's either, RAM, CPU or possibly compact flash? The DC is a
 few miles away, so contemplating jumping on Ebay and buying some spares to
 cover as many realistic outcomes as possible. Any thoughts or experience
 with this?
 
 
 
 Thanks
 
 David
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX240 and SRX550 Web Filtering Capacity

[Brad Fleming]

Does anyone know the enhanced web filtering performance of the SRX240 and 
SRX550? I'm not finding a specific reference in the data sheet or other 
documents.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Help with DDoS fpc slot and loopback wedge messages

[Brad Fleming]

Hello all,

One of our MX10s apparently has a sense of humor; it decided to bounce all of 
its routing protocols early morning on the April 1st. We saw all OSPFv2, 
OSPFv3, LDP, and BGP neighbors bounce at the exact same time and restore 
roughly 45 seconds later. In the wake of the event we noticed two log messages 
that we've never seen before.

bunches of OSPFv3 neighbors down
Apr  1 00:35:59  agg-kc-1 /kernel: %KERN-7: DDOS referring to an invalid fpc 
slot (255)while updating protocol stats
Apr  1 00:36:00  agg-kc-1 tfeb0 Host Loopback:HOST LOOPBACK WEDGE DETECTED IN 
PFE 0
few more protocols breaking
protocols coming back online

We're running Junos 11.4R1.14. We don't have any of the DDoS features of the MX 
explicitly configured; they're all in default state.

Regarding the loopback wedge message:
http://kb.juniper.net/InfoCenter/index?page=contentid=KB26276

In our case the ingress and egress ports are all on the same 20x1G MIC card. 
But I'm not sure if the RE in an MX10 requires the fabric to get packets on the 
wire or whether its hardwired to each potential ingress / egress MIC slot.

Any insight or thoughts on the subject would be very much appreciated!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX240 Series and BGP Routes (and other things)

[Brad Fleming]

On Mar 1, 2013, at 10:41 AM, Eugeniu Patrascu eu...@imacandi.net wrote:

 I guess it has to do with the EOL announcement for the J series where the
 SRX is promoted as the successor platform.
 For full tables, the J series were the smallest Juniper routers that you
 could buy and with 2GB of RAM they work very well.
 I'm sad to see them gone.

And if you're willing to go off-support you can even get the J-series up to 4GB 
of RAM thanks to the 4 DIMM slots and standard PC3200 modules.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Are these temps high enough to cause any issues?

[Brad Fleming]

Here's from an MX-10 in a 68F ambient room with pretty good airflow through the 
chassis. This node also has a 2x10Gbps in the box generating some additional 
heat.

root@lab-MX# ...cs optics | match temperature | except high | except low
Module temperature:  29 degrees C / 85 degrees F
Module temperature:  27 degrees C / 81 degrees F


On Feb 11, 2013, at 5:31 PM, Morgan McLean wrx...@gmail.com wrote:

 Here is the output of a few commands (bolded).
 
 In the past two weeks, one SFP from each of our border MX80's have failed.
 They were juniper 1gig sx modules. I'm not sure if this is coincidence, or
 if its heat related. According to the thresholds, things seem to be OK, but
 I figured I should ask. For instance, the warn threshold for the modules
 are like 180deg F, not sure what it is for the chassis or individual chips.
 *
 *
 *someuser@somehost.somewhere* *show interfaces diagnostics optics |match
 temperature |except high|except low *
Module temperature:  50 degrees C / 122 degrees
 F
Module temperature:  50 degrees C / 122 degrees
 F
Module temperature:  48 degrees C / 119 degrees
 F
Module temperature:  47 degrees C / 117 degrees
 F
Module temperature:  49 degrees C / 120 degrees
 F
Module temperature:  51 degrees C / 124 degrees
 F
 
 *someuser@somehost.somewhere show chassis environment *
 Class Item   Status Measurement
 Temp  PEM 0  OK
  PEM 1  OK
  RE 0 IntakeOK 48 degrees C / 118 degrees F
  RE 0 Front Exhaust OK 51 degrees C / 123 degrees F
  RE 0 Rear Exhaust  OK 48 degrees C / 118 degrees F
  Routing Engine OK 55 degrees C / 131 degrees F
  Routing Engine CPU OK 66 degrees C / 150 degrees F
  TFEB 0 QX 0 TSen   OK 51 degrees C / 123 degrees F
  TFEB 0 QX 0 Chip   OK 61 degrees C / 141 degrees F
  TFEB 0 LU 0 TSen   OK 51 degrees C / 123 degrees F
  TFEB 0 LU 0 Chip   OK 66 degrees C / 150 degrees F
  TFEB 0 MQ 0 TSen   OK 51 degrees C / 123 degrees F
  TFEB 0 MQ 0 Chip   OK 58 degrees C / 136 degrees F
  TFEB 0 TBB PFE TSenOK 48 degrees C / 118 degrees F
  TFEB 0 TBB PFE ChipOK 59 degrees C / 138 degrees F
  TFEB 0 TFEB PCIE TSen  OK 53 degrees C / 127 degrees F
  TFEB 0 TFEB PCIE Chip  OK 69 degrees C / 156 degrees F
 Fans  Fan 1  OK Spinning at high speed
  Fan 2  OK Spinning at high speed
  Fan 3  OK Spinning at high speed
  Fan 4  OK Spinning at high speed
  Fan 5  OK Spinning at high speed
 
 -- 
 Thanks,
 Morgan
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MF Classifier on L2Circuit Endpoints?

[Brad Fleming]

Is there any way to configure a multi-field classifier on an L2Circuit's local 
drop port? I'm afraid the answer will be no but was hoping someone knows some 
magic. I'm working on an SRX240 but wouldn't mind knowing whether other 
platforms support it.

Assuming the answer is no: How do you guys provide QoS services on MPLS L2 
services?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Summarize Global Table

[Brad Fleming]

On Oct 27, 2011, at 3:38 PM, Tima Maryin wrote:
 On 25.10.2011 20:21, Brad Fleming wrote:
 Are there any tricks to auto-summarize the contents of a RIB where the 
 tributary routes are not originated locally?
 
 Example:
 Input routes:
 prefix: 1.0.0.0/16, next-hop: 5.5.5.5
 prefix: 1.0.1.0/16, next-hop: 5.5.5.5
 prefix: 1.0.2.0/16, next-hop: 4.4.4.4
 prefix: 1.0.3.0/16, next-hop: 5.5.5.5
 
 Consolidated, Installed routes:
 prefix: 1.0.0.0/14, next-hop: 5.5.5.5
 prefix: 1.0.2.0/16, next-hop: 4.4.4.4
 
 Basically a way to consolidate total number of prefixes entering the FIB.
 
 If such a thing existed we could feed non-Juniper, TCAM-based routers a 
 smaller table but still maintain the advantages of best path, hot potato 
 routing.
 
 
 If you have got some peers/uplinks which are ISPs with full table there will 
 eventually  be scenarios when you will be forced to hack some of you 
 aggregates with specifics again and again to avoid blackholing. Since 
 customers of those ISPs tends to use specifics to manipulate inbound traffic.
 
 
 If you're not ISP does 0/0 looks like an option? :)

We're an ISP; just a charitable, not-for-profit one with budget crunch issues 
right now. :D

I think we'll end up doing the aggregation approach and sacrificing the ability 
to offer BGP services from our aging CAM-based boxes. Fortunately we still have 
a reasonable amount of CAM; I'm just thinking what we can do before the 
2015-2017 timeframe when the table growth will start to become an actual 
problem.

I do very much appreciate all the discussion, links, etc in this thread; I've 
learned of multiple new draft RFCs and some new ideas on approaching the issue. 
Thanks!
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Summarize Global Table

[Brad Fleming]

Ahh.. good point. I didn't think about the problem from the machine's 
standpoint. It would need a target / hard number of prefixes or the table would 
be the exact same.

Thanks for the response!


On Oct 25, 2011, at 11:56 AM, Stefan Fouant wrote:

 You can use aggregate
 /generated routes which require more specific contributing routes to become 
 active, and then only advertise the protocol aggregate routes to your 
 downstream nodes that have smaller tables, however you still need to create 
 the aggregates which is a manual process.
 
 You can get pretty creative however, in your definition of aggregates, so 
 that they can encompass a large number of specifics - for example, if your 
 downstream node only supported a FIB of a few routes, you could create 2 
 aggregates on the upstream node, perhaps 0/1 and 128/1.  This is an extreme 
 example, but you get the idea.
 
 As far as I know, there are no ways to automatically summarize along the 
 lines of what you are getting at because routers aren't intelligent enough to 
 determine what prefix masks to use for summarization without user input.
 
 What you would need to accomplish what you are describing is some way to tell 
 the device that you want to summarize all the routing information into x 
 number of prefixes, and then have the router automatically compute the best 
 summaries where routing information overlaps and can be consolidated into a 
 single prefix/mask combination.
 
 Stefan Fouant
 JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
 Technical Trainer, Juniper Networks
 
 Follow us on Twitter @JuniperEducate
 
 Sent from my iPad
 
 On Oct 25, 2011, at 12:21 PM, Brad Fleming bdfle...@gmail.com wrote:
 
 Are there any tricks to auto-summarize the contents of a RIB where the 
 tributary routes are not originated locally?
 
 Example:
 Input routes:
 prefix: 1.0.0.0/16, next-hop: 5.5.5.5
 prefix: 1.0.1.0/16, next-hop: 5.5.5.5
 prefix: 1.0.2.0/16, next-hop: 4.4.4.4
 prefix: 1.0.3.0/16, next-hop: 5.5.5.5
 
 Consolidated, Installed routes:
 prefix: 1.0.0.0/14, next-hop: 5.5.5.5
 prefix: 1.0.2.0/16, next-hop: 4.4.4.4
 
 Basically a way to consolidate total number of prefixes entering the FIB.
 
 If such a thing existed we could feed non-Juniper, TCAM-based routers a 
 smaller table but still maintain the advantages of best path, hot potato 
 routing.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] LDP Interop with IOS

[Brad Fleming]

Hello all,

I'm having a tough time with LDP interoperability between Juniper and Cisco 
gear. I'm starting to wonder if this isn't a limitation of the Cisco platform 
in the lab.

I have the following devices:
+ Brocade NetIron XMR 4000 running IronWare 5.1.00b
+ Cisco 2821 ISR running IOS 12.4(24)T5 T-train w/ Advanced IP Services
+ Juniper SRX running Junos 10.0R4.7

The Cisco is acting as the P router between services deployed on the Brocade 
and Juniper. Connectivity is like so:
Juniper SRX --- 2xT1 / MLPPP --- Cisco 2821 --- Ethernet --- Brocade XMR

OSPFv2 happily comes online on all systems and IP routes propagate as expected.
LDP on the other hand, never seems to come up on the Cisco.
What's very odd is that both the Brocade and Juniper believe the LDP session is 
up and functioning.

If I replace the Cisco 2821 with another SRX, J-Series, or Brocade NI CER (adv 
prem) LDP happily comes online with no issues and services flow as expected.

Does anyone have a working example of LDP between a Cisco ISR and Juniper gear 
they would be willing to share?

Thanks in advance for any suggestions or insights!

--
OSPF works but LDP is busted:

Cisco-2821(config-if)#do show ip ospf neigh

Neighbor ID Pri   State   Dead Time   Address Interface
192.168.199.109   1   FULL/BDR00:00:32192.168.204.69  
GigabitEthernet0/0
192.168.199.340   FULL/  -00:00:37192.168.204.74  Multilink100
kr-kludgy(config)#do show mpls ldp neigh

Cisco-2821(config)#end



Configurations are extremely simple:

Brocade:
!
default-max-frame-size 9216
!
router ospf
 area 0.0.0.0
!
interface loopback 1
 ip ospf area 0.0.0.0
 ip address 192.168.199.109/32
!
!
interface ethernet 1/11
 port-name to-Cisco
 enable
 ip ospf area 0.0.0.0
 ip address 192.168.204.69/30
 ip mtu 9198
!
router mpls
 mpls-interface e1/11
  ldp-enable
!


Cisco:
!
ip cef
!
mpls label protocol ldp
!
interface Loopback0
 ip address 192.168.206.53 255.255.255.255
!
interface Multilink100
 description MLPPP-to-Juniper-SRX
 bandwidth 3000
 ip address 192.168.204.73 255.255.255.252
 ip ospf 2495 area 0.0.0.0
 load-interval 30
 mpls label protocol ldp
 mpls ip
 ppp multilink
 ppp multilink links minimum 1
 ppp multilink group 100
 max-reserved-bandwidth 100
!
interface GigabitEthernet0/0
 description to-Brocade-XMR
 ip address 192.168.204.70 255.255.255.252
 no ip proxy-arp
 ip pim sparse-mode
 ip ospf 2495 area 0.0.0.0
 load-interval 30
 duplex full
 speed 1000
 mpls label protocol ldp
 mpls ip
 no cdp enable
!
interface Serial0/0/0:0
 description T1-to-SRX-1
 no ip address
 encapsulation ppp
 load-interval 30
 no fair-queue
 ppp multilink
 ppp multilink group 100
 max-reserved-bandwidth 100
!
interface Serial0/0/1:0
 description T1-to-SRX-2
 no ip address
 encapsulation ppp
 load-interval 30
 no fair-queue
 ppp multilink
 ppp multilink group 100
 max-reserved-bandwidth 100
!
router ospf 2495
 mpls ldp sync
 router-id 192.168.206.53
 log-adjacency-changes
 auto-cost reference-bandwidth 100
!
mpls ldp router-id Loopback0 force
!


Juniper:
interfaces {
lsq-0/0/0 {
unit 0 {
description MLPPP to Cisco 2821;
encapsulation multilink-ppp;
bandwidth 3k;
family inet {
address 192.168.204.74/30;
}
family mpls;
}
}
t1-1/0/0 {
unit 0 {
description T1 to Cisco 2821 1;
family mlppp {
bundle lsq-0/0/0.0;
}
}
}
t1-2/0/0 {
unit 0 {
description T1 to Cisco 2821 2;
family mlppp {
bundle lsq-0/0/0.0;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.199.34/32;
}
}
}
}
routing-options {
router-id 192.168.199.34;
}
protocols {
mpls {
interface all;
}
ospf {
reference-bandwidth 1000g;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface lsq-0/0/0.0;
}
}
ldp {
interface lsq-0/0/0.0;
interface lo0.0;
}
}
security {
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LDP Interop with IOS

[Brad Fleming]

Thanks very much for all the replies.

Unfortunately the issue was 100% operator error. I somehow overlooked the lack 
of ip ospf 2495 area 0.0.0.0 under the Cisco's loopback0 interface. Once I 
dropped that on the interface and cleared OSPF processes my LDP neighbors came 
online correctly. Jez should have been the first thing I checked.

Sorry to waste time, bits, and disk space on such a simple problem. Thanks 
again for replies though!



On Jun 29, 2011, at 5:53 PM, Mario Andres Rueda wrote:

 Take a look
 
 If you are using multiple  addresses  on your juniper interface facing cisco 
 you must use 
 
 Allow-subnet-mismatch
 
 Over ldp interface configuration
 
 This is mandatory prior junos 9.0 series
 
 Regards
 
 
 Enviado desde mi BlackBerry de Movistar
 
 -Original Message-
 From: Tim Warnock tim...@timoid.org
 Sender: juniper-nsp-boun...@puck.nether.net
 Date: Thu, 30 Jun 2011 08:10:14 
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] LDP Interop with IOS
 
 We have a heterogeneous Juniper-Cisco environment where LDP seems to
 work with no known problems. It is significantly different from yours
 in that we have:
 
 - IS-IS as our IGP
 - Juniper M320/MX and Cisco CRS1/IOS XR (and one 12K/IOS XR) P routers
 - Juniper M/MX and Cisco 12K/IOS as PE routers
 
 If you're still interested in config examples send me an email.
 
 Steinar Haug, Nethelp consulting, sth...@nethelp.no
 
 I'm interested in some configs if you would - I burnt days on it and had no
 luck.
 
 I'm also interested in a l2circuit (martini circuit) - xconnect as well.
 
 I did manage to get LDP up: there was a few setting on the cisco that needed
 to be set (implicit null, matching MTU and force LDP binding to loop0) and I
 used OSPF as my IGP, but I couldn't get a L2 circuit to come up.
 
 This was SRX to ISR like OP.
 
 Thanks
 Tim.
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] problem with ospf between linux/quagga and JunOS via GRE interface

[Brad Fleming]

On Nov 19, 2010, at 12:06 PM, Sergey wrote:


On Friday 19 November 2010, you wrote:


# show interfaces gr-1/2/0.2
point-to-point;


This isn't the point-to-point you're looking for. Find the one under
protocols ospf instead. :)


I attempted to remove point-to-point. No effect. :-(


I think he means setting the p2p here:

bdflem...@tester# set protocols ospf area 0.0.0.0 interface ge-0/0/15  
interface-type ?

Possible completions:
  nbma Nonbroadcast multiaccess
  p2mp Point-to-multipoint NBMA
  p2p  Point-to-point
[edit]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Policy - then accept == Route Reflector?

[Brad Fleming]

No router will send IBGP learned routes to another IBGP peer unless
configured to be a route-reflector.


the MX960 with 9.6R2.11 did that. I was quite surprised as I was
expecting the behaviour you describe.


Do you happen to have configurations saved from that situation? That  
seems like either (a) a MASSIVE BGP bug or (b) configuration causing  
unintended results. With a sample config, we might be able to confirm  
or deny the (b) possibility.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] physical interface policer

[Brad Fleming]

I agree with you that this seems like a simple task but in true  
Juniper fashion, there's a hundred ways to do it depending on your  
needs! :D


NOTE: I've never actually worked with these kinds of policers before  
so obviously test any suggestions first.


I think the physical interface policer must be referenced in a  
firewall filter. Then the filter is applied to an address family on a  
unit.

http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policers-physical-interface-aggregate-configuring.html

I don't know everything you'd like to achieve, but an Aggregate  
Policer / logical-interface-policer **might** be a better fit since  
its designed to be applied to multiple address families.

http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-configuring-aggregate-policers.html#id-11078456

I know it this isn't the most graceful solution, but to avoid the  
potential typos / human input problems, you could apply the policer  
via a group. Kind of like this:


u...@blah show configuration groups
apply-policer-random-name {
interfaces {
xe-4/1/0 {
unit * {
family * {
filter L-ECN
}
}
}
}
}

u...@blah show configuration
snip
apply-groups apply-policer-random-name

On Oct 13, 2010, at 8:34 AM, Bit Gossip wrote:


Hi Mac,
what you mention will do the job which is to police ALL traffic  
ingress

into a physical interface which is:
- ALL address-families of ALL logical units.
This means that I have to create a firewall filter per address-family
because the documentation says: 'You cannot specify family any. You  
must

configure a specific protocol family for a firewall filter that
references a physical interface policer.'
And then apply it to all address-families of all logical-units.

This is incredibly cumbersome and error-prone.

Is there no simple way to apply a soft policer, that is marking not
dropping, just to the physical interface?
Thanks,
Bit.


On Wed, 2010-10-13 at 09:23 -0400, Mac GroupStudy wrote:
Let me position my thoughts as well, I have been out of JUNOS for  
some

time but I did get pretty far in my knowledge there along the way.
Also, this is from the Juniper site for configuring policers on a
physical interface:


Applying Firewall Filters That Reference Physical Interface Policers
After you configure a firewall filter that references a physical
interface policer, you apply it as an input or an output filter to a
logical interface.

To apply a firewall filter that references a physical interface
policer as an input filter:

 * Include the input filter-name statement at the [edit
   interfaces interface-name unit logical-unit-number family
   family-name filter] hierarchy level.

To apply a firewall filter that references a physical interface
policer as an output filter:

 * Include the output filter-name statement at the [edit
   interfaces interface-name unit logical-unit-number family
   family-name] hierarchy level.

In the following example, firewall filter inet-filter is applied to
family inet on interface ge-1/2/0.0. The filter is applied to  
incoming

IPv4 traffic on the interface.

[edit]
interfaces {
ge-1/2/0 {
unit 0 {
family inet {
filter {
   input inet-filter;
}
   address 10.100.16.2/24
}
}

On Wed, Oct 13, 2010 at 9:20 AM, Mac GroupStudy
mac.groupst...@gmail.com wrote:
   Help me with my JUNOS commands structure and interfaces but
   unit 0 is the physical interface correct? I mean, you always
   have to configure unit 0 so to me that is just part of the
   interface configuration.



   On Wed, Oct 13, 2010 at 8:36 AM, Bit Gossip
   bit.gos...@chello.nl wrote:
   This is Mx480 Junos10.2R2.11 and DPC.
   Any idea why I can not apply a
   physical-interface-policer to a
   physical-interface?
   While it can be applied to 'unit 0' of the same
   interface.

   Thanks,
   bit.

   [edit interfaces xe-4/1/0]
   l...@rc2# run show configuration firewall policer L-ECN
   physical-interface-policer;
   if-exceeding {
  bandwidth-percent 90;
  burst-size-limit 64k;
   }
   then loss-priority high;

   [edit interfaces xe-4/1/0]

   l...@rc2# set layer2-policer ?
   Possible completions:
   + apply-groups Groups from which to inherit
   configuration data
   + apply-groups-except  Don't inherit configuration
   data from these
   groups

   [edit interfaces xe-4/1/0]
   l...@rc2# set 

[j-nsp] Public Looking Glass Template

[Brad Fleming]

I'm thinking of using a smaller SRX for public telnet/ssh access to  
run some basic commands at a CLI (show route, traceroute). Does anyone  
do similar and would be willing to share their system-login-class  
configuration?


I can get the box limited down to only the 4 to 5 commands I want to  
allow by using a regex filter on the login class but issuing a ? at  
the default prompt takes 3-4 *minutes* to return results. I'll include  
my configuration since it seems likely I made a mistake. Thanks in  
advance for any suggestions.


--- JUNOS 10.0R3.10 built 2010-04-16 08:47:35 UTC
b...@host show configuration system login class guests
idle-timeout 1;
permissions network;
allow-commands show route;
deny-commands ^telnet.*$|^ssh.*$|^op.*$|^file.*$|^request.*$|^start.* 
$|^show route ccc.*$|^show route export.*$|^show route flow.*$|^show  
route forwarding-table.*$|^show route label.*$|^show route label- 
switched-path.*$|^show route output.*$|^resolution.*$|^show route  
snooping.*$|^show route source-gateway.*$|^show route active-path.*$| 
^ping.*$|^mtrace.*$|^load.*$|^test.*$|^set.*$|^save.*$;

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Public Looking Glass Template

[Brad Fleming]

I'm thinking of using a smaller SRX for public telnet/ssh access to  
run some basic commands at a CLI (show route, traceroute). Does anyone  
do similar and would be willing to share their system-login-class  
configuration?


I can get the box limited down to only the 4 to 5 commands I want to  
allow by using a regex filter on the login class but issuing a ? at  
the default prompt takes 3-4 *minutes* to return results. I'll include  
my configuration since it seems likely I made a mistake. Thanks in  
advance for any suggestions.


--- JUNOS 10.0R3.10 built 2010-04-16 08:47:35 UTC
b...@host show configuration system login class guests
idle-timeout 1;
permissions network;
allow-commands show route;
deny-commands ^telnet.*$|^ssh.*$|^op.*$|^file.*$|^request.*$|^start.* 
$|^show route ccc.*$|^show route export.*$|^show route flow.*$|^show  
route forwarding-table.*$|^show route label.*$|^show route label- 
switched-path.*$|^show route output.*$|^resolution.*$|^show route  
snooping.*$|^show route source-gateway.*$|^show route active-path.*$| 
^ping.*$|^mtrace.*$|^load.*$|^test.*$|^set.*$|^save.*$;

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] LS to LSQ Interfaces

[Brad Fleming]

When upgrading JunosES software from 9.6 to 10.0R3 the ls-0/0/#  
interface needs to be changed to lsq-0/0/#. This needs to happen on  
the actual interface on any physical interfaces in the bundle. Does  
anyone know of a graceful way to perform this task? Does anyone know  
why Juniper decided to change the name of the interface (certainly  
makes no sense to me)?

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LS to LSQ Interfaces

[Brad Fleming]

Unfortunately we access these devices over the MLPPP bundle. So the  
bundle needs to be up for us to issue that command or the upgrade /  
reboot command.


Is there a way to make this part of a one-time start up script though?  
Like something Junos could automatically do with the config after the  
update has been applied and the box rebooted?



On Jul 30, 2010, at 10:19 AM, Jonathan Looney wrote:

In configuration mode, type 'replace pattern ls- with lsq-'.  That  
should replace any occurence of ls- with lsq-. You should probably  
also run show | compare afterward to ensure that this made the  
expected changes.


-Jon

On Fri, Jul 30, 2010 at 10:48 AM, Brad Fleming bdfle...@gmail.com  
wrote:
When upgrading JunosES software from 9.6 to 10.0R3 the ls-0/0/#  
interface needs to be changed to lsq-0/0/#. This needs to happen on  
the actual interface on any physical interfaces in the bundle. Does  
anyone know of a graceful way to perform this task? Does anyone know  
why Juniper decided to change the name of the interface (certainly  
makes no sense to me)?


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour

[Brad Fleming]

I

would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.


I still prefer the IOS way, where TOS byte values are re-
written on ingress (I believe we began a small petition for
this capability a year or more back, but it didn't gain any
traction). However, it works just as well in JUNOS, just on
egress.


I actually prefer the Junos method for at least some scenarios.

In my case, we connect to several other QoS-aware networks that all  
use different values for different things (ie: AF41 = EF = AF42 = AF21  
= me going crazy). Using Junos's method its very simple to do a  
different rewrite map on the egress interface toward the other  
networks. So there's basically a single piece of configuration to make  
everything function.. and a single place that things could get broken.


However, I would agree that for smaller sites (ie: J-series, SRX, etc)  
the ingress method is much easier. Having a FULL CoS stanza just to  
mark some traffic EF is kind of annoying. And I can see the arguments  
for ingress methods in other networks as well.


Of course this is just my opinion and I certainly don't run a huge  
network like some of you guys!

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SYN Flood SNMP Filtering

[Brad Fleming]

Hello all,

Is it possible to filter SNMP traps to specific hosts on an SSG-550M  
running ScreenOS 6.2?


We're getting ~38K SNMP traps regarding SYN floods from all points on  
the Internet to our monitoring system. The SNMP trap collection system  
is not as full-featured as we'd like and cannot do the filtering on  
its side. So we'd like to just avoid having the traps sent to the  
monitoring system at all.. less junk for it to sort through is always  
a good thing!


Alternatively, is there a way to change the severity of the SYN flood  
event on the SSG? IE: SYN Floods seem to be seen as emergency events.  
If we could simply make them information events, they'd never be sent  
to the monitoring system; thus achieving the desired result.


If this is a n00b question, apologies.. I'm just getting my feet wet  
with day-to-day administration of our SSG. Thanks for any assistance  
or suggestions.


-brad
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SYN Flood SNMP Filtering

[Brad Fleming]

We're getting ~38K SNMP traps regarding SYN floods from all points  
on the Internet to our monitoring system.


How about resolving the issue by mitigating the SYN-floods, which  
are the real problem?


No money to do so at this point; we have the hardware and software in- 
hand and that's it. Charity+budget cuts and all that...


I don't believe the SSG does SYN proxy'ing, correct?

I am interested how to mitigate a SYN flood properly though. Perhaps I  
can build a case for upgrades next budget year. Any suggestions,  
directions, insights, etc are appreciated. :D

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SSG Admin User Help

[Brad Fleming]

It does help, thank you. That's pretty much what I figured was  
happening. Looks like I'll be doing a root admin recovery during  
maintenance tonight too! :D



On Jun 3, 2010, at 1:05 PM, David W. Ford wrote:

If you are using a non-root account, you are not allowed to create  
or remove

user accounts.  Only the root administrator account (named netscreen
unless it was changed) is allowed to create or remove admin user  
accounts.
If you're logged on with the root administrator account you should  
be able

to remove it with the unset command.

Hope that helps.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Aggregated Ethernet QoS

[Brad Fleming]

On May 6, 2010, at 11:58 PM, Paul Waller wrote:

I can't find any documentation on CoS/QoS configuration on  
Aggregated Ethernet from Junipers web site, if anyone knows any  
links pls share.


I know what configuration I want to do I'm just not sure where it  
has to be applied i.e on Gig interface, AE interface or ex interfaces.


Be very careful what version of JunOS you use with AE and CoS. We  
discovered a software bug in 9.3 on the M10i platform where BA  
classifiers were not working on AE bundles. In our case, the packets  
were marked correctly but the classifier was simply throwing  
everything into the best-effort forwarding-class. The workaround was  
to configure a MF classifier until the bug could be resolved. Just be  
sure to TEST the config on a bench with proper hardware before  
deployment. Be sure to check egress forwarding-class on the non-AE  
interfaces to make sure your classifiers are working.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] erase configuration

[Brad Fleming]

On Apr 25, 2010, at 9:38 AM, David water wrote:


What is equivalent of wire erase in JUNOS?



It depends.. load factory-defaults is good for certain things. If I'm  
sending a router back to a retailer (after demo for example), I  
typically drop to a shell and delete everything from


rm /config/juniper.conf*
rm /config/rescue*
rm /var/db/config/juniper.conf*
rm /log/messages*

I'm guessing there are other things I should delete, but those will  
get the most obvious ones (I think).


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] non juniper SFP in MX(No virus check: scan engine not ready)

[Brad Fleming]

On Feb 18, 2010, at 2:08 AM, Georgios Vlachos wrote:


Hello list,



I know non juniper SFP work in MX but would you be worried if you  
they are

not recognized at all by chassisd? Moreover show chassis hardware or
pic-status does not list the SFPs at all. On the other hand the  
links come
up and forward traffic with no apparent errors. Would you feel  
confident

about it?




l...@mx960_ lab# run show log chassisd| last

.


Feb 16 15:50:10 pic_copy_port_info:Got cable_type for FPC 0 PIC 2  
port 6

cable num=0, str=



We typically use vendor-endorsed SFPs for production / core / critical  
links. If need to cut costs on a project, we'll use 3rd party modules  
for interfaces servicing non-critical stuff (like local servers,  
secondary systems, testing networks, etc). While the cost difference  
isn't huge, sometimes a few hundred dollars could mean getting a  
project approved in my environment.

--
Brad Fleming
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] upgrading M120 directly from 8.5 to 9.3

[Brad Fleming]

My experience is to always test the upgrade on a spare device;  
especially if its an unsupported upgrade path. A similar chassis  
running the same config will help determine what parts of the config  
are likely to change. If possible, I'd suggest attaching your spare  
device to your in-service network and make sure services will continue  
to work. I know this all seems like a huge pain, but if you're  
anything like me you only upgrade software every couple years (unless  
there's a major problem).


If you don't have spare gear available, I'd suggest opening a TAC case  
and asking for an official, supported upgrade path using software  
that's available today. That way if something goes wrong, you already  
have a ticket open with the basic info.

--
Brad Fleming

On Jan 11, 2010, at 1:59 PM, Chuck Anderson wrote:


Juniper recommends not upgrading more than 3 releases, but 8.5 to 9.3
would be a 4-release upgrade (9.0 - 9.1 - 9.2 - 9.3).  Has anyone done
this with success?  It seems strange to me that Juniper wouldn't test
and support an upgrade from one E-EOL release to another without
having to jump through a non-E-EOL release, and in fact a release that
has actually reached EOL.

8.5 reaches EOL on 2011-05-15
9.2 has reached EOL as of 2009-11-15

How is one supposed to upgrade in a supported manner once 9.2 is
removed from the web site?  Luckily, it is still there now.  But if I
have a problem with 9.2 during this intermediate upgrade step, Juniper
won't support it because it is EOL?  Seems like someone didn't think
this through very well.

I'd like to avoid the pain and just go directly from 8.5 to 9.3.  What
are your experiences?

Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JUNOS vulnerability with malformed TCP packets

[Brad Fleming]

I think it depends how the vulnerability is discovered. If its  
discovered by groups that are likely to exploit the issue, I'd prefer  
Juniper tell me NOW. If it is discovered internally by Juniper  
technicians (or in a trusted customer lab), I'm OK with Juniper fixing  
the issue and releasing details 6 months later.


I suppose severity of the exploit is another sliding metric for  
whether I want to know immediately or not.


-brad

On Jan 7, 2010, at 11:44 AM, Darrell Root wrote:



Anyone know why some issues identified as early as January 2009 are  
only
being released now almost a year later?  Just curious on some of  
these

security alerts and timeframe...


If Juniper finds a security DDOS vulnerability, and it's not general  
knowledge,
I'd prefer them to integrate the fix into their code without an  
announcement.  That way,
by the time the hackers find out about the vulnerability, the fix  
may have already been

deployed to many of our affected routers.

In this case that saved me a crash upgrade project.  By the time it  
was announced

I already had the fixed code on my JunOS boxes.

Darrell

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp