I was wondering if anyone was using a Alcatel-Lucent 7750 Service Router (SR) in their network? How does this platform compare the the Cisco ASR, Brocade MLXe, and Juniper MX line?
They are definitely good for that. We use them in part of our network for something very similar. I am not sure why they aren't mentioned that much. I know that they have been pretty popular in the past couple years. We are planning on using 7750 SR-a4's in the future but right now we mainly have 7750SR7/12s. Sent from my iPhone
If you know Juniper and Cisco, the learning curve isn't so bad to pick up the ALU CLI, after working with it for a brief time, you catch on quickly. Their products are quite impressive, and a # of the carriers, are moving to them and some have already moved to them and are quite happy with their decision. On Wed, May 6, 2015 at 6:24 PM, Colton Conor <colton.conor@gmail.com> wrote:
The show stuff is certainly there but the config is a bit different. You may have to get used to using the "info" command. :) They also use logical IP interfaces which are then tied to physical, you don't directly configure L3 on a physical interface. You also have designations between service and network physical interfaces, although nowadays they can be set as "hybrid.". It's really pretty simple if you are used to a Cisco or Juniper. They have tab and ? completion now for both commands as well as elements similar to Junos which is helpful. Phil -----Original Message----- From: "Bob Evans" <bob@FiberInternetCenter.com> Sent: 5/6/2015 11:55 PM To: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Alcatel-Lucent 7750 Service Router (SR) I will be getting one to try. I am pretty sure it will support the ol' "show ? , config ?" If not that might be a problem :-) Thank You Bob Evans CTO
+1 for the command structure and configuration being pretty simple to follow if you're used to a Cisco or Juniper. In the main they are pretty good at what they do I guess but I'm not sure whether or not we're having seriously bad luck or there's something else a miss but sadly we've had a near 50% hardware failure rate on some of the cards we have deployed in our 7750 SR12 infrastructure. Reply off list if you need any more information. Mick -- Mick O'Donovan | Network Engineer | BT Ireland | Website: http://www.btireland.net Looking Glass: http://lg.as2110.net Peering Record: http://as2110.peeringdb.com AS-SET Macro: AS-BTIRE | ASN: 2110 On 07/05/15 05:29, Phil Bedard wrote:
I am worried as most tech's know Cisco and Juniper, so going to ALU would be a learning curve based on replies I am getting off list.
It's definitely quite different from the CLI. I'm still dabbling, but the guys here who have been through the training and are immersed in it really like it. We're using a couple for feature-rich BNG - lots of MLPPP at high bandwidths (for broadband), heavyweight QoS, BGP to the CE, etc. It's very controllable by RADIUS - template configs that you can fill in the values for, rather than the Cisco approach of AVPs with pages of config in. ALU have an e-learning "SR-OS introduction" course, which is going down pretty well for jump-starting our Ops people. Regards, Tim.
It really bothers me to see that people in this industry are so worried about a change of syntax or terminology. If there's one thing about the big vendors that bothers me, it's that these batteries of vendor specific tests have allowed many "techs" to get lazy. They simply can't seem to operate well, if at all, in a non-Cisco (primarily) environment. On May 7, 2015 1:12:11 AM AKDT, Tim Franklin <tim@pelican.org> wrote:
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
You know where these people wouldn't fit? W/ISPs. Every three years or so you are forklifting the majority of your wireless PtMP for either a new series or a totally different vendor. New backhaul vendors often. You're building AC and DC power plants. You likely touch Cisco, juniper, HP, mikrotik, ubiquiti, Linux, windows, *BSD/pfsense, lucent, accedian/ciena, etc due to various client and network requirements all in the same week, AND you have to make them work together nicely :) It's not the environment for somebody like that, and I truly don't understand how people of that.. "caliber" end up working on large scale WANs and global transit networks. Frankly, it scares me a bit. On May 7, 2015 9:07:35 AM AKDT, Craig <cvuljanic@gmail.com> wrote:
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Many of these churn rates result from problems self inflicted hence all the dramatic sdn promises, popularity in abstractions, Api all the things, let's go yang/netconf and retrofit every ietf standard. There's benefits but gotta rant a little. What's better than correct? Well over correct of course.
I'd half-agree :) Making "it's different" in and of itself a reason not to use a particular vendor does seem to head towards laziness. But with the best will in the world, your good engineers *will* be slower until they familiarise with the new mind-maps (particularly things like the logical/physical split, SAPs, etc on the ALU) and the new magic words - although hopefully they'll be excited to learn something new too. Your weaker engineers are going to need more of a push and/or some help, and the further towards helpdesk and scripts you get, the more you're going to need to provide training - be that internal, external, new scripts and cribs sheets or whatever. That's an impact and cost it's unwise to ignore. Regards, Tim.
yep.. its way easier and faster to take a look at what is configured: A:R01>config>service>vprn# interface "to-what-ever-eBGP" A:R01>config>service>vprn>if# info ---------------------------------------------- description "L3 Ckt ID: 555555555555" enable-ingress-stats cpu-protection 231 address 299.299.299.299/30 cflowd interface ipv6 address 2001:xxxx:xxxxx::xxxxx/126 exit sap 1/1/2 create cpu-protection 231 ingress filter ip 3356 filter ipv6 3356 flowspec exit exit ---------------------------------------------- On Thu, May 7, 2015 at 12:08 PM, Chris Boyd <cboyd@gizmopartners.com> wrote:
And if you ever need to find out what can commands exist for a certain string "xxx" tree flat detail | match xxx is a huge helper when learning. e.g. A:router# tree flat detail | match aspath-regex show router bgp routes [<family> [type <mvpn-type>]] aspath-regex <reg-ex> show router bgp routes [<family> [<l2vpn-type>]] aspath-regex <reg-ex> On Thu, May 7, 2015 at 9:16 AM, Craig <cvuljanic@gmail.com> wrote:
-- *Trent Farrell* *Riot Games* *IP Network Engineer* E: tfarrell@riotgames.com | IE: +353 83 446 6809 | US: +1 424 285 9825 Summoner name: Foro
Forgot to send this yesterday… We use them in our networks along with ASR9Ks and MXs. There are a lot of them deployed around the world doing very similar things as ASRs and MXs. The config is more like Juniper than Cisco IMHO. Being kind of the “3rd” vendor they have a tendency to implement features proposed by both Cisco and Juniper faster than Cisco and Juniper when proposed by the other vendor. For instance Segment Routing is a Cisco thing, but ALU has already implemented it in their latest 13.0 software, Juniper is sort of dragging their feet on it because it’s a Cisco thing. Same goes for NG-MVPN (BGP signaled multicast VPN). Cisco dragged their feet on it because it was a Juniper thing, ALU had no issues implementing it much sooner. Most of ALUs innovation is on the MPLS services side. We use them for business VPN (L2 and L3) but the underlying protocols are all standard stuff and interoperate with everything else. Phil -----Original Message----- From: Colton Conor Date: Wednesday, May 6, 2015 at 17:48 To: NANOG Subject: Alcatel-Lucent 7750 Service Router (SR)
On 7/May/15 15:16, Phil Bedard wrote:
Forgot to send this yesterday…
We use them in our networks along with ASR9Ks and MXs. There are a lot of them deployed around the world doing very similar things as ASRs and MXs. The config is more like Juniper than Cisco IMHO. Being kind of the “3rd” vendor they have a tendency to implement features proposed by both Cisco and Juniper faster than Cisco and Juniper when proposed by the other vendor. For instance Segment Routing is a Cisco thing, but ALU has already implemented it in their latest 13.0 software, Juniper is sort of dragging their feet on it because it’s a Cisco thing. Same goes for NG-MVPN (BGP signaled multicast VPN). Cisco dragged their feet on it because it was a Juniper thing, ALU had no issues implementing it much sooner. Most of ALUs innovation is on the MPLS services side. We use them for business VPN (L2 and L3) but the underlying protocols are all standard stuff and interoperate with everything else.
I went to an ALU lab last year to look at some of their kit. Very impressive in the BNG space, and they've had a good reputation for that even before I laid hands on one. The CLI is pretty neat, and easy to learn. You're right about ALU not being fussy (but being faster) on implementing features that Cisco and Juniper squabble over. We have just received a test router we have for the next couple of months, and may consider them for some roles in the network if we are happy. My only gripe with ALU is their Metro-E offering is currently not where I'd like it to be. Mark.
participants (15)
-
Bob Evans -
Bruce -
Chris Boyd -
Colton Conor -
Craig -
Dan Snyder -
Josh Reynolds -
Mark Tinka -
Mick O'Donovan -
Phil Bedard -
Rob Seastrom -
Stephen Fulton -
Tim Franklin -
Trent Farrell -
Watson, Bob