Configuring access switches in an enterprise may involve deploying
a bunch of identical settings to a load of devices, this kind of work is time
consuming and not to say BORING AS HELL!

In case you are working with Cisco or Juniper as the vendor
of the devices there is a way of deploying the configuration automatically by
using a DHCP+TFTP server.

The process is very simple, at their default configuration a
switch will try to receive an IP via DHCP at this moment we can use DHCP in order
to point it to the tftp server with a predefined configuration file, after
getting this file the device will load it automatically

I'll start with Cisco being the simplest, in case you have a Cisco router and a Cisco switch you can use the router as both the DHCP and the
TFTP server, to do so:

Enable TFTP server function of the router (don’t forget to
put the file in the local flash of the Router)

tftp-server flash: network-confg

In case there is no Router, the Router doesn't support the TFTP-Server function or you just have a dedicated servers
you want to use

All you need is to use all you
need is to is to configure the pool with option 150 pointing to the TFTP server
and put a config file on the TFTP root folder.

Note that Cisco will first
load a file with one of the following names: network-confg\ router-confg\
ciscortr.cfg \ cisconet.cfg

I suggest including "no
service config" in the base configuration file, otherwise as the configuration
is loaded the device will try to load a new file with its' new host-name every
time it renews the DHCP lease.

Now let's move to another vendor – Juniper, in this case
it's a bit more complicated as we need a couple more DHCP options.

In Juniper's case the process is very similar, with the difference
that the switch includes a software upgrade as part of the process so we need
more free space on the tftp server, for this example I used Red Hat Linux for
both the DHCP and the TFTP, here is the configuration the DHCP side, first of
all DHCPD has to be ISC 4 and above.

Edit /etc/dhcp/dhcpd.conf

Under "#
Define Custom Options"

Configure
new option group, in my case named Juniper

option space JUNIPER; #option;

configure
all the suboptions to be "text" type

option JUNIPER.config-file-name
code 1 = text;

option JUNIPER.image-file-type code 2 = text;

option JUNIPER.transfer-mode code 3 = text;

option JUNIPER.image-file-name code 00= text;

option JUNIPER.alt-image-file-name code 4= text;

add options 43 and 150 to the group

option JUNIPER -encapsulation code 43 = encapsulate JUNIPER;

option option-150 code 150 = ip-address;

*Note the type of option 150 is IP.

After we configured the group we can use it in the scope
itself, in the same file add the scope configuration

subnet x.x.x.0 netmask 255.255.255.0

option
routers <Default Gateway IP>;

option
host-name
"default";

host-name
option will change the hostname of the switch, note that the switch will only
load the configuration file with the name of its hostname.

option
subnet-mask
255.255.255.0;

option
domain-search "networklabs.info";

option
domain-name-servers <DNS SERVER IP>;

option
ntp-servers
<NTP SERVER IP>;

option
option-150
<TFTP SERVER IP>;

option
tftp-server-name "<TFTP
SERVER IP/HOSTNAME>";

option JUNIPER.image-file-name
"/<NEW JUNOS VERSION FOR THE SWITCH TO LOAD>";

When a device is activated with license that include App Mode the root user and all access to the BASH is being blocked.

In case the activation of the app mode was not wanted we need to install a different license without this feature and modify the DB to disable this mode, to do so just run the following command after installing the new key :

(tmos)# modify /sys db systemauth.disablerootlogin value false

in case a key is yet to be changed you'll get an error :

01070356:3: Root Account feature not licensed.

To better secure the device it is recomended to keep it in this mode.
Enable this mode by running:

Here is a nice feature you can use on a Cisco device to make the usage easier in case of a console server or just for limiting access for an experienced user - We can create a menu with pre-configured commands \ actions.

Here is a sort of "Best practices guide" for a Cluster configuration on F5's Big-IP devices, I will refer to the configuration of two devices but same applyed to a larger cluster.
First of all we need to make sure

I like to create a more proactive configuration by adding a pool which consists of a couple of servers as the representation of the LAN and the ISP \ FW as the representation of the WAN, so as long as this pool is active we have both LAN and WAN connectivity from the device and if the pool fails F5 lost WAN\LAN access so we need to failover.

Then add the pool as a trigger for a failover - System ›› High Availability

The concept of the ssl offloading is very simple, we perform the encryption before reaching the end server,in other words let's say we have a Data Center with 50 Web servers, we want to make the data more secure by implementing SSL encryption on our HTTP data, at this point we can configure each server to work with https OR we can add a device that adds the SSL on an outgoing packet and removes it from the once coming back, that way our traffic is secured and we save on server resources.before getting to the configuration part i want to spend a moment on the CA-Bundle or also known as intermediate Certificates .. There are some CA's out there that in order to use them we have to append an Intermediate certificate to the Certificate we have, the intermediate is sort of a reference of our CA pointing it to the root that will verify it, in other words it's the certificate of the CA that authorized our certificate.for example some browsers will not have the root of Go-daddy even though they're CA is well known and authorized so in case a website using one of there certificates (but no intermediate is installed) will be accessed by and old browser it will show the certificate is not verified and we'll have an error message accessing.Using the intermediate in the F5 is very simple, all we need to do is import it to the device and append it in the client profile as "Chain Certificate"

Importing the Certificate to the device:System > File Management > SSL Certificate List > ImportWe'll group the intermediate to the certificate and the key using a ProfileLocal Traffic > Profiles > SSL > ClientName the Profile mark Certificate, Key and ChainCertificate is the certificate we just loadedkey is the private key associated to the certificate, in case we uploaded the certificate that includes the key (for example a 'p12') choose the certificateand the Chain is the intermediate certificate of our CA

Now all we have to do is apply the Profile on the wanted traffic by adding it to the appropriate virtual serverLocal Traffic > Virtual Server

Basic config, Name IP and port

Just need to make sure we choose an HTTP profile and the SSL profile we have configured earlier.

Don't forget to point the Virtual server to the pool you need,other than that we're all done.
Hope this post was helpful, If it was please consider a donation:
BTC Address: 1CnyMpjd1RntRDxSus2hu2aDMyzL4Kj29N
LTC Address: LUqrKbzGihTU2GEnL3EwsuuLHCsxCJMdtR

I would like to share a case I had involving MacSec over a layer 3 link.The equipment was: 2 Cisco Switches (3750X), Cisco 2821 Router, Juniper J4350 Router.Objective: establish MacSec between the Switches.First of all MacSec will not work on layer 3, to make it work we need to emulate layer 1 between the switches, I did this VIA MPLS (Ethernet over MPLS).

A quick tip on IPv6 support in a Cisco 3560 Switch, unlike other devices (such as the 3750) the default configuration of the 3560 switch has all IPv6 functionality disabled, In order to enable the IPv6 on this Catalyst all we need to do is apply the correct template on the devicethis can be achieved by running the following command from Global config mode