Where Packets can be made to stand up and dance.
The image above shows a link aggregation group between two switches. The reason we use Link Aggregation Groups (LAGs) are they allow you to combine multiple network physical connections to make a single higher load sharing bandwidth path thus increase the throughput beyond what a single connection could support, and also to provide redundancy incase one of the links should fail.
You can read on how to configure LAG’s on Ruckus Switches here:
Ruckus : Configure Link Aggregation Groups
This is how to build a Link Aggregation Group on the Ruckus 7150. It is slightly different on the 7250’s.
tpwsw1# conf t
Configure the Link Aggregation Group. There are multiple LAG types and they must match on both sides of the lag, other vendors may use different names for the same thing here are the common ones:
| Ruckus LAG Types | Other Vendor Types |
| Static | On |
| Dyanmic | Active |
Configure a static LAG.
tpwsw1(config)# lag <name-of-the-lag> static id 1
Configure a dynamic LAG.
tpwsw1(config)# lag <name-of-the-lag> dynamic id 1
The LAG ID can be automatically generated and assigned to a LAG using the auto option.
tpwsw1(config)# lag <name-of-the-lag> dynamic id auto
The Link Aggregation Group IDs are unique for each LAG on the switch. The LAG ID can’t be assigned to more than one LAG. If a LAG ID is already used, the CLI will reject the new LAG configuration and display an error message that suggests the next available LAG ID that can be used.
Once the LAG is built you have to add ports to the LAG.
tpwsw1(config-lag-<name-of-the-lag>)# ports ethernet 1/2/7 ethernet 1/2/8
I am home! I have been travelling for work for the best part of the past 5 weeks. I was in Boston doing a network refresh the week before Easter, which included replacing all the network cables, installing new Palo Alto Firewalls and removing Cisco ASA’s. I also removed all Cisco Switches and installed a new stack of Ruckus 7250, replace the core switches with 2 new Arista’s. I then came home for 2 days and I left again for Singapore for 3 weeks. I was in Singapore integrating a new company we bought into our network, this was a team effort as we had other sites to bring online within 48 hours. Copenhagen and a small site in Kaohsiung, Taiwan. I have learned a lot over the past 2 month. I have some articles to write on what I have learned but for now, I just wanted to give a quick update. Here is some cable porn from the Boston Network Refresh.
Before:
After:
I have recently been setting up some Arista switches for a network refresh at our Boston site.
MLAG is short for Multi Chassis Link Aggregation and it allows more than 1 switch usually 2, to act like one logical switch which can allow you to just manage one switch instead of multiple. It also helps with redundancy and diversify paths. Its an awesome technology. Here is the basic MLAG Topology:
1. Create Port Channel For Peer Links
I am using 2 Arista DCS-7150S-24-R switches with 2 10Gb Ethernet as our MLAG peer links. On each switch we will create a port channel 1000
tpwsw1# config t tpwsw1(conf)#interface e23-24 tpwsw1(config-if-Et23-24)# channel-group 1000 mode active tpwsw1(config-if-Et23-24)# interface port-channel 1000 tpwsw1(config-if-Po1000)# switchport mode trunk
2. Create a VLAN for Peer MLAG Communication
You need to create a separate VLAN for MLAG communication and assign it the mlag-peer trunk group and disable spanning-tree on the VLAN. This step is done on both switches.
tpwsw1(conf)#vlan 4094 tpwsw1(config-vlan-4094)# trunk group mlag-peer tpwsw1(config-vlan-4094)# interface port-channel 1000 tpwsw1(config-if-Po1000)# switchport trunk group mlag-peer tpwsw1(config-if-Po1000)# exit tpwsw1(conf)#no spanning-tree vlan 4094
tpwsw2(conf)#vlan 4094 tpwsw2(config-vlan-4094)# trunk group mlag-peer tpwsw2(config-vlan-4094)# interface port-channel 1000 tpwsw2(config-if-Po1000)# switchport trunk group mlag-peer tpwsw2(config-if-Po1000)# exit tpwsw2(conf)#no spanning-tree vlan 4094
3. Set an IP on each Switch
On VLAN 4094 that was created above, we need to assign it an IP so each switch can communicate over layer 3 with each other.
tpwsw1(conf)#int vlan 4094 tpwsw1(config-if-Vl4094)# ip address 1.1.1.1/30
tpwsw2(conf)#int vlan 4094 tpwsw2(config-if-Vl4094)# ip address 1.1.1.2/30
***Send some pings to confirm basic connectivity
4. Configure MLAG peering for each switch
tpwsw1(config)#mlag tpwsw1(config-mlag)#local-interface vlan 4094 tpwsw1(config-mlag)#peer-address 1.1.1.2 tpwsw1(config-mlag)#peer-link port-channel 1000 tpwsw1(config-mlag)#domain-id mlagDOMAIN
tpwsw2(config)#mlag tpwsw2(config-mlag)#local-interface vlan 4094 tpwsw2(config-mlag)#peer-address 1.1.1.1 tpwsw2(config-mlag)#peer-link port-channel 1000 tpwsw2(config-mlag)#domain-id mlagDOMAIN
5. Verify MLAG Domain
On each switch, do a #show mlag to see if MLAG is up and running and you can confirm this by seeing State:Active and peer-link status: UP and locl-int status:UP
tpwsw1(config-mlag)#show mlag MLAG Configuration: domain-id : mlagDOMAIN local-interface : Vlan4094 peer-address : 1.1.1.2 peer-link : Port-Channel1000 MLAG Status: state : Active negotiation status : Connected peer-link status : Up local-int status : Up system-id : 02:1c:73:1e:97:dc MLAG Ports: Disabled : 0 Configured : 0 Inactive : 0 Active-partial : 0 Active-full : 0
tpwsw2(config-mlag)#show mlag MLAG Configuration: domain-id : mlagDOMAIN local-interface : Vlan4094 peer-address : 1.1.1.1 peer-link : Port-Channel1000 MLAG Status: state : Active negotiation status : Connected peer-link status : Up local-int status : Up system-id : 02:1c:73:1e:97:dc MLAG Ports: Disabled : 0 Configured : 0 Inactive : 0 Active-partial : 0 Active-full : 0
You can read more about MLAG here – https://www.arista.com/en/products/multi-chassis-link-aggregation-mlag
A great book to read about Arista is called Arista Warrior. I loved it. You can buy it here:
Today, I officially start the CCNP Route Switch Course.
I have purchased the following book set, I have provided a link if you wish to purchase them:
I am also using Chris Bryant’s Video Udemy Course (Who helped me pass the CCNA R&S and Security, very thorough video series) and I will try and get his books. I have provided a link if you wish to purchase them :
https://www.udemy.com/ccnpallinone/
I plan to have passed the CCNP Switch by July, because I have some pretty big work trips coming up and I know that is going to get in the way a little. However the 18hr flight to Singapore, I should be able to get through a power of reading and labs 🙂
I will start to blog on my progress and things I am learning.
Wish me Luck!
Continuing my theme from last week with the Ruckus ICX Switches. Here is how to add a switch to a stack hot.
Show existing Stack
#Stack secure-setup
Which will discover the new device. Election will run and reboot the newly Stacked Units.
#show stack
‘Wr mem’ on the master switch
As you may know Brocade ICX switching line was purchased by Ruckus Networks. I have been messing with the Ruckus ICX 7250. Here is the steps to stack them using their Twin-AX cables.
Firstly stacking ICX switches has to be done on 10G Ports, so firstly you have to verify you have the correct license for those ports with the command:
# show license
As you can see from the output there 2 licensed 10G ports and that is the minimum you need to stack.
Doing a ‘show run’ confirms that 1/2/1 and 1/2/3 are set to 10G because they DO NOT show up in show run.
Once the 10G ports have been confirmed you can stack them. Here is how.
I have included a link where you can see the cost or purchase these devices:
Here is a picture of a Twin-AX Cable
I have included a link where you can see the cost or purchase these devices:
Once the Cables are connected you only have to enable stacking on one switch
Now search for the other devices connected to the stack and confirm you want them part of the election process, then all the non master switches will reboot.
Once the members have rebooted you can verify the stack us up and also shows the connections between the stack ports
Don’t forget to Save
#wr mem
When you configure a Cisco device, you need to use a console cable and connect directly to the system to access it. Follow the SSH setup below, will enable SSH access to your Cisco devices, since SSH is not enabled by default. Once you enable SSH, you can then access it remotely using SecureCRT or any other SSH client.
Set hostname and domain-name
The hostname has to have a hostname and domain-name.
switch# config t switch(config)# hostname tpw-switch tpw-switch(config)# ip domain-name thepacketwizard.com
Setup Management IP
In the following example, the management ip address will be set to 10.100.101.2 in the 101 VLAN. The default gateway points to the firewall, which is 10.100.101.1
tpw-switch# ip default-gateway 10.100.101.1 tpw-switch# interface vlan 101 tpw-switch(config-if)# ip address 10.100.101.2 255.255.255.0
Generate the RSA Keys
The switch or router should have RSA keys that it will use during the SSH process. So, generate these using crypto command as shown below.
tpw-switch(config)# crypto key generate rsa The name for the keys will be: tpw-switch.thepacketwizard.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
Setup the Line VTY configurations
Setup the following line vty configuration, where input transport is set to SSH only. Set the login to local, and password to 7, and make sure Telnet is not enabled:
tpw-switch# line vty 0 4 tpw-switch(config-line)# transport input ssh tpw-switch(config-line)# login local tpw-switch(config-line)# password 7 tpw-switch(config-line)# exit
If you have not set the console line yet, use the following:
tpw-switch# line console 0 tpw-switch(config-line)# logging synchronous tpw-switch(config-line)# login local
Create the username password
If you don’t have an username created already, here is how:
tpw-switch# config t Enter configuration commands, one per line. End with CNTL/Z. tpw-switch(config)# username thepacketwizard password tpwpassword123 tpw-switch# enable secret tpwenablepassword
Make sure the password-encryption service is turned-on, which will encrypt the password, and when you do “show run”, you’ll see only the encrypted password and not clear-text password.
tpw-switch# service password-encryption
Verify SSH access
From the switch, if you do ‘show ip ssh’, it will confirm that the SSH is enabled on this Cisco device.
tpw-switch# show ip ssh SSH Enabled - version 1.99 Authentication timeout: 120 secs; Authentication retries: 3
After the above configurations, login from a remote machine to verify that you can ssh to this cisco switch.
In the example, 10.100.101.2 is the management ip-address of the switch.
TPW-Remote-Computer# ssh 10.100.101.2 login as: thepacketwizard Using keyboard-interactive authentication. Password: tpw-switch>en Password: tpw-switch#
You are now setup and logged in on SSH!
To read more on SSH visit: https://en.wikipedia.org/wiki/Secure_Shell
Over the last 3 weeks since the Christmas and New Year Holidays, I have been upgrading all of our firewalls globally, many of them are an High Availability Pair. This means they are redundant and being redundant allows me to upgrade them individually while the site stays full up and functional.
The instructions for upgrading an HA pair are recommended because:
Before you Begin :
Take backup of the configuration as well as Tech Support from both HA Peers. Give proper names to each file, here is how:
Device > Setup > Operations > Save Named Configuration Snapshot
Device > Setup > Operations > Export Named configuration Snapshot
Device > Setup > Operations > Export Device State (If device managed from panorama
Device > Support > Generate Tech Support File, and then download it. (Might be required if any issues)
(Optional but recommended) Disable preemption on High Availability settings to avoid the possibility of unwanted failovers. Disabling preempt configuration change must be committed on both peers. Likewise, once completed, re-enabling must be committed on both peers.
To disable preempt, go to
Device > High Availability > Election Settings and uncheck Preemptive.
Then, perform a commit.
If upgrade is between major versions (4.1 -> 5.0 OR 5.0-> 6.0), it is advisable to disable TCP-Reject-Non-SYN, so that sessions can failover even when they are not in sync. : Do this on both Firewalls from the CLI:
# set deviceconfig setting session tcp-reject-non-syn no # commit
(Optional but recommended) Arrange for Out-of-Band access (Console access) to the firewall if possible. This is again to help recover from any unexpected situation where we are unable to login to the firewall. If you have a Terminal Server awesome, if not a simple Cell Phone tethered to a Laptop with RDP is also fine.
The Upgrade Process
Suspend Backup Device
From the CLI
> request high-availability state suspend
From the GUI
Go to Device > High Availability > Operational Commands > Suspend local device.
Install the new PAN-OS on the suspended device
Device > Software > Install
Reboot the device to complete the install.
When the upgraded device is rebooted, check the dashboard to check the version, wait for all the interfaces to come backup green.
If the device is still in suspended state make it functional again
From the CLI
> request high-availability state functional
From the GUI
Go to Device > High Availability > Operational Commands > Make Local Device Functional
Repeat steps on other firewall.
Suspend Primary Device
From CLI
> request high-availability state suspend
From the GUI
Go to Device > High Availability > Operational Commands > Suspend local device.
*The Backup Firewall will become Active – it does take 30-45 seconds so don’t panic
Install the new PAN-OS on the suspended device:
Device > Software > Install
Reboot the device to complete the install.
When the upgraded device is rebooted, check the dashboard to check the version, wait for all the interfaces to come backup green.
If the device is still in suspended state make it functional again
From the CLI
> request high-availability state functional
From the GUI
Go to Device > High Availability > Operational Commands > Make Local Device Functional
To Get Primary Back to Primary by suspending the backup (current active) firewall (The Original Backup Firewall)
From the GUI,
Go to Device > High Availability > Operational Commands > Suspend local device.
Once the Primary became active again, enable the suspended backup firewall
Enable TCP-Reject-Non-SYN, so that sessions can failover even when they are not in sync. : (Do this on both Firewalls)
# set deviceconfig setting session tcp-reject-non-syn yes # commit
Re-Enable preempt configuration change must be committed on both peers. To re-enable preempt, go to Device > High Availability > Election Settings and uncheck Preemptive. Then, perform a commit.
How to Downgrade
If an issue occurs on the new version and a downgrade is necessary:
To revert to the previous PAN-OS screen, run the following CLI command:
# debug swm revert
This causes the firewall to boot from the partition in use prior to the upgrade. Nothing will be uninstalled and no configuration change will be made.
However please be aware while running this command –
After rebooting from a SWM revert, the configuration active at the time before upgrade will be loaded with the activation of the previous partion. Any configuration changes made after upgrade will not be accounted for and will need to be manually recovered by loading the latest configuration version and committing the changes.
How to determine the proper MTU size with ICMP pings
To find the proper MTU size, you have to run a special ping to the destination address. This is usually the gateway, local server or an IP address domain name internet (e.g. thepacketwizard.com). You probably want to start around 1800 and move down 10 each time until you get to a ping reply. Once you have a ping reply start moving backup by 2-5 bits to get to the fragmented packet size. Take that value and add 28 to the value to account for the various TCP/IP headers. E.g. let’s say that 1452 was the proper packet size (where you first got an ICMP reply to your ping). The actual MTU size would be 1480, which is the optimum for the network we’re working with. Header size varies depending what the packet is traversing.
1500 Standard MTU
– 20 IP Header
– 24 GRE Encaps.
– 52 IPSec Encap.
– 8 PPPoE
– 20 TCP Header
Windows
ping (host) (-f) (-l (packet size)) An example would be: ping thepacketwizard.com -f -l 1800 (result = "Packet needs to be fragmented but DF set.") ping thepacketwizard.com -f -l 1472 (result = reply)
The options used are:
Linux
ping (-M do) (-s (packet size)) (host) An example would be: ping thepacketwizard.com -M do -s 1800 (result = "Frag needed and DF set" or "message too long") ping thepacketwizard.com -M do -s 1472 (result = reply)
The options used are:
Mac
ping (-D) (-s (packet size)) (host) An example would be: ping thepacketwizard.com -D -s 1800 (result = "sendto: Message too long") ping thepacketwizard.com -D -s 1462 (result = reply)
The options used are:
There is a lot to know about MTU check it out on Wikipedia : Wikipedia – MTU
