Re: [c-nsp] Nexus Architecture question

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
I don't know that we can/should draw that conclusion - as you mentioned, you 
opened a TAC case but from my understanding it was never driven to a terminal 
resolution - either "known limitation, live with it" or "bug, we will/won't fix 
it" or "you're doing it wrong". I tested this on 2nd gen n9k and it works fine, 
I don't have 1st gen gear in my lab so can't empirically confirm that the 
broadcom-based line cards do or don't behave properly and why, or whether 
there's an alternative config that does work. One wrinkle here is that these 
linecards are now well past end of sale, and in fact are past End of 
Vulnerability/Security Support as well, so maybe it's a moot point anyway. For 
10GBASE-T in the 2nd gen I'd suggest the X9788TC-FX linecard and FM-E2 fabric 
module, these should behave properly with the config I posted earlier.

Tim

From: Drew Weaver 
Sent: Friday, June 11, 2021 8:20 AM
To: 'Jeffrey G. Fitzwater' ; Tim Stevenson (tstevens) 
; 'cisco-nsp@puck.nether.net' 
Subject: RE: Nexus Architecture question

Yes, the problem is that the OS doesn't compensate for the flaws in the 
Broadcom based line cards.

Thanks,
-Drew


From: Jeffrey G. Fitzwater mailto:jf...@princeton.edu>>
Sent: Friday, June 11, 2021 11:19 AM
To: Drew Weaver mailto:drew.wea...@thenap.com>>; 'Tim 
Stevenson (tstevens)' mailto:tstev...@cisco.com>>; 
'cisco-nsp@puck.nether.net' 
mailto:cisco-nsp@puck.nether.net>>
Subject: Re: Nexus Architecture question

I am not sure this question was asked in this thread, but are you using a 
custom COPP and not the default?

If you have a custom COPP you must apply the new policy with that name prefix 
i.e. router-core-copp-acl-hsrp
Vs copp-acl-hsrp.

We do this on our 7 and 9ks so that any new code does not override the custom 
COPP policies.

Jeff Fitzwater
Princeton University




From: cisco-nsp 
mailto:cisco-nsp-boun...@puck.nether.net>> 
on behalf of Drew Weaver mailto:drew.wea...@thenap.com>>
Date: Friday, June 11, 2021 at 08:43
To: Drew Weaver mailto:drew.wea...@thenap.com>>, 'Tim 
Stevenson (tstevens)' mailto:tstev...@cisco.com>>, 
'cisco-nsp@puck.nether.net' 
mailto:cisco-nsp@puck.nether.net>>
Subject: Re: [c-nsp] Nexus Architecture question
Just for the list this ended up being a Nexus/NXOS limitation.

-Original Message-
From: cisco-nsp 
mailto:cisco-nsp-boun...@puck.nether.net>> 
On Behalf Of Drew Weaver
Sent: Tuesday, June 8, 2021 11:07 AM
To: 'Tim Stevenson (tstevens)' mailto:tstev...@cisco.com>>; 
'cisco-nsp@puck.nether.net' 
mailto:cisco-nsp@puck.nether.net>>
Subject: Re: [c-nsp] Nexus Architecture question

Sure,

N9K-SUP-B
version 9.3(6)

Also tried: 7.0(3)I7(8)

Thanks,
-Drew




-Original Message-
From: Tim Stevenson (tstevens) mailto:tstev...@cisco.com>>
Sent: Friday, June 4, 2021 4:40 PM
To: Drew Weaver mailto:drew.wea...@thenap.com>>; 
'cisco-nsp@puck.nether.net' 
mailto:cisco-nsp@puck.nether.net>>
Subject: RE: Nexus Architecture question

Hi Drew,

Can you specify hardware platform and software version here? I am not seeing 
what you're seeing, the config I sent blocks a BGP port scan in nmap, and 
prevents BGP peering to anything other than the specified IP. I am testing on 
Nexus 9500 with 10.1 NXOS; I suspect you are using some other platform eg n5k 
or n7k? I may be able to try it out here depending on what you're using.

Thanks,
Tim


-Original Message-
From: Drew Weaver mailto:drew.wea...@thenap.com>>
Sent: Thursday, June 3, 2021 12:37 PM
To: Tim Stevenson (tstevens) mailto:tstev...@cisco.com>>; 
'cisco-nsp@puck.nether.net' 
mailto:cisco-nsp@puck.nether.net>>
Subject: RE: Nexus Architecture question

Hi Tim,

I replied off-list with additional details but I wanted to reply on list to 
answer your specific questions:

I copied the strict policy and then edited it with these classes at the top:

policy-map type control-plane Test6
  class custom-copp-system-p-bgp-allow
police cir 19000 pps bc 128 packets conform transmit violate drop
  class custom-copp-system-p-bgp-deny
police cir 0 pps bc 1 packets conform transmit violate drop

These are the configured class-maps:

Class-map type control-plane match-any custom-copp-system-p-bgp-allow
  match access-group name custom-copp-system-p-acl-bgp-allow
Class-map type control-plane match-any custom-copp-system-p-bgp-deny
  match access-group name custom-copp-system-p-acl-bgp-deny

These are the configured ACLs:

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 any eq bgp
10 permit tcp any gt 1023 any eq bgp
20 permit tcp any eq bgp any gt 1023

control-plane
  service-policy input Test6

The primary difference that I notice between the two configurations is that 
your allow is set to cos 7 and on mine it is not specified and yours is 
policing on bps and mine

Re: [c-nsp] Nexus Architecture question

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Hi Drew, 

Can you specify hardware platform and software version here? I am not seeing 
what you're seeing, the config I sent blocks a BGP port scan in nmap, and 
prevents BGP peering to anything other than the specified IP. I am testing on 
Nexus 9500 with 10.1 NXOS; I suspect you are using some other platform eg n5k 
or n7k? I may be able to try it out here depending on what you're using.

Thanks,
Tim


-Original Message-
From: Drew Weaver  
Sent: Thursday, June 3, 2021 12:37 PM
To: Tim Stevenson (tstevens) ; 'cisco-nsp@puck.nether.net' 

Subject: RE: Nexus Architecture question

Hi Tim, 

I replied off-list with additional details but I wanted to reply on list to 
answer your specific questions:

I copied the strict policy and then edited it with these classes at the top:

policy-map type control-plane Test6
  class custom-copp-system-p-bgp-allow
police cir 19000 pps bc 128 packets conform transmit violate drop
  class custom-copp-system-p-bgp-deny
