Aruba AOS-10

Aruba AOS-10 at a Glance

ArubaOS 10 (AOS 10) is the distributed network operating system working with Aruba Central that controls Aruba Access Points (APs) and optional gateways. With its flexible architecture, network teams can deliver reliable and secure wireless connectivity for small offices, mid-sized branches, even large campus environments, and remote workers. Working in tandem with cloud-native Aruba Central, AOS 10 provides the WLAN management and control to deliver
greater scalability, security, and AI-powered optimization.

Key Benefits:

  • Simplify the deployment and upgrade of wireless networks using a unified operating system that meets the needs of remote workers, branch offices, and large campus environments.
  • Optimize radio frequencies operation and deliver reliable and high-performing connectivity with AI-automation and machine learning insights.
  • Provide the highest levels of security with policy enforcement across wired and wireless environments and secure segmentation.
  • Unify the management of wired, wireless, and SD-WAN using Aruba Central to create a single pane of glass as part of Aruba’s Edge Services Platform (ESP).
  • Future-proof your wireless investment using a cloud-native, microservices architectural model while leveraging existing hardware

AOS-10 Architecture:

The AOS 10 architecture consists of two layers:

  • Infrastructure layer—The infrastructure layer consists of a WLAN setup that can be either a campus setup or a branch setup. Either can consist only of APs, or APs combined with gateway clusters.
  • Cloud management layer—The cloud management layer consists of Aruba Central which is a cloud management SAAS platform.

AOS10 combines both IAP and Aruba Controller based Architecture under a single Architecture. It does it as follows:

  • Aruba Central is the Management and Control Plane for both AP only and AP + Controller (AOS10 uses keyword Gateways for Controllers) based Architecture.
  • Unlike in AOS8, where AP only Architecture (IAP) was supported by Central (Cloud), while Controller based Architecture required Onprem (AirWave). The AOS10 Architecture now supports Central for both AP only and AP + Gateway based setup.
  • The IAP setup is now AP only (Standalone AP) setup without any concept of VC as all the VC functions are now pushed to Central.
  • AOS 10 removes the limitation of the number of APs and clients in a single roaming domain compared to IAP clusters. Currently, the supported AOS 10 Bridge Mode scaling recommendations are up to 500 APs and 5000 clients. With almost four times the previous recommended maximum for 128 IAPs in a cluster, this resolves several limitations in the IAP architecture. If the setup scales over 500APs, the Gateway is recommended.
  • The Gateway are no longer WLAN Gateway only, the Gateway acts as both SDWAN and WLAN Gateway, both share same AOS software image.

The following side-by-side comparison shows an example deployment before and after upgrading from an Airwave-managed IAP cluster to AOS 10 Bridge Mode.

Although Wi-Fi client traffic is handled similarly in both AOS 10 Tunnel Mode and AOS 8 Campus Mode, several important changes require planning, as highlighted in the side-by-side diagrams below.

Step 1 Wi-Fi client traffic from the corporate laptop and guest phone is encapsulated using GRE in both platforms. The AOS 10 deployment can be configured in Central to encapsulate traffic in GRE with IPsec.

Step 2 AOS 8 Mobility Conductor and AirWave appliances are decommissioned since they are not available in AOS 10.

Step 3 AOS 10 hardware requires Aruba Central for management and monitoring.

Step 4 IPsec, AMON, and SNMP traffic sent to the Mobility Conductor and AirWave AOS 8 is replaced by HTTPS traffic sent from Aruba gateways and APs.

More details: https://www.arubanetworks.com/techdocs/VSG/docs/035-campus-migrate/esp-campus-migrate-000/

Happy Reading…

Exploring Aruba 8.x API via Postman

Exploring Aruba 8.x API via Postman

Postman is a great tool to test APIs, we can make a group of API calls known as collection in Postman. The collection could also be run from CLI via Newman.

Postman has a lot of good documentation to start and test the API function. The ArubaOS 8.x though provide the swagger interface which could be directly used to test and run APIs, however the collection function on Postman provides good automation function.

I will use Postman to take a tech support logs and export it to external tftp/ftp server.

