Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Łukasz Bromirski]

> On 16 Nov 2017, at 08:49, Gert Doering  wrote:
> 
> Hi,
> 
> On Wed, Nov 15, 2017 at 11:03:50PM +0100, ??ukasz Bromirski wrote:
>> 2901 supports VRRP. 
> 
> Yes, but not VRRPv3 for IPv6 (at least in the code base we've rolled
> out, haven't investigated if it's in some sort of 15.6T or later).

It may be. That’s from my home terminal server:

rtr-ts#sh ver | i IOS
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.6(2)T1, 
RELEASE SOFTWARE (fc1)
rtr-ts(config)#fhrp version vrrp v3

That’s a version that was published July last year.

>> Those things are ???PI??? code (Platform Independent).
> Right, so why is there no HSRPv2 on ASR920, or EIGRP on NCS5000, or static
> LSPs on 6500?  These are all control plane features, independent off the 
> underlying hardware.

It’s up to BU to pull the code. I never wrote anywhere that, You
know, everybody is pulling all the code they can find just for
the sake of having everything :) The trend these days is exactly
opposite thanks to years of roasting us (Cisco) for having too
much features and in effect - too much bugs. PMs for BUs it
seems started to be picky in terms of what goes in. This is in
addition to the fact, that right now every new platform should
run IOS-XE, which by itself is perfectly capable of running
modular, and this again add options. ASR 9xx are quite complex
in terms of hardware offload capabilities BTW, and each SKU may
have it’s own ‘specialities’. It’s worth double-checking release
notes and config guides with local SE before booking time for
testing.

Having said that - there may be some hardware dependencies with
HSRP or LSPs (for EIGRP the only think I can think of is no immediate
need to run it in SP networks). But that’s just me guessing, not
our official policy.

>> As soon as you hit hardware dependencies however in platforms that
>> offload something to hardware??? yes, world isn???t a fairy tale, no matter 
>> which
>> vendor you decide to lock-in-to.
> 
> I fully understand hardware limitations, coming from a world full of
> 6500 :-) - and the 6500/7600 split was a good example of "no, these lacking
> features have nothing to do with hardware capabilities”.

I know You do :) 

> Things like missing EIGRP or HSRPv2 cannot even be properly explained
> with BU in-fighting (like, OTV vs EVPN) if the code is already there for
> the OS used…

It’s probably more like Inception (the movie). Layers of layers over
layers of different requests, priorities, platform positioning challenges,
and so on.

-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Brian Turnbow]

Hi,

> > NCS5500s do not support EIGRP
> 
> Return to Step 1 - "why, if you have customers actually *liking* your
vendor-
> lock-in features, why would you stop shipping them?".
> 
> Actually they seem to be really liking that... ASR920 doesn't do HSRPv2
> (though it *does* support HSRPv1).  So, if you have a 2901 + ASR920 as
> router pair, no IPv6 first-hop redundancy for you (while ASR920 will do
VRRP
> instead, 2901 won't).
> 

Very strange indeed, XR supports eigrp and I don't see how it could be
hardware related.

Baffling...

I hope it doesn't extend to other devices where XR is extending to..
It is already hard enough to make sure the hardware support for what you
need is there.
If software features go missing randomly from different devices when the
documentation bug strikes it will really be a pain.

Brian
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Gert Doering]

Hi,

On Wed, Nov 15, 2017 at 11:03:50PM +0100, ??ukasz Bromirski wrote:
> 2901 supports VRRP. 

Yes, but not VRRPv3 for IPv6 (at least in the code base we've rolled
out, haven't investigated if it's in some sort of 15.6T or later).

> Those things are ???PI??? code (Platform Independent).

Right, so why is there no HSRPv2 on ASR920, or EIGRP on NCS5000, or static
LSPs on 6500?  These are all control plane features, independent off the 
underlying hardware.

> As soon as you hit hardware dependencies however in platforms that
> offload something to hardware??? yes, world isn???t a fairy tale, no matter 
> which
> vendor you decide to lock-in-to.

I fully understand hardware limitations, coming from a world full of
6500 :-) - and the 6500/7600 split was a good example of "no, these lacking
features have nothing to do with hardware capabilities".

Things like missing EIGRP or HSRPv2 cannot even be properly explained
with BU in-fighting (like, OTV vs EVPN) if the code is already there for
the OS used...

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Łukasz Bromirski]

Gert,

> Return to Step 1 - "why, if you have customers actually *liking* your
> vendor-lock-in features, why would you stop shipping them?".
> 
> Actually they seem to be really liking that... ASR920 doesn't do HSRPv2
> (though it *does* support HSRPv1).  So, if you have a 2901 + ASR920
> as router pair, no IPv6 first-hop redundancy for you (while ASR920 will
> do VRRP instead, 2901 won't).

2901 supports VRRP. Those things are “PI” code (Platform Independent).
As soon as you hit hardware dependencies however in platforms that
offload something to hardware… yes, world isn’t a fairy tale, no matter which
vendor you decide to lock-in-to.

—
./


signature.asc
Description: Message signed with OpenPGP
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Gert Doering]

Hi,

On Wed, Nov 15, 2017 at 02:13:20PM +0100, Brian Turnbow wrote:
> Wanted to correct a post from a while back I made when discussing
> NCS5500s 

Thanks for that.