police cir 0 pps bc 1 packets conform transmit violate drop 

These are the configured class-maps:

Class-map type control-plane match-any custom-copp-system-p-bgp-allow
  match access-group name custom-copp-system-p-acl-bgp-allow
Class-map type control-plane match-any custom-copp-system-p-bgp-deny
  match access-group name custom-copp-system-p-acl-bgp-deny

These are the configured ACLs:

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 any eq bgp 
10 permit tcp any gt 1023 any eq bgp 
20 permit tcp any eq bgp any gt 1023
  
control-plane
  service-policy input Test6

The primary difference that I notice between the two configurations is that 
your allow is set to cos 7 and on mine it is not specified and yours is 
policing on bps and mine is policing on pps. (I am pretty certain that 
throughout the process I have tried it both ways).

I find it a bit hard to follow that on this platform there is no way to write 
"just block everything that matches this class" you still have to give it a 
"burst" [which I obviously don't want] I understand that behind the scenes the 
control plane is supposed to "do the right thing" but it is just difficult to 
understand that from reading it.

With this configuration applied:

1) Any host that NMAPs the device sees 179 open.
2) BGP sessions establish (if configured on the Nexus) for hosts that are not 
192.168.1.2/32

Is there any way to find out what class traffic from a specific SRC IP or to a 
specific port is getting caught at in a CoPP policy?

I suspect that the TCP/179 traffic is just bypassing these classes altogether 
and most likely are getting handled further down in the CoPP policy but I 
haven't been able to prove that.

Thanks so much.
-Drew




-Original Message-
From: Tim Stevenson (tstevens)  
Sent: Wednesday, June 2, 2021 5:31 PM
To: Drew Weaver ; 'cisco-nsp@puck.nether.net' 

Subject: RE: Nexus Architecture question

Hi Drew, 

In answer to your question about BGP, the BGP process runs only on the 
supervisor engine, it does not run on the linecards or anywhere else. It's a 
single process, not a per-interface process or anything like that.

Curious how exactly you are configuring CoPP to filter this? With default CoPP, 
I get an "open/tcpwrapped" (green) response on TCP 179; I was able to get a 
"filtered" (red) response by adding a CoPP class that matches on BGP and 
polices to a CIR of 0. I preceeded that class with a class that matches on a 
specific neighborship - that BGP neighborship is successfully established while 
nmap still returns as filtered from my host.

ip access-list allow-bgp
  10 permit tcp 10.1.1.1/32 gt 1023 10.1.1.2/32 eq bgp
  20 permit tcp 10.1.1.2/32 eq bgp 10.1.1.1/32 gt 1023 ip access-list drop-bgp
  10 permit tcp any any eq bgp
  20 permit tcp any eq bgp any
!
class-map type control-plane match-any allow-bgp
  match access-group name allow-bgp
class-map type control-plane match-any drop-bgp
  match access-group name drop-bgp
!
policy-map type control-plane test-copp-policy-strict
  class allow-bgp
set cos 7
police cir 36000 kbps bc 128 bytes conform transmit violate drop
  class drop-bgp
police cir 0 bps bc 32000 bytes conform transmit violate drop


Hope that helps,
Tim



-Original Message-
From: cisco-nsp  On Behalf Of Drew Weaver
Sent: Wednesday, June 2, 2021 6:41 AM
To: 'cisco-nsp@puck.nether.net' 
Subject: [c-nsp] Nexus Architecture question

Has anyone seen a document from Cisco that shows where various processes 
running on various Nexus switches actually run from?

For example on a 9508 the nxapi runs in a Linux VM and in order to secure it 
you have to drop into the VM and use iptables.

I am trying to figure out where the BGP process lives (for lack of a better 
word). Does it run on

Re: [c-nsp] Nexus Architecture question

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Hi Drew, 

In answer to your question about BGP, the BGP process runs only on the 
supervisor engine, it does not run on the linecards or anywhere else. It's a 
single process, not a per-interface process or anything like that.

Curious how exactly you are configuring CoPP to filter this? With default CoPP, 
I get an "open/tcpwrapped" (green) response on TCP 179; I was able to get a 
"filtered" (red) response by adding a CoPP class that matches on BGP and 
polices to a CIR of 0. I preceeded that class with a class that matches on a 
specific neighborship - that BGP neighborship is successfully established while 
nmap still returns as filtered from my host.

ip access-list allow-bgp
  10 permit tcp 10.1.1.1/32 gt 1023 10.1.1.2/32 eq bgp
  20 permit tcp 10.1.1.2/32 eq bgp 10.1.1.1/32 gt 1023
ip access-list drop-bgp
  10 permit tcp any any eq bgp
  20 permit tcp any eq bgp any
!
class-map type control-plane match-any allow-bgp
  match access-group name allow-bgp
class-map type control-plane match-any drop-bgp
  match access-group name drop-bgp
!
policy-map type control-plane test-copp-policy-strict
  class allow-bgp
set cos 7
police cir 36000 kbps bc 128 bytes conform transmit violate drop
  class drop-bgp
police cir 0 bps bc 32000 bytes conform transmit violate drop


Hope that helps,
Tim



-Original Message-
From: cisco-nsp  On Behalf Of Drew Weaver
Sent: Wednesday, June 2, 2021 6:41 AM
To: 'cisco-nsp@puck.nether.net' 
Subject: [c-nsp] Nexus Architecture question

Has anyone seen a document from Cisco that shows where various processes 
running on various Nexus switches actually run from?

For example on a 9508 the nxapi runs in a Linux VM and in order to secure it 
you have to drop into the VM and use iptables.

I am trying to figure out where the BGP process lives (for lack of a better 
word). Does it run on the line cards? In the control plane? Both? Does it vary 
depending on which model and which line cards?

The reason I am asking is because I've noticed that no matter what I do I 
cannot seem to "close" the BGP port by using CoPP.

It always shows up as being open when doing a port scan against the system 
using NMAP. I know that the switch should not establish a connection with 
random hosts but I really am getting hung up on it being 'scannable'/visible at 
all.


___
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/
--- End Message ---
___
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 9300 sflow performance

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Hi Satish, 

I have not worked much with this particular switch, but per the docs you need 
to size the TCAM regions appropriately to enable sflow. Your show command 
output filters any line with "0" in it - the regions in question are not carved 
by default, they are set to 0. To provision them, you'll need to borrow entries 
from some other region (ie, size down another region to size up the span/sflow 
regions). 