Aruba API Guide: https://www.arubanetworks.com/techdocs/ArubaOS_83x_Web_Help/Content/PDFs/ArubaOS%208.3.0.x%20API%20Guide.pdf

Difference between Params and Body in Postman:

Params correspond to the request parameters that are appended to the request URL.they are most used with GET requests. On the other hand, Body is the actual request body (usually it defines the request payload or the data needs to be processed by the request). PUT and POST requests are usually read the data from the body of the request and not from the params.

Login to Aruba Controller via Postman:

The Aruba API Guide provides good documentation on the APIs available on the 8.x version. You can also goto the Swagger Interface for the device by logging to the MM and going to the url: https://<controller-ip>:4343/api

Please note that the port number 4343 should be open on the FW and/or allowed on the controller.

I will use the post function in postman with the username and password keys in the body of the put request to login, a successfull authentication will return a UIDARUBA which can be used as a token for all the subsequent GET/SET requests after the login attempt.

In the above example I have used collection variables to enter username and password as a variable to the post function. Postman also provides option to write test scripts to capture responses and validate the success/failure of the function. We also used this script to capture the value of UIDARUBA from the response and set it as a variable for subsequent functions.

The variables are saved as Collection variables:

I am running another request in the Postman Collection to create a logs.tar file on the Aruba Controller. The Post Params and body content requirement can be captured from the controller swagger interface.

Please set the body content format as JSON.

The final Post request would be to tftp tranfer the logs.tar.7z file from the flash: to the tftp Server.

The review of the MM audit-trail logs did confirmed the command pushed for generating the logs.tar file and the tftp transfer.

Happy Reading….

SSH Aruba MM/MD via Public Key Auth

SSH Aruba MM/MD via Public Key Auth

The support of certificate base login to the MM/MD provide a good security capability of the Aruba MM/MDs.

Aruba still don’t support importing the public key directly and thus your SSH public key can only be imported into the Aruba controller using an X509 certificate. Therefore we first need to create a certificate include you public and private key.

I would use openssl to create a public/private key pair and also to generate a final Self-Signed Cert for uploading to the Aruba Controller.

I would use a Window laptop and use putty for ssh.

Installing OpenSSL on Windows Machine:

Thanks to Shining Light Production for providing an installer version of OpenSSL for the Windows Machine:

https://slproweb.com/products/Win32OpenSSL.html

You can download the Installer (MSI) from their site and its pretty easy to Install.

Once installed modify the environmental variables of you Windows Machine to use it directly from any location.

Using OpenSSL to Generate Private Key and Cert:

Use the following command to generate the Private Key with the specified key length.

Use the following command to generate a Self Signed Cert using private key and add the required inputs as prompted.

OpenSSL Command CheatSheet: https://www.freecodecamp.org/news/openssl-command-cheatsheet-b441be1e8c4a/

Uploading the Certificate to Aruba Controller:

We need to upload the Certificate to the Aruba Controller as a Public Certificate, browse and upload the Certificate:

Adding Mgmt Account Associated to the Cert:

Create the mgmt account with required access and associate the Certificate to the mgmt-account.

Using Putty to Login to the Controller:

We need to associate the private key on the PC to login to the Controller. However Putty requires the key to be in a specific format else it would give error as follows:

We would download Puttygen to convert the Private key in the format as suited to Putty.

Open Puttygen and use the load option to load the previously created private key. Once loaded Save the private key in the .ppk format using the Save Private Key option, also better to add the keypassphrase during saving.

Now that the Private key is converted to correct format, load the private key again to putty and ssh to the Aruba Controller. Find the following on how/where to load the Private Key in Putty:

We would be prompted to username and the Passphrase that you set during the key import. Enter the username that we created on Aruba Controller and enter the passphrase set during the private key import and you should login fine.

More details on how to setup it up on the Aruba 6.x Architecture:

https://wlanimp.blogspot.com/2017/04/creating-aruba-ssh-login-keys-and.html

Happy Reading…..

Aruba DHCP Option 60

Aruba DHCP Option 60 (Vendor Class Identifier)

Almost all vendors implement the DHCP Option 60 RFC(2132) Vendor Class Identifier in their own way. The DHCP Option 60 is a string that the Access Point includes in the DHCP Discovery packet to the DHCP Server.