> > > And then, what features it gets - the first list on cisco.com was
> >> amazingly thin on details, but one of the interesting bits was 
> >>"no support for EIGRP",which I  find highly astonishing - you have a
> vendor that has a nice
> >> customer-lock-in  feature, purely control-plane (so, no need to do
> hardware-specific
> > > coding),  and they... forget to enable it?
[..]
> NCS5500s do not support EIGRP

Return to Step 1 - "why, if you have customers actually *liking* your
vendor-lock-in features, why would you stop shipping them?".

Actually they seem to be really liking that... ASR920 doesn't do HSRPv2
(though it *does* support HSRPv1).  So, if you have a 2901 + ASR920
as router pair, no IPv6 first-hop redundancy for you (while ASR920 will 
do VRRP instead, 2901 won't).

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Brian Turnbow]

Hi

Wanted to correct a post from a while back I made when discussing
NCS5500s 

> 
> > And then, what features it gets - the first list on cisco.com was
>> amazingly thin on details, but one of the interesting bits was 
>>"no support for EIGRP",which I  find highly astonishing - you have a
vendor that has a nice
>> customer-lock-in  feature, purely control-plane (so, no need to do
hardware-specific
> > coding),  and they... forget to enable it?


> It is available  but needs to installed as an add on package..
> http://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/system-setup/60x/b-
> ncs5500-system-setup-guide-60x/b-system-setup-ncs5k_chapter_0110.html
> 

Nope, it is in fact another of the dreadful documentation bugs.
NCS5500s do not support EIGRP


Brian


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 31/Jul/17 11:48, Saku Ytti wrote:

> Not trying to start debate about which BGP implementation is better or
> worse. Just pointing out Juniper being 'worst' implementation is
> highly subjective. Another network might have 0 problems with JunOS
> BGP and massive issues with XR BGP.

I think we can all agree on that.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Saku Ytti]

On 31 July 2017 at 12:14,   wrote:


>> I could also give similarly BGP examples, which would make it appear like 
>> IOS-
>> XR has bad BGP compared to JunOS.
> I'd like to hear those actually.

I'm not gonna go through emails, cases and wiki, so just stuff from
top of my head.

XR re-advertises default at every update generation cycle, leading to
far-end potentially reset the route age changing their route
selection. This is against RFC4271 which forbids resending same
unchanged route. (CSCve41797)
XR ORR does not advertise any route (not even suboptimal) if next-hop
needs recursion.
Maybe 7 BGP crash bugs in 5.3.1 that hit us
Hard to track BGP ghosting issues (technically not ghosting, closing
TCP window so nothing can be communicated, while rest of the network
has converged, one box may be lagging tens of minutes or hour)
Static define on BGP process size, after which you just crash, instead
of use memory you actually have, breaking scaling

Then 'minor' stuff, like breaking compatibility with RFC1771 speakers
in minor release update (CSCva74669), unable to to talk standard
compliant RFC1771 implementation. Our product description does not
mandate that you must be 4271. Certainly does not feel good to
suddenly break bunch of BGP sessions to customers for no good reason.

Then of course the LPTS stuff, we see perhaps twice a month issue
where some XIPC TCP queue gets congested and all BGP sessions hitting
that queue get dropped. With no indication what was in the TCP queue.

I cherry-picked problems we don't have with JunOS. Of course in JunOS
you've long time had very unpredictable convergence between bgp and
krt.

Not trying to start debate about which BGP implementation is better or
worse. Just pointing out Juniper being 'worst' implementation is
highly subjective. Another network might have 0 problems with JunOS
BGP and massive issues with XR BGP.
--
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[adamv0025]

Hey,
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Sunday, July 30, 2017 11:01 AM
> 
> On 30 July 2017 at 12:06,   wrote:
> 
> Hey,
> 
> > So if the backbone is subject to DDoS attacks and carries traffic of
> > multiple priority levels, then stay away from Trio.
> >
> > ASR9k has stupidly long upgrade times but at least it's NPU and Fabric
> > architecture is basically alright.
> > The LACP QOS is a moot point, there's no right and wrong way of doing
> > the split.
> 
> I think you're cherry picking examples to highlight architecture differences. 
I really try to be objective and I acknowledge that ASR9k has some issues on 
its own.
However the issues I'm most worried about are HW/Architectural flaws, for which 
it is ever so harder to convince platform architects to make any changes to 
status quo, especially when there's no support from market. 

> I
> have some trust in market, if it would be this black and white, Juniper would
> be dead.
> 
Well, not really, let me ask a simple pooling question to the list, how many of 
you folks have a Spirent or IXIA tester in a loop with MX960 or ASR9k to find 
out how the box behaves under various stress situations?

Market doesn't care, simply because there's no need, the SLAs are not that 
tight in most cases, there's only handful of ISPs who can afford to have full 
time tester engineers to truly test the platform or new line-cards they are 
about to purchase. 
Oh and most of the times the cheaper option is chosen anyways.  

Personally I enjoy the competition on the oblivious market as it allows me to 
purchase HW I need for lower prices. 


