Re: Multi-gigabit edge devices as CPE
The ACX5000 series are Ethernet-only switches. They hold about 120,000 entries in FIB, and as of today despite all the RAM, are only sold with support for 300,000 entries in RIB. The chipset is not Juniper in-house, though; so make sure all your features work. The ACX series is more of a hybrid. They are probably more likened to Layer 2 routers than switches. They are primarily designed as Mobile backhaul devices where integration into existing IP MPLS infrastructure would be a cost saving and design advantage. You can see this with the other models that have the TDM (E1/T1) interfaces. Those models use SAToP and CESoPSN to move TDM based circuits over an MPLS network. It's all rather clever really. The Ethernet ports on those models as well as the ethernet only models are an extension of that. They provide layer 2 interfaces where you don't really require layer 3 services (such as ethernet based mobile backhaul). So they are a switch, yes, but more than that. They utilise MPLS L2VPN/L2Circuits to move ethernet over the MPLS infrastructure. Hence why I thought it could be an alternative to terminating the layer 3 at the edge. Hamish
Re: Multi-gigabit edge devices as CPE
Is it a necessity to terminate the layer 3 at the edge? You could get a 10Gbps switch and move it all back to a central location where you have your high end routers. It would then be terminated as a VLAN and be a router on a stick kind of topology. Could be a cheaper way to do it without taking MPLS all the way out to the edge. As Tim said above, I too was thinking about the Juniper ACX. The 5048/5096 model could suit your needs. They are primarily designed as layer 1(TDM)/2 backhaul devices and i'm not sure they can do a full table. They do have full JunOS MPLS features. Could be a way to use MPLS-TE to move the layer 2 back to a core location and terminate later 3 there. Would give you some flexibility over just doing ethernet stuff as I mentioned in the first paragraph. Hamish On Thu, Apr 9, 2015 at 10:46 AM, Daniel Rohan dro...@gmail.com wrote: I work at a state REN and we are seeking a lead for a new edge device for on prem deployment at customer sites. We currently deploy two classes of routers-- a high end and a low end. Both the high end and the low end use some of the standard edge features: MPLS-TE, MBGP, flowspec, vrf, PIM, etc. We deliver full tables over these devices to the customers that need them. We recently finished a new ethernet procurement and have a large number of sites (~200) moving from 1Gbps in bandwidth to 1-10Gb in bandwidth. Our currently deployed low-end router can't handle these speeds and we can't afford to place our high end router at 200+ sites. So, we're looking for a middle tier router to deploy. Something with 2+ SFP+ ports, software that can handle the aforementioned features, and something with an API that we can leverage for programmatic management. So far we've not found anything that checks all the boxes. Layer 3 switches seem like obvious choices, but lack some of the features and RIB/FIB we need at the edge. Other devices like the Juniper MX5/10 certainly meet the requirements, but are priced way beyond what we can afford. Any suggestions for devices we might have overlooked? Preferably in the less than 10K per unit price point. If such a magical device exists. -Dan
Re: What can I infer from show ip route and similar BGP commands?
Hi there,
Perhaps this would be easier and help you out:
http://bgp.he.net/AS3701#_graph4
Cheers,
Hamish
On Tue, Dec 9, 2014 at 12:48 PM, Reza Motamedi motam...@cs.uoregon.edu
wrote:
Hello NANOG,
I’m a researcher and I was trying to understand the data I collected from
some BGP Looking Glasses. Basically, I was hoping to see if BGP records can
tell me where my university’s provider (AS3701) is peering with its
providers. I issued two BGP queries to Level3’s LGs, one in Seattle and one
in Amsterdam for my school’s prefix. My strong guess was that our provider
(AS3701) peers with Level3 in Seattle. I was hoping to conclude something
like this: if the peering occurs in Seattle, the Seattle LG should reveal
it, but Amsterdam should not.
AS3701 is Nero (Network for Education and Research in Oregon) which I
assume is a small regional AS. I don't think Nero peers with Level3 in
Amsterdam, however, I get this AS for my next hop even when I issue the
command from Amsterdam. On the other hand “car1.Sacramento1” suggests that
the peering happens in Sacramento.
This result makes me think what I get is from a combination of iBGP and
eBGP, which is also apparent from “Internal/External” keywords in the data.
My main issue is that the keywords are not always available. In some other
LG I just get a next hop IP and an AS path. How can I make sure that the
peering information comes from an eBGP peering? I think the next hop IP
might be the answer, right?
I included the results of the command for both LGs here, hopefully somebody
could explain to me
-
Route results for 128.223.0.0/16 from Amsterdam, Netherlands
BGP routing table entry for 128.223.0.0/16
Paths: (2 available, best #1)
3701 3582
AS-path translation: { OREGONUNIV UONET }
car1.Sacramento1 (metric 58341)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: North_America Lclprf_100 Level3_Customer United_States
Sacramento
Originator: car1.Sacramento1
3701 3582
AS-path translation: { OREGONUNIV UONET }
car1.Sacramento1 (metric 58341)
Origin IGP, metric 0, localpref 100, valid, internal
Community: North_America Lclprf_100 Level3_Customer United_States
Sacramento
Originator: car1.Sacramento1
-
Route results for 128.223.6.81/16 from Seattle, WA
BGP routing table entry for 128.223.0.0/16
Paths: (4 available, best #3)
3701 3582
AS-path translation: { OREGONUNIV UONET }
4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net)
Origin IGP, localpref 90, valid, external
Community: North_America Lclprf_90 Level3_Customer United_States Seattle
Level3:11847
3701 3582, (received-only)
AS-path translation: { OREGONUNIV UONET }
4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net)
Origin IGP, localpref 100, valid, external
Community: Level3:90
3701 3582
AS-path translation: { OREGONUNIV UONET }
car1.Sacramento1 (metric 34363)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: North_America Lclprf_100 Level3_Customer United_States
Sacramento
Originator: car1.Sacramento1
3701 3582
AS-path translation: { OREGONUNIV UONET }
car1.Sacramento1 (metric 34363)
Origin IGP, metric 0, localpref 100, valid, internal
Community: North_America Lclprf_100 Level3_Customer United_States
Sacramento
Originator: car1.Sacramento1
Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Computer and Information Science
University of Oregon