A DHCP server can be configured to filter on received option 60 string values and forward standard or vendor specific options (Option 43) in DHCP offer and acknowledgement packets.  Filtering using option 60 allows different types of devices that require vendor-specific information to co-exist in a common broadcast domain. (Having Cisco and Aruba AP in the same subnet, the DHCP Server should be configured with DHCP Option 43 and 60 for each Vendor).

If you do not specify an option 60 for some scope, the content of option 43 is returned to any DHCP client asking for an IP address in that subnet. In general we should try to define it in the DHCP scope as it makes sure that option 43 is returned only to APs and not other clients but it also depends upon the type of the DHCP server. For example Cisco IOS based DHCP scopes allow only one option 60 string (VCI) per scope , So you may not want to use it if you have different Vendor APs in the same subnet using IOS based DHCP.There is no such limitation on the Windows Server and hence the correct procedure is to define Option 60 for each Vendor.

The string value that is forwarded to the DHCP server is dependent on the Aruba Access Points mode.


 Aruba Access Points also requires specific option 60 values to be returned in DHCP offer and acknowledgement packets for vendor specific information to be considered. The expected option 60 value being dependent on the mode of the Access Points. If the expected option 60 value is not present in the DHCP offer or acknowledgement packet, any supplied vendor specific information is ignored. 

Vendor Specific Information (Option 43):

Aruba Access Points support vendor-specific information that can be provided in offer and acknowledgement packets. The type of vendor-specific information that is supported by an Aruba Access Point is dependent on the mode. For example Instant mode Access Points can be supplied with HTTP Proxy Server (Option 148) and/or (Option 43) AirWave Server information while Campus mode or Unified Access Points can be supplied Mobility Controller information. 

AirWave Server Discovery For IAP:

HTTP Proxy For IAP:

******Please note that both the username and password are forwarded to Instant mode Access Points in offers and acknowledgements in clear text. ******

The HTTP Proxy option can be used with Instant mode Access Points that are managed by AirWave or Central. When managed by AirWave, the HTTP Proxy option can be combined with the AirWave Server Discovery option. 

Controller Discovery For Campus/Unified AP:

Lets see the DHCP Scope Configuration for IAP and Campus/Unified APs.

Windows DHCP Server Config for Unified/Campus AP:

Windows DHCP Server Config for IAP AirWave:

Windows DHCP Server Config for IAP Http Proxy:

DHCP Server Config On Aruba OS Switch:

DHCP Server Config On Cisco Switch:

Happy Reading…..

SCP Service on Aruba Mobility Controllers

SCP Service on Aruba Mobility Controllers

The Aruba Mobility Controllers support the SCP Server feature, where you can enable SCP Service on the MMs and MDs. This feature helps to transfer files between MM and MDs without any external SCP Server requirement and also helps to transfer files to and from any device running SCP client.

The command to enable/disable the service:

(Test)[MDC] (config)#service scp
(Test)[MDC] (config)#no service scp

This feature however is not a full featured SCP support. Its only supports the native SCP protocol, SFTP/WinSCP protocols are not supported. If you try to connect to it via the WinSCP GUI interface it would not work, however you can use the SCP cli command to upload/download files to the Mobility Controllers.

If you have any SCP client installed on your device, you can use the Command line to download upload the file.

Following example where I am using the command line interface of my windows laptop to download the logs.tar file from the Aruba Controller. Here x.x.x.x is the controller ip, I need to type the root admin password when prompted before the transfer will start.

C:\Users\admin>scp admin@x.x.x.x:logs.tar.7z C:\Users\admin
The authenticity of host ‘x.x.x.x (x.x.x.x)’ can’t be established.
RSA key fingerprint is SHA256:kig0wBq0xYQKZsSi/C1zvTs9eGaDXj920VjuMLxdX38.
Are you sure you want to continue connecting (yes/no)?
Warning: Permanently added ‘x.x.x.x’ (RSA) to the list of known hosts.
admin@x.x.x.x’s password:
logs.tar.7z 100% 19MB 18.8MB/s 00:01

Similarly I can use the CLI command to upload a file to the Aruba Controller. In the following command I am upload a TEST.txt file to the Aruba Mobility Controller with IP x.x.x.x. I would be prompted for the admin password of the Controller.

C:\Users\admin>scp C:\Users\admin\TEST.txt admin@x.x.x.x:
admin@x.x.x.x’s password:
TEST.txt 100% 40 6.5KB/s 00:00

More on this feature:

https://www.arubanetworks.com/techdocs/ArubaOS_82_Web_Help/Content/ArubaFrameStyles/SCP/Secure_Copy_Protocol.htm

Happy Reading….

Moving a Client to specific UAC/MD on Aruba 8.x Cluster

Moving a Client to specific UAC/MD on Aruba 8.x Cluster

The previous post cover bucketmap and UAC computation concept of Aruba 8.x Architecture.

http://the-ethernets.com/2020/09/aruba-bucketmap-uac-computation-concept/

Many a times there are situation/requirement where we would like to have control on what MD, the APs and clients should connect. This might be needed for some validation test or other use cases.

The Cluster feature does allow option to disable loadbalancing for the APs, use ap-move command, this gives you control of pointing a specific AP to a specific controller via the LMS or static configuration. However there is no straight forward method to control the clients, the Cluster feature does not have an options to disable loadbalancing feature for the clients. Also there is no client-move command as available for the APs.

There is however a method via which you can define what UAC should a station/client index be assigned. Thus giving you control of defining the UAC for a specific client/station index.

******Please note this is not a recommended practice and should not be performed regularly. This command is also disruptive and would impact other clients as well********

This method moves the client from one UAC to another, but unfortunately, it changes the UAC and Standby UAC of all clients in the same bucket index, not a single client, because UACs and Standby UACs of clients follow the bucket index.

Following are the steps:

  1. Identify the bucket index / station index for your test client.

(Test)[MDC] #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35

The above command gives the bucket index / station index 178 for the client mac 5a:10:5e:5a21:c9 connected to the TEST SSID.

2. Identify the UAC ID assigned to the MD where you want to move the test Client.

(Test) [MDC] #show aaa cluster essid-all bucketmap
Bucket map for Test, Rcvd at : Tue Sep 22 08:41:14 2020
Item Value
—- —–
Essid Test
UAC0 10.17.10.10
UAC1 10.17.10.11

From the above you can see for the Test SSID, MD 10.17.10.10 is assigned ID of 0 and MD 10.17.10.11 is assigned ID of 1.

3. Identify the Cluster Leader.

From my experience I have noticed the cluster leader is assigned the UAC ID of 0, however it always better to confirm.

(Test) [MDC] #show lc-cluster group-membership
Cluster Enabled, Profile Name = “Test_Cluster”

peer 10.17.10.10 128 L2-Connected CONNECTED (Member, last HBT_RSP 75ms ago, RTD = 1.241 ms)
self 10.17.10.11 128 N/A CONNECTED (Leader)

4. From the Cluster Leader, assign the new UAC to the bucket index/station index.

(Test)[MDC] #cluster-debug bucketmap essid Test bucketindex 178 active 1 standby 0

In the above command we are assigning the bucket/station index to a new active UAC ID and Standby UAC ID. You can check the show user-table to validate the new UAC is pushed to the client.

Please note that above command has to be executed on the Cluster Leader.

******Please note this is not a recommended practice and should not be performed regularly. This command is also disruptive and would impact other clients as well********

Happy Reading….

Aruba bucketmap, UAC Computation Concept

Aruba bucketmap, UAC Computation Concept

The Aruba 8.x architecture introduced a new feature of Cluster. The Clustering is a combination of multiple managed devices (MDs) working together to provide high availability to all clients, ensuring service continuity and load-balancing feature.

The clustering feature provides :
Seamless Roaming
Client Stateful Switchover
AP and Client Loadbalancing

Cluster bucketmap/mapping table:

The Aruba Controller creates a mapping table called the bucketmap. The mapping table/bucketmap is table that provides the mapping of the station/client index to the UAC(User Anchor Controller). This table is pre-populated even before any client/user is connected to the Aruba AP.

The bucketmap is per ssid basis, each ssid has its own bucket map. The output below shows the two bucketmap for the SSID: Test and LAB_TEST

(Test) [MDC] #show aaa cluster essid-all bucketmap

Bucket map for Test, Rcvd at : Tue Sep 22 08:41:14 2020

Item Value
—- —–
Essid Test
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01

Bucket map for LAB_TEST, Rcvd at : Tue Sep 22 06:59:44 2020

Item Value
—- —–
Essid LAB_TEST
UAC0 10.17.10.10
UAC1 10.17.10.11
Active Map[0-31] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[32-63] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[64-95] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[96-127] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[128-159] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[160-191] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[192-223] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
Active Map[224-255] 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01

As you can see the bucket map include variables like: SSID, UAC. Thus this bucketmap would not change until change in cluster size or any new SSID added. We can pretty much say the bucketmap is permanent and this is what allows each client to have the same UAC wherever/to any AP it connect in the network.

Once the bucketmap is computed, the Cluster leader pushes the mapping table to all the APs.

Now that the AP has this mapping table, the AP uses this to decide what should be the UAC for the client that has connected to it. When a user connects to an AP, the AP runs the hashing algorithm on the user mac address ( the algorithm uses the last 3 bytes of the client mac address) and spits out a Station index. This station index is a value between 0 – 255 and is referred against the mapping table/bucketmap to decide the UAC for the client.

Following diagram gives a brief of the process.

In the output below you see the details for the user with mac address: 20:4c:03:62:aa:d3 and IP address 10.17.11.90.

The station/client index computed for the client is: 27. The station index was referred against the bucketmap and identified that 10.17.10.10 was the UAC for this station/client.

(Test) [MDC] #show aaa cluster essid LAB_TEST users

Active Users for ESSID : LAB_TEST

BUCKET MAC IP Active UAC Standby UAC
—— — — ———- ———–
27 20:4c:03:62:aa:d3 10.17.11.90 10.17.10.10 10.17.10.11

You can also use the following command if you are aware of the client mac address and ssid name the client is connected.

(Test)[MDC] #cluster-debug calc-sta-uac 5a:10:5e:5a:21:c9 LAB_TEST
STA Index:178
STA A-UAC:10.1.2.36
STA S-UAC:10.1.2.35

Thus to summarised as explained by David Westcott in one of the Airheads forum:

https://community.arubanetworks.com/t5/Wireless-Access/UAC-Assignment-After-Client-Leaves-User-Table/td-p/536405

When the cluster is created, the cluster leader builds a bucket map for each ESSID that is part of the cluster. The cluster leader takes the total number of cluster members and assigns a number to each one, starting with 00, 01, 02… for however many cluster MCs there are. The cluster leader then creates a bucket map for one of the ESSIDS and distributes the numbers across the bucket map. Think of the bucket map as simply two lookup tables for each ESSID with 256 positions in each lookup table. The first tables is the active or UAC pointers and the 2nd table is the standby or S-UAC pointers. (This is done for each ESSID)

When the maps are created for each ESSID, they are sent to the APs. This map will be the same, as long as you do not add an MC or remove an MC from the cluster. So the APs hold the maps. When a user tries to connect to an ESSID, the AP performs a hash on the extended unique identifier (last 6 hex digits in the MAC address) of the user MAC address, and generates an ASCII number between 0-255.

Once the AP has generated the hash for the client, it simply uses the ASCII hash value and looks up that position in both the active and standby tables in the bucket map, finds the controller number 00,01,.. and cross references it to the IP address of the MC and establishes the UAC and S-UAC tunnels for the user.

Happy Reading….

iPERF Throughput Test

iPERF Throughput Test

Iperf is a handy tool to measure the bandwidth and the quality of a network link. It is a commonly used network testing tool that can create Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) data streams and measure the throughput of a network that is carrying them.

Iperf allows the users to vary various parameters that can be used for testing the network, or alternatively for optimizing and tuning a network. Iperf has a client and server functionality, and can measure the throughput between the two ends, either unidirectionally or bi-directionally.

Iperf can be installed very easily on any Linux or Microsoft Windows system, where one host can be configured as a client, the other one as server.

Setup required for running the iperf test:

1. Download the iperf setup, you can download it from: https://iperf.fr/
2. Copy the setup file on the two hosts you would be using to perform the test.
3. Set one host in the server mode and the other in the client mode with the following syntax:

To set the host in server mode use the command : iperf -s

C:\IOS Images\iperf-2.0.5-2-win32>iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
————————————————————

To set the client in client mode use the command : iperf -c <server ip address>

C:\IOS Images\iperf-2.0.5-2-win32>iperf -c 192.168.1.5      // Where 192.168.1.5 is server ip address.

The other parameters available in iperf are:

C:\IOS Images\iperf-2.0.5-2-win32>iperf –helpUsage: iperf [-s|-c host] [options]       iperf [-h|–help] [-v|–version]

Client/Server:
-f, –format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, –interval # seconds between periodic bandwidth reports
-l, –len #[KM] length of buffer to read or write (default 8 KB)
-m, –print_mss print TCP maximum segment size (MTU – TCP/IP header)
-o, –output output the report or error message to this specified file
-p, –port # server port to listen on/connect to
-u, –udp use UDP rather than TCP
-w, –window #[KM] TCP window size (socket buffer size)
-B, –bind bind to , an interface or multicast address
-C, –compatibility for use with older versions does not sent extra msgs
-M, –mss # set TCP maximum segment size (MTU – 40 bytes)
-N, –nodelay set TCP no delay, disabling Nagle’s Algorithm
-V, –IPv6Version Set the domain to IPv6

Server specific:
-s, –server run in server mode
-U, –single_udp run in single threaded UDP mode
-D, –daemon run the server as a daemon

Client specific:
-b, –bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, –client run in client mode, connecting to
-d, –dualtest Do a bidirectional test simultaneously
-n, –num #[KM] number of bytes to transmit (instead of -t)
-r, –tradeoff Do a bidirectional test individually
-t, –time # time in seconds to transmit for (default 10 secs)
-F, –fileinput input the data to be transmitted from a file
-I, –stdin input the data to be transmitted from stdin
-L, –listenport # port to receive bidirectional tests back on
-P, –parallel # number of parallel client threads to run
-T, –ttl # time-to-live, for multicast (default 1)
-Z, –linux-congestion set TCP congestion control algorithm (Linux only)

Miscellaneous:
-x, –reportexclude [CDMSV] exclude C(connection) D(data) M(multicast) S(settings) V(server) reports
-y, –reportstyle C report as a Comma-Separated Values
-h, –help print this message and quit
-v, –version print version information and quit

[KM] Indicates options that support a K or M suffix for kilo- or mega-

Use the syntax with some additional parameters ” iperf.exe – c -P 10 -w 1000k ” ( -P refers to the number of parallel TCP streams and –w referes to the TCP window size )

Happy Reading….

Creating Chained Certificate

Creating Chained Certificate

Many a times we see that the CA (Third Party Certificate Authority) does not provide a chained cert rather they provide  a signed Server Cert and might provide us the Intermediate CA cert and the Root CA cert separately.

In couple of cases they just provide you a signed Server Cert and might expect you to download the Intermediate cert and the Root cert and chain the final cert if required and use it. Many vendor devices do not support an unchained Server cert and they expect you to get a chained Server cert  before it could uploaded to the device.

Lets see how we can generate a chained cert from an unchained certificate. I’ll use the following server cert as an example.

The above cert is a Server cert issue by “Go Daddy” well known CA. However the certificate is not  chained, if you open the certificate in notepad you’ll find that it is just a Server cert.

For generating a chained cert you need to append the Server cert with the Intermediate CA cert and the Root CA cert. In our case “Go Daddy Secure Certificate Authority” is the Intermediate CA and “Go Daddy Class 2 Certificate Authority” is the Root CA.

The way you need to append the file is, you need to keep the Server cert on top, followed by Intermediate CA cert and then the Root CA cert i.e it is just the opposite as it is show in the Certificate Path on the server Cert. Open all the certificates in notepad, also open a blank notepad and copy paste the Server cert, followed by Intermediate cert and then the Root cert and save this as a final cert which should be ready to be uploaded to the device.

—–BEGIN CERTIFICATE—–
Server Cert
—–END CERTIFICATE———-BEGIN CERTIFICATE—–
Intermediate CA Cert
—–END CERTIFICATE———-BEGIN CERTIFICATE—–
Root CA Cert
—–END CERTIFICATE—–

All the certificates on windows 7 are stored in the windows register and not in any specific folder. You can view the certificates using the cert manager (Type certmgr.msc and it will bring up the following window).

For Mac users the certificates are stored in Keychain Access (In the Finder, open Utilities and then open Keychain Access.)
These are the repositories where all the certificates are stored and referenced to check if any certificate is valid or not i.e the Certificate Authority is a Trusted Root CA or not.
There are chances that the Intermediate CA certificate may have expired which will cause the entire certificate to go invalid (untrusted).
In a recent incident DigiCert’s Intermediate Certificate expired, which caused multiple users to get the untrusted certificate error.

The expired certificate in question was the “DigiCert High Assurance EV Root CA” [Expiration July 26, 2014] certificate. This temporary intermediate certificate was used in years past as part of a compatibility chain for older devices.The problem was related to the locally installed legacy intermediate certificate that was no longer used and no longer required for the certificate installation. This certificate was not been used for over three years and was unnecessary for installations, however the device having issues were not updated. The users affected appear to have the expired intermediate in the ‘login’ keychain or stored locally on their server or in have the expired intermediate installed on a backend server or application.

DigiCert fixed the issue for the customer’s by getting the old cert removed from their machines and new valid Intermediate cert updated on these devices.

How to create the chained cert when the Root CA cert and Intermediate CA cert is not provided the CA:

Usually your CA will provide you the Intermediate CA cert and the Root CA cert or the steps to get them from their Website. However if this is not the case for you and if these are some well known CA’s we should already have their Intermediate and Root cert on your laptop in the registry or the Keychain Access. Lets see how we can get the Intermediate and the Root CA certificate.

Click on the Server cert to open it. Goto the “Certificate path” click on the Intermediate Certificate for your test certificate it is “Go Daddy Secure Certificate Authority”

Click on View Certificate on the lower right corner, which will open up the Intermediate CA cert. Now we want to export this cert so that we can use the cert for chaining. Goto the Details tab for the certificate.

Click on Copy to File, which should open up the export Wizard.

Click Next > Choose the format : ” Base-64 encoded x.59″

Click on Next > Browse and give a name to the file. (Remember this is the Intermediate CA cert so save it some where on your laptop and give it a name like intermediatecert). Click Next and Finish. This will successfully export the Intermediate CA cert on you desktop, now repeat the same process to get the Root CA cert exported on your desktop you click on the Root CA cert in the server or the Intermediate CA cert.

Once you have successfully exported both the Intermediate and the Root CA cert you can open them in notepad and append the Server cert as we already discussed initially.

Added information:

The certificates are stored in the registry at: HKLM/Software/Microsoft/SystemCertificates

Personal certificates, or other certificates specific to the logged in user are at: HKCU/Software/Microsoft/SystemCertificates

They are stored as binary blobs, so they need to be decoded, and the MMC plugin is a good way to do this.

Happy Reading….

SNMP walk/get from the the Cisco IOS CLI

SNMP walk/get from the the Cisco IOS CLI

In my previous post I have discussed about how to do a SNMP walk from the MIB browser or from the Cisco Prime Infrastructure.

http://the-ethernets.com/2020/09/using-mib-browser-for-snmp-walk-query/

http://the-ethernets.com/2020/09/snmpwalk-from-cisco-prime-infrastructure/

 

However many a times you would like to test if the device is responding to a specific MIB/OID or not, while you don’t have access to the PI or you cannot connect to the device via MIB browser.

Interestingly the Cisco IOS device does support querying the device itself for a specific OID using SNMP under the tclsh (TCL shell).

Enable the snmp server manager on the device using the command:

 

Router(config)# snmp-server manager

Router#tclsh
Router(tcl)#snmp_getnext TEST 1.3.6.1.4.1.9.9.13.1.3 // here TEST is the community {<obj oid=’ciscoEnvMonTemperatureStatusEntry.2.1′ val=’chassis’/>}

More on this is available on the following link:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/configuration/15-mt/ios-tcl-15-mt-book/nm-script-tcl.html#GUID-C3694BC4-2CD9-4873-843B-3CDA5B4FCC39

Happy Reading…..