> Just to offer one counter-point, imagine you have 10GE egress port in ASR9k,
> either VLANs or satellite subdivided. Now send 20Gbps of traffic to 1 VLAN or
> 1 satellite port.
> 10Gbps of traffic going to that 10Gbps port gets dropped by ingress NPU,
> without any knowledge of egress satellite port or egress VLAN. So all VLANs,
> all satellite ports are dead, because one customer got DDoS. 
Not exactly,  
1) Traffic waiting to be sent across the fabric has already been processed by 
the ingress NPU and classified correctly and therefore is sitting in fabric 
queues of different priority. 
2) Arbiter will always try to place packets in high-priority fabric queue onto 
the fabric first and only if the high-priority queues are empty it will try to 
service lower-priority queues. 
3) So if back-pressure is initiated by the egress NPU, then up to 10Gbps of 
high priority traffic makes it through to the egress satellite ports or egress 
VLANs hosted on a particular physical 10GE port and is therefore treated by 
their individual policers on egress NPU. 
4) so only low priority traffic is affected in this scenario. 
 
Oh and this is the best case scenario, as some ASICs out there won't send 
back-pressure per individual port but only after the overall compute capacity 
of the ASIC is depleted so all ports on the egress ASIC suffer from the 
backpressure, not just the one getting the DDOS.  
And some ASICs won't send backpressure until theoretical max forwarding 
capacity of the ASIC is depleted, which obviously results in massive overload 
of the ASIC and mayhem dropping regardless of packet priority. 
  
 
> I'm not saying ASR9k is definitely worse, I'm saying like Miercom tests, you
> can make any vendor look bad/good against any other vendor, by knowing
> both platforms and cherry-picking pathological examples.
> 
I bet that all these "independent" folks have no idea about the HW architecture 
of boxes they are testing and how to test them properly.  

> For me personally, MX edge has lot less customer impacting issues than XR
> edge, but I fully expect situation to be different with different set of
> requirements and features. I suspect XR IPC/state duplication/state share is
> fundamentally fragile.
> 
I'm more concerned about the basic traffic forwarding through the box, and that 
is more robust on ASR9k than it is on MX. 

> I could also argue ASR9k has no functional control-plane protection, because
> every BGP neighbour in NPU share same policer, so if one of them has L2
> loop and offers too much BGP, all of them are dead. Or
> ICMP6 or ARP or whatever. And you cannot manually intervene, as LPTS
> packets are not subject to interface MQC, you just wait for baddies to stop.
> Cisco is aware and are working to fix this, but when and how will fix surface,
> no one knows.
> Out-of-the-box LPTS is superior protection to MX, but MX can be configured
> better, but I suspect there single digit networks who are technically able.
> JNPR should ship with sensible defaults.
> 
Yes I agree, MX has also great FW filter versatility and combined with 2nd gen 
trio on MPC3 is excellent for edge filtering and DDoS protection. 

> I could also give similarly BGP examples, which would make it appear like IOS-
> XR has bad BGP compared to JunOS. 
I'd like to hear those actually.

> But I could of 

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Gert Doering]

Hi,

On Sun, Jul 30, 2017 at 08:02:49PM -0400, Phil Bedard wrote:
> None of the folks in the target market for the NCS run EIGRP, at least not 
> in their SP networks.  Most are asking for less features in software, not 
> more. 

I can see that argument for IOS and IOS XE, but for something that is 
supposed to be fully modular like IOS XR, having another control plane
feature in a separate process (which you do not run when you do not 
want it = no impact) should be save enough.

Note the emphasis on "control plane" - no tricky hardware programming
interaction, just central CPU handling specific protocol packets.

I can also see the wish to avoid spending development resources on a
"new protocol that nobody uses", but since the feature is already there
on XR on CRS-1 and ASR9k, if that is a serious argument, it opens up
lots of question marks on internal development processes...

(OTOH, EIGRP seems to be there, as an optional bundle, as has been
answered already - so it's just the documentation of "supported features"
on the platform web site which is/was misleading)

> ISSU is also something the platform is not meant to support as it???s 
> incredibly complex and prone to breaking things.  

I can see that.

> Like I said, first out it was targeted for large service provider
> and web companies. There are other things that come to the box first
> those providers are looking for like more powerful RPs, YANG models,
> streaming telemetry, no transceiver lock-in, etc.  It runs XR so
> the platform supports SP features including edge PE and core type
> functionality from small to large boxes.  The last SP I worked at
> we replaced edge 9Ks with the NCS since we didn???t need all the
> functionality of the 9K in those locations. There is still development
> left and it will never support all the functionality of XR on the
> 9K, but it???s getting there.  The platform isn???t going anywhere.

Now that's good news :-)  (though "the platform" could be NCS-5001
or NCS-5501 here, which are different enough that it's not clear if
this holds for both platforms...)

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Phil Bedard]

None of the folks in the target market for the NCS run EIGRP, at least not in 
their SP networks.  Most are asking for less features in software, not more. 
ISSU is also something the platform is not meant to support as it’s incredibly 
complex and prone to breaking things.  Like I said, first out it was targeted 
for large service provider and web companies. There are other things that come 
to the box first those providers are looking for like more powerful RPs, YANG 
models, streaming telemetry, no transceiver lock-in, etc.  It runs XR so the 
platform supports SP features including edge PE and core type functionality 
from small to large boxes.  The last SP I worked at we replaced edge 9Ks with 
the NCS since we didn’t need all the functionality of the 9K in those 
locations. There is still development left and it will never support all the 
functionality of XR on the 9K, but it’s getting there.  The platform isn’t 
going anywhere.  

Phil 

