I find this highly unlikely.
I think you have a burden of proof that what you claim is actually
what is happening.
Do you have packet capture to show absence of stated traffic? And
existence of the expected packet in its stead?
On Wed, 19 Jun 2024 at 08:45, Hank Nussbacher via cisco-nsp
wrote:
I don't think there is enough information here to understand the problem.
So you have
RouterA - RouterB
RouterA is 192.0.2.1/24
RouterB is 128.139.197.146
RouterB advertises bunch of /32s to routerA, with next-hop 192.0.2.1?
This seems nonsensical to me, where is routerA supposed to send the
from RT
defined in extcommunity 100.
On Sun, 9 Jun 2024 at 07:57, Arne Larsen wrote:
>
> Sort off, I need the default route from the vrf with the import target
> 64515:112, that's our leak for the shared vrf to the internet
>
>
> /Arne
>
> On 08/06/2024 17.31, Saku Ytti
On Sat, 8 Jun 2024 at 18:26, Arne Larsen via cisco-nsp
wrote:
> Yes, it'd with route-target I'm trying to get it to work, and what I'm
> trying to get rid off is the default route from the IOT vrf to be
> imported into the SHARED vrf.
Ok so the problem is not sharing routes between VRF, problem
On Mon, 6 May 2024 at 15:53, james list via cisco-nsp
wrote:
> The question: since the PO remains up, why we see this behaviour ?
> are BDPU sent just over one link (ie the higher interfac e) ?
Correct.
> how can we solve this issue keeping this scenario ?
> moving to RSTP could solve ?
No.
On Mon, 12 Feb 2024 at 09:44, james list wrote:
> I'd like to test with LACP slow, then can see if physical interface still
> flaps...
I don't think that's good idea, like what would we know? Would we have
to wait 30 times longer, so month-3months, to hit what ever it is,
before we have
On Sun, 11 Feb 2024 at 17:52, james list wrote:
> - why physical interface flaps in DC1 if it is related to lacp ?
16:39:35.813 Juniper reports LACP timeout (so problem started at
16:39:32, (was traffic passing at 32, 33, 34 seconds?))
16:39:36.xxx Cisco reports interface down, long after
On Sun, 11 Feb 2024 at 15:24, james list wrote:
> While on Juniper when the issue happens I always see:
>
> show log messages | last 440 | match LACPD_TIMEOUT
> Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp
> current while timer expired current Receive State: CURRENT
Hey James,
You shared this off-list, I think it's sufficiently material to share.
2024 Feb 9 16:39:36 NEXUS1
%ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface
port-channel101 is down (No operational members)
2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN:
port-channel101:
on observing link
flap.
On Sun, 11 Feb 2024 at 14:14, Saku Ytti wrote:
>
> I don't think any of these matter. You'd see FCS failure on any
> link-related issue causing the BGP packet to drop.
>
> If you're not seeing FCS failures, you can ignore all link related
> problems in this case
I don't think any of these matter. You'd see FCS failure on any
link-related issue causing the BGP packet to drop.
If you're not seeing FCS failures, you can ignore all link related
problems in this case.
On Sun, 11 Feb 2024 at 14:13, Havard Eidnes via juniper-nsp
wrote:
>
> > DC technicians
On Sun, 11 Feb 2024 at 13:51, james list via juniper-nsp
wrote:
> One think I've omit to say is that BGP is over a LACP with currently just
> one interface 100 Gbs.
>
> I see that the issue is triggered on Cisco when eth interface seems to go
> in Initializing state:
Ok, so we can forget BGP
Open JTAC and CTAC cases.
The amount of information provided is wildly insufficient.
'BGP flaps' what does that mean, is it always the same direction? If
so, which direction thinks it's not seeing keepalives? Do you also
observe loss in 'ping' between the links during the period?
Purely
On Jun, 21 Jan 2024 at 03:17, Ross Halliday
wrote:
> Moving to qos-group for egress classes got me the result I was looking for.
> Thank you very much!
I'm happy that you got the results you wanted, but that shouldn't have
fixed it. The 'priority level 3' is the only thing that I can think of
On Fri, 19 Jan 2024 at 05:10, Ross Halliday via cisco-nsp
wrote:
> We've inherited some older ASR9000 systems that we're trying to support
> in-place. The software version on this one router is fairly old at 6.1.4.
> Driving it are a pair of RSP440-SE. The line cards are A9K-MOD160-SE with
>
On Thu, 21 Dec 2023 at 09:21, Hank Nussbacher via cisco-nsp
wrote:
> It used to be TAC was a main selling card of Cisco vs competitors. Not
> any longer :-(
Don't remember them ever being relatively or absolutely good.
Having one support channel for all requests doesn't work, because >99%
On Sat, 16 Dec 2023 at 18:38, Charles Sprickman via cisco-nsp
wrote:
> > There are hundreds of GRE tunnels.
>
> I have nothing to offer, and I'm mostly out of the ISP game, but I am so
> curious what the use-case is here, especially the "BGP to each CPE". I
> understand this might be private
On Mon, 2 Oct 2023 at 13:22, Dobbins, Roland via cisco-nsp
wrote:
> cache timeout inactive 15
> Kentik recommends 15s:
>
> This is an old, out-of-date recommendation from Cisco should be retired.
>
> 5s is plenty of time for inactive flows.
What is the basis for this recommendation? With 1:10k
On Mon, 2 Oct 2023 at 09:14, Hank Nussbacher via cisco-nsp
wrote:
> Does this make sense to go 1:1 which will only increase the number of
> Netflow record to export? Everyone that does 1:1000 or 1:1
> sampling, do you also seen a discrepancy between Netflow stats vs SNMP
> stats?
Both
pps
> RX
> 0 unicast packets 0 multicast packets 0 broadcast packets
> 0 input packets 0 bytes
> 0 jumbo packets 0 storm suppression bytes
> 0 runts 0 giants 0 CRC 0 no buffer
> 0 input error 0 short frame 0 overrun 0 underrun 0 ignored
> 0 w
You've changed JNPR from 30s to 1s, but not CSCO. I'm not sure if this
is the only problem, as insufficient data is shown about the state and
LACP PDUs.
I believe the command is 'lacp rate fast' or 'lacp period short', to
reduce risk of operators getting bored, In your case, the former.
On Sun,
On Sun, 12 Mar 2023 at 20:50, Mark Tinka via cisco-nsp
wrote:
> ASR9K1 has more routes with better paths toward destinations via its
> upstream than ASR9K2 does.
Or at worst, race.
You might want add-path or best-external for predictability and
improved convergence time.
--
++ytti
On Wed, 1 Mar 2023 at 02:41, Phil Bedard via cisco-nsp
wrote:
> With XR7 the idea was to mimic how things are done with Linux repos by having
> a specific RPM repo for the routers and the patches which is managed similar
> to Linux and that’s how all software is packaged now. Dependencies are
On Tue, 14 Feb 2023 at 02:21, Lee Starnes via cisco-nsp
wrote:
> So attempted to just remove the ACL and try. Still nothing. Lastly, I
> enabled telnet and tried to connect via telnet. Still nothing. I really
> don't want to restart the switch if there is any other way to resolve this.
>
>
On Wed, 8 Feb 2023 at 09:48, Hank Nussbacher via cisco-nsp
wrote:
> So how does one escalate such an issue within TAC? Is there some secret
> email like escalati...@cisco.com or vp-...@cisco.com that one can contact?
You call your account team, express your grief and set expectations.
Then you
On Thu, 8 Dec 2022 at 11:40, Marcin Kurek wrote:
>
> > https://www.rfc-editor.org/rfc/rfc8654.html
>
> Thanks!
>
> > But it was [8936, 1240].min - so it was 'negotiated' here to the
> > smallest? If you change the 8936 end to 1239, then that will be used,
> > regardless who starts it.
>
> Yes,
On Thu, 8 Dec 2022 at 11:25, Marcin Kurek wrote:
> Interesting, but why would 'sh run' or 'write' raise an interrupt?
> Isn't this a branch in code that handles the CLI?
Maybe to access NVRAM? I don't know for sure, I didn't pursue it, I
just know I could observe it.
> I'm not sure if I'm
On Wed, 7 Dec 2022 at 22:20, Marcin Kurek wrote:
> > I've seen Cisco presentations in the 90s and early 00s showing
> > significant benefit from it. I have no idea how accurate it is
> > today,nor why it would have made a difference in the past, like was
> > the CPU interrupt rate constrained?
>
Hey Marcin,
> XR without enabled PMTUD (default setting) means ~1240 bytes available
> for TCP payload.
>
> That seems to be a bit small, did you perform any kind of performance
> testing to see the difference between defaults and let's say 9000 for BGP?
I am embarrassed to say, but I _just_
> Assuming typical MPLS network running L2VPNs and L3VPNs, how do you
> configure MTU values for core interfaces? Do you set interface (L2) MTU,
> MPLS MTU and IP MTU separately?
We set the 'physical' MTU (In IOS-XR+Junos L2 but no CRC is in this
humber) as high as it went when the decision was
How would you imagine it works, in a world without any limitations?
This seems like a day1 building ethernet LANs question, unless I'm
missing something.
Comcast learns the 1701 now from every site.
Frame comes in with DMAC 1701
Where does Comcast send it? Should it balance between three sites?
On Fri, 14 Oct 2022 at 23:32, Gert Doering via cisco-nsp
wrote:
> For a true time geek, the time the rPIs provide is just not good
> enough (fluctuates +/- 20 usec if the rPI has work to do and gets
> warm) :-)
Meinberg does not do HW timestamping, nor does NTP. Almost every NIC
out there
On Sat, 6 Aug 2022 at 05:27, Paul via cisco-nsp
wrote:
> Storm control pps is bugged on the 10g ports on the older 4900
> platforms, 4948E , 4900M, sup6 platforms.
When you say 'bugged', what do you specifically mean? Do you mean the
platform can do PPS accounting in HW and there is DDTS or do
at 13:52, Joe Maimon wrote:
>
> Thanks for responding. I was looking for a controller like command to
> see maybe there were some malformed frames or something, but couldnt
> find one on this platform.
>
>
>
> Saku Ytti wrote:
> > On Thu, 4 Aug 2022 at 02:06, Joe M
On Thu, 4 Aug 2022 at 02:06, Joe Maimon via cisco-nsp
wrote:
> I have a vendor trying to turn up a 10gb link from their juniper mx to a
> cisco 4900M, using typical X2 LR.
>
> The link was being upgraded from a functioning 1gb. Same traffic.
10G will serialise packets 10x faster. Even if the
On Fri, 15 Jul 2022 at 03:09, Charles Sprickman wrote:
> I’m doing much less work with Cisco these last few years, and you reminded me
> I do have some folks with ASR-1000 series that are way, way, way overdue for
> some work. I have literally no idea about how the current licensing scheme
>
Junos automatically assigns LL as 1st. IOS-XR can be made to do this
auto-assign, and will use the same policy to generate it.
SROS validates that the set of virtuals are identical, so having SROS
in the network forces you to look a little bit deeper, if you want
VRRP to actually work.
It is
On Thu, 19 May 2022 at 10:27, Hank Nussbacher wrote:
> Others have explained this. Basically, a BGP peer gets locked onto one
> of the LAG links and will migrate to another link in the event that the
> specific link goes down. This is normal behavior.
I'm not sure about normal behaviour and
Hey Chris,
On Fri, 18 Mar 2022 at 11:03, Chris Welti wrote:
> Can't report from production, but we have a 8201-32FH (Q200/Gibraltar) in the
> lab
> right now. Currently considering it as a successor for 400G deployments
> where we had NCS55A1-24H for 100G before.
> So far so good for our use
Yellow,
The box has been out for quite some time now, but I've not heard much
from the community. I don't even know anyone else but 1299 who operate
it.
I'd very much like to hear from anyone who is running the device in
production about their experience with it, even if the experience is
just
On Tue, 28 Dec 2021 at 11:36, Hank Nussbacher wrote:
> Using just IOS-XR, is one able to filter out Netflow records (example)
> based solely on IP address, so flows are not recorded if any record
> starts with 192.168.*.* ? If not, is there an external box one can buy
> that can do that?
I
On Mon, 22 Nov 2021 at 11:14, Gert Doering wrote:
> Haven't tried, but that would be extremely annoying.
>
> The use case I have in mind is using large communities to control
> per-peer-AS exports, as in:
>
> :0: --> "do not announce to $yourasn"
> :1: --> "prepend to $yourasn"
We need to
On Sat, 13 Nov 2021 at 21:23, Mark Tinka wrote:
> And that is all fine, provided YOU, as the operator, are deciding policy.
I don't think IETF is making standards for specific implementation.
The implementation agnostic solution is to keep all routes which we
rejected due to consulting
On Sat, 13 Nov 2021 at 13:48, Mark Tinka wrote:
>
> So some friends and I are working on an RFC draft to fix this:
>
> https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-rov-no-rr
>
> Comments and contributions are most welcome.
I chose my words carefully when I said 'RPKI rejects',
On Thu, 11 Nov 2021 at 10:19, Mark Tinka wrote:
> Thanks for the clue, Saku. Hopefully someone here has the energy to ask
> Cisco to update their documentation, to make this a recommendation. I
> can't be asked :-).
I think it should just be a config error. You're not just cucking
yourself, but
On Thu, 11 Nov 2021 at 10:08, Mark Tinka wrote:
> And Junos defaults to always maintaining a copy of Adj-RIB-In, which is
> why we don't have that issue there, non?
Correct. Add 'keep none' to junos, and you'll have the same issue.
--
++ytti
___
On Thu, 11 Nov 2021 at 09:50, Mark Tinka wrote:
> What's the thought-process here?
When you receive an RTR update, you change your ingress policy, and
you don't know what is the correct result without re-evaluating.
--
++ytti
___
cisco-nsp mailing
On Thu, 11 Nov 2021 at 09:38, Mark Tinka wrote:
> We are currently running 6.7.1, mainly to fix some LDPv6 issues.
>
> However, we started seeing this "too many BGP refresh messages" issue as
> far back as 6.4.2.
Did you run RPKI? Did you have softinbound disabled?
This would cause a refresh
On Tue, 9 Nov 2021 at 19:13, Gert Doering wrote:
> Cisco is a textbook example how to drive away a truly loyal user base,
> and then blaim it on stock market analysts ("they said that any company
> without a recurring revenue software model will be dead soon").
Ranting and raving follows.
All
On Tue, 2 Nov 2021 at 09:00, Drew Weaver wrote:
> RP/0/RSP0/CPU0:Oct 31 15:18:37.422 EDT: ntpd[263]: %IP-IP_NTP-5-HP_CONN_LOST
> : High priority NTP peer connection lost - Stratum 2->3.
> RP/0/RSP0/CPU0:Oct 31 15:34:14.370 EDT: ntpd[263]:
> %IP-IP_NTP-5-HP_CONN_RECOVERED : High priority NTP
On Thu, 21 Oct 2021 at 09:22, wrote:
> Risk? Not really any risk there ... in 20+ years of using third party
> optics/SFPs, we've never had an issue with any ... only situation, as
> others have stated, could be when opening a ticket with TAC and the
> optics aren't reported as Cisco ...
When
On Fri, 10 Sept 2021 at 14:53, Mark Tinka wrote:
> With Cisco putting a lot more effort into IOS XR, I really wonder if the
> ASR1000 and other platforms based on IOS XE will be around in the
> medium-to-long term.
Didn't they just release next-gen catalyst switches and isr cpes
(rebranded as
, james list wrote:
>
> Hi
> just tested and police rate x pps is only applicable to control plane
>
> Cheers
>
> Il giorno mer 8 set 2021 alle ore 15:51 Lukasz Bromirski
> ha scritto:
>>
>> Saku is always on point ;)
>>
>> > On 8 Sep 2021, at 15:
On Wed, 8 Sept 2021 at 16:30, Lukasz Bromirski wrote:
> > 3) is there any mode to limit pps and not only bandwidth
>
> I no longer remember this from top of my mind, but there’s bunch of good
> QoS/HQoS presentations about ASR 1000 in particular on ciscolive.com that you
> can use as
On Fri, 30 Jul 2021 at 20:29, Nick Hilliard wrote:
> there are several reconfig / deconfig operations that can't be handled
> on XR using a single commit, e.g. changing ISIS NET address, some
> netflow stuff, etc.
Deapplying and removing QoS policy in a single commit :). Opening
tickets about
On Thu, 3 Jun 2021 at 22:46, Drew Weaver wrote:
> IP access list custom-copp-system-p-acl-bgp-allow
> 3 permit tcp 192.168.1.2/32 gt 1023 any eq bgp
> 4 permit tcp 192.168.1.2/32 eq bgp any gt 1023
>
> IP access list custom-copp-system-p-acl-bgp-deny
> 1 permit tcp any
On Fri, 4 Jun 2021 at 17:19, Mark Smith wrote:
> Thanks for comments. This is very valuable info. What are your thoughts about:
> flow udp default rate 0
> flow tcp default rate 0
>
> Are they safe to use? Cisco did not recommend them but I dont understand why.
> And they failed to explain.
Hey Mark,
> Any comments on this? @Saku Ytti you probably have good opinions and inside
> knowledge?
Sorry, not really. LPTS is quite a blockbox and there is not much you
can do to improve if you have actual control-plane issues after LPTS.
Unlike in Junos where you can have multiple
I'm assuming the egress port te0/1/7 is not simply full (including
microbursts), because I guess we wouldn't be here if it was.
Have you walked through QFP packet drop decks?
Can you review if you may be software switching, instead of QFP.
show platform hardware qfp active infrastructure punt
Hey,
> We recently upgraded our network from ASR1004s to ASR1009xs.
>
> We are encountering thruput limits on 10G interfaces and were wondering
> whether others have seen that as well.
> We have a Cisco TAC case open now for 2 weeks but nothing has progressed
> so I was wondering whether anyone
On Sat, 27 Mar 2021 at 17:11, Maximilian Wilhelm wrote:
> I'm wondering if the default classfulness is biting you here. Have you
> tried
>
> network 10.0.0.2 mask 255.255.255.255
His problem is that the connected network is less specific and he
wants to (potentially incorrect solution)
You can create a static route pointing to the interface and
redistribute that static route.
But you're doing it wrong. I'm not sure what is right without
understanding more accurately what you are doing, but some flavor of
a) have different logical interface for edge and !edge, with different
https://www.mail-archive.com/cisco-nsp@puck.nether.net/msg68161.html
On Wed, 24 Feb 2021 at 13:26, Hank Nussbacher wrote:
>
> So we bought a bunch of ASR1009x along with IOS-XE and are encountering
> the joy of Smart licensing.
>
> Once we have our license established, do we need to leave the
>
On Sat, 30 Jan 2021 at 02:51, Jerry Bacon wrote:
> Finally was able to get this all working and tested. As we surmised, it
> works properly either with or without the "rewrite", as long as it's
> symmetrical. So I guess it comes down to a personal or network
> preference. I can see a slight
On Mon, 21 Dec 2020 at 18:07, wrote:
> Good point, also all the potential attribute filtering (in XR) would it be
> applied prior to accepting the route into soft-reconfig version of the
> table?
IOS-XR is only post-policy. So whatever you reject does not contribute
towards the limit, allowing
On Sat, 19 Dec 2020 at 13:45, Lukas Tribus wrote:
> soft-reconfig inbound always amounts to 100 MB of memory consumption
> for a v4 + v6 full feed as of last week on 32-bit XR. I can live with
> 100MB of memory consumption per full feed, so I'm doing soft-reconfig
> inbound always everywhere.
On Fri, 18 Dec 2020 at 22:07, Jakob Heitz (jheitz) via cisco-nsp
wrote:
> Testing the RPKI validity in route-map causes BGP REFRESH messages.
> Lots of them.
I think the community largely got blindsided by this, I suspect
marketability of the whole solution would have been a lot poorer if
this
On Wed, 16 Dec 2020 at 17:57, Sheremet Roman wrote:
> Thank you for your time, i just can't understand how i can apply
> received prefixes to my current ACL's.
With QPPB, you don't, with QPPB while processing the BGP NLRI, based
on community or whatever information you have in RIB you
On Thu, 17 Dec 2020 at 13:56, Sheremet Roman wrote:
> So, i should read more about QoS? There i can limit speed to X mb/s
> based on BGP community ?
Yes, you should read up on QPPB if that fits your bill:
Hey,
> So, this is my current configuration for cap bandwidth, when i add
> IP like "x.x.x.x" into access list cisco cap this IP.
I don't agree with any of this as a good product or good technical
implementation of the product, but putting that aside.
> How i can manage ACL's remotely, i
Hey,
> Can someone help me out here? I'm trying to find a way to delay the
> propagation of a loopback interface in isis.
>
> The problem is the border node in sd-access, which uses the loopback
> interface for Lisp, and as soon the fabric sees the interface it sends
> traffic to the address.
>
>
On Fri, 11 Dec 2020 at 16:09, wrote:
> With "Spitfire" do you mean the "Silicon One Q100" by Israeli Leaba
> Semiconductor (bought by cisco in 2016) founders include Eyal Dagan and Ofer
> Iny, founders of Dune Networks, which got sold to Broadcom in 2009 please?
Yes.
> And with "paradise" I
On Fri, 11 Dec 2020 at 11:02, wrote:
> I'm hesitant to recommend Broadcom based platform (NCS5k/Arista/ACX) for
> platform certification testing in a worry that it will bite us in a long run,
> though less so for a P role (as opposed to PE role).
You will struggle to use data to state why
Hey,
> So in most cases it will look that way:
> #show mls cef exception status
> Current IPv4 FIB exception state = TRUE
> Current IPv6 FIB exception state = FALSE
> Current MPLS FIB exception state = FALSE
>
> And yes, the box will drop down to a few MBit of Traffic.
Not only that, but there
On Tue, 15 Sep 2020 at 11:22, t...@pelican.org wrote:
> I'd usually want to err on the side of having more data and putting
> appropriate filtering between the data and the person viewing, rather than
> NOT having data it later turns out would be useful.
Yes tons of (bad) input isn't a
On Thu, 13 Aug 2020 at 03:25, Yham wrote:
> Can anyone please tell which is considered a best practice when it comes to
> the advertising default route? If any vendor documentation addresses this,
> please feel free to share.
In my opinion there is never a need to carry default route in dynamic
On Thu, 30 Jul 2020 at 19:12, wrote:
Hey,
> If I'm not mistaken, sflow/netflow does not pick up null0 routed
> flows. Plz correct me if I am wrong.
I don't think there is a single answer to this question. It depends on
a platform, where netflow/sflow is done and in what order are
functions
On Thu, 30 Jul 2020 at 15:37, Drew Weaver wrote:
> So if a flow is less than the sampling rate it does not export anything, I
> believe is what you are saying.
If none of the 500th packets belong to flow of your interest, you
won't see anything of the flow.
--
++ytti
On Thu, 30 Jul 2020 at 15:26, Drew Weaver wrote:
> So just for a refresher if you are sampling lets say at 1:500 and lets say 1
> byte goes through an interface that is not intended to produce an export?
> The exporting only happens if the amount of data is over a certain threshold?
> Does
On Fri, 24 Jul 2020 at 16:52, Nick Hilliard wrote:
> yep, that works fine for electricity because the cost of generating
> electricity is a significant percentage of the amount that the end user
> pays. I.e. the marginal cost is significant, so it's worth billing per
> kWh. If this model had
On Fri, 24 Jul 2020 at 16:24, Nick Hilliard wrote:
> in this specific case, you're confusing the total cost of customer
> ownership with cost of service delivery. The main individual components
> of residential ip service access are fixed business costs and whether
> people avail of customer
On Thu, 23 Jul 2020 at 21:08, Nick Hilliard wrote:
> The whole idea of having your routing stack poll a remote server with a
> query which essentially asks "should I continue to operate?" with a
> default answer of "No" seems like a unusually stupid way to provision a
> network. Regardless of
On Thu, 23 Jul 2020 at 11:02, Mark Tinka wrote:
> The other option we'd looked at was the SSM (Smart Software Manager)
> on-prem, as I'm not keen on having routers make arbitrary calls to some
> cloud over at Cisco.
You could also use local HTTP proxy, which may be less OPEX to
maintain or may
On Thu, 23 Jul 2020 at 08:50, Mark Tinka wrote:
> Is this part of their new Smart Licensing strategy?
>
> We are still running IOS XE 3.17S on our CSR1000v RR's, and that still
> uses the trusty Permanent AX license.
You can still have SLR
On Thu, 16 Jul 2020 at 16:31, Tim Durack wrote:
> Not trying to be smart or pedantic: modern routers are built out of lots of
> "ASICs". I imagine the forwarding element design is the differentiator:
I don't think there is other option here :)
> 1. Fixed pipeline: EARL family
> 2. Progammable
On Thu, 16 Jul 2020 at 11:25, James Bensley
wrote:
> You're right, and I should have been clearer that the ES20+ cards used
> the NP3C NPU. But I wouldn't say that ES20 cards / PFC3 cards clearly
> are not an NPU. I think they are actually in the interesting middle
> ground between what I would
On Mon, 13 Jul 2020 at 20:39, James Bensley
wrote:
> Back in the 7600s it was NPU based, and what we call NPUs today are
> sometimes a collection of ASICs that form a "complex of ASICs". That
> is what powered the 7600, the NP3C NPU. 7600s used a group of ASICs
> working together to perform
On Mon, 13 Jul 2020 at 12:42, wrote:
> On J2 you can pretty much enable all the bells and whistles you can and
> still get the same pps rate out of it as with no features enabled.
I don't think this is strictly true, maybe it's true for several
cases. But even without recirculation, I think you
On Mon, 13 Jul 2020 at 00:54, Mark Tinka wrote:
> The general messaging, over the years, has been that ASIC is quick but
> not flexible, while NPU is flexible but can get bogged down by added
> flexibility in time.
The classical view is that packet through ASIC takes constant,
invariant time,
On Sun, 12 Jul 2020 at 21:30, Mark Tinka wrote:
> NPU or TCAM, both provide hardware-based forwarding.
This is a bit orthogonal. You can have an NPU with TCAM or NPU with
DRAM. You could also have ASIC with TCAM or ASIC with DRAM.
But if there is a clear line when a piece of hardware becomes
On Sun, 12 Jul 2020 at 12:45, Radu-Adrian FEURDEAN
wrote:
> > then also say Juniper MX, PTX are not hardware, Cisco 8k is
> > not hardware, Jericho2 isn't hardware, modern stuff tends to run off
> > of DRAM, not TCAM.
>
> Most of them can definitely do more than dumb packet forwarding, but
On Sat, 11 Jul 2020 at 21:09, Radu-Adrian FEURDEAN
wrote:
> Hi, wasn't ASR1k a "software-based" series, with route lookups NOT done from
> TCAM, fib limit being the RAM, and forwarding done by homegrown QFP?
I would say no, it was not software based, by HW. First gen QSFP or
Popey was 400MHz
On Fri, 19 Jun 2020 at 14:26, Mark Tinka wrote:
> > ASR9k also has low and high scale cards, we buy the low scale, even
> > for edge. But even low scale is pretty high scale in this context.
>
> You're probably referring to the TR vs. SE line cards, yes?
I do, correct.
--
++ytti
On Fri, 19 Jun 2020 at 14:23, Benny Lyne Amorsen via cisco-nsp
wrote:
> Per-packet overhead is hefty. Is that a problem today?
For us it is in DDoS scenario, we have customers whose product is to
ingest DDoS and send clean out, so we need to deliver the bad traffic
to them. With large
On Fri, 19 Jun 2020 at 14:04, Mark Tinka wrote:
> Even Cisco sort of went down this path with the CRS-3 when they - very
> briefly - sold the so-called CRS LSP (Label Switch Processor) forwarding
> engine:
ASR9k also has low and high scale cards, we buy the low scale, even
for edge. But even
On Fri, 19 Jun 2020 at 13:29, Robert Raszuk wrote:
Hey,
> What you are saying is technically true but not realistically important.
>
> Why - the answer is history of PTX.
I think this is interesting anecdote, but not much more.
> It was originally designed and architected on the very basis of
On Fri, 19 Jun 2020 at 11:35, Mark Tinka wrote:
> > So instead of making it easy for software to generate MPLS packets. We
> > are making it easy for hardware teo generate complex IP packets.
> > Bizarre, but somewhat rational if you start from compute looking out
> > to networks, instead of
On Fri, 19 Jun 2020 at 11:03, Mark Tinka wrote:
> MPLS has been around far too long, and if you post web site content
> still talking about it or show up at conferences still talking about it,
> you fear that you can't sell more boxes and line cards on the back of
> "just" broadening carriage
On Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp
wrote:
> > I don't understand the point of SRv6. What equipment can support IPv6
> > routing, but can't support MPLS label switching?
> This probably does not change anything for SRv6, as that too will likely
> be an extra cost
On Thu, 18 Jun 2020 at 13:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does not.
> That is first fundamental difference. There are customers using both all over
> the world and therefore any suggestion to just use OSPFv3 is IMHO quite
>
1 - 100 of 958 matches
Mail list logo
