[j-nsp] SRX for access/core routing/MPLS duties?
Michael Damkot
mdamkottwc at gmail.com
Wed Jul 28 11:52:35 EDT 2010
I have two 5XXX series SRX boxes in an Active / Active cluster sitting in the middle of a network. They currently carry the following: (PIM goes up and down depending on downstream pulls)
inet.0: 322738 destinations, 968448 routes (322735 active, 2 holddown, 20 hidden)
Restart Complete
Direct: 12 routes, 11 active
Local: 12 routes, 12 active
OSPF: 77 routes, 77 active
BGP: 968344 routes, 322632 active
IGMP: 1 routes, 1 active
PIM: 2 routes, 2 active
Convergence times are sub 4 minutes, but I completely agree that there are some new kid on the block issues that still crop up on a regular basis.
It's also worth note that I am only peering with internal BGP neighbors, no external neighbors at this time.
On Jul 28, 2010, at 11:34 , Ben Dale wrote:
>
>> I've been reading past threads on the SRX line with interest. It seems this box can do many of the things we are looking for (at a low price point), which include:
>>
>> - MPLS
>> - IPv4 routing (OSPF, BGP)
>> - Runs JunOS
>> - Could be used at the access layer
>> - Future IPv6 support
>> - If required, could be used as an edge device holding a full IPv4 table (at least, the SRX650 and above)
>>
>> Can anyone comment on experiences with these devices, such as:
>>
>> - Wire rate? yea/nay?
>
> The branch office models (100, 210, 240, 650) are all software-based forwarding engines, so nay. The 650 is pretty gutsy, but it's no EX. Word on the street is that there will be a model arriving soon that fits between the 650 and the 3400, but will be based on the high-end hardware (SPC/NPC) platform.
>
>> - Anyone ever tried to use one as an edge router w/a full BGP feed?
>
> Yes. Results were mixed, but generally avoid this scenario if you can. As discussed in other recent threads - flow-mode processing is not ideal for an edge-router (you move from a PPS limitation with a normal router to a session table limitation for starters), and performance-wise full-table updates are nothing to write home about.. though you will have plenty of time to write home about them while waiting for them to complete if you so wish..
>
>> - MPLS -- mainly EoMPLS type stuff, esp. at the access layer
>
> This IMHO is where the SRX really shines and the "One-OS" mantra really sees the light of day. Juniper didn't leave too much out of the SRX code - EoMPLS, VPLS, L3VPN, Logical-Tunnel interfaces, it's all there - they really are the swiss-army knife of access boxes, and at a very surprising price. Just make sure you go high-memory for everything day one. SRX240s will take 2GB of 3rd party RAM quite happily too.
>
>> - Stability (we understand that this is highly specific to the JunOS release)
>
> You've got that right ; ) Seriously though, the MPLS-code in the SRXs seems to be pretty tight - most of the bugs I come across seem to be related to the security-processing and clustering side of things which is all (relatively) new. That said, since moving the majority of my customers to 10.0r3 my open JTAC Cases have significantly decreased (the same can be said for EX). That's not to say there aren't still some doozies out there though (turn on HTTPS in 10.0r3 and browse to the web interface, now make some coffee, now learn a foreign language, now log in).
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list