-Original Message-
From: Gert Doering <g...@greenie.muc.de>
Date: Friday, July 28, 2017 at 03:27
To: Phil Bedard <phil...@gmail.com>
Cc: Rick Martin <rick.mar...@arkansas.gov>, "cisco-nsp@puck.nether.net" 
<cisco-nsp@puck.nether.net>
Subject: Re: [c-nsp] Nexus 7707 as Internet Edge Router?

Hi,

On Thu, Jul 27, 2017 at 09:27:36PM -0400, Phil Bedard wrote:
> Do you require something with redundant RPs?  The fixed NCS5001/NCS5501 
would probably fit what you need well if you don???t.  The chassis based NCS 
systems are a bit overkill for your needs.  The NCS5XXX were mainly pitched to 
larger providers originally with their own account teams so I don???t think 
much info on them has trickled down to VARs yet.  If you have any questions let 
me know.  

"Anything detailed" you have on the NCS5* would be welcome - the material
on www.cisco.com is a bit sparse.

Since we're considering to either go for QFX5100 or NCS5* for bandwidth
expansion in our "core" (= no customer connections, no external connections,
all 10G links, not much demand for QoS due to DWDM underlay where we can
just add more bandwidth if needed), understanding how Cisco positions the
NCS5001 series and whether this is a one-off thing that will be end-of-life
next year ("remember the ME3600?") or something which is going to receive
proper love and caring is one of the most important questions here...

And then, what features it gets - the first list on cisco.com was 
amazingly thin on details, but one of the interesting bits was "no 
support for EIGRP", which I find highly astonishing - you have a vendor
that has a nice customer-lock-in feature, purely control-plane (so, 
no need to do hardware-specific coding), and they... forget to enable it?

gert
-- 
USENET is *not* the non-clickable part of WWW!
   
//www.muc.de/~gert/
Gert Doering - Munich, Germany 
g...@greenie.muc.de
fax: +49-89-35655025
g...@net.informatik.tu-muenchen.de



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 30/Jul/17 15:33, Saku Ytti wrote:

> Personally I feel the obvious right answer is, that the platform
> dynamically divides bandwidth numbers by active_member_count, and
> programs that to the TM, if active_member_count changes, TM
> programming changes.

This is what Junos does on the Trio on an MX. The programming of each
member link is dynamic depending on its availability.


>
> Like you said, requires very good balancing. But even that seems
> mostly solved problem today, when you have additional abstraction
> level between hash-result and egress_interface. As imbalances can be
> handled by unevenly populating the hash-result=>egress_interface
> mapping table.

The main problem is that the load balancing code and the policing code
are not really aware of each other (which makes sense as these are
separate functions). If the vendors could find a way to make both bits
of code aware about each other when implemented by an operator, to
improve the situation.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Saku Ytti]

On 30 July 2017 at 14:35, Mark Tinka  wrote:

>> The LACP QOS is a moot point, there's no right and wrong way of doing the
>> split.
>
> Doubling the bandwidth because the policer programs as such each member
> link is definitely the wrong way.

Agreed. Of course you can work around, and configure the MQC as
desired_bw/member_count. But that breaks up badly if you lose link
from LACP.

Personally I feel the obvious right answer is, that the platform
dynamically divides bandwidth numbers by active_member_count, and
programs that to the TM, if active_member_count changes, TM
programming changes.

Like you said, requires very good balancing. But even that seems
mostly solved problem today, when you have additional abstraction
level between hash-result and egress_interface. As imbalances can be
handled by unevenly populating the hash-result=>egress_interface
mapping table.


-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 30/Jul/17 11:06, adamv0...@netconsultings.com wrote:


> The LACP QOS is a moot point, there's no right and wrong way of doing the
> split. 

Doubling the bandwidth because the policer programs as such each member
link is definitely the wrong way.

The biggest trick with policing a LAG is that the load balancing has to
be (near) perfect. Without that, it becomes tricky, or at worst, means
that you only support LAG policing for traffic that is easy to hash
across multiple member links.

Either way, hitherto, Juniper do it better than Cisco.

That said, it's still a complicated process, so we've found other ways
to solve the issue.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 30/Jul/17 11:06, adamv0...@netconsultings.com wrote:


> The LACP QOS is a moot point, there's no right and wrong way of doing the
> split. 

Doubling the bandwidth because the policer programs as such each member
link is definitely the wrong way.

The biggest trick with policing a LAG is that the load balancing has to
be (near) perfect. Without that, it becomes tricky, or at worst, means
that you only support LAG policing for traffic that is easy to hash
across multiple member links.

Either way, hitherto, Juniper do it better than Cisco.

That said, it's still a complicated process, so we've found other ways
to solve the issue.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Saku Ytti]

On 30 July 2017 at 12:06,   wrote:

Hey,

> So if the backbone is subject to DDoS attacks and carries traffic of
> multiple priority levels, then stay away from Trio.
>
> ASR9k has stupidly long upgrade times but at least it's NPU and Fabric
> architecture is basically alright.
> The LACP QOS is a moot point, there's no right and wrong way of doing the
> split.

I think you're cherry picking examples to highlight architecture
differences. I have some trust in market, if it would be this black
and white, Juniper would be dead.

