Mailing List Archive

On 19/Jun/20 15:24, steve ulrich wrote:

> never underestimate the desire of product managers and engineering teams to have their own petri dishes to swim around in.

Probably what got us (and keeps getting us) into this mess to begin with.

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/

On Fri, Jun 19, 2020 at 9:05 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 19/Jun/20 14:50, Tim Durack wrote:
>
> > If y'all can deal with the BU, the Cat9k family is looking
> > half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS)
> > etc.
> > UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA
> > license now covers software support...
> >
> > Of course you do have to deal with a BU that lives in a parallel
> > universe (SDA, LISP, NEAT etc) - but the hardware is the right
> > price-perf, and IOS-XE is tolerable.
> >
> > No large FIB today, but Cisco appears to be headed towards "Silicon
> > One" for all of their platforms: RTC ASIC strapped over some HBM. The
> > strategy is interesting: sell it as a chip, sell it whitebox, sell it
> > fully packaged.
> >
> > YMMV
>
> I'd like to hear what Gert thinks, though. I'm sure he has a special
> place for the word "Catalyst" :-).
>
> Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed
> for the guillotine, in which case investing any further into an IOS XE
> platform could be dicey at best, egg-face at worst.
>
> I could be wrong...
>
> Mark.
>
>
It could be worse: Nexus ;-(

There is another version of the future:

1. SP "Silicon One" IOS-XR
2. Enterprise "Silicon One" IOS-XE

Same hardware, different software, features, licensing model etc.

Silicon One looks like an interesting strategy: single ASIC for fixed,
modular, fabric. Replace multiple internal and external ASIC family,
compete with merchant, whitebox, MSDC etc.

The Cisco 8000/8200 is not branded as NCS, which is BCM. I asked the
NCS5/55k guys why they didn't use UADP. No good answer, although I suspect
some big customer(s) were demanding BCM for their own programming needs.
Maybe there were some memory bandwidth issues with UADP, which is what Q100
HBM is the answer for.

--
Tim:>
_______________________________________________
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/

On 19/Jun/20 16:09, Tim Durack wrote:

>
> It could be worse: Nexus ;-(
>
> There is another version of the future:
>
> 1. SP "Silicon One" IOS-XR
> 2. Enterprise "Silicon One" IOS-XE
>
> Same hardware, different software, features, licensing model etc.

All this forking weakens a vendor's position in some respects, because
when BU's are presenting one company as 6,000 ones, it's difficult for
buying consistency.

Options are great, but when options have options, it starts to get ugly,
quick.

Ah well...


>
> Silicon One looks like an interesting strategy: single ASIC for fixed,
> modular, fabric. Replace multiple internal and external ASIC family,
> compete with merchant, whitebox, MSDC etc.

That is the hope. We've been to the cinema for this one before, though.
Quite a few times. So I'm not holding my breath.


>
> The Cisco 8000/8200 is not branded as NCS, which is BCM.

Not all of it - remember the big pink elephant in the room, the NCS
6000? That is/was nPower. Again, sending customers in all sorts of
directions with that box, where now ASR9000 and the new 8000 seem to be
the go-to box. Someone can't make up their mind over there.


> I asked the NCS5/55k guys why they didn't use UADP. No good answer,
> although I suspect some big customer(s) were demanding BCM for their
> own programming needs. Maybe there were some memory bandwidth issues
> with UADP, which is what Q100 HBM is the answer for.

When you're building boxes for one or two customers, things like this
tend to happen.

But like I've been saying for some time, the big brands competing with
the small brands over merchant silicon doesn't make sense. If you want
merchant silicon to reduce cost, you're better off playing with the new
brands that will charge less and be more flexible. While I do like IOS
XR and Junos, paying a premium for them for a chip that will struggle
the same way across all vendor implementations just doesn't track.

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/

On Fri, Jun 19, 2020 at 10:34 AM Mark Tinka <mark.tinka@seacom.mu> wrote:

>
>
> On 19/Jun/20 16:09, Tim Durack wrote:
>
> >
> > It could be worse: Nexus ;-(
> >
> > There is another version of the future:
> >
> > 1. SP "Silicon One" IOS-XR
> > 2. Enterprise "Silicon One" IOS-XE
> >
> > Same hardware, different software, features, licensing model etc.
>
> All this forking weakens a vendor's position in some respects, because
> when BU's are presenting one company as 6,000 ones, it's difficult for
> buying consistency.
>
> Options are great, but when options have options, it starts to get ugly,
> quick.
>
> Ah well...
>
>
> >
> > Silicon One looks like an interesting strategy: single ASIC for fixed,
> > modular, fabric. Replace multiple internal and external ASIC family,
> > compete with merchant, whitebox, MSDC etc.
>
> That is the hope. We've been to the cinema for this one before, though.
> Quite a few times. So I'm not holding my breath.
>
>
> >
> > The Cisco 8000/8200 is not branded as NCS, which is BCM.
>
> Not all of it - remember the big pink elephant in the room, the NCS
> 6000? That is/was nPower. Again, sending customers in all sorts of
> directions with that box, where now ASR9000 and the new 8000 seem to be
> the go-to box. Someone can't make up their mind over there.
>
>
> > I asked the NCS5/55k guys why they didn't use UADP. No good answer,
> > although I suspect some big customer(s) were demanding BCM for their
> > own programming needs. Maybe there were some memory bandwidth issues
> > with UADP, which is what Q100 HBM is the answer for.
>
> When you're building boxes for one or two customers, things like this
> tend to happen.
>
> But like I've been saying for some time, the big brands competing with
> the small brands over merchant silicon doesn't make sense. If you want
> merchant silicon to reduce cost, you're better off playing with the new
> brands that will charge less and be more flexible. While I do like IOS
> XR and Junos, paying a premium for them for a chip that will struggle
> the same way across all vendor implementations just doesn't track.
>
> Mark.
>
>
Yes, for sure NCS6K was a completely different beast, much as NCS1K, NCS2K.
Not sure why the NCS naming was adopted vs. ASR, and then dropped for
8000/8200. Probably lots of battles within the Cisco conglomerate.

Not defending, just observing. Either way, networks got to get built,
debugged, maintained, debugged, upgraded, debugged. All while improving
performance, managing CAPEX, reducing OPEX.

--
Tim:>
_______________________________________________
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/

Hi,

On Fri, Jun 19, 2020 at 03:05:50PM +0200, Mark Tinka wrote:
> On 19/Jun/20 14:50, Tim Durack wrote:
>
> > If y'all can deal with the BU, the Cat9k family is looking
> > half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS)
> > etc.
> > UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA
> > license now covers software support...
[..]
>
> I'd like to hear what Gert thinks, though. I'm sure he has a special
> place for the word "Catalyst" :-).

There's a special place in hell for people re-using the "Catalyst" brand
name and then putting yearly renewable licenses on it. Or IOS XE.

I'm not actually sure *which* BU is doing "Catalyst" these days, but
we're so annoyed about Cisco these days that I haven't really looked at
all these new and shiny products from all these new and shiny BUs with
all these new and shiny operating systems in quite a while.

I've been told Merak is very nice... if all you're interested in is
"sell to Enterprise customers and make lots of cash".

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

>
> One of the advantages cited for SRv6 over MPLS is that the packet contains
>> a record of where it has been.
>>
>
Not really ... packets are not tourists in a bus.

First there are real studies proving that most large production networks
for the goal of good TE only need to place 1, 2 or 3 hops to traverse
through. Rest is the shortest path between those hops.

Then even if you place those node SIDs you have no control which interfaces
are chosen as outbound. There is often more then one IGP ECMP path in
between. You would need to insert adj. SIDs which does require pretty fine
level of controller's capabilities to start with.

I just hope that no one sane proposes that now all packets should get
encapsulated in a new IPv6 header while entering a transit ISP network and
carry long list of hop by hop adjacencies it is to travel by. Besides even
if it would it would be valid only within given ASN and had no visibility
outside.

Thx,
R.
_______________________________________________
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/

> I've been told Merak is very nice... if all you're interested in is "sell
to
> Enterprise customers and make lots of cash".

We asked the sales-person weather that meraki devices can handle ipv6
(as customer traffic) and for the cloudy management access (in an ipv4 free
world)
But they did not know this, told us they will ask, but we did not get any
answer yet ...

Juergen.


_______________________________________________
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/

On 19/Jun/20 17:26, Gert Doering wrote:

> There's a special place in hell for people re-using the "Catalyst" brand
> name and then putting yearly renewable licenses on it. Or IOS XE.
>
> I'm not actually sure *which* BU is doing "Catalyst" these days, but
> we're so annoyed about Cisco these days that I haven't really looked at
> all these new and shiny products from all these new and shiny BUs with
> all these new and shiny operating systems in quite a while.

We bought the C6880-X for our core switch back in 2014. It's still
humming, running plain old IOS.

The upgrade path is Arista for this. I'm not sure what switching is
doing over at Cisco, these days.

Mark.

On 19/Jun/20 20:19, ljwobker@gmail.com wrote:

> >From the vendor standpoint, the market has never been able to agree on what makes a "core" application. If I have five "big" customers, I guarantee you that:
> - one of them will need really big ACLs, even though it's a "core" box to them.
> - one of them will want to terminate high speed L2VPN circuits, even though it's a "core" box.
> - one of them will need to do hierarchical shaping and granular QoS, even though it's a "core" box.
> - one of them will want to have lots of headroom in the FIB (2-3x today's global tables) ... even though it's a "core" box.
> - one of them will want to buy something that they can "migrate out to the edge" one day...
>
> Say it with me: "even though it's a "core" box"
>
> This puts me (as the vendor) in a super weird spot... I can try to create a card/PID that addresses *some subset* of this, charge a lot less for it, and hopefully sell a bunch. Or I'm left creating something that I can sell into that broader market, but then that thing has to "do all the stuff" and I'm going to charge for it appropriately.
>
> The physics dictate that "Really High Speed Silicon" does not exist which can solve all of those things. I can solve SOME with a given chip design, but not all.

Well, if I'm honest, it's the vendors who created "tiers" back in the
day, so they can sell boxes in the way they did, and still do.

Ever since Ethernet became the gold standard, what a core, edge,
peering, branch, e.t.c., box is has been meaningless. It was meaningless
before Ethernet (I mean, to some, the Cisco 3640 was a core router,
while to others it was a peering router), but it's more meaningless in
the days of Ethernet.

The reason the ASR9000 sells better than the CRS or NCS 6000, is the
same reason the MX sells better than the PTX or T-series. It's all about
Ethernet.

So now, vendors who are able to build boxes that can license Ethernet
ports will be the winners, because I don't have to pay the upfront capex
for the entire card, and can just grow as I need. The Transport boys
have been doing it for so long, why can't the IP boys do the same? The
good news is, they have started.

Secondly, and perhaps more importantly, if vendors can build around a
single ASIC across a multitude of platforms, then there is hope. If you
have to build a different ASIC for every tier of a network, you end up
with the issues you raise, above. The reason the MX does so well is
because in addition to being an Ethernet platform, it uses the same ASIC
(since Trio, to be clear), which gives Juniper and its customers plenty
of flexibility across a variety of applications.

There is a lesson, here, to be learned.

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/

Hi,

On Sat, Jun 20, 2020 at 07:42:31PM +0200, Mark Tinka wrote:
> On 19/Jun/20 17:26, Gert Doering wrote:
>
> We bought the C6880-X for our core switch back in 2014. It's still
> humming, running plain old IOS.

The 6880/6840 products were promising at that time, but the pricing made
it uninteresting. So we kept our 6506Es for a time...

> The upgrade path is Arista for this. I'm not sure what switching is
> doing over at Cisco, these days.

... and then went to Arista 7050SX2/SX3 for the "edge things" (small
routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN).

Nice stuff like the JSON RPC API, which is nice to work with and
amazingly *fast* (compared to JunOS commit times...). And, most important,
a good TAC and a company interested in listening to their customers.


I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because
we have MPLS PEs that basically "live behind" the 7050SX, and now need
to have vlans *through* them, to reach a MPLS P router).

I do understand that the BRCM Trident is fairly limited wrt MPLS handling,
so Arista decided "better no MPLS than something which is not enough
for people" - unfortunately for us, because we only want "LDP and
single-label swap/pop", but I can accept the technical arguments to
some extent.


(As a side note, changing our network from EIGRP to OSPF for IPv4 did
not come for free, so I would have much preferred to stay in my self-
chosen vendor lock-in with Cisco. But Cisco has gone insane these days,
and new boxes like the NCS5500 come *without* EIGRP support. So they
really do not want us customers locked in...)

gert

--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On 20/Jun/20 19:58, Gert Doering wrote:

> The 6880/6840 products were promising at that time, but the pricing made
> it uninteresting. So we kept our 6506Es for a time...

We haven't done anything with them since we bought and deployed them in
2014.

They are serving their purpose quite well, and when it's time for them
to go, the Arista kicks.


> ... and then went to Arista 7050SX2/SX3 for the "edge things" (small
> routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN).
>
> Nice stuff like the JSON RPC API, which is nice to work with and
> amazingly *fast* (compared to JunOS commit times...). And, most important,
> a good TAC and a company interested in listening to their customers.

We run the 7508E for core switching in large PoP's, and the 7280R for
data centre access aggregation in all PoP's (this replaced our Juniper
EX4550 and EX4600 platforms).

We are very happy - but these are pure Layer 2 switching use-cases.


> I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because
> we have MPLS PEs that basically "live behind" the 7050SX, and now need
> to have vlans *through* them, to reach a MPLS P router).
>
> I do understand that the BRCM Trident is fairly limited wrt MPLS handling,
> so Arista decided "better no MPLS than something which is not enough
> for people" - unfortunately for us, because we only want "LDP and
> single-label swap/pop", but I can accept the technical arguments to
> some extent.

You know how I feel about Broadcom chips :-).

If Arista aren't that comfortable about them, you'd do well to take them
at their word, hehe.


> (As a side note, changing our network from EIGRP to OSPF for IPv4 did
> not come for free, so I would have much preferred to stay in my self-
> chosen vendor lock-in with Cisco. But Cisco has gone insane these days,
> and new boxes like the NCS5500 come *without* EIGRP support. So they
> really do not want us customers locked in...)

Looking at things, it's probably cheaper for you to spend money on
getting an open IGP than spending money dealing with the indecision
Cisco sometimes goes through.

Mark.

On 20/Jun/20 00:41, Anoop Ghanwani wrote:

> One of the advantages cited for SRv6 over MPLS is that the packet
> contains a record of where it has been.

I can't see how advantageous that is, or how possible it would be to
implement, especially for inter-domain traffic.

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/

On 20/Jun/20 08:49, Reuben Farrelly via cisco-nsp wrote:

> Meraki doesn't currently support IPv6 in any way, shape or form.
>
> Some other things you'll find missing in Meraki products:
>
> - Zone based firewalls - Meraki MX doesn't do zones
> - Routing protocols for all but the most absolutely basic use cases
> - Client side VPN.  More specifically it does PPTP but not so many
> people are sold on the security and NAT problems that come with PPTP
> - Modern crypto - IPSec Auth is limited to MD5/SHA1 for example.
> - Any sort of xDSL, they only have Ethernet models.  If you need xDSL
> you'll need a bridge modem for the carriage circuit
> - Extremely limited NAT capabilities, no ALG, no ability to disable
> NAT between eg WAN and LAN ports which means it's almost useless for
> an MPLS circuit.  The lack of control over NAT also makes it
> impossible to run a publically addressable DMZ
> - SSL decryption which makes content filtering a bit less useful
> - Cellular is limited to not all 4G bands (notably does not support
> 700MHz here in Australia) and Cell backup is not supported in an HA setup
>
> And dare I say it, Segment Routing and MPLS definitely are not part of
> the featureset ;)
>
> There are many good things about Meraki (eg dashboard, autovpn,
> updates, ease of provisioning), but in my recent experience with MX/MS
> products you have to spend as much if not more time working out what
> Meraki products *can not* do as what they *can* do - and know the
> product limitations before you design and deploy not during (don't
> assume anything).
>
> Personally I would only recommend Meraki for a small business with
> very basic and well defined requirements.  Even then once you factor
> in the cost of licensing + hardware and compare it to a low end Cisco
> Enterprise product that does not have said limitations, you may find
> the cost is about the same over 3 or more years.

Sounds like pfSense might be a better option :-).

If I can summarize it in one sentence, is Meraki meant to be Cisco's
SD-WAN job?

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/

On 21/Jun/20 00:54, Sabri Berisha wrote:

> That will be very advantageous in a datacenter environment, or any other
> environment dealing with a lot of ECMP paths.
>
> I can't tell you how often during my eBay time I've been troubleshooting
> end-to-end packetloss between hosts in two datacenters where there were at least
> 10 or more layers of up to 16 way ECMP between them. Having a record of which
> path is being taken by a packet is very helpful to determine the one with a crappy
> transceiver.
>
> That work is already underway, albeit not specifically for MPLS. For example,
> I've worked with an experimental version of In-Band Network Telemetry (INT)
> as described in this draft: https://tools.ietf.org/html/draft-kumar-ippm-ifa-02
>
> I even demonstrated a very basic implementatoin during SuperCompute 19 in Denver
> last year. Most people who were interested in the demo were academics however,
> probably because it wasn't a real networking event.
>
> Note that there are several caveats that come with this draft and previous
> versions, and that it is still very much work in progress. But the potential is
> huge, at least in the DC.

Alright, we'll wait and see, then.



> That's a different story, but not entirely impossible. A probe packet can
> be sent across AS borders, and as long as the two NOCs are cooperating, the
> entire path can be reconstructed.

Yes, for once-off troubleshooting, I suppose that would work.

My concern is if it's for normal day-to-day operations. But who knows,
maybe someone will propose that too :-).

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/

_______________________________________________
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/