leaf1# show hardware access-list tcam region  | eg -i sflow
   sFlow ACL [sflow] size =0
 SPAN+sFlow ACL [span-sflow] size =0
leaf1#

Please check the section "Prerequisites for sFlow" section in the documentation 
here for details:
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/system_management/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x/b_Cisco_Nexus_9000_Series_NX-OS_System_Management_Configuration_Guide_7x_chapter_011000.html

Hope that helps,
Tim

-Original Message-
From: Satish Patel  
Sent: Tuesday, April 13, 2021 9:13 AM
To: Tim Stevenson (tstevens) 
Cc: Lasse Birnbaum Jensen ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 9300 sflow performance

Folks,

I know this thread is old but I am having some strange issues, you
guys may help me out.

This is my config on CIsco Nexus 9396PX  (NXOS 7.0(3)I7(8))

hardware access-list tcam region span-sflow 256
!
feature sflow
sflow counter-poll-interval 30
sflow collector-ip 10.30.0.91 vrf management
sflow collector-port 9995
sflow agent-ip 172.30.0.26

When i am trying to set a data-source interface I am not able to use 40G ports.

sflow data-source interface e2/1

above command silently accepts command but when i run "show run sflow"
command to verify i am not seeing data-source interface e2/1 in
config, but if i use 10G interface e1/1 that does work.

Cisco official document saying:

Make sure that the sFlow and SPAN ACL TCAM region sizes are configured
for any uplink ports that are to be configured as an sFlow data source
on the following devices: Cisco Nexus 9332PQ, 9372PX, 9372TX, and
93120TX switches and Cisco Nexus 9396PX, 9396TX, and 93128TX switches
with the N9K-M6PQ or N9K-M12PQ generic expansion module (GEM).

I didn't find any region for SPAN ACL to carve size, what and where do
I need to set SPAN ACL size? This is what i have currently.

(config)# show hardware access-list tcam region | exclude 0
   IPV4 PACL [ifacl] size =  512
 IPV4 Port QoS [qos] size =  256
IPV4 VACL [vacl] size =  512
IPV4 RACL [racl] size =  512
 Egress IPV4 VACL [vacl] size =  512
   Egress IPV4 RACL [e-racl] size =  256
  Ingress System size =  256
   Egress System size =  256
 Ingress COPP [copp] size =  256
 Redirect [redirect] size =  512
   NS IPV4 Port QoS [ns-qos] size =  256
  NS IPV4 VLAN QoS [ns-vqos] size =  256
   NS IPV4 L3 QoS [ns-l3qos] size =  256
 VPC Convergence/ES-Multi Home [vpc-convergence] size =  256
   ranger+ IPV4 QoS [rp-qos] size =  256
  ranger+ IPV6 QoS [rp-ipv6-qos] size =  256
ranger+ MAC QoS [rp-mac-qos] size =  256
   sFlow ACL [sflow] size =  256

On Mon, May 13, 2019 at 2:08 PM Tim Stevenson (tstevens) via cisco-nsp
 wrote:
>
>
>
>
> -- Forwarded message --
> From: "Tim Stevenson (tstevens)" 
> To: Lasse Birnbaum Jensen , "cisco-nsp@puck.nether.net" 
> 
> Cc:
> Bcc:
> Date: Mon, 13 May 2019 18:06:58 +
> Subject: RE: [c-nsp] Nexus 9300 sflow performance
> First gen n9k does not support Netflow at all, only sflow. 2nd gen 
> (EX/FX/FX2) support both, but there is the SPAN+SFlow limitation (we are 
> working on fixing that for FX2, which can theoretically support these 
> concurrently).
>
> For recommended sampling value, we set the rate limiters at values that we 
> feel the switch can handle. So you should select a sampling value where you 
> do NOT see HWRL drops, as then it's truly 1:n. If you drop samples, then your 
> sampling is 1:n up to the point where you tail drop excess packets, and that 
> will skew the samples you actually process and export and reduce the 
> statistical validity of the sample.
>
> Using mgmt0 should be fine for sflow export.
>
> Hope that helps,
> Tim
>
>
> -Original Message-
> From: Lasse Birnbaum Jensen 
> Sent: Monday, May 13, 2019 10:58 AM
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 9300 s

Re: [c-nsp] NXOS 7 apply VTY access-list to both IPv4 and IPv6

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Should be like this:

tstevens-9236c-1(config)# line vty
tstevens-9236c-1(config-line)# ip
ip ipv6
tstevens-9236c-1(config-line)# ip access-class foo in
tstevens-9236c-1(config-line)# ipv6 access-class bar in
tstevens-9236c-1(config-line)# sh run | sec vty
line vty
  access-class foo in
  ipv6 access-class bar in
tstevens-9236c-1(config-line)#


Hope that helps,
Tim


-Original Message-
From: cisco-nsp  On Behalf Of Francisco José 
Bernal Fernández
Sent: Wednesday, January 13, 2021 9:37 AM
To: Drew Weaver 
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] NXOS 7 apply VTY access-list to both IPv4 and IPv6

Hi .

You need to create ipv6 acces-list.

Regards

> El 13 ene 2021, a las 18:10, Drew Weaver  escribió:
> 
> Nevermind I actually figured this out. I had created the V6 ACL as a V4 ACL.
> 
> Apologies for the bytes.
> 
> -Original Message-
> From: cisco-nsp  On Behalf Of Drew Weaver
> Sent: Wednesday, January 13, 2021 12:01 PM
> To: 'cisco-nsp@puck.nether.net' 
> Subject: [c-nsp] NXOS 7 apply VTY access-list to both IPv4 and IPv6
> 
> Hello,
> 
> I am doing basic configuration on a switch with NXOS 7. It seems to not want 
> to let me specify different ACLs per "address family" even though it seems to 
> imply that it should be possible. If I enter the command as "ip access-class 
> V4ACL in" and then try to enter "ipv6 access-class V6ACL in" it says: ACL 
> with given name exists with different type
> 
> It is not a huge deal because CoPP filters it first, but I would like to do 
> it for the sake of paranoia and consistency.
> 
> It doesn't seem to be possible to create an ACL that is both IPv4 and IPv6 on 
> this platform, so I am not entirely certain how you do this.
> 
> Thanks,
> -Drew
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=_0xdyUFzHei0BVlt5FeNWn1NB6M1VAlq8UquBTATmY8&s=zdo83IO7gCmeeQPmDv_zrwEhIS5FRVbvUttgzMeSEkg&e=
> archive at 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw&m=_0xdyUFzHei0BVlt5FeNWn1NB6M1VAlq8UquBTATmY8&s=HavN1jnpsgGQa4V-PZQAKKapytaGyR47SsWz81CBTsg&e=
> ___
> 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/
--- End Message ---
___
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 9300 sflow performance

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
First gen n9k does not support Netflow at all, only sflow. 2nd gen (EX/FX/FX2) 
support both, but there is the SPAN+SFlow limitation (we are working on fixing 
that for FX2, which can theoretically support these concurrently).

For recommended sampling value, we set the rate limiters at values that we feel 
the switch can handle. So you should select a sampling value where you do NOT 
see HWRL drops, as then it's truly 1:n. If you drop samples, then your sampling 
is 1:n up to the point where you tail drop excess packets, and that will skew 
the samples you actually process and export and reduce the statistical validity 
of the sample.

Using mgmt0 should be fine for sflow export. 

Hope that helps,
Tim


-Original Message-
From: Lasse Birnbaum Jensen  
Sent: Monday, May 13, 2019 10:58 AM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 9300 sflow performance

Im not totally sure about the N9300 architecture. But normally the mgmt 
interface is connected "directly" to the control plane cpu, thus having it 
process a lot of packets will take CPU resources and might impact control-plane 
protocols and jobs. Netflow is performed in the ASICs and I think it would be 
better to use an ASIC bounded interface if possible.

Best regards
 
Lasse Birnbaum Jensen
Network Architect
IT-services
 
T  +45 65 50 28 73
M  +45 60 11 28 73
la...@sdu.dk
http://www.sdu.dk/ansat/lbje
 
University of Southern Denmark
Campusvej 55
DK-5230 Odense M
www.sdu.dk 
Lasse Birnbaum Jensen

D. 20/03/2019 18.27 skrev "cisco-nsp på vegne af Satish Patel" 
:

Thanks Tim,

Here is the output of show hardware rate-limiter.  ( i believe it's 40k)

This is my first time dealing with SFLOW, Can you share some
configuration parameter i should use for best practice would be great,
What is 1-in-N sample actually?

I am planning to use mgmt0 interface for SFLOW and its 1G so i assume
it will handle all the flow. do you seeing any concern there?


# show hardware rate-limiter

Units for Config: packets per second
Allowed, Dropped & Total: aggregated since last clear counters


Module: 1
  R-L Class   Config   Allowed Dropped
Total
 
+--++---+---+-+
  L3 glean 100   0   0  
   0
  L3 mcast loc-grp3000   0   0  
   0
  access-list-log  100   0   0  
   0
  bfd1   0   0  
   0
  exception 50   0   0  
   0
  fex 3000   0   0  
   0
  span  50   0   0  
   0
  dpss6400   0   0  
   0
  sflow  4 25134089890   0   
25134089890

On Wed, Mar 20, 2019 at 12:07 PM Tim Stevenson (tstevens)
 wrote:
>
> Yes, this is 1st gen. The SFLOW/SPAN restriction should not apply there.
>
> Re: 60Gbps/24Mpps and SFLOW, SFLOW does not do aggregation of stats for 
flows in the switch like netflow does - it's just 1-in-n packet sampling. As 
such, the value of "n" should be high enough that both the switch & the 
collector are not overburdened. Note that we will rate limit SFLOW copies to 
the CPU so that's the first 'bottleneck'. If you end up tail-dropping samples, 
the statistical validity of your sampled set goes out the window, so you want 
to ensure that 1-in-n is a number that does not hit that rate limiter.
>
> I don't have a 1st gen switch handy to see what the defaults are for that 
value. It should show up in 'sh hardware rate-limiter'. In 9300-EX with 9.2.2 
it's 40Kpps.
>
> Beyond that, you also want to make sure the collector is able to consume 
everything coming from all sflow enabled switches without dropping, for the 
same reason mentioned above.
>
> Hope that helps,
> Tim
>
>
> -Original Message-
> From: Satish Patel 
> Sent: Wednesday, March 20, 2019 8:40 AM
> To: Nick Cutting 
> Cc: Tim Stevenson (tstevens) ; 
cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 9300 sflow performance
>
> We have cisco Nexus9000 C9396PX
>
> 60 Gbs is data traffic, and 24Mpps ( packet per second ) not sure how
> to convert it into flows. Could you please share your sflow
> configuration if you don't mind?
>
> I had nfsen in past with 8CPU / 4GB memory but it was damn slow :(
> but it could be me.. i will set up again and see if it worth it or
> not.
>
> On Wed, Mar 20, 2019 at 11:34 AM Nick Cutting  wrote:
  

Re: [c-nsp] Cisco Nexus Data Broker

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Release notes have this information. EX & FX are both supported. 3600-R is not.

See Table 2/Table 3 here:
https://www.cisco.com/c/en/us/td/docs/net_mgmt/xnc/nexus_data_broker/release_notes/Nexus_Data_Broker_Release_Notes_371.html

Hope that helps,
Tim


-Original Message-
From: cisco-nsp  On Behalf Of Robert Hass
Sent: Friday, May 10, 2019 5:23 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Cisco Nexus Data Broker

Hi
I cannot find information which current models of Nexus switches are
supporting Cisco Nexus Data Broker.

Documents on cisco.com are quite outdated - from 2014 or 2017.

I'm wondering if Data Broker is supported on Nexus 9300 EX/FX and Nexus
3600-R series.

Rob
___
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/
--- End Message ---
___
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] TCAM utilization on Nexus 9396

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Please check the config guide. I am not as familiar w/the 1st gen switches as 
2nd gen, but there should be at least some level of reconfigurability of the 
regions in gen 1. So you may be able to size up the region you want by removing 
entries from some other region.

Yes, region resizing requires a switch reboot.

Tim

-Original Message-
From: Satish Patel  
Sent: Wednesday, March 20, 2019 12:12 PM
To: Tim Stevenson (tstevens) 
Cc: Cisco Network Service Providers ; Nick Cutting 

Subject: Re: TCAM utilization on Nexus 9396

Thanks for clarification, i have noticed when i add 1 rules number
bump +1 but i believe you can't go above 510 right? that is hard limit
if i am not wrong.

also changing in resource required reload.


On Wed, Mar 20, 2019 at 2:07 PM Tim Stevenson (tstevens)
 wrote:
>
> Yes, ACL lines consume space in the TCAM. TCAM can be recarved according to 
> the features in use/required.
>
> As long as the policy fits in the available TCAM space for that feature 
> (software will complain and fail your config if it won't), enforcement is at 
> full rate, no performance penalty for that.
>
> Tim
>
> -Original Message-
> From: Satish Patel 
> Sent: Wednesday, March 20, 2019 10:46 AM
> To: Cisco Network Service Providers ; Nick Cutting 
> ; Tim Stevenson (tstevens) 
> Subject: TCAM utilization on Nexus 9396
>
> Folks and ( Tim/Nick )
>
> I have Cisco Nexus 9396 L3 switch and running bunch of ACL ( IPv4
> Access-list to block certain traffic )  today i was reading about TCAM
> and when i look at switch i found following utilization, so trying to
> understand how ACL relationship with TCAM.
>
> - Does number of ACL impact TCAM utilization or traffic ?
>
>
> # show hardware access-list resource utilization
>
> slot  1
> ===
>
>
>
> INSTANCE 0x0
> -
>
>
>  ACL Hardware Resource Utilization (Mod 1)
>  --
> UsedFreePercent
> Utilization
> ---
> Ingress IPv4 PACL   3   509 0.59
> Ingress IPv4 Port QoS   4   252 1.56
> Ingress IPv4 VACL   2   510 0.39
> Ingress IPv4 RACL   226 286 44.14
> Egress IPv4 VACL3   509 0.59
> Egress IPv4 RACL3   253 1.17
> SUP COPP205 51  80.08
> SUP COPP Reason Code TCAM   6   122 4.69
> Redirect2   510 0.39
> SPAN21  235 8.20
> VPC Convergence 1   255 0.39
>
> LOU 2   22  8.33
> Both LOU Operands   2
> Single LOU Operands 0
> LOU L4 src port:1
> LOU L4 dst port:1
> LOU L3 packet len:  0
> LOU IP tos: 0
> LOU IP dscp:0
> LOU ip precedence:  0
> LOU ip TTL: 0
> TCP Flags   0   16  0.00
>
> Protocol CAM2   244 0.81
> Mac Etype/Proto CAM 0   14  0.00
>
> L4 op labels, Tcam 00   10230.00
> L4 op labels, Tcam 21   62  1.58
> L4 op labels, Tcam 60   20470.00
>
> Ingress Dest info table 0   512 0.00
>
> Egress Dest info table 0 512 0.00
--- End Message ---
___
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] TCAM utilization on Nexus 9396

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Yes, ACL lines consume space in the TCAM. TCAM can be recarved according to the 
features in use/required. 

As long as the policy fits in the available TCAM space for that feature 
(software will complain and fail your config if it won't), enforcement is at 
full rate, no performance penalty for that.

Tim

-Original Message-
From: Satish Patel  
Sent: Wednesday, March 20, 2019 10:46 AM
To: Cisco Network Service Providers ; Nick Cutting 
; Tim Stevenson (tstevens) 
Subject: TCAM utilization on Nexus 9396

Folks and ( Tim/Nick )

I have Cisco Nexus 9396 L3 switch and running bunch of ACL ( IPv4
Access-list to block certain traffic )  today i was reading about TCAM
and when i look at switch i found following utilization, so trying to
understand how ACL relationship with TCAM.

- Does number of ACL impact TCAM utilization or traffic ?


# show hardware access-list resource utilization

slot  1
===



INSTANCE 0x0
-


 ACL Hardware Resource Utilization (Mod 1)
 --
UsedFreePercent
Utilization
---
Ingress IPv4 PACL   3   509 0.59
Ingress IPv4 Port QoS   4   252 1.56
Ingress IPv4 VACL   2   510 0.39
Ingress IPv4 RACL   226 286 44.14
Egress IPv4 VACL3   509 0.59
Egress IPv4 RACL3   253 1.17
SUP COPP205 51  80.08
SUP COPP Reason Code TCAM   6   122 4.69
Redirect2   510 0.39
SPAN21  235 8.20
VPC Convergence 1   255 0.39

LOU 2   22  8.33
Both LOU Operands   2
Single LOU Operands 0
LOU L4 src port:1
LOU L4 dst port:1
LOU L3 packet len:  0
LOU IP tos: 0
LOU IP dscp:0
LOU ip precedence:  0
LOU ip TTL: 0
TCP Flags   0   16  0.00

Protocol CAM2   244 0.81
Mac Etype/Proto CAM 0   14  0.00

L4 op labels, Tcam 00   10230.00
L4 op labels, Tcam 21   62  1.58
L4 op labels, Tcam 60   20470.00

Ingress Dest info table 0   512 0.00

Egress Dest info table 0 512 0.00
--- End Message ---
___
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 9300 sflow performance

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
-Original Message-
From: Satish Patel  
Sent: Wednesday, March 20, 2019 10:23 AM
To: Tim Stevenson (tstevens) 
Cc: Nick Cutting ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 9300 sflow performance

Thanks Tim,

Here is the output of show hardware rate-limiter.  ( i believe it's 40k)


>> Yes looks to be the same as on 9300-EX/FX/FX2.


This is my first time dealing with SFLOW, Can you share some
configuration parameter i should use for best practice would be great,
What is 1-in-N sample actually?


>> Sampling rate is controlled via config:
tstevens-93180yc-ex-4(config)# sflow sampling-rate ?
  <4096-10>  SFlow Sampling rate

>> You need to calculate the PPS of the traffic on the source interfaces to 
>> determine the sampling rate that will keep the max number of samples to 
>> under 40K from all sources.


I am planning to use mgmt0 interface for SFLOW and its 1G so i assume
it will handle all the flow. do you seeing any concern there?


>> With max of 40Kpps of sampling, it should be fine on 1G mgmt0.
>> Tim


# show hardware rate-limiter

Units for Config: packets per second
Allowed, Dropped & Total: aggregated since last clear counters


Module: 1
  R-L Class   Config   Allowed DroppedTotal
 +--++---+---+-+
  L3 glean 100   0   0 0
  L3 mcast loc-grp3000   0   0 0
  access-list-log  100   0   0 0
  bfd1   0   0 0
  exception 50   0   0 0
  fex 3000   0   0 0
  span  50   0   0 0
  dpss6400   0   0 0
  sflow  4 25134089890   0   25134089890

On Wed, Mar 20, 2019 at 12:07 PM Tim Stevenson (tstevens)
 wrote:
>
> Yes, this is 1st gen. The SFLOW/SPAN restriction should not apply there.
>
> Re: 60Gbps/24Mpps and SFLOW, SFLOW does not do aggregation of stats for flows 
> in the switch like netflow does - it's just 1-in-n packet sampling. As such, 
> the value of "n" should be high enough that both the switch & the collector 
> are not overburdened. Note that we will rate limit SFLOW copies to the CPU so 
> that's the first 'bottleneck'. If you end up tail-dropping samples, the 
> statistical validity of your sampled set goes out the window, so you want to 
> ensure that 1-in-n is a number that does not hit that rate limiter.
>
> I don't have a 1st gen switch handy to see what the defaults are for that 
> value. It should show up in 'sh hardware rate-limiter'. In 9300-EX with 9.2.2 
> it's 40Kpps.
>
> Beyond that, you also want to make sure the collector is able to consume 
> everything coming from all sflow enabled switches without dropping, for the 
> same reason mentioned above.
>
> Hope that helps,
> Tim
>
>
> -Original Message-
> From: Satish Patel 
> Sent: Wednesday, March 20, 2019 8:40 AM
> To: Nick Cutting 
> Cc: Tim Stevenson (tstevens) ; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 9300 sflow performance
>
> We have cisco Nexus9000 C9396PX
>
> 60 Gbs is data traffic, and 24Mpps ( packet per second ) not sure how
> to convert it into flows. Could you please share your sflow
> configuration if you don't mind?
>
> I had nfsen in past with 8CPU / 4GB memory but it was damn slow :(
> but it could be me.. i will set up again and see if it worth it or
> not.
>
> On Wed, Mar 20, 2019 at 11:34 AM Nick Cutting  wrote:
> >
> > Good point.  We waited for the second Gen
> >
> > Regarding 60 Gbs, isn’t that is the data traffic, not the flows or sampled 
> > flows levels?
> >
> > Our NFSEn box is centos
> >
> > 4 vCPU and 4 GBrams
> >
> > Collecting flows from maybe only 30 devices, about 20Gbs and 3k flows per 
> > sec.
> >
> > -Original Message-
> > From: Tim Stevenson (tstevens) 
> > Sent: Wednesday, March 20, 2019 11:20 AM
> > To: Nick Cutting ; Satish Patel 
> > ; cisco-nsp@puck.nether.net
> > Subject: RE: [c-nsp] Nexus 9300 sflow performance
> >
> > This message originated from outside your organization.
> >
> > Make sure you distinguish between N9300 (1st generation) and 
> > N9300-EX/FX/FX2 (2nd generation). The SFLOW + SPAN limitation applies only 
> > to the latter. It's also on the latter that Netflow is supported, which can 
> > run concurrently with SPAN sessions.
> >
> > Tim
> >
> > -Original Message-
> > From: cisco-nsp  On Behalf Of Nick 
> > Cutting
> > Sent: Wednesday, March 20, 2019 6:19 AM
> > To: Satish Patel ; cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] Nexus 9300 sflow performance
> >
> > We use sflow on 9300's, no performan

Re: [c-nsp] Nexus 9300 sflow performance

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Yes, this is 1st gen. The SFLOW/SPAN restriction should not apply there.

Re: 60Gbps/24Mpps and SFLOW, SFLOW does not do aggregation of stats for flows 
in the switch like netflow does - it's just 1-in-n packet sampling. As such, 
the value of "n" should be high enough that both the switch & the collector are 
not overburdened. Note that we will rate limit SFLOW copies to the CPU so 
that's the first 'bottleneck'. If you end up tail-dropping samples, the 
statistical validity of your sampled set goes out the window, so you want to 
ensure that 1-in-n is a number that does not hit that rate limiter. 

I don't have a 1st gen switch handy to see what the defaults are for that 
value. It should show up in 'sh hardware rate-limiter'. In 9300-EX with 9.2.2 
it's 40Kpps.

Beyond that, you also want to make sure the collector is able to consume 
everything coming from all sflow enabled switches without dropping, for the 
same reason mentioned above.

Hope that helps,
Tim


-Original Message-
From: Satish Patel  
Sent: Wednesday, March 20, 2019 8:40 AM
To: Nick Cutting 
Cc: Tim Stevenson (tstevens) ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 9300 sflow performance

We have cisco Nexus9000 C9396PX

60 Gbs is data traffic, and 24Mpps ( packet per second ) not sure how
to convert it into flows. Could you please share your sflow
configuration if you don't mind?

I had nfsen in past with 8CPU / 4GB memory but it was damn slow :(
but it could be me.. i will set up again and see if it worth it or
not.

On Wed, Mar 20, 2019 at 11:34 AM Nick Cutting  wrote:
>
> Good point.  We waited for the second Gen
>
> Regarding 60 Gbs, isn’t that is the data traffic, not the flows or sampled 
> flows levels?
>
> Our NFSEn box is centos
>
> 4 vCPU and 4 GBrams
>
> Collecting flows from maybe only 30 devices, about 20Gbs and 3k flows per sec.
>
> -Original Message-
> From: Tim Stevenson (tstevens) 
> Sent: Wednesday, March 20, 2019 11:20 AM
> To: Nick Cutting ; Satish Patel ; 
> cisco-nsp@puck.nether.net
> Subject: RE: [c-nsp] Nexus 9300 sflow performance
>
> This message originated from outside your organization.
>
> Make sure you distinguish between N9300 (1st generation) and N9300-EX/FX/FX2 
> (2nd generation). The SFLOW + SPAN limitation applies only to the latter. 
> It's also on the latter that Netflow is supported, which can run concurrently 
> with SPAN sessions.
>
> Tim
>
> -Original Message-
> From: cisco-nsp  On Behalf Of Nick Cutting
> Sent: Wednesday, March 20, 2019 6:19 AM
> To: Satish Patel ; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Nexus 9300 sflow performance
>
> We use sflow on 9300's, no performance hit - but you cannot use span sessions 
> at the same time.
>
> Newer code revisions support netflow, without the SPAN session limitation, 
> although we have not tried netflow on the 9300 yet.
>
> For a collector We use NFSEN - opensource, and quite a big install base, and 
> it seems to handle a lot of flows.
>
> It supports sflow and netflow as we have a mix, just make sure you add the 
> sflow option at build time as it’s a bit funky old linux to add it after.
>
>
>
> -Original Message-
> From: cisco-nsp  On Behalf Of Satish Patel
> Sent: Wednesday, March 20, 2019 8:21 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Nexus 9300 sflow performance
>
> This message originates from outside of your organisation.
>
> Folks,
>
> I have L3 Nexus 9300 switch which is running 60Gbps traffic on ISP interface 
> so I’m planning to run sflow on that specific interference to get flow.
>
> Does it going to create any performances issue on switch?
>
> Can I run sflow on Layer 3 LACP interface?
>
> Can anyone suggest free open source sflow collector?
>
> Sent from my iPhone
> ___
> 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/
--- End Message ---
___
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 9300 sflow performance

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Make sure you distinguish between N9300 (1st generation) and N9300-EX/FX/FX2 
(2nd generation). The SFLOW + SPAN limitation applies only to the latter. It's 
also on the latter that Netflow is supported, which can run concurrently with 
SPAN sessions.

Tim

-Original Message-
From: cisco-nsp  On Behalf Of Nick Cutting
Sent: Wednesday, March 20, 2019 6:19 AM
To: Satish Patel ; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Nexus 9300 sflow performance

We use sflow on 9300's, no performance hit - but you cannot use span sessions 
at the same time.

Newer code revisions support netflow, without the SPAN session limitation, 
although we have not tried netflow on the 9300 yet.

For a collector We use NFSEN - opensource, and quite a big install base, and it 
seems to handle a lot of flows.

It supports sflow and netflow as we have a mix, just make sure you add the 
sflow option at build time as it’s a bit funky old linux to add it after.



-Original Message-
From: cisco-nsp  On Behalf Of Satish Patel
Sent: Wednesday, March 20, 2019 8:21 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Nexus 9300 sflow performance

This message originates from outside of your organisation.

Folks,

I have L3 Nexus 9300 switch which is running 60Gbps traffic on ISP interface so 
I’m planning to run sflow on that specific interference to get flow. 

Does it going to create any performances issue on switch? 

Can I run sflow on Layer 3 LACP interface?

Can anyone suggest free open source sflow collector? 

Sent from my iPhone
___
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/
--- End Message ---
___
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] Qos Statistics on the 7K

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Hi Brad, 

I checked this on n7700 F3 - concur that even w/'statistics per-entry', the hit 
count is not incrementing in 'sh ip access' output when the ACL is used for QOS 
classification. Same behavior in 8.3.1.

>From what I see, the statistics are in fact incrementing in hardware, you can 
>verify by attaching to the LC via 'attach mod x' and using 'sh sys internal 
>access-list input entries detail' and find the block with your ACL (might be a 
>bit tedious doing it this way as all policies, including CoPP etc, will be 
>listed out there). Not sure why that is not just being exported up and 
>aggregated in the sup, though the 'usual' use-case for monitoring ACL hit 
>counts has centered around security ACLs.

VDC-1 Ethernet2/1 : 
 

INSTANCE 0x0
---

  Tcam 0 resource usage:
  --
  Label_a = 0x201
   Bank 1
   --
 IPv4 Class
   Policies: QoS(all-ip) 
   Netflow profile: 0
   Netflow deny profile: 0
   Entries: 
 [Index] Entry [Stats]
 -
  [0015:000b:000b] qos ip 0.0.0.0/0 10.1.1.0/24  [398869316] 


I guess you're hoping to figure out which specific ACEs are matching in each 
class (vs just seeing the total number of packets classified in each class, as 
seen in 'sh policy-map interface')? I can check w/our engineering team and see 
if there's some reason this has not been implemented.

Hope that helps,
Tim



-Original Message-
From: cisco-nsp  On Behalf Of Bradley Ordner
Sent: Wednesday, November 14, 2018 8:49 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Qos Statistics on the 7K

Hi,

This may have been asked before, even on Cisco Support Community I have an 
answer but it doesn't seem to be working for me.

We have a Layer 3 port with a QoS policy for marking traffic inbound. I have 
added the 'statistics per-entry' command in our ACL but I do not see any hits. 
When checking the policy and queueing, I see traffic being matched.

We are only marking inbound on this port, is it not supported or do I have a 
bug? I am on version - 7.2(0)D1(1)

Match: access-group QOSACL- BLAH
46082768 packets
  set dscp 56

Thanks

Brad Ordner

___
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/
--- End Message ---
___
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] Fixed switch based on N9K-X9636C-RX

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
There isn't one. Closest is Nexus 3636C-R, this is J+ based like the 9636C-RX 
but with on-chip tables only (no external TCAM).

Tim

-Original Message-
From: cisco-nsp  On Behalf Of Drew Weaver
Sent: Wednesday, August 8, 2018 5:39 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Fixed switch based on N9K-X9636C-RX

Has anyone come across a 1U Nexus switch that has TCAM like the N9K-X9636C-RX?

Thanks,
-Drew

___
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/
--- End Message ---
___
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] N9K ASIC port grouping

[Tim Stevenson (tstevens) via cisco-nsp]

106   255   140   -13 1632

BR,
Pedro Caetano

On Mon, Jun 25, 2018 at 2:00 PM, Tim Stevenson (tstevens) via cisco-nsp <
cisco-nsp@puck.nether.net> wrote:

> ___
> 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/
>
>
> -- Forwarded message --
> From: "Tim Stevenson (tstevens)" 
> To: Youssef Bengelloun-Zahr , Cisco Network Service
> Providers 
> Cc:
> Bcc:
> Date: Mon, 25 Jun 2018 18:00:40 +
> Subject: RE: [c-nsp] N9K ASIC port grouping
> Not aware of a single document that will show that for all platforms. Best
> way is "show interface hardware-mappings". "Unit" and "Slice" are the main
> points of reference (unit == ASIC instance, slice == pipeline).
>
> E.g., 93180yc-ex:
> leaf1# sh int hard
> Legends:
>SMod  - Source Mod. 0 is N/A
>Unit  - Unit on which port resides. N/A for port channels
>HPort - Hardware Port Number or Hardware Trunk Id:
>HName - Hardware port name. None means N/A
>FPort - Fabric facing port number. 255 means N/A
>NPort - Front panel port number
>VPort - Virtual Port Number. -1 means N/A
>Slice - Slice Number. N/A for BCM systems
>SPort - Port Number wrt Slice. N/A for BCM systems
>SrcId - Source Id Number. N/A for BCM systems
>MacIdx - Mac index. N/A for BCM systems
>MacSubPort - Mac sub port. N/A for BCM systems
>
> 
> 
> Name   Ifindex  Smod Unit HPort FPort NPort VPort Slice SPort SrcId
> MacId MacSP
> 
> 
> Eth1/1 1a00 1016255   0 -10 16324
>0
> Eth1/2 1a000200 1017255   4 -10 17344
>2
> Eth1/3 1a000400 1018255   8 -10 18364
>4
> Eth1/4 1a000600 1019255   12-10 19384
>6
> Eth1/5 1a000800 1012255   16-10 12243
>0
> Eth1/6 1a000a00 1013255   20-10 13263
>2
> Eth1/7 1a000c00 1014255   24-10 14283
>4
> Eth1/8 1a000e00 1015255   28-10 15303
>6
> Eth1/9 1a001000 108 255   32-10 8 162
>0
> Eth1/101a001200 109 255   36-10 9 182
>2
> Eth1/111a001400 1010255   40-10 10202
>4
> Eth1/121a001600 1011255   44-10 11222
>6
> Eth1/131a001800 104 255   48-10 4 8 1
>0
> Eth1/141a001a00 105 255   52-10 5 101
>2
> Eth1/151a001c00 106 255   56-10 6 121
>4
> Eth1/161a001e00 107 255   60-10 7 141
>6
> Eth1/171a002000 100 255   64-10 0 0 0
>0
> Eth1/181a002200 101 255   68-10 1 2 0
>2
> Eth1/191a002400 102 255   72-10 2 4 0
>4
> Eth1/201a002600 103 255   76-10 3 6 0
>6
> Eth1/211a002800 1060255   80-11 2040
> 140
> Eth1/221a002a00 1061255   84-11 2142
> 142
> Eth1/231a002c00 1062255   88-11 2244
> 144
> Eth1/241a002e00 1063255   92-11 2346
> 146
> Eth1/251a003000 1056255   96-11 1632
> 130
> Eth1/261a003200 1057255   100   -11 1734
> 132
> Eth1/271a003400 1058255   104   -11 1836
> 134
> Eth1/281a003600 1059255   108   -11 1938
> 136
> Eth1/291a003800 1052255   112   -11 1224
> 120
> Eth1/301a003a00 1053255   116   -11 1326
> 122
> Eth1/311a003c00 1054255   120   -11 1428
> 124
> Eth1/321a003e00 1055255   124   -11 1530
> 126
> Eth1/331a004000 1048255   128   -11 8 16
> 110
> Eth1/341a004200 1049255   132   -11 9 18
> 112
> Eth1/3

Re: [c-nsp] N9K ASIC port grouping

[Tim Stevenson (tstevens) via cisco-nsp]

--- Begin Message ---
Not aware of a single document that will show that for all platforms. Best way 
is "show interface hardware-mappings". "Unit" and "Slice" are the main points 
of reference (unit == ASIC instance, slice == pipeline). 

E.g., 93180yc-ex:
leaf1# sh int hard
Legends:
   SMod  - Source Mod. 0 is N/A
   Unit  - Unit on which port resides. N/A for port channels
   HPort - Hardware Port Number or Hardware Trunk Id:
   HName - Hardware port name. None means N/A
   FPort - Fabric facing port number. 255 means N/A
   NPort - Front panel port number
   VPort - Virtual Port Number. -1 means N/A
   Slice - Slice Number. N/A for BCM systems
   SPort - Port Number wrt Slice. N/A for BCM systems
   SrcId - Source Id Number. N/A for BCM systems
   MacIdx - Mac index. N/A for BCM systems
   MacSubPort - Mac sub port. N/A for BCM systems


Name   Ifindex  Smod Unit HPort FPort NPort VPort Slice SPort SrcId MacId 
MacSP

Eth1/1 1a00 1016255   0 -10 16324 0
Eth1/2 1a000200 1017255   4 -10 17344 2
Eth1/3 1a000400 1018255   8 -10 18364 4
Eth1/4 1a000600 1019255   12-10 19384 6
Eth1/5 1a000800 1012255   16-10 12243 0
Eth1/6 1a000a00 1013255   20-10 13263 2
Eth1/7 1a000c00 1014255   24-10 14283 4
Eth1/8 1a000e00 1015255   28-10 15303 6
Eth1/9 1a001000 108 255   32-10 8 162 0
Eth1/101a001200 109 255   36-10 9 182 2
Eth1/111a001400 1010255   40-10 10202 4
Eth1/121a001600 1011255   44-10 11222 6
Eth1/131a001800 104 255   48-10 4 8 1 0
Eth1/141a001a00 105 255   52-10 5 101 2
Eth1/151a001c00 106 255   56-10 6 121 4
Eth1/161a001e00 107 255   60-10 7 141 6
Eth1/171a002000 100 255   64-10 0 0 0 0
Eth1/181a002200 101 255   68-10 1 2 0 2
Eth1/191a002400 102 255   72-10 2 4 0 4
Eth1/201a002600 103 255   76-10 3 6 0 6
Eth1/211a002800 1060255   80-11 2040140
Eth1/221a002a00 1061255   84-11 2142142
Eth1/231a002c00 1062255   88-11 2244144
Eth1/241a002e00 1063255   92-11 2346146
Eth1/251a003000 1056255   96-11 1632130
Eth1/261a003200 1057255   100   -11 1734132
Eth1/271a003400 1058255   104   -11 1836134
Eth1/281a003600 1059255   108   -11 1938136
Eth1/291a003800 1052255   112   -11 1224120
Eth1/301a003a00 1053255   116   -11 1326122
Eth1/311a003c00 1054255   120   -11 1428124
Eth1/321a003e00 1055255   124   -11 1530126
Eth1/331a004000 1048255   128   -11 8 16110
Eth1/341a004200 1049255   132   -11 9 18112
Eth1/351a004400 1050255   136   -11 1020114
Eth1/361a004600 1051255   140   -11 1122116
Eth1/371a004800 1044255   144   -11 4 8 100
Eth1/381a004a00 1045255   148   -11 5 10102
Eth1/391a004c00 1046255   152   -11 6 12104
Eth1/401a004e00 1047255   156   -11 7 14106
Eth1/411a005000 1076255   160   -11 3664170
Eth1/421a005200 1077255   164   -11 3766172
Eth1/431a005400 1078255   168   -11 3868174
Eth1/441a005600 1079255   172   -11 3970176
Eth1/451a005800 1036255   176   -10 36648 0
Eth1/461a005a00 1037255   180   -10 37668 2
Eth1/471a005c00 1038255   184   -10 38688 4
Eth1/481a005e00 1039255   188   -10 39708