Just to offer one counter-point, imagine you have 10GE egress port in
ASR9k, either VLANs or satellite subdivided. Now send 20Gbps of
traffic to 1 VLAN or 1 satellite port.
10Gbps of traffic going to that 10Gbps port gets dropped by ingress
NPU, without any knowledge of egress satellite port or egress VLAN. So
all VLANs, all satellite ports are dead, because one customer got
DDoS. You can't fix this by setting 1Gbps policer on egress
VLAN/satellite, as egress NPU never gets the traffic. And ingress NPU
has no awareness of egress VLAN/satellite, so it can't police it,
unless you figure out IP addresses (and they are static, and you only
have one  ingress port).

I'm not saying ASR9k is definitely worse, I'm saying like Miercom
tests, you can make any vendor look bad/good against any other vendor,
by knowing both platforms and cherry-picking pathological examples.

For me personally, MX edge has lot less customer impacting issues than
XR edge, but I fully expect situation to be different with different
set of requirements and features. I suspect XR IPC/state
duplication/state share is fundamentally fragile.

I could also argue ASR9k has no functional control-plane protection,
because every BGP neighbour in NPU share same policer, so if one of
them has L2 loop and offers too much BGP, all of them are dead. Or
ICMP6 or ARP or whatever. And you cannot manually intervene, as LPTS
packets are not subject to interface MQC, you just wait for baddies to
stop. Cisco is aware and are working to fix this, but when and how
will fix surface, no one knows.
Out-of-the-box LPTS is superior protection to MX, but MX can be
configured better, but I suspect there single digit networks who are
technically able. JNPR should ship with sensible defaults.

I could also give similarly BGP examples, which would make it appear
like IOS-XR has bad BGP compared to JunOS. But I could of course
choose examples to show how IOS-XR has better BGP than JunOS.

Different network, different set of features and requirements,
different box will appear better.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[adamv0025]

> Rick Martin
> Sent: Tuesday, July 25, 2017 11:03 PM
> 
> We have solicited quote from our local, and normally very trusted, Cisco
> partner for Internet Edge Router with 10X10G towards service provider and
> 2X40G towards our network. Current deployment will be two 2X10G LAG
> bundles to ISP's (40G), this will be replacing current MX104.
> 
> I did not specify what Cisco platform, I expected them to come back with
ASR
> 1006 or better. I did specifically state that I did not personally believe
that
> Nexus was the right platform - but they came back with a very low ball bid
on
> Nexus 7707. They knew they were up against Juniper MX platform...
> 
> I cannot find much on this particular router - um, switch online so I
would like
> to seek the knowledge of this group to see what your thoughts are on this
> platform for Internet edge router.
> 
> We only accept default from service provider (BGP) so route table size is
not
> currently an issue. We have the normal Internet edge stuff going on but
> nothing too heavy, no tunneling or other highly complex configuration.
> 
> We are virtually all Cisco in our statewide network and have a fair amount
of
> N9K serving us in the data center as well as customer Ethernet
aggregation.
> The only area Cisco has consistently  lost on our network for the past 10+
> years has been at our Internet edge locations (3 currently) so I believe
they
> are doing everything they can to win...
> 
Since you've been using what possibly is the worst carrier-grade BGP
implementation out there for past 10+ years and you're fine with it (junos,
if someone doesn't know what I mean), heck you'd be fine with anything I
guess. You haven't mentioned any edge filtering or traffic sampling so I
assume you're not doing those either, in which case, yeah a decent switch
that can do some BGP seems like the right solution, in other words why
spending money on functionality you don't need or care about, right? 

If you can handle the poor BGP implementation -which will eventually be ok
in 18 or 19 as things are in the pipeline, Juniper MX is good but only for
ISP market (single priority traffic). 
However Juniper MX is certainly not good fit for CSP market (mixing traffic
of different priorities in your backbone), well to be fair since the fix
from couple months ago you'll be able to configure it do the right thing at
least on wan input to trio, unfortunately from fabric direction it'll
remain, well, not optimal due to unwillingness to fix.  
So if the backbone is subject to DDoS attacks and carries traffic of
multiple priority levels, then stay away from Trio. 

ASR9k has stupidly long upgrade times but at least it's NPU and Fabric
architecture is basically alright.
The LACP QOS is a moot point, there's no right and wrong way of doing the
split. 


adam


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Nick Cutting]

Coming from the MSP (managed service provider)  world where I am - EIGRP is 
great - I can summarize anywhere - and our cheap clients will only ever buy IP 
base licensed 3xxx switches.  

Even though they are on the 42nd floor of a 10 million dollar office with a 
giant  leather rhinoceros...

 So my choices are, if I want to summarize, multi area OSPF limited to 200 
routes or EIGRP which is simple and clean.



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick 
Hilliard
Sent: Friday, July 28, 2017 5:39 AM
To: Gert Doering <g...@greenie.muc.de>
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 7707 as Internet Edge Router?

Gert Doering wrote:
> And then, what features it gets - the first list on cisco.com was 
> amazingly thin on details, but one of the interesting bits was "no 
> support for EIGRP", which I find highly astonishing - you have a 
> vendor that has a nice customer-lock-in feature, purely control-plane 
> (so, no need to do hardware-specific coding), and they... forget to enable it?

But no-one in the SP world uses EIGRP anyway so this is a moot point, right?

Right??

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Brian Turnbow]

Hi,



> 
> "Anything detailed" you have on the NCS5* would be welcome - the
material
> on www.cisco.com is a bit sparse.
> 

Check out the cisco live session for some good info.
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=94040
=popup


> Since we're considering to either go for QFX5100 or NCS5* for bandwidth
> expansion in our "core" (= no customer connections, no external
> connections, all 10G links, not much demand for QoS due to DWDM underlay
> where we can just add more bandwidth if needed), understanding how Cisco
> positions the
> NCS5001 series and whether this is a one-off thing that will be
end-of-life
> next year ("remember the ME3600?") or something which is going to
receive
> proper love and caring is one of the most important questions here...
> 

>From what we've been told it will continue to evolve and receive new
features 
There is also going to be a smaller chassis based system coming out soon.

> And then, what features it gets - the first list on cisco.com was
amazingly thin
> on details, but one of the interesting bits was "no support for EIGRP",
which I
> find highly astonishing - you have a vendor that has a nice
customer-lock-in
> feature, purely control-plane (so, no need to do hardware-specific
coding),
> and they... forget to enable it?

It is available  but needs to installed as an add on package..
http://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/system-setup/60x/b-ncs5
500-system-setup-guide-60x/b-system-setup-ncs5k_chapter_0110.html

Best Regards

Brian
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Gert Doering]

Hi,

On Fri, Jul 28, 2017 at 10:39:02AM +0100, Nick Hilliard wrote:
> Gert Doering wrote:
> > And then, what features it gets - the first list on cisco.com was 
> > amazingly thin on details, but one of the interesting bits was "no 
> > support for EIGRP", which I find highly astonishing - you have a vendor
> > that has a nice customer-lock-in feature, purely control-plane (so, 
> > no need to do hardware-specific coding), and they... forget to enable it?
> 
> But no-one in the SP world uses EIGRP anyway so this is a moot point, right?
> 
> Right??

That's one of the problems with Cisco as of the last few years, that they
do not understand that there is no hard distinction between "Enterprise",
"SP" and "Datacenter" anymore.

So having dedicated product lines that always miss something crucial because
"no, that feature is only for the other market" really stinks.

(Now, why wouldn't an enterprise customer use an NCS5001?  "Can we please
give Cisco the money, instead of buying a QFX5100 for 20% less money, 
and then having to change our IGP"?)

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Nick Hilliard]

Gert Doering wrote:
> And then, what features it gets - the first list on cisco.com was 
> amazingly thin on details, but one of the interesting bits was "no 
> support for EIGRP", which I find highly astonishing - you have a vendor
> that has a nice customer-lock-in feature, purely control-plane (so, 
> no need to do hardware-specific coding), and they... forget to enable it?

But no-one in the SP world uses EIGRP anyway so this is a moot point, right?

Right??

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Gert Doering]

Hi,

On Thu, Jul 27, 2017 at 09:27:36PM -0400, Phil Bedard wrote:
> Do you require something with redundant RPs?  The fixed NCS5001/NCS5501 would 
> probably fit what you need well if you don???t.  The chassis based NCS 
> systems are a bit overkill for your needs.  The NCS5XXX were mainly pitched 
> to larger providers originally with their own account teams so I don???t 
> think much info on them has trickled down to VARs yet.  If you have any 
> questions let me know.  

"Anything detailed" you have on the NCS5* would be welcome - the material
on www.cisco.com is a bit sparse.

Since we're considering to either go for QFX5100 or NCS5* for bandwidth
expansion in our "core" (= no customer connections, no external connections,
all 10G links, not much demand for QoS due to DWDM underlay where we can
just add more bandwidth if needed), understanding how Cisco positions the
NCS5001 series and whether this is a one-off thing that will be end-of-life
next year ("remember the ME3600?") or something which is going to receive
proper love and caring is one of the most important questions here...

And then, what features it gets - the first list on cisco.com was 
amazingly thin on details, but one of the interesting bits was "no 
support for EIGRP", which I find highly astonishing - you have a vendor
that has a nice customer-lock-in feature, purely control-plane (so, 
no need to do hardware-specific coding), and they... forget to enable it?

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Phil Bedard]

Do you require something with redundant RPs?  The fixed NCS5001/NCS5501 would 
probably fit what you need well if you don’t.  The chassis based NCS systems 
are a bit overkill for your needs.  The NCS5XXX were mainly pitched to larger 
providers originally with their own account teams so I don’t think much info on 
them has trickled down to VARs yet.  If you have any questions let me know.  

Thanks, 
Phil (now @cisco)

-Original Message-
From: cisco-nsp <cisco-nsp-boun...@puck.nether.net> on behalf of Rick Martin 
<rick.mar...@arkansas.gov>
Date: Tuesday, July 25, 2017 at 18:03
To: "cisco-nsp@puck.nether.net" <cisco-nsp@puck.nether.net>
Subject: [c-nsp] Nexus 7707 as Internet Edge Router?

We have solicited quote from our local, and normally very trusted, Cisco 
partner for Internet Edge Router with 10X10G towards service provider and 2X40G 
towards our network. Current deployment will be two 2X10G LAG bundles to ISP's 
(40G), this will be replacing current MX104.

I did not specify what Cisco platform, I expected them to come back with 
ASR 1006 or better. I did specifically state that I did not personally believe 
that Nexus was the right platform - but they came back with a very low ball bid 
on Nexus 7707. They knew they were up against Juniper MX platform...

I cannot find much on this particular router - um, switch online so I would 
like to seek the knowledge of this group to see what your thoughts are on this 
platform for Internet edge router.

We only accept default from service provider (BGP) so route table size is 
not currently an issue. We have the normal Internet edge stuff going on but 
nothing too heavy, no tunneling or other highly complex configuration.

We are virtually all Cisco in our statewide network and have a fair amount 
of N9K serving us in the data center as well as customer Ethernet aggregation. 
The only area Cisco has consistently  lost on our network for the past 10+ 
years has been at our Internet edge locations (3 currently) so I believe they 
are doing everything they can to win...

I value any thoughts from any of you. If you have knowledge that this is or 
is not a suitable platform for this area on our network I would love to learn 
about it.

Thanks in advance
rick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 27/Jul/17 00:42, James Jun wrote:

> As I understand it, on MX, if you configure a say a 2 Gbps policer on a LAG 
> (ae)
> interface, each member interface will receive pro-rata share of CIR to meet 
> aggregate rate of 2 Gbps across the whole LAG.
>
> On XR platform, by default, application of 2 Gbps policer on Bundle-Ether will
> replicate the same 2 Gbps on every member 10G interface -- this may or may not
> give you the desired effect you'd expect.
>
> Neverthless, this is a moot point now.  As of IOXR 6.0.1, Aggregate Bundled 
> QoS
> is now supported:
>
>   "Aggregated Bundle QoS feature allows the shape, bandwidth, police rates 
> and 
>   burst values to be distributed between the active members of a bundle, where
>   a QoS policy-map is applied."
>  
>   P/0/RSP0/CPU0:ASR9000(config)# hw-module all qos-mode 
> bundle-qos-aggregate-mode

Very interesting.

As we don't use the ASR9000 for edge routing, I didn't know the feature
had made it to this platform.

I know it has just arrived to IOS XE, which means it has been available
on the ASR1000 platform for a little while now. We enabled it over
there, but found a bug where the router won't export flows when the
feature is enabled. We just tested engineering code yesterday that
confirms a fix, so that is good.

Has anyone actually tested this on the ASR9000 to know if it works as on
the MX? Online documentation is not very clear about how it's setup,
operation options, e.t.c.


> My biggest problem of ASR9K on revenue boxes is that it takes a rocket science
> to SW upgrade the platform if you care about downtime duration.  Single homed
> customers are very sensitive to multi-hour maintenance window, and then there
> is also that FPD upgrade that you have to run on every line card and reload 
> each.
>
> When a TAC confirmed bug behavior is noted and software upgrade is advised, 
> it's
> a hassle to get change window approved due to the complexities of SW jump.

Yep, big issue.

Also, for some reason, every time we've upgraded code on our CRS boxes,
we end up with some kind of RP, FP or PLIM issue and/or failure. In some
cases, we've had to RMA units, and in others, have had to re-seat line
cards, e.t.c. We are now on IOS XR 6.1.3 for the CRS, which is going well.

To be fair, we recently also saw RE failures when upgrading our MX
platforms to Junos 16.2. But a simple Junos recovery on the failed RE
was the fix, and not a hardware replacement.


> On the flip side, on MX platforms, I'm not a big fan of Juniper BGP 
> implementation
> myself IMO.
>
> Performance seems to be improving noticeably as of recent SW versions, and BGP
> is all around snappy on the new 64-bit MX RE, but update-group behavior 
> handling
> seems awful.
>
> Why is it that when you de-configure the last remaining peer on a customer 
> facing
> peer-group, it resets all 175 BGP sessions on the entire chassis when you 
> commit?
> May be I'm doing something wrong, but best practice seems to be to configure 
> a fake
> BGP peer to force rpd to operate differently.
>
>   
> https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-sessions.html
>
>"When, because of a configuration change, BGP transitions from needing two 
> copies
>of a route to not needing two copies of a route (or the reverse), all 
> sessions 
>over which VPN routes are exchanged go down and then come back up."
>
>   "The way to prevent these unnecessary session flaps is to configure an 
> extra RR 
>client or EBGP session as a passive session with a neighbor address that 
> does 
>not exist. This example focuses on the EBGP case, but the same workaround 
> works  
>for the RR case."

Does this only affect VPN routes, or even Global? I've not seen this
issue on our side. But then again, we don't run Internet in a VRF, if
this is your scenario.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[James Jun]

On Wed, Jul 26, 2017 at 04:39:10PM -0500, Aaron Gould wrote:
> Please let me know what y'all mean by this comment regarding *policing on
> LAG's*.

As I understand it, on MX, if you configure a say a 2 Gbps policer on a LAG (ae)
interface, each member interface will receive pro-rata share of CIR to meet 
aggregate rate of 2 Gbps across the whole LAG.

On XR platform, by default, application of 2 Gbps policer on Bundle-Ether will
replicate the same 2 Gbps on every member 10G interface -- this may or may not
give you the desired effect you'd expect.

Neverthless, this is a moot point now.  As of IOXR 6.0.1, Aggregate Bundled QoS
is now supported:

  "Aggregated Bundle QoS feature allows the shape, bandwidth, police rates and 
  burst values to be distributed between the active members of a bundle, where
  a QoS policy-map is applied."
 
  P/0/RSP0/CPU0:ASR9000(config)# hw-module all qos-mode 
bundle-qos-aggregate-mode


> 
> "We have refused to use the ASR9000 as an edge router because of how Cisco
> implement policing on LAG's, in general. However, we use them quite
> extensively as border and peering routers."
>

My biggest problem of ASR9K on revenue boxes is that it takes a rocket science
to SW upgrade the platform if you care about downtime duration.  Single homed
customers are very sensitive to multi-hour maintenance window, and then there
is also that FPD upgrade that you have to run on every line card and reload 
each.

When a TAC confirmed bug behavior is noted and software upgrade is advised, it's
a hassle to get change window approved due to the complexities of SW jump.


On the flip side, on MX platforms, I'm not a big fan of Juniper BGP 
implementation
myself IMO.

Performance seems to be improving noticeably as of recent SW versions, and BGP
is all around snappy on the new 64-bit MX RE, but update-group behavior handling
seems awful.

Why is it that when you de-configure the last remaining peer on a customer 
facing
peer-group, it resets all 175 BGP sessions on the entire chassis when you 
commit?
May be I'm doing something wrong, but best practice seems to be to configure a 
fake
BGP peer to force rpd to operate differently.

  
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-sessions.html

   "When, because of a configuration change, BGP transitions from needing two 
copies
   of a route to not needing two copies of a route (or the reverse), all 
sessions 
   over which VPN routes are exchanged go down and then come back up."

  "The way to prevent these unnecessary session flaps is to configure an extra 
RR 
   client or EBGP session as a passive session with a neighbor address that 
does 
   not exist. This example focuses on the EBGP case, but the same workaround 
works  
   for the RR case."


I prefer ASR9K for multi-homed customers that can withstand long outages, but 
for
single-tailed circuits or when I need a "do everything router" in a new market 
in
as compact as possible form, MX480 is a nice fit for us.  ASR9K has overall more
power hungry requirements IMO, and MX has much better line card product 
offerings
on both low and high ends (MPC3E and MPC7 are great).

James
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Aaron Gould]

Please let me know what y'all mean by this comment regarding *policing on
LAG's*.

I'm thinking about doing this and would like to know what you mean by that.

-Aaron Gould


"We have refused to use the ASR9000 as an edge router because of how Cisco
implement policing on LAG's, in general. However, we use them quite
extensively as border and peering routers."



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Nick Hilliard]

Mark Tinka wrote:
> We have refused to use the ASR9000 as an edge router because of how
> Cisco implement policing on LAG's, in general. However, we use them
> quite extensively as border and peering routers.

seconded.  I don't like using them for single-homed customer edge
because the software upgrade and patch process is a complete pain and
will cause prolonged downtime unless you have dual rsps, in which case
you'll only end up with prolonged downtime if you're doing major
upgrades or have a requirement which can only be solved by turbobooting.

They're great for dual-homed customer edge and inter-as duty though.

Nick

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Nexus 7707 as Internet Edge Router?

[Mark Tinka]

On 26/Jul/17 00:02, Rick Martin wrote:

> We have solicited quote from our local, and normally very trusted, Cisco 
> partner for Internet Edge Router with 10X10G towards service provider and 
> 2X40G towards our network. Current deployment will be two 2X10G LAG bundles 
> to ISP's (40G), this will be replacing current MX104.
>
> I did not specify what Cisco platform, I expected them to come back with ASR 
> 1006 or better. I did specifically state that I did not personally believe 
> that Nexus was the right platform - but they came back with a very low ball 
> bid on Nexus 7707. They knew they were up against Juniper MX platform...

I think the most appropriate unit to compare against the MX is the ASR9000.

MX vs. Nexus 7700 is apples and steak.

In general, the ASR9000 will give you as much bang for your buck as the
MX will (i.e., MX240/480/960/2010/2020). Don't waste your time looking
at the MX80 or MX104.

We have refused to use the ASR9000 as an edge router because of how
Cisco implement policing on LAG's, in general. However, we use them
quite extensively as border and peering routers.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Nexus 7707 as Internet Edge Router?

[Rick Martin]

We have solicited quote from our local, and normally very trusted, Cisco 
partner for Internet Edge Router with 10X10G towards service provider and 2X40G 
towards our network. Current deployment will be two 2X10G LAG bundles to ISP's 
(40G), this will be replacing current MX104.

I did not specify what Cisco platform, I expected them to come back with ASR 
1006 or better. I did specifically state that I did not personally believe that 
Nexus was the right platform - but they came back with a very low ball bid on 
Nexus 7707. They knew they were up against Juniper MX platform...

I cannot find much on this particular router - um, switch online so I would 
like to seek the knowledge of this group to see what your thoughts are on this 
platform for Internet edge router.

We only accept default from service provider (BGP) so route table size is not 
currently an issue. We have the normal Internet edge stuff going on but nothing 
too heavy, no tunneling or other highly complex configuration.

We are virtually all Cisco in our statewide network and have a fair amount of 
N9K serving us in the data center as well as customer Ethernet aggregation. The 
only area Cisco has consistently  lost on our network for the past 10+ years 
has been at our Internet edge locations (3 currently) so I believe they are 
doing everything they can to win...

I value any thoughts from any of you. If you have knowledge that this is or is 
not a suitable platform for this area on our network I would love to learn 
about it.

Thanks in advance
rick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/