Dt00xte220en 17

OMNISWITCH LAN - R8
BOOTCAMP - EDITION 17
PARTICIPANT'S GUIDE
The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE.
Proprietary Ownership Declaration
I agree not to copy, produce, reproduce, transfer, distribute, decode and/or modify any
ALE material (including any and all documentation, manuals, software presentation,
student book and software files) made available and/or used as part of the ALE training.
I acknowledge that sharing of any kind of courseware and media used are strictly forbidden
without approval from ALE Training Services.
I represent and warrant that I will not use or not permit to use the courseware and\or
educational tools supplied by ALE to provide trainings in a private capacity or for my
employer or any third party.
I also acknowledge and agree that ALE owns and reserves all copyright in and all other
intellectual property rights relating to the ALE training material (including courseware and
all associated documentation) provided during the training.
I understand that any breach or threat of breach of the above shall entitle ALE to injunctive
and other appropriate equitable relief (without the necessity of proving actual damages),
in addition to whatever remedies ALE may have at law.
Furthermore, I acknowledge and agree that ALE will be entitled to cancel immediately any
and all of my Certifications in case of any breach of the above.
Maintenance – eBook
The eBook is available on the Knowledge Hub training platform. Internet access is required
to download the eBook.
Participants should be informed that they must bring their laptop for the classroom or
virtual session.
In case of issue for downloading the eBook, the user can open a ticket with the ALE
Welcome Center for assistance.
ALE technical support will be provided on an "AS IS" and "AS AVAILABLE" basis without
warranty of any kind.
AOS OmniSwitch LAN
Bootcamp
DT00XTE220EN
Agenda
1
Topics
Administration – Class schedule
Course agenda
Your opinion counts!
Reach the session evaluation
2
Administration – Class schedule
Standard class hours Break Badges for participants Internet access

5 days 9:00 AM to 5:00 PM Lunch 12:00 to 1:00 PM Access to the classroom & the
restaurant
Morning & Afternoon 15 Min
3
Agenda
Day 1
• Course introduction • Virtual Chassis
‐ Training course agenda & Access to remote lab ‐ Overview & Lab: Virtual chassis (6360)
• OmniSwitch R8 - Portfolio Description • VLANs Management

‐ Overview ‐Overview & Labs : VLAN
• AOS OmniSwitch Management • Basic Switch Management & Diagnostic

‐ Log into the switch ‐ Overview& Lab: Switch maintenance and
‐ Managing Files/Directories Diagnostics tools
‐ Labs :
‐ Working/Running/Certified Directory
• Power over Ethernet (PoE)
4 ‐ Remote Switch Access
‐Overview
Agenda
Day 2
• Multiple VLAN Registration Protocol
• Link Aggregation Groups ‐ Overview
‐ Overview ‐ Lab : MVRP
‐ Lab : Link Aggregation and 802.1Q
• AOS Network security
• Spanning Tree Protocole (STP) ‐ Overview
‐ Overview ‐ Lab: Port mapping
‐ Lab : STP ‐ Lab: Learned Port Security
• Multiple Spanning Tree Protocol (MSTP)

‐ Overview
‐ Lab : MSTP
5
Agenda
Day 3 • Open Shortest Path First (OSPF)

‐
‐ Fundamentals
‐ Areas
• Dual Home Link (DHL) ‐ Adv. Features & Troubleshooting
‐ Overview ‐ Global Routing Protocol Redistribution
‐ Lab : Dual Home Link Active-Active ‐ Lab: OSPF
• VRRP
‐ Overview • Graceful Restart
‐ Lab : Virtual router redundancy Protocol ‐ Overview
• IP interfaces • DHCP
6 ‐ Overview ‐ Overview
‐ Lab : DHCP Serveur & DHCP Relay
Agenda
Day 4 • Security Network

‐Overview Access Guardian
• Quality of Service ‐Lab : Access Guardian Implementation
‐ Overview
‐ Lab : Quality of Service • Link Layer Discovery Protocol (LLDP)
‐ Overview
• OmniVista 2500 NMS ‐Lab : LLDP Implementation
‐ Overview
‐ Lab :Access to the OmniVista 2500 NMS server
• Multicast Introduction
‐ Overview
• Flow Based Filtering (ACL)
‐ Lab: IP Multicast switching
‐ Overview
‐ Lab : Security Network Access Control
7
Agenda
Day 5 • Ethernet Ring Protection

• Distance Vector Multicast Routing Protocol ‐ Overview & Lab
‐ Overview
• Private VLAN
• Protocol Independent Multicast (PIM) ‐ Overview & Lab
‐ Overview
‐ Lab :Access to the OmniVista 2500 NMS server • Optional topics depending on trainee needs
and time available
• Virtual Routing & Forwarding (VRF
‐Overview & Lab ‐Border Gateway Protocol (BGP) : Overview & Lab
‐SPB Overview
• Mac-Sec
8 ‐ Overview & Lab • Session evaluation on KH
AOS – Technical Documentations
OmniSwitch xxxx Series Hardware Users Guide
• Switch hardware components and basic switch hardware
OmniSwitch AOS Switch Management Guide
• Describes basic attributes of the switch and basic switch administration tasks
OmniSwitch AOS Network Configuration Guide
• Describes how to set up and monitor software features that will allow the switch to operate in a live network
environment
OmniSwitch AOS Advanced Routing Configuration Guide
• Describes how to set up and monitor advanced routing protocols for operation in a live network environment
OmniSwitch CLI Reference Guide
• Comprehensive resource to all Command Line Interface (CLI) commands available on the OmniSwitch products
OmniSwitch Transceivers Guide
• Provides specifications and compatibility information SFP/XFP/QSFP/… transceivers supported on the OmniSwitch
switches
9
Internet Ressources
• Alcatel-Lucent Enterprise Web Site
https://www.al-enterprise.com/en
• Training & Certification

https://www.al-enterprise.com/en/services/education-services
• RFC Technical documents

http://www.ietf.org
10
Internet Resources
Partners Website ALE Network Equipment
• MyPortal • www.al-enterprise.com/en/products/switches
Spacewalkers Community
• www.spacewalkers.com
11
OmniSwitch Details - Product Data sheets
LAN Switches
• OmniSwitch 2260 WebSmart switch: datasheet
• OmniSwitch 6360 LAN switch: datasheet
• OmniSwitch 6465 L2+ Hardened LAN Switch datasheet
• OmniSwitch 6560 L2+ Multigig LAN switch: datasheet
• OmniSwitch 6570 Gigabit Metro Ethernet LAN Switch datasheet
• OmniSwitch 6860 L3 LAN switch with multigig and DPI option datasheet
• OmniSwitch 6865 L3 Hardened Switch datasheet
• OmniSwitch 6900 L3 core switch datasheet Management Platform
• OmniSwitch 9900 Chassis core switch datasheet • OmniVista 2500 (on premises) datasheet
• OmniVista Cirrus (cloud) datasheet
Stellar WLAN
• OmniAccess Stellar AP1101 802.11ac AP: datasheet
• OmniAccess Stellar AP1201 entry-level 802.11ac wave 2 AP: datasheet
• OmniAccess Stellar AP1201H resident 802.11ac wave 2 AP: datasheet
• OmniAccess Stellar AP1220 high performance wave 2 AP: datasheet
• OmniAccess Stellar AP1230 ultra high performance wave 2 AP: datasheet
• OmniAccess Stellar AP1251 hardened wave 2 AP: datasheet
• OmniAccess Stellar AP1301 entry level Wi-Fi 6 AP: datasheet
• OmniAccess Stellar AP1311 high performance Wi-Fi 6 AP: datasheet
• OmniAccess Stellar AP1351 premium high-end Wi-Fi 6 AP: datasheet
• OmniAccess Stellar AP1360 hardened outdoor Wi-Fi 6 AP: datasheet
Poster (Complete ALE Network Solutions Portfolio)
Document showcasing the networking products designed by ALE.

Summary of the features proposed by each product.
Download it from the MyPortal website.
Your opinion counts!
Evaluation links are available to you as of the last day of the session and can therefore be filled in
at the end of the session before leaving the classroom or virtual class.
Two main situations have to be considered to access to the course evaluation, and this depends
on the Knowledge Hub session status (while still being in “In progress”, and as of it has switched
to “Completed”).
The status switches usually the next Monday after the session has ended.
14
Reach the session evaluation
Directly from the Home page / My Recent Learning activity;
•if “Evaluate” option is viewable, please click on it.
•if “Evaluate” is not proposed, click on “Open Curriculum” and after, on “Evaluate”
15
OMNISWITCH R8
REMOTE LAB CONNECTION
OBJECTIVES
Upon completion this module,
you will be able to:
• Describe Remote-Labs (R-Labs) topology

• Connect to a Remote-Lab (R-Lab)
CONNECT TO THE DATA RLAB
• A web browser is required to connect to the Rlab
• Recommended web browsers:
• Chrome
• Edge
Notes: Other web browser may have some issue with copy/paste from a lab guide to the remote terminal
session. Known workaround for FireFox: https://sudoedit.com/firefox-async-clipboard/
https://rdp.al-mydemo.com/
- Username: LanpodXa ou LanpodXb (X = R-Lab Number)
- Password: unique per session – Sent from our LMS to the Instructor
REMOTE LABS > TOPOLOGY
Two possibilities
6900-A : Model 6900T24C2
OS6900-A 1 OS6900-B 2
1/1/25 1/2/1
1/1/26 1/2/2
Or 6900-A : Model 6900T20
OS6900-A 1 OS6900-B 2
1/2/1 1/2/1
1/2/2 1/2/2
Switch Interface IP address

6900-A EMP 10.4.Pod#.1
6900-B EMP 10.4.Pod#.2
6560-A EMP 10.4.Pod#.3
6360-A EMP 10.4.Pod#.5
6360-B EMP 10.4.Pod#.6
6860-A EMP 10.4.100+Pod#.7
6860-B EMP 10.4.100+Pod#.8

REMOTE LABS > TOPOLOGY
1
3
4
VIRTUAL MACHINES
• 10 VM (Clients)
• AAA Training Server POD x

• DHCP Server, Radius Server: 192.168.100.102
• Web Server: 192.168.100.102
• FTP Server: 192.168.100.102
• login “admin” and password “switch”
• Podx_OV<ov_release>
• OmniVista 2500: 192.168.100.107
• Firewall/NAT server
• Podx_pfSense : 192.168.100.108
DHCP SERVER
• A DHCP server is running with an IP address of 192.168.100.102 and has the following
scopes (where x stands for the switch number):
OMNIVISTA 2500 & INTERNET ACCESS
• An OmniVista 2500 server is configured with the IP address 192.168.100.107/24.
• The OmniVista 2500 is reachable

from RDP desktop through a WEB
client at the URL:
https://10.4.pod#.208:8443
• DNS server on the client : 10.0.0.51
• If Internet access is required for VM clients,

a pre-configuration has to be done on the OS6900-A
THANK YOU
CAMPUS LAN NETWORK
SOLUTION
O M N I S W I T C H P O RT F O L I O
OBJECTIVES
• List the OmniSwitch models and their

characteristics
• Describe ALE secured code
ALE NETWORK PORTFOLIO
NETWORK PORTFOLIO Hardened
WLAN OmniAccess Stellar Wi-Fi 6E OmniAccess

AP1201H
Wi-Fi 6
Wi-Fi 5
AP1301H AP1411
AP1431 AP375
AP5xx OA4xxx
AP136x
AP1201/BG AP1251 AP1301 AP13xx AP1451
AP12xx
PARTNERS
IP/MPLS
NEW
LAN OmniSwitch
OS6860E/N
Core
Access
POL
OS6900 OS9900
WDM
OS6570M
7750 SR 7705 SAR
OS6360
7250 IXR 7210 SAS
Rugged
VSR
SD-WAN
7450 ESS /SASE
OS2x60 OS6560
OS6865 OS6465/T
Management Location Based Asset Tracking SERVICES

Software Services
OmniVista 2500
OmniVista Cirrus NaaS by
UPAM ALE
Proactive Lifecyle Management
Nokia Network Services Platform
CAMPUS SWITCH DESCRIPTION
OMNISWITCH 6360
Model OS6360-(P)10 /P10A
MAIN CHARACTERISTICS 8 fixed 10/100/1000 Base-T ports

POE: IEEE 802.3at OMNISWITCH 6360
2 fixed RJ45 (1G) uplink ports
2 SFP (1G) uplink ports
Gigabit Ethernet LAN switch * No FPoE/PPoE fot P10A model OS6360-(P)10/P10A
10, 24, 48 port models (PoE/non-PoE)
1G user port models:
Model OS6360-(P)24
Increased Uplink\VFL speeds (PH24), (P24X)
10GBaseT ports
24 fixed 10/100/1000 Base-T ports
Partial (optimized) PoE budget models POE: IEEE 802.2at
Full PoE budget models (P)24 2 RJ45/SFP (1G) combo ports
2 SFP+ (1/10G) ports
Fast & Perpetual PoE support OS6360-(P)24, (PH24), (P24X)
Increased # of Fan-less models Model OS6360-(P)48,
(P48X)
OS6360-P10A 48 fixed 10/100/1000 Base-T ports
Same features as OS6360-P10 expect for Fast PoE & Perpetual PoE POE: IEEE 802.2at
(P)48 2 RJ45/SFP (1G) combo ports
P48X 2 RJ45/SFP+ (1/10G) combo
ports
2 SFP+ (1/10G) ports OS6360-(P)48, (P48X)
TYPICAL DEPLOYMENT
OS6360-PH48
Gigabit Ethernet switch in small networks Forty-six (46) - 10/100/1000Base-
T
Provides integrated Voice/Data/Wi-Fi solution PoE (802.3at) ports
For networks with 1Gig access and 1Gig & 10Gig uplinks Two (2) - 10/100/1000/2.5G PoE
(802.3bt) ports
Two (2) - RJ45/SFP+ combo ports
(Default 1G, upgradeable to 10G)
Two (2) - SFP+ software
configurable ports:
Two (2) - SFP uplinks OS6360-P48H
Two (2) - SFP+ uplink or VFL ports
Internal 950W AC power supply
OMNISWITCH 6465
Model OS6465-P6
MAIN CHARACTERISTICS 4 fixed 10/100/1000 Base-T ports
OMNISWITCH 6465
POE+: IEEE 802.2at
Compact Hardened Value LAN switch HPoE 60W : up to 2 ports OS6465-P6
Virtual Chassis: Up to 4 switches in a local or remote stack (up to 10km) 2 x SFP ports
Stacking ports (2 x SFP)
Industrial PoE with HPoE (60W) on all models
Supports Cat 5E/6 cabling standards DIN AC Power supplies
Hot-swappable, fully redundant power supplies (AC+AC, AC+DC or DC+DC) OS6465-BPN-H(180W)
Switch Backup & Restore OS6465-BPN (75W)
IEEE 1588v2 PTP support Model OS6465(T)-P12

MACSec Support 8 fixed 10/100/1000 Base-T ports OS6465-P12
Auto-fabric technology POE+: IEEE 802.2at
HPoE 60W : up to 4 ports
Fanless 2 x SFP ports
Alarm relay Input/Output Stacking ports (2 x SFP)
Basic L3 routing: IPv4 and IPv6 OS6465T-P12 Extended Temp
Ethernet Switch
Operating Temperature -10 to +60 ℃
OS6465T-(P12) Extended Temperature Ethernet Switches DIN AC Power supplies
Perpetual PoE and Fast PoE are now supported on 6465P-12 (8.8R1) OS6465-BPN-H(180W)
OS6465-BPN (75W) OS6465-P28
Model OS6465-P28
TYPICAL DEPLOYMENT 22 fixed 10/100/1000 Base-T ports
POE+: IEEE 802.2at
HPoE 60W : up to 8 ports
Ruggedized Access switch for: 2 x SFP ports
OS6465T-(P)12
Transportation 4 x SFP+ ports
Traffic control systems Stacking ports (2 x SFP+)
Utilities DIN DC Power supply
IP surveillance systems OS6465-BPRD(180W)
Outdoor installations DIN AC Power supply
OS6465-BPR(180W)
Model OS6560-X10
8 x 10/100/1G Base-X ports
2 x QSFP+ 20G stacking ports
OMNISWITCH 6560
Model OS6560-24X4
24 x 10/100/1G Base-T ports
2 x SFP 1G ports
4 x SFP+ 1/10G ports
Model OS6560-P24X4
MAIN CHARACTERISTICS 24 x 10/100/1G Base-T POE+ ports

2 x SFP 1G ports OMNISWITCH 6560
Value Multi-GIG and 10G LAN switch Model OS6560-24Z8 OS6560-X10 10G
Linux based AOS software 16 x 10/100/1000 Base- ports
8 x 1G / 2,5G Base-T ports
1/10Gig or MultiGig (1G/2.5G) port models 2 x SFP+ 1/10G ports
Up to eight switches in a virtual chassis (uplink / stacking / remote stacking)
OS6560-24X4 Multi Gig
PoE (802.3.at) and HPOE (802.3.bt) standards Model OS6560-P24Z8
OS6560-P24X4
16 x 10/100/1000 Base- ports (802.3af/at)
10G, 10G remote, and 20G stacking options 8 x 1G / 2,5G Base-T ports
Backup Power supply POE (802.3af/at/bt) (Up to 95W on a port)
2 x SFP+ 10G ports
MACSec Support (uplink/stacking / remote stacking)
OS6560-24Z8
Same power supplies as OS6860 Model OS6560-24Z24
OS6560-P24Z8
Metro Ethernet Features 24 x 100/1G/2,5G Base-T ports
OSPF stub area 2 x QSFP 20G dedicated stacking ports
Model OS6560-P24Z24
24 x 100/1G/2,5G Base-T ports OS6560-24Z24
POE (802.3af/bt) (Up to 95W on a port) OS6560-P24Z24
4 x SFP+ 10G ports
2 x QSFP 20G dedicated stacking ports
TYPICAL DEPLOYMENT Model OS6560-P48Z16
32 x 10/100/1000 Base-T ports OS6560-P48Z16
For networks with 802.11ac multi-gig APs POE (802.3af/at) (Up to 30W on a port)
16 x 100/1G/2,5G Base-T ports
(over the air throughput >1G) (PoE over 2.5G access) POE (802.3af/at/bt) (Up to 95W on a port)
4 x SFP+ 10G ports
2 x QSFP 20G dedicated stacking ports
Access switch in 10 gigabit converged campus networks OS6560-48X4
Model OS6560-48X4
Aggregation for wired and wireless access 48 x 10/100/1000 Base-T ports
OS6560-P48X4
Carrier and Service Provider Ethernet Access 2 x SFP ports
POE (802.3af/at/bt)
4 x SFP+ 10G ports (Stacking/Uplinks)
Model OS6560-P48X4
48 x 10/100/1000 Base-T ports
POE (802.3af/at) (Up to 30W on a port)
2 x SFP ports
POE (802.3af/at/bt)
4 x SFP+ 10G ports (Stacking/Uplinks)
OMNISWITCH 6560
METRO ETHERNET FEATURES OMNISWITCH 6560
Starting from 89R01, all models of OS6560 support Metro Ethernet features. OS6560-X10 10G
A perpetual Metro license is required to enable this functionality.

OS6560-24X4 Multi Gig
Following features are included in metro license. OS6560-P24X4
CPE Test Head

Hardware Loopback OS6560-24Z8
PPPoE-IA OS6560-P24Z8
Ethernet OAM
SAA
Link OAM
OS6560-24Z24
VLAN Stacking
OS6560-P24Z24
DPA
OS6560-P48Z16
OS6560-48X4
OS6560-P48X4
OMNISWITCH 6570M -12(D)
OS6570M-12 GigE
OmniSwitch® 6570M Metro Ethernet LAN Switch • 1RU x 1/2 rack chassis.
Deployments benefiting from the OmniSwitch 6570M family include: • 8xRJ45 10/100/1000 BaseT
• Edge of small-to-mid-sized networks
• 2x100/1G Base-X SFP,
• Branch office enterprise and campus workgroups
• 2x1G/10G SFP+ ports.
• Service provider managed services application
Customer Premises Equipment (CPE) • Internal AC PSU.
Fibre aggregations • Separately orderable 19" rack

mount kit and optional backup
power supply
OS6570M-12/-12D
OMNISWITCH 6570M –U28
OS6570M-U28
OMNISWITCH 6860E
STACKABLE GIGABIT ETHERNET LAN SWITCH
MAIN CHARACTERISTICS OMNISWITCH 6860E
Stackable Gigabit Ethernet LAN switch
Up to 264 Gb/s of wire-rate capacity Models OS6860(E)-(P)24/48 OS6860(E)-(P)24 (D)
Advanced L3 routing*: VRF, Multicast, IPv4 and IPv6 24-port and 48-port models
RJ45 and/or PoE+/++ and SFP
Up to eight switches in a virtual chassis (local or remote stacking) ports
Optional choice of standard or advanced backup power 4 fixed SFP+ (1G/10G) ports
2 VFL QSFP+ stacking ports (20G
Universal Network Profiles: Policy based access each)
Network Analytics and Control (signature based) AC power supply
Application monitoring enforcement OS6860(E)-(P)48 (D)

Models OS6860(E)-(P)24/48D
RESTful API and OpenFlow for SDN
Same as OS6860(E)-P24/48
With a DC power supply
TYPICAL DEPLOYMENT
Models OS6860E-P24Z8 OS6860E-P24Z8
Converged campus networks 16 x 100/1000 Base-T POE+ ports
Access switch 8 x 2.5G Multi-Gigabit HPoE ports
Multi-Gig Advanced Access 4 fixed SFP+ (1G/10G) ports
2 VFL QSFP+ ports (20G each)
High capacity & high-density wired and wireless access AC power supply
Distribution switch
Data Center
Top of Rack switch
Carrier and Service Provider Ethernet Access
OMNISWITCH 6860N
MAIN CHARACTERISTICS OMNISWITCH 6860N
Secure virtual networks Models OmniSwitch 6860N-
OS6860N-P(H)(X)48M
P(H)(X)48Mc
SPB, VxLAN*, MPLS* VPNs
36 100/1G/2.5G BaseT bt PoE
256-bit MACsec 12 100/1G/2.5G/5G/10G BaseT bt
Native Inline routing PoE
2 QSFP28 VFL ports
WiFi 6 Ready 1 expansion slot OS6860N-P24M
Full Multi-gig Support
95W PoE (802.3bt) Models OmniSwitch 6860N-P24Mc
24 100/1G/2.5G/5G/10G BaseT bt
Next-Gen HW PoE
Hi-speed uplinks 2 QSFP28 VFL ports
2 x 100G Stacking 1 expansion slot OS6860N-P(H)48Z
Built for Next-Gen L3 Access Networks Models OmniSwitch 6860N-
P(H)48Zc
36 x 1GBaseT 60W PoE, 12 x 5G multi-
TYPICAL DEPLOYMENT gig 95W PoE, 4 x 10/25G SFP28 fixed, OS6860N-P24Z
MACsec uplinks
Converged campus networks
Models OmniSwitch 6860N-P24Zc
Multi-Gig Advanced Access 12 x 1GBaseT 60W PoE, 12 x 5G multi-
Access switch gig 95W PoE, 4 x 10/25G SFP28 fixed,
High capacity & high-density wired and wireless access MACsec uplinks
OS6860N-U28(D)
Distribution switch Models OmniSwitch 6860N-U28(D)
Data Center 24 x 100/1000BaseX,4 x 1/10G SFP+,
Top of Rack switch 4 x 10/25G SFP28 fixed uplinks. All
ports MACsec capable.
Carrier and Service Provider Ethernet Access
OMNISWITCH 6860N
Click for More details on datasheets

OMNISWITCH 6865
ADVANCED RUGGEDIZED ETHERNET LAN SWITCH
Model OS6865-P16X
MAIN CHARACTERISTICS 8 x 10/100/1000 ports (POE+)
OMNISWITCH 6865
4 x 10/100/1000 ports (POE+, HPoE 75W )
Advanced Ruggedized Ethernet LAN switch 2 x 1G SFP ports (uplink)
2 x SFP+ ports (1G/10G, uplink or stacking) OS6865-P16X (D)
Optional backup power Up to 320W PoE Budget
Up to eight switches in a virtual chassis
Model OS6865-P16XD
Local or remote stacking
Same as OS6865-P16X
Advanced L3 routing license With a DC power supply
Universal Network Profiles: Policy based access
Model OS6865-U12X
Network Analytics and Control with signature
2 x 1G BaseX SFP ports
based traffic inspection 4 x 100/1000 Base-T HPoE ports
RESTful API and OpenFlow for SDN (all are 75W PoE capable)
OS6865-U12X (D)
4 x 100/1000 BaseX SFP ports
Metro Ethernet Features 2 x SFP+ ports (1G/10G)
IEEE 1588v2: Precision Time Protocol (PTP) (uplink or stacking)
Up to 300W PoE Budget
Pre-defined role templates in AG for IEDs, Cameras
Multicast Over SPB Optimizations Model OS6865-U12XD
Operating Temperature -10 to +60 ℃ Same as OS6865-U12X
With a DC power supply
TYPICAL DEPLOYMENT Model OS6865-U28X

20 x 100/1000 BaseX SFP ports
4 x 100/1000 BaseT HPoE ports OS6865-U28X (D)
Ruggedized Advanced Access switch for: (all are 75W PoE capable)
Industrial applications 4 x SFP+ ports (1G/10G) (uplink/stacking)
2 x 20G QSFP stacking ports
Utility and transportation networks Up to 280W PoE Budget
Access layer in outdoor cabinets
Carrier and Service Provider Ethernet Access Model OS6865-U28XD
Same as OS6865-U28X
Security & Surveillance With a DC power supply
OMNISWITCH 6900
MAIN CHARACTERISTICS OMNISWITCH 6900
Stackable 10/25/40/100 Gig LAN switch Models OS6900-C32E 10/25/40/100 Gig
OS6900-C32E
32-port unpopulated QSFP28 ports
Sub-microsecond latency 100/40/4x25/4x10 GE
Up to 6.4 Tb/s of wire-rate capacity
Redundant power Models OS6900-X48C6
48 fixed SFP+ (1G/10G) ports OS6900-X48C6
Front to back or back to front cooling models 6 fixed QSFP28 ports 10/25/40/100 GE
Advanced L3 routing: VRF, Multicast, IPv4 and IPv6 Up to 72 SFP+ (10G) ports (splitter)
Universal Network Profiles; Policy based VM movement Models OS6900-T48C6
Auto-Intelligent Fabric OS6900-T48C6
48 fixed Base-T (1G/10G) ports
In Service Software Upgrade 6 fixed QSFP28 ports
100/40/4x25/4x10 GE
Shortest Path Bridging (SPB), IPv4/IPv6 routing over SPB
Models OS6900-X48C4E*
Virtual Extensible LAN (VxLAN) OS6900-X48C4E
40 ports unpopulated SFP+ 1/10 GE
RESTful API and OpenFlow for SDN 8 ports unpopulated SFP28 1/10/25 GE
Virtual chassis technology 4 ports unpopulated QSFP28
100/40/4x25/4x10 GE
OS6900-V48C8
Models OS6900-V48C8
TYPICAL DEPLOYMENT 48 ports unpopulated SFP28 1/10/25 GE
8 ports unpopulated QSFP28
For core networks of large networks 100/40/4x25/4x10 GE
OS6900-X24C2
Top-of-rack or Spine switches in Data Center networks demanding a high Models OS6900-X24C2
10G or 40G port density and/or FC connectivity 26 fixed SFP+ (1G/10G) ports
2 fixed QSFP28 ports
OS6900-T24C2
Models OS6900-T24C2
24 fixed Base-T (1G/10G) ports
2 fixed SFP+ VC/Uplink ports
2 fixed QSFP28 ports
OMNISWITCH 9907
7 Slot Chassis based LAN Switch with 6 line card slots OS9907-CHAS OS9907
1 CMM (Chassis Management Module) Slots
7 slot chassis
1 CMM/NI Slot
5 Network Interface Module Slots
4 CFM (Chassis Fabric Module) Slots, rear accessible OS99-CMM
4 power supply bays, front accessible 2 QSFP 40 GigE Ports
3 fan tray Slots, rear accessible
High-performance and very low latency Layer-2/Layer-3 switching
OS99-CFM
Up to two OS9907 can be connected using virtual chassis technology.
2.56 or 12.8 Tbps Full Duplex current switching capacity 1.28 Tbps switching capacity
Hardware Redundancy
Power supply OS99-CFM2
Management Single ASIC with 6.4 Tbps switching 2 x CMM with
Switch fabric capacity integrated ports
OS99-CMM
Fans
Internal PoE supply/ HPoE up to 75W & 802.3at support
OS99-2PS-A for uplink or VFL
10800W of inline PoE power OS9907-Fan tray

OS99-CFM OS99-CFM2 OS9907-Fan Tray
11-RU form factor or
TYPICAL DEPLOYMENT
Core/aggregation switch
Data Center
End of Row Switch
Spine-Leaf Architecture (L3 design)
OMNISWITCH 9912
12-slot Chassis based LAN Switch OS9912
2 CMM (Chassis Management Module) Slots
10 Network Interface Module Slots
4 CFM (Chassis Fabric Module) Slots, rear accessible
4 power supply bays, front accessible 2 x CMM
3 fan tray Slots, rear accessible OS9912-CHAS with 4
QSFP28
High-performance and very low latency Layer-2/Layer-3 switching 12 slot chassis
100G ports
25.6 Tbps Full Duplex switching fabric
OS9912 will support virtual chassis technology in future release. OS99-CMM2
Hardware Redundancy 4 QSFP28 100 GigE Ports
Power supply
Management
OS9912-CFM
Switch fabric
Fans 12.8 Tbps switching capacity
OS9912-Fan Tray
OS9912-CFM
Internal PoE supply/ HPoE up to 75W & 802.3at support
7920W of inline PoE power
OS9912-Fan Tray
17.25-RU form factor
TYPICAL DEPLOYMENT
Data Center
End of Row Switch
OMNISWITCH 9900 NI MODULES & POWER SUPPLIES
OS99-GNI-48
MAIN CHARACTERISTICS
MAIN CHARACTERISTICS 48 x RJ-45 10/100/1000-BaseT ports OMNISWITCH 9900
OS99-GNI-P48
Modules provide very low latency for high-performance server clusters and core 48 x RJ-45 10/100/1000-BaseT PoE ports OS9907
8 ports HPoE (75W)
connectivity over QSFP28, QSFP+, SFP+, DAC or CAT 5/6. 40 ports 802.3at (30W)
OS99-GNI-U48
Modular slots offer versatility in terms of 100GigE QSFP28, 40 GigE QSFP+, 10 GigE 48 unpopulated wire rate SFP 1000Base-X ports
SFP+, 10 G Base-T and 10/100/1000Base-T ports. OS99-XNI-U12Q
12 x 1/10G SFP+
Each QSFP port is capable of operating as 40 GigE or 4x10 GigE. 1 x 10/40G QSFP
Each QSFP28 port is capable of operating as 40/100 GigE or 4x10/25 GigE. OS99-XNI-U24
24 x 1/10G SFP+
Internal POE supply/ HPoE up to 75W & 802.3at support OS99-XNI-P24Z8 OS99-PS-A
16 x 1G/10G Base-T ports 3000W@220V
Power Supply options 8 x 1G/2.5G/10G Base-T ports
Redundant Power
1200W@110V
Ports 1-8: 10/100/1000/2500/5000/10000 Mbps or
Support 75W HPoE supplies 3+1
PS-AC (3000W@220V/ 1200W@110V)
PS-DC (2500W)
Ports 9-24:10/100/1000/10000 Mbps
Up to 30W POE (at)
OS99-PS-A
OS9912
OS99-PS-D
OS99-XNI-UP24Q2
2500W
12 x 1/10GigE SFP+ ports
12 x 1G/2.5G/10G BaseT 802.3bt PoE ports
2 x 40G QSFP+
TYPICAL DEPLOYMENT OS99-XNI-48

48 x 1G/10G Base-T 802.3at PoE ports
Converged campus networks OS99-XNI-U48

48 x 1G/10G SFP+ ports
OS99-XNI-P48Z16
Data Center 32 x 1G/10G Base-T 802.3at PoE ports
16 x 1G/2.5G/10G BaseT 802.3bt PoE ports
End of Row Switch Ports 1-8 support 75W HPoE
9-48 ports up to 30W (at)
OS99-CNI-U8
8 x 100G unpopulated wire rate QSFP28 ports
OS99-CNI-U20
20 x 100G QSFP28
OEM SWITCHES
OMNISWITCH 2260
Gigabit Ethernet LAN switch
8-, 24- and 48 ports
Fan-less on 10/P10, 24/P24 models Model OS2260-(P) 8
Standalone 8 fixed 10/100/1000 Base-T ports OS2260-(P)10
Advanced Layer2+ with static routing POE: IEEE 802.2at/af
4 fixed SFP (1G) ports
Optimized PoE+ budget
PPoE/FPoE
1G user port/uplink models
Model OS2260-(P) 24
OmniVista Cirrus Support
Limited CLI, Webview2.0 24 fixed 10/100/1000 Base-T ports
POE: IEEE 802.2at/af OS2260-(P)24
No 10G uplinks 2 fixed SFP (1G) ports
No Backup Power Supply
No Stacking
Model OS2260-(P) 48
TYPICAL DEPLOYMENT 48 fixed 10/100/1000 Base-T ports
POE: IEEE 802.2at/af
• Small and medium-sized business network solutions 2 fixed RJ45/SFP (1G) ports
OS2260-(P)48
• High-speed desktop connectivity
• Secure wireless connectivity
• Unified communications (IP telephony, video, and converged solutions)
OMNISWITCH 2360
MAIN CHARACTERISTICS Model OS2360-(P) 24
OMNISWITCH 2360
Stackable Gigabit LAN switches 2 fixed SFP (1) ports
OS2360-(P)24(X)
10 GigE virtual chassis bandwidth up to 4 units (stacking)
Model OS2360-P24X
24- and 48-port models
Gigabit Ethernet SFP uplink ports or 10 Gigabit Ethernet SFP+ uplink ports POE: IEEE 802.2at/af
2 SFP+ (1/10G) uplink ports
(X models) 2 SFP+ (1/10G) VFL ports
Reduced power consumption with energy efficient ethernet (EEE)
technology Model OS2360-(P) 48
Simplified web-based management 48 fixed 10/100/1000 Base-T ports OS2360-(P)48(X)
Fanless with non-POE 8 and 24 ports model 2 fixed RJ45/SFP (1G) ports
Easy MAC/IP-based ACLs
Model OS2360-P48X
No Backup Power Supply 48 fixed 10/100/1000 Base-T ports
2 fixed SFP (1G) uplink ports
2 SFP+ (1/10G) uplink ports
OS2360-U24X
TYPICAL DEPLOYMENT 2 SFP+ (1/10G) VFL ports
• Brand and campus workgroups Model OS2360-U24X

24 x 100M/1G SFP ports
6 x SFP(+) SW configurable ports:
• SMB networks 4 x 1/10GE uplinks, 2x10 GE uplinks/VFL
OS2360-U48X
Model OS2360-U48X
48 x 100M/1G SFP ports
6 x SFP(+) SW configurable ports:
4 x 1/10GE uplinks, 2x10 GE uplinks/VFL
OMNISWITCHES COMPARISON
OMNISWITCH WEBSMART 2260, 2360 COMPARISON
OS2260 OS2360
Software OEM OEM
L2 L2
Features
Non Stackable Stackable
Routing Basic static Basic static
10M/100M/1G 10M/100M/1G
User ports
802.3at support 802.3at support
Uplinks 1 Gbps 1/10 Gbps

Stacking No Yes
Switching 80.4 Mpps 133.9 Mpps
Fabric Capacity 216 Gb/s 216 Gb/s
Traffic Analysis No No
Advanced Security AG, UNP AG, UNP
Management OmniVista 2500 NMS OmniVista 2500 NMS
Mac Table 16K 16K
Routing Table 2 Static entries 32 Static entries
Multicast IGMP / Switching IGMP / Switching
OMNISWITCH 6360, 6465, 6560, 6570 COMPARISON
OS6360 OS6465 OS6560 OS6570M
Software AOS 8 base AOS 8 base AOS 8 base AOS 8 base

AOS L2 & Basic L3 AOS L2 & Basic L3 AOS L2 & Basic L3 AOS L2 & Basic L3
Features
Stackable Stackable Stackable Stackable w/Metro Ethernet
Static, RIP/RIPng, Static, RIP/RIPng,
Routing Basic static and RIP/RIPng Basic static and RIP/RIPng
OSPF Stub area OSPF Stub area
10M/100M/1G/2.5G
10M/100M/1G 10M/100M/1G
User ports 802.3at/bt 10M/100M/1G
802.3at support 802.3at support
95W POE (1 port)
Uplinks 10 Gbps 1/10 Gbps 10 Gbps 10 Gbps
Stacking 20 Gbps links 20 Gbps links 10/20 Gbps links 10/20 Gbps links
Switching 208 Mpps 131 Mpps 208 Mpps 210 Mpps
Fabric Capacity 140 Gb/s 176 Gb/s 168 Gb/s 60/168 Gb/s
Traffic Analysis Network Analytics Network Analytics Network Analytics Network Analytics
Advanced Security AG, UNP, CP, BYOD AG, UNP, CP, BYOD AG, UNP, CP, BYOD AG, UNP, CP, BYOD
Management OmniVista 2500 NMS OmniVista 2500 NMS OmniVista 2500 NMS OmniVista 2500 NMS
Mac Table 16K 16K 16K 32K
Routing Table 256-entries 256-entries 256-entries 256-entries
Multicast IGMP / Switching IGMP / Switching IGMP / Switching IGMP / Switching
OMNISWITCH 6860E/N, 6900, 9900 COMPARISON
6860E OS6860N OS6900 OS9900
Software AOS 8 base AOS 8 base AOS 8 base AOS 8 base
AOS L2 & Adv. L3 AOS L2 & Adv. L3 AOS L2 & Basic L3 Chassis with 5
Features Virtual Chassis, SPB-M Virtual Chassis, SPB-M Stackable line card slots
Static, OSPFv2, OSPFv3, IS-IS Static, OSPFv2, OSPFv3, IS-IS IPv4,
Routing Full, advanced IP Routing Full, advanced IP Routing
RIP/RIPng, BGP IS-IS, RIP/RIPng, BGP
10M/100M/1G/2.5G
10M/100M/1G/2.5G/5G 10M/100M/1G/2.5G/10G
802.3at support 10M/100M/1G/2.5G/10G
User ports 60W POE+ on 4 ports (E)
802.3bt support
40G/100G
40G/100G
60W POE+ on 4 ports (E) 802.3at/bt
75W HPOE 8 ports (P24Z8)
Uplinks 10 Gbps 10 Gbps 10/40/100 Gbps 10/40/100 Gbps
Stacking 80 Gbps links 100 Gbps links 10/40/100 Gbps links 2x40 Gbps links
Switching 190.6 Mpps 758.9 Mpps 2000 Mpps 767 Mpps
Fabric Capacity 264 Gb/s 1,120 Gb/s 64 Tb/s 2.56 Tb/s
Network Analytics, DPI, Network Analytics, DPI,
Traffic Analysis Application Monitoring Application Monitoring
Network Analytics Network Analytics
Advanced Security AG, UNP, CP, BYOD AG, UNP, CP, BYOD MACsec AG, UNP, CP, BYOD AG, UNP, CP, BYOD, MACsec
Management OmniVista 2500 NMS OmniVista 2500 NMS OmniVista 2500 NMS OmniVista 2500 NMS
Mac Table 48K 64K 228K 128K
Routing Table 12K 12K 128K 128K
Multicast Full IP Multicast routing Full IP Multicast routing Full IP Multicast routing Full IP Multicast routing
OMNISWITCH -PRODUCT DATA SHEETS
OMNISWITCH DETAILS - PRODUCT DATA SHEETS
LAN Switches
• OmniSwitch 6360 LAN switch: datasheet
• OmniSwitch 6465 L2+ Hardened LAN Switch datasheet
• OmniSwitch 6560 L2+ Multigig LAN switch: datasheet
• OmniSwitch 6570 Gigabit Metro Ethernet LAN Switch datasheet
• OmniSwitch 6860 L3 LAN switch with multigig and DPI option datasheet
• OmniSwitch 6865 L3 Hardened Switch datasheet
• OmniSwitch 6900 L3 core switch datasheet
• OmniSwitch 9900 Chassis core switch datasheet Management Platform
• OmniVista 2500 (on premises) datasheet
Stellar WLAN • OmniVista Cirrus (cloud) datasheet
• OmniAccess Stellar AP1101 802.11ac AP: datasheet
• OmniAccess Stellar AP1201 entry-level 802.11ac wave 2 AP: datasheet
• OmniAccess Stellar AP1201H resident 802.11ac wave 2 AP: datasheet
• OmniAccess Stellar AP1220 high performance wave 2 AP: datasheet
• OmniAccess Stellar AP1230 ultra high-performance wave 2 AP: datasheet
• OmniAccess Stellar AP1251 hardened wave 2 AP: datasheet
• OmniAccess Stellar AP1301 entry level Wi-Fi 6 AP: datasheet
• OmniAccess Stellar AP1351 premium high-end Wi-Fi 6 AP: datasheet
• OmniAccess Stellar AP1360 hardened outdoor Wi-Fi 6 AP: datasheet
ALE SECURED CODE
LAN CAMPUS - HARDENED AOS SOFTWARE
• ALE diversified AOS ALE
• Increasing security at network devices Secured
Code
• Same functionality and performance as the normal
release
• Network Protection • Secure Diversified Code

• Intrinsic vulnerabilities • Independent verification & validation of OS
• Code exploits • Automatic diversification on bootup
• Embedded malware
• Potential back doors
THANK YOU
OMNISWITCH R8
C O N N E C T I N G TO T H E S W I T C H
OBJECTIVES
• Describe the different possibilities of connection

to the switch
OVERVIEW
• Goal
Remote user
AOS OmniSwitch Login via SSH, telnet,
HTTP/HTTPS (WebView)
or SNMP (OV)
OXO R > 9.1

Authentication Server R.1
Local or external database
-> no aaa authentication http

EMP (Outbound IP
interface) -> show aaa authentication
Local User Service type = Default
1rst authentication server = local
Login via console port Service type = Console
• How it works 1rst authentication server = local
Service type = Telnet
• Allow or deny access available management Authentication = Use Default,
Service type = Ftp
• On Console, Telnet, HTTP, HTTPS, FTP, SSH, and SNMP Authentication = Use Default,
• Authenticated Switch Access (ASA) feature Service type = Http
Authentication = denied
• Lock or Unlock session types Service type = Snmp
Authentication = Use Default,
(aaa authentication command) ---
CONNECTING TO THE SWITCH
Local or Remote Connection
• Example: Allow or deny access available management
-> show aaa authentication

-> show aaa authentication
Service type = Default
1st authentication server = local Service type = Default
Service type = Console 1st authentication server = local
1st authentication server = local Service type = Console
Service type = Telnet 1st authentication server = local
Authentication = Use Default, Service type = Telnet
1st authentication server = local Authentication = Use Default,
Service type = Ftp 1st authentication server = local
Authentication = Use Default, Service type = Ftp
1st authentication server = local Authentication = Use Default,
Service type = Http 1st authentication server = local
Authentication = Use Default, Service type = Http
1st authentication server = local Authentication = denied
Service type = Snmp Service type = Snmp
Authentication = Use Default, Authentication = Use Default,
... ...
-> no aaa authentication http

SWITCH USER ACCOUNT
• How it works
• Stored in the local user database and / or on external authentication servers
AOS OmniSwitch
Authentication Server Local User
RADIUS or LDAP Login via console port
The Local userDB file is named userTable8

Path: flash/system directory
By default : 2 users “admin and default”
*User login information and user privileges

can be stored on the servers.
Default login name and password
Login : admin
Password : switch
* Up to 64 users can be configured in the local switch database

* User Privileges : read and write access to command domains and families
ACCESS VIA THE CONSOLE PORT
• Goal
• By default, single user management account is available at the first bootup of the switch
• How it works
AOS OmniSwitch
Login to the Console Port

* By default, DCE console connection
* Except for 6900 V72/C32 (cross cable)
1 RJ45 – Port console 2 USB - RS232 3 Micro-USB - USB 4 Micro-USB - RS232
More information about

cable used are available on
the eBook below in section
“If you want to know more”
* USB Adapter with Bluetooth Technology supported on an OS6465, 6560, 6860, 6865, 6900-V72 /C32
USB adapters supported are listed on release note
ACCESS VIA THE CONSOLE PORT
• CLI: Command Line Interface
• Use software like Tera Term, Putty, HyperTerminal …
Default settings
Note: the configuration for the 6900 V72 / C32,

6900 T24C2 and 6860N switches is different:
Speed (baud) : 115200

Parity: None
Stop bits : 1
Flow control : none
ACCESS VIA THE EMP PORT
• Goal
• Bypass the network interface modules (NI)
• Remotely manage the switch directly via the CMM
(not available in all switches)
USB Ethernet Dongle (8.9.R1)

• This feature allows for a USB-to-Ethernet interface for switches that
lack an EMP port. This interface is treated just like an EMP interface.
• All functions and CLIs related to EMP are applicable to the USB-to-
Ethernet dongle.
OS6860N Notes:
• USB 3.0 version dongles are supported on OS6360/6465/6560 models.
• USB 2.0 version dongles are supported on all models.
• All the chassis of a VC should have a USB-to-Ethernet dongle for proper VC EMP functionality.
• The EMP port IP address of the master chassis

(Virtual Chassis)
ip interface master emp address 172.25.167.203 mask 255.255.255.224
TELNET, SSH, HTTP, SNMP
Session specification
Session AOS OmniSwitch
Telnet (V4 or V6) 6
FTP (V4 or V6) 4
SSH + SFTP (V4 or V6 secure session) 8
HTTP 4
Total sessions (Secure Shell, Telnet, FTP, HTTP, and console) 20
SNMP 50
Secure Shell public key authentication Password
DSA/RSA/ECSDA Public Key
* Extract from OmniSwitch AOS Release 8 Specifications Guide
Secure Shell public key authentication Password

DSA/RSA Public Key
RFCs Supported for SSHv2 RFC 4253 – SSH Transport Layer Protocol
RFC 4418 – UMAC: message Authentication Code Universal Hashing
ACCESS VIA WEBVIEW
• Goal
• The switch can be monitored and configured using WebView
• View is limited to one switch
• Access can be secured
• How it works
• The WebView application is embedded in the switch and is accessible via a web browser
CONNECTING TO THE SWITCH: ACCESS VIA WEBVIEW
• Webview configuration
webview server enable • Enables the WebView Application (default= enabled)
webview force-ssl enable • Forces SSL connection between browser and switch (default=enabled)
webview http(s) port • Changes the port number for the embedded Web server
aaa authentication http local • Checks the local database for HTTP authentication
-> show webview

WebView Server = Enabled,
WebView Access = Enabled,
WebView Force-SSL = Enabled,
WebView HTTP-Port = 80,
WebView HTTPS-Port = 443
On premise or on Cloud (OV Cirrus)
ACCESS VIA SNMP
• SNMP - IPv4 & IPv6 OmniVista Advanced
Applications
• Versions
• SNMPv1
• SNMPv2 OmniVista 2500 Series
• SNMPv3 Infrastructure
Analytics
Displays Application Traffic Patterns
• Main applications to manage and supervise
• Discovery
• Topology
• Access Guardian, UNP
• Performance
• Traps/Events
• VLAN Manager
• Locator
• Policy Mgt Topology Quarantine Manager and Remediation
Provides Global device containment
• …
THANK YOU
OmniSwitch R8
Remote Switch Access
How to
✓ Administrate the OmniSwitches remotely
Contents
1 Accessing to the Switch Remotely .......................................................... 2
2 Authenticating to the Switch ................................................................ 4
2.1. Enabling the SSH connection ...................................................................... 4
2.2. Testing the SSH connection ....................................................................... 4
2.2.1. Configuring the OmniSwitch .............................................................................. 5
3 Accessing to the WebView ................................................................... 6

3.1. Setting up the HTTP Session ...................................................................... 6
3.2. Opening the WebView ............................................................................. 7
3.3. Configuring the OmniSwitch from the WebView ............................................... 8
3.4. Visualize your chassis .............................................................................. 9
3.5. Creating a VLAN from the WebView ............................................................. 9
3.6. Deleting a VLAN from the WebView ............................................................ 10
2
Implementation
1 Accessing to the Switch Remotely

The OmniSwitches have been reinitialized with a minimum Network configuration. Please note this is not an
empty configuration.
- A static route is configured to reach the administration network 10.0.0.0, allowing you to have IP
connectivity from your remote desktop to any switch of your R-Lab.
3
Switch Interface IP address

6900-A EMP 10.4.Pod#.1
6900-B EMP 10.4.Pod#.2
6560-A EMP 10.4.Pod#.3
6360-A EMP 10.4.Pod#.5
6360-B EMP 10.4.Pod#.6
6860-A EMP 10.4.100+Pod#.7
6860-B EMP 10.4.100+Pod#.8
- If the switch has an EMP interface (OS6900, OS6860E), an IP address will be assigned to it.
- If the switch does not have an EMP interface (OS6560, OS6360), a USB-to-Ethernet dongle is connected to
the usb port of the switch. This creates a USB-to-Ethernet interface for switches that do not have an EMP
port. This interface is treated as an EMP interface, and all EMP-related functions and CLIs are applicable
to the USB-to-Ethernet dongle.
- For example, check the IP interface of one switch which has an EMP interface (ex. 6900-A):
sw1 (6900-A) -> show ip interface
Total 3 interfaces
Flags (D=Directly-bound)
Name IP Address Subnet Mask Status Forward Device Flags

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.X.1 255.255.255.0 UP NO EMP
EMP-CMMA-CHAS1 0.0.0.0 0.0.0.0 DOWN NO EMP
Loopback 127.0.0.1 255.255.255.255 UP NO Loopback
---[truncated]---
- For example, check the IP interface of one switch which doesn’t have an EMP interface and uses the
dongle USB-to-Ethernet (ex. 6360-A):

Total 3 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.X.5 255.255.255.0 UP NO EMP
- From your Windows Desktop, open a console and try to ping the 8 switches:
C:\>ping 10.4.Pod#.1
C:\>ping 10.4.Pod#+100.7
C:\>ping 10.4.Pod#+100.8
4
2 Authenticating to the Switch

Authenticated Switch Access (ASA) provides the ability to restrict which users can configure the switch
remotely. Switch login attempts can be challenged via the local database, or a remote database such as RADIUS
or LDAP. ASA applies to Telnet, FTP, SNMP, SSH, HTTP, and the console and modem ports.
2.1. Enabling the SSH connection

- Log into the OS6560-A, then use the command to verify that the switch is checking its local database when
an SSH connection is attempted:
sw3 (6560-A) -> show aaa authentication
Service type = Default
1st authentication server = local
Service type = Console
Service type = Telnet
Service type = Ftp
Service type = Http
Service type = Snmp
Service type = Ssh
Notes > Why “local”?

The keywork “local” in “1st authentication server = local” means that the local database will be the first
database to be polled for authentication information.
Tips
If the SSH service type has Authentication = denied, type the command:
-> aaa authentication ssh local
2.2. Testing the SSH connection

- Test the SSH connection (by using the Teraterm software available in Windows Start button> All Programs
> Tera Term > Tera Term):
* Example with switch 3 pod 5

5
- Enter the following credentials:
- You are now connected to the OS6560-A via SSH:
2.2.1. Configuring the OmniSwitch

- First, we are going to change the Inactivity Timer
- Change the value of Inactivity Timer to “60”
- Save the modification in the running directory

sw3 (6560-A) -> session cli timeout 60
sw3 (6560-A) -> write memory
File /flash/working/vcsetup.cfg replaced.

File /flash/working/vcboot.cfg replaced.
sw3 (6560-A) -> show session config

Cli Default Prompt = sw3 (6560-A) ->,
Cli Banner File Name = ,
Cli Inactivity Timer in minutes = 60,
Ftp Banner File Name = ,
Ftp Inactivity Timer in minutes = 4,
Http Inactivity Timer in minutes = 4,
Http Banner File Name = ,
Login Timer in seconds = 55,
Maximum number of Login Attempts = 3,
6
3 Accessing to the WebView

The OmniSwitch can also be monitored and configured by using the WebView (Alcatel-Lucent Enterprise’s web-
based device management tool). The WebView application is embedded in the OmniSwitch and is accessible via
a web browser.
3.1. Setting up the HTTP Session

- Check that the HTTP service is enabled (ex. 6560-A):
Pod11sw3 login: admin
Password: switch
Sw3 (6560-A) -> show aaa authentication

[/TRUNCATED]
Service type = Http
[/TRUNCATED]
- As you can see here, HTTP authentication is enabled, and the first authentication server to be polled is
the local database.
Notes
By default, the WebView is enabled on the OmniSwitch but you are not allowed to authenticate. On the
Remote-Lab, the WebView access has already been enabled.
It is possible to disable it with the command: no aaa authentication http
- Check the WebView status:
sw3 (6560-A) -> show webview

Tips
SSL is forced by default in Release 8. It means that you can’t connect with plain HTTP on R8 OmniSwitches, you
will be automatically redirected to an HTTPS connection.
7
3.2. Opening the WebView

- From the Windows Desktop, open a Web Browser (ex. Firefox, Chrome)
- In the URL area, type https://<IP address of OS6560-A> (10.4.Pod#.3)
- Login to the WebView with the admin credentials:

User Name : admin
Password : switch
Language : English
After a successful connection, the dashboard page appears
The switch configuration is divided into seven main configuration groups

- Physical,
- Layer 2,
- Networking
- Service management,
- Security
- Quality of service
- Device management.
8
3.3. Configuring the OmniSwitch from the WebView

- First, we are going to change the Inactivity Timer from the WebView.
- From the horizontal menu bar at the top of the page, select Security > ASA, then click Session and then
Configuration.
Change the value to "45 for the CLI interface and “15” for the Webview" then click on Apply at the
bottom of the page
- From the CLI, check that the modification has been taken into account:
sw3 (6560-A) -> show session config
Cli Default Prompt = sw3 (6560-A) ->,
Cli Banner File Name = ,
Cli Inactivity Timer in minutes = 45,
Ftp Banner File Name = ,
Ftp Inactivity Timer in minutes = 4,
Http Inactivity Timer in minutes = 15,
Http Banner File Name = ,
Login Timer in seconds = 55,
Maximum number of Login Attempts = 3,
- Return to the Webview application. In the horizontal icon bar at the top of the page, select the third
icon from the left (write memory).
- Click yes to save the modification in the active directory (running).

9
3.4. Visualize your chassis

- In the horizontal menu bar at the top of the page, select Physical, then in the "Chassis management"
column, click on "Chassis visualization".
- You can hover with your mouse over the ports to get more information By clicking on a port you will be
redirected to the chassis port configuration page.
3.5. Creating a VLAN from the WebView
- Select Layer 2 > VLAN in the VLAN management column or in the left menu.
- Click on the "+" icon to create a new VLAN
- The table of the vlan created on the switch is displayed.
Vlan : 59
Description : Student
10
- Click on SUBMIT and the new VLAN 59 is displayed in the table
- Connect to the OmniSwitch 6560-A and verify that the VLAN has been created on the OmniSwitch :
sw3 (6560-A) -> show vlan

vlan type admin oper ip mtu name
------+-------+-------+------+------+------+------------------
1 std Ena Dis Dis 1500 VLAN 1
59 std Ena Dis Dis 1500 student
4094 vcm Ena Dis Dis 1500 VCM IPC
3.6. Deleting a VLAN from the WebView
- Select Layer 2 > VLAN Mgmt in the left-hand me

- Select the VLAN(s) to be deleted from the table (e.g. VLAN 59)
- Click on the " trashbin " icon to the right
- Click on yes
- In the CLI of the OmniSwitch 6560-A, verify that the VLANs have been deleted and save it on flash
running directory

------+-------+-------+------+------+------+------------------

OMNISWITCH R8
M A N A G I N G F I L E S / D I R E C TO R I E S
OBJECTIVES
• Describe the specificities of the OmniSwitch

switch bootup process
• Describe the OmniSwitch directories
architecture
• List the OmniSwitch Command Line Interface
(CLI) specificities
RELEASE 8 OMNISWITCHES
AOS RELEASE 8
OMNISWITCH 6360 OMNISWITCH 6560 OMNISWITCH 6860E/N OS6570M (GIGABIT METRO ETHERNET)
HARDENED SWITCHES
OMNISWITCH 6465
OMNISWITCH 6900 OMNISWITCH 9900
OMNISWITCH 6865
R8
AOS MANAGING FILES/DIRECTORIES
FLASH MEMORY • Rollback Based on the working, certified and User-defined
directories
USER DEFINED DIR
• Additional User-defined directories
• Created by the user (any name)
• Can be used to store additional switch configurations.
WORKING CERTIFIED USER. DIR. NETWORK • Configuration changes CAN be saved directly to any user-
defined directory
Uosn.img Uosn.img Uosn.img Policy.cfg log_Files *

vcboot.cfg vcboot.cfg vcboot.cfg
vcsetup.cfg vcsetup.cfg vcsetup.cfg
* swlog_chassis1. to 1.6
files and swlog_archive
(max 40 files)
OS6360 OS6465 OS6570 OS6860 OS6860N 0S6900 0S9900

OS6560 OS6865
Configuration vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg

files vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg
image files Nosa.img Nos.img Wos.img Uos.img Uosn.img Tos.img Mhost.img

(AOS) Mos.img
Yos.img Meni.img
(V72/C32/X48C
6/T48C6/
X48C4E/V48C8
T24C2 …
* Extract from “Release Notes –- Release 8.9R3
R8
• System Boot Sequence Flash RAM
• Bootstrap Basic Operation (U-Boot)
• Hardware Initialization BOOTROM 1
• Memory Diagnostics
• Image selection ROOT IMAGE

DIR
3 BOOT (KERNEL)
• AOS is copied and loaded into RAM SELECTION
2
• The image contains its own copy of WORKING
KERNEL.LNK FROM
the kernel specific to the SW version DIR. OS PACKAGE
CERTIFIED KERNEL.LNK FROM

DIR. OS PACKAGE
RUNNING DIRECTORY
4
USER DEFINED KERNEL.LNK FROM

DIR. OS PACKAGE
R8
FLASH MEMORY FLASH MEMORY
FLASH MEMORY
WORKING USER. DIR. CERTIFIED WORKING CERTIFIED USER. DIR. CERTIFIED
OR =
RAM
≠ DIFFERENT CONTENT
BOOT FROM THE

WORKING DIRECTORY
RAM RAM
WORKING
OR FROM THE USER
DEFINED DIRECTORY
OR CERTIFIED CERTIFIED
RUNNING CONFIGURATION
USER. DIR.
RUNNING CONFIGURATION RUNNING CONFIGURATION
Command to force reboot from WORKING directory or user defined directory: Command to force reboot from CERTIFIED directory:
-> reload from working no rollback-timeout -> reload all
-> reload from <userdefined> no rollback-timeout
R8
Configuration Rollback
Directory which the switch booted from and
where the configuration changes will be
saved
* Except when the Running directory is the Certified directory
WORKING & CERTIFIED directory are different
RAM content is different from the WORKING

directory content
For example : a configuration done on RAM but not save on flash. Lost in
case of reboot
sw7 (OS6860-A) -> write memory
WORKING and CERTIFIED directories content are

still different
The content of the RAM memory and WORKING

directory are similar (synchronized)
* Running configuration (RAM): current operating configuration of the switch retrieved from the running
directory in addition to any configuration changes made by the user.
R8
Configuration Rollback
WORKING and CERTIFIED directory are still

different
sw7 (OS6860-A) -> copy running certified
WORKING and CERTIFIED directory are similar
sw7 (OS6860-A) -> write memory flash-synchro = write memory + copy running certified
R8
• When the switch boots from the CERTIFIED
3
directory, changes made to the switch cannot
be saved and files cannot be moved between
directories.
FLASH MEMORY FLASH MEMORY
1 1
4
WORKING CERTIFIED USER. DIR. CERTIFIED
≠ DIFFERENT CONTENT 5
RAM RAM
2 2
CERTIFIED CERTIFIED
RUNNING CONFIGURATION RUNNING CONFIGURATION

R8
CONFIGURATION BACKUP & RESTORE
• Configuration Backup
• Backup of the session banner, userTable* and vcboot.cfg files
• The configuration backup command creates a .tar file where are stored the collected files
• The tar file name is “configuration_backup.tar” and will be placed in “/flash/config-backup-
recovery” folder
• Up to 10 .tar files can be stored in the /flash/config-backup-recovery directory

• Configuration Restore
• When the “restore” option is used, the switch:
• Selects the “configuration_backup.tar” file in “/flash/config-backup-recovery” folder
• Extract the .tar file to get the userTable, session banner, and vcboot.cfg files.
R8
• USB Backup and Restore
• If a USB drive is plugged in, switch will store image files, power supply and system configuration
files to USB storage drive automatically upon user commands “write memory” or “copy running-
certified” “copy flash-synchro” if USB backup is enabled on switch.
• The USB drive can be used to restore images and config (power supply and system) from the USB
drive on a switch with usb auto-copy command enabled.
• If the user configures a password at the time of enabling the back-up and restore, then the
corresponding back-up and restore content will be encrypted and decrypted.
usb backup admin-state {enable | disable} [key <> | hash-key<>]
usb auto-copy <enable | disable> copy-config <enable| disable> from <directory-path>

[key <> | hash-key<>]
R8
THIN CLIENT OMNISWITCH
• No configuration is stored on the switch. It will contact OmniVista 2500 to retrieve the
config.
• Thin-client mode is configured through the activation process.
• Switch boots up normally and registers to OV 2500 as part of the activation process.
• Thin-client mode must be configured as part of the activation response message.
• In thin-client mode, no configuration is saved in the ‘running’ directory
• But there will be vcboot.cfg with the minimal network reachability configuration.
• ‘write memory’ can be executed but configurations will not be saved to the vcboot,cfg file.
• All configuration changes should be done in OV 2500.
Callhome OmniVista 2500
Sends Config
R8
CLI – HELP > QUICK WALKTHROUGH
Command Line Interface (CLI) specifications
Online Help
A ‘?’ can be used to get a list of all possible commands

or
-> v?
VIEW VI
-> vlan ?
PORT NO IPMVLAN 802.1Q <vid> <vlan1-vlan2>
Directory management commands

Built-in Filtering
pwd – shows current directory.
cd – changes directory. -> show vlans | more
mkdir – creates a new directory. -> show mac-learning | grep 00:20:da:55:56:76
-> show ip ospf routes | egrep "^10\.10.*" | sort | less
ls – lists contents of a directory.
Completion
dir – lists contents of a directory.
Recognize partial keywords to CLI command syntax.
Eg : sh vl for show vlan mv – moves a file. CLI Line Editor and History
cp – copies a file.
rm – removes a file. -> history
1 write memory
2 show running-directory
3 ls /flash/working
4 show microcode working
5 show microcode certified
6 ls /flash/working
THANK YOU
OmniSwitch R8
OmniSwitches Directories Content (R8)
How to
✓ Manage the OmniSwitches R8 main directories content
Contents
1 Introduction .................................................................................... 2
2 Viewing the Image & Configuration Files .................................................. 2
3 Checking the working and certified Directories .......................................... 2
3.1. Displaying the working and certified directories content .................................... 2
3.2. Displaying the microcode version ................................................................ 3
4 Booting behavior in Release 8 ............................................................... 3
5 Determining from which directory the switch was loaded? ............................. 3
6 Synchronizing RAM and Running Directory ................................................. 4
7 Saving the Running Configuration to Working Directory ................................. 5
8 Creating a User-Defined Directory .......................................................... 7
9 Deleting the User Directory .................................................................. 8
10 Annex: USB Backup & Restore ............................................................... 8
2
1 Introduction
In Release 8, the management of an OmniSwitch is controlled by 2 types of files:
- Images files, which are proprietary code developed by Alcatel-Lucent Enterprise to run the hardware.
- A configuration files, named vcboot.cfg and vcsetup.cfg, in text format, sets and controls the
configurable functions.
The directory structure that store the image and configuration files is divided in several parts:
- The certified directory contains files that have been certified by an authorized user as the default files
for the switch.
- The working directory is a holding place for new files. Files in the working directory must be tested
before committing them to the certified directory.
- The user-defined directories are created by the user and are like the working directory in that they can
contain image and configuration files.
- The running directory is the directory where the configuration changes will be saved.
- The running configuration, stored in the RAM, contains the current operating parameters of the
OmniSwitch obtained from the image and configuration files.
2 Viewing the Image & Configuration Files

- Logging into the OmniSwitch
o Open the OS6560-A serial console (shortcut available on the Windows desktop).
o Use following authentication credentials:
Login: admin
Password: switch
3 Checking the working and certified Directories
3.1. Displaying the working and certified directories content

- Check the files that are in each directory by entering the following:
sw3 (6560-A) -> ls -l /flash/working |or| ls -l /flash/certified
total 109220
-rw-r--r-- 1 admin user 111683640 Sep 26 01:04 Nos.img
-rw------- 1 root root 46 Nov 3 03:17 boot.md5
-rwxr-xr-x 1 admin user 153 Nov 3 03:17 cloudagent.cfg
-rw-r--r-- 1 admin user 237 Jun 11 2016 cspbroker.conf
-rw-r--r-- 1 admin user 74 Sep 1 2015 imgsha256sum
drwxr-xr-x 4 admin user 4096 Jun 1 02:18 pkg
- rw-r--r-- 1 admin user 2787 Nov 3 03:15 vcboot.cfg
-rw-r--r-- 1 admin user 209 Nov 3 03:15 vcsetup.cfg
3
3.2. Displaying the microcode version

- To display the microcode version installed on the OmniSwitch:
sw3 (6560-A) -> show microcode working |or| show microcode certified |or| show microcode loaded
/flash/working
Package Release Size Description
-----------------+-------------------------+---------+-----------------------------------
Nos.img 8.7.98.R03 111683640 Alcatel-Lucent OS
Notes: “Loaded”?
- Loaded displays the currently active microcode versions.
- Entering the command show microcode also displays the currently active microcode version.
4 Booting behavior in Release 8
- At the time of a normal boot (cold start):

- The switch will reboot from certified directory if contents (images and vcboot.cfg) are different from
the running directory (which can be the working directory, or a user-defined directory).
- If contents are the same, the switch will reboot from the running directory (which can be the working
directory, or a user-defined directory).
Warning > The “reload all” command particularity

IF THE OMNISWITCH IS REBOOTED WITH THE “RELOAD ALL” COMMAND, IT WILL REBOOT FROM THE CERTIFIED
DIRECTORY, NO MATTER WHAT THE CONTENT OF THE RUNNING DIRECTORY IS (SAME/DIFFERENT THAN THE
CERTIFIED DIRECTORY CONTENT)
- If the running directory is the certified directory, you will not be able to save any changes made to the
running directory. If the switch reboots, any configuration changes will be lost. In order to save
configuration changes, the running directory cannot be the certified directory.
5 Determining from which directory the switch was loaded?

When a switch boots the RUNNING CONFIGURATION will come from either the certified, working, or
a user-defined directory. A switch can be rebooted to run from any directory using the reload from command.
To check from which directory the OmniSwitch is running, and the content comparison between the WORKING
and CERTIFIED directories:
sw3 (6560-A) -> show running-directory
CONFIGURATION STATUS
Running CMM : MASTER-PRIMARY,
CMM Mode : VIRTUAL-CHASSIS MONO CMM,
Current CMM Slot : CHASSIS-1 A,
Running configuration : WORKING,
Certify/Restore Status : CERTIFIED
SYNCHRONIZATION STATUS
Running Configuration : SYNCHRONIZED
- Running configuration: WORKING > the OmniSwitch is running from the working directory.
- Certify/Restore Status: CERTIFIED > the working directory content matches the certified directory
content.
- Running Configuration: SYNCHRONIZED > the running configuration matches the WORKING configuration.
4
6 Synchronizing RAM and Running Directory

Perform some configuration to make the running configuration different from the configuration stored in the
working and certified directories. Observe what happens.
- Performing modifications in the configuration

o Create 3 new VLANs (2, 3, and 99):

------+-------+-------+------+------+------+------------------
sw3 (6560-A) -> vlan 2

sw3 (6560-A) -> vlan 3
sw3 (6560-A) -> vlan 99

------+-------+-------+------+------+------+------------------
- 3 new VLANs are now created. Changes are made to the configuration file in RAM. These changes take
effect immediately but are not written permanently; they will be lost if the OmniSwitch reboots.
Running Configuration : NOT SYNCHRONIZED
- Running configuration: WORKING > the OmniSwitch is running from the WORKING directory.
- Certify/Restore Status: CERTIFIED > the working directory content matches the certified directory
content.
- Running Configuration: NOT SYNCHRONIZED > the running configuration does not match the
configuration of the working directory.
Warning > What if the OmniSwitch reboots now?

IF THE OMNISWITCH IS REBOOTED NOW (VIA A COMMAND RELOAD FROM WORKING … OR IF POWER TO THE
OMNISWITCH IS INTERRUPTED), THE OMNISWITCH WILL BOOT, ALL THE CHANGES IN THE RUNNING
CONFIGURATION WILL BE OVERWRITTEN, AND THE OMNISWITCH WILL ROLL BACK TO THE WORKING DIRECTORY,
SINCE THE WORKING AND CERTIFIED DIRECTORIES ARE THE SAME.
IN OUR CASE, THE VLAN 2, 3 AND 99 WILL BE LOST, AS THEY ARE NOW STORED IN THE RUNNING
CONFIGURATION.
5
7 Saving the Running Configuration to Working Directory

Save the configuration (VLANs created previously) from the running directory to the working directory. Verify it
by using CLI commands.
- To save the running configuration to the working directory:

- To check that:
Certify/Restore Status : CERTIFY NEEDED
- Running configuration: WORKING > the OmniSwitch is running from the working directory.
- Certify/Restore Status: CERTIFY NEEDED > the WORKING directory does not match the CERTIFIED
directory.
- Running Configuration: SYNCHRONIZED > the running configuration matches the configuration of the
working directory.

IF THE OMNISWITCH IS REBOOTED NOW (VIA A COMMAND RELOAD ALL OR IF POWER TO THE OMNISWITCH IS
INTERRUPTED), THE OMNISWITCH WILL BOOT FROM THE CERTIFIED DIRECTORY, ALL THE CHANGES IN THE
RUNNING CONFIGURATION WILL BE OVERWRITTEN, AND THE OMNISWITCH WILL ROLL BACK TO THE CERTIFIED
DIRECTORY.
HOWEVER, SINCE THE CONFIGURATION FILE WAS SAVED TO THE WORKING DIRECTORY, THAT FILE IS STILL IN
THE WORKING DIRECTORY AND CAN BE RETRIEVED.
SINCE THE WORKING AND CERTIFIED DIRECTORIES ARE NOT THE SAME, THE OMNISWITCH WILL BE RUNNING
FROM THE CERTIFIED DIRECTORY.
- Let’s reboot the OmniSwitch and see what happens:

sw3 (6560-A) -> reload all
Only one reload may be active in VC mode, other scheduled reloads will be canceled
Confirm Reload All (Y/N) : y
This operation will verify and copy images before reloading.

It may take several minutes to complete.
6
Running configuration : CERTIFIED,

------+-------+-------+------+------+------+------------------
- Note that when an OmniSwitch is running from the CERTIFIED directory, it is not possible to manipulate
files in the directory structure (i.e. a configuration will be applied in the running configuration, but it
will not be possible to save it neither in the working nor the certify directory):
sw3 (6560-A) -> vlan 4
ERROR: Write memory is not permitted when switch is running in certified mode
- Let’s reboot the OmniSwitch on Working directory where vlan have been recorded:
sw3 (6560-A) -> reload from working no rollback-timeout
Confirm Activate (Y/N) : y
It may take several minutes to complete...
- Let’s check if the vlan are present


------+-------+-------+------+------+------+------------------
4094 cm Ena Dis Dis 1500 VCM IPC
7
8 Creating a User-Defined Directory

User-defined directories are like the working directory in that they can contain image and configuration files.
These directories can have any name and can be used to store additional switch configurations. Configuration
changes CAN be saved directly to any user-defined directory.
- Create a user defined directory and copy the contents of the WORKING directory to it:
sw3 (6560-A) -> mkdir lab

sw3 (6560-A) -> cp working/*.* lab
cp: can't open 'working/boot.md5': Permission denied
Tips
The lab directory may have been already created, ignore error and proceed on.
During the copy; it tries to copy the boot.md5 file but a “permission denied” message is displayed. This file is
auto generated so ignore this error and proceed.
- Now let’s see what files are stored in the newly created directory:
sw3 (6560-A) -> ls lab
Nos.img cspbroker.conf vcboot.cfg.sav
cloudagent.cfg vcboot.cfg vcsetup.cfg
- Boot the switch from the new user-defined directory (lab):

sw3 (6560-A) -> reload from lab no rollback-timeout
Confirm Activate (Y/N): y
- Once the switch boots, verify that it booted from the lab directory:
Running configuration : lab,
- Running configuration: lab > the OmniSwitch is running from the user-defined lab.
- Certify/Restore Status: CERTIFY NEEDED > the running directory (“lab”) does not match the CERTIFIED
directory.
- Running Configuration: SYNCHRONIZED > the running configuration matches the configuration stored in
the running directory (here the user-defined “lab” directory)

IF THE OMNISWITCH IS REBOOTED (IF THE POWER TO THE OMNISWITCH IS INTERRUPTED), THE OMNISWITCH
WILL BOOT FROM THE CERTIFIED DIRECTORY, SINCE THE RUNNING (LAB) AND CERTIFIED DIRECTORIES ARE NOT
THE SAME (Certify/Restore Status: CERTIFY NEEDED).
- Overwrite the contents of the certified directory with the configuration from the running directory
(“lab” directory here):
sw3 (6560-A) -> copy running certified
Wed Apr 2 04:22:40 : flashManager FlashMgr Main INFO message:
+++ Verifying image directory lab on CMM flash
Wed Apr 2 04:23:04 : ChassisSupervisor MipMgr INFO message:
+++ Copy running to certified succeeded
8
Notes
The copy running certified command should only be done if the running configuration has been verified.
- Check the synchronization status:

Running configuration : lab,
- Running configuration: lab > the OmniSwitch is running from the user-defined lab.
- Certify/Restore Status: CERTIFIED > the running directory (“lab”) matches the CERTIFIED directory.
- Running Configuration: SYNCHRONIZED > the running configuration matches the configuration stored in
the running directory (here the user-defined “lab” directory)
IF THE OMNISWITCH IS REBOOTED (IF THE POWER TO THE OMNISWITCH IS INTERRUPTED), THE OMNISWITCH
WILL BOOT FROM THE “LAB” DIRECTORY, SINCE THE RUNNING (LAB) AND CERTIFIED DIRECTORIES ARE THE SAME
(Certify/Restore Status: CERTIFIED).
9 Deleting the User Directory

- Delete lab directory :
sw3 (6560-A) -> rm -Rf lab
sw3 (6560-A) -> ls -l lab
ls: lab: No such file or directory
10 Annex: USB Backup & Restore

In Release 8, it is also possible to backup the images and configuration from certified and running directories
into a USB key (/uflash/6860/certified and /uflash/6860/running directories).
Here is an example of a USB backup. This exercise cannot be done on the remote lab. The USB port is used to
connect the USB-to-Eth dongle
- To enable access to the device connected to the USB port:

sw3 (6560-A) -> usb enable
Tue Aug 14 14:00:26 : uflash uflashMain INFO message:

+++ /uflash interface enable
Mounting /dev/sdb1
+++ /uflash mounted
Tue Aug 14 14:00:26 : SSAPP main INFO message:

+++ CAUTION: Do usb disable before removing usb
WARNING: CAUTION: Do usb disable before removing usb
- To enable the USB backup feature on the switch:

9
sw3 (6560-A) -> usb backup admin-state enable

+++ Received SET for Admin State
+++ Just before calling /bin/uflashUtils usbBackUpEnable

+++ /uflash back up enable
+++ USB back-up Started
+++ /flash/certified backup to USB started
sw3 (6560-A) ->

+++ /flash/certified backup completed
+++ /flash/working backup to USB started

+++ /flash/working backup completed
+++ USB backup completed
- When this command is enabled, the images and configuration from certified and running directories are
copied into /uflash/6560/certified and /uflash/6560/running directories.
- When write memory is executed and backup is enabled, the configuration files and images from
/flash/<running-directory> are copied to /uflash/6560/<running-directory name> (ex. lab)
File /flash/working/vcsetup.cfg saved to USB.

File /flash/working/vcboot.cfg saved to USB.

10
- When usb backup admin-state is enabled and copy running certified and write memory flash-synchro
commands are executed, the configuration and images from /flash/certified will be copied to
/uflash/6560/certified:
sw3 (6560-A) -> write memory flash-synchro
File /flash/working/vcsetup.cfg saved to USB.

File /flash/working/vcboot.cfg saved to USB.
Tue Aug 14 14:03:32 : flashManager FlashMgr Main INFO message:

+++ Verifying image directory working on CMM flash
Please wait...

+++ Image file Nos.img differs - copying file

+++ Starting USB backup
Tue Aug 14 14:04:10 : ChassisSupervisor MipMgr INFO message:

+++ Copy running to certified succeeded
- To check the USB (uflash directory) content:

sw3 (6560-A) -> cd /uflash
sw3 (6560-A) -> ls
6560 System Volume Information
sw3 (6560-A) -> cd 6560
sw3 (6560-A) -> ls
certified working
sw3 (6560-A) -> cd working
sw3 (6560-A) -> ls
Nos.img vcboot.cfg vcsetup.cfg
sw3 (6560-A) -> cd ..
sw3 (6560-A) -> ls
certified working
sw3 (6560-A) -> cd certified
sw3 (6560-A) -> ls
Nos.img vcboot.cfg vcsetup.cfg
OMNISWITCH R8
V I RT U A L C H A S S I S
OBJECTIVES
• List the Virtual Chassis benefits

• Identify the Virtual Chassis specificities per
switch model
• List the different start up use case
• Summarize the Virtual Chassis configuration
steps
• List the synchronization steps occurring on a
switch which is part of a Virtual Chassis
VIRTUAL CHASSIS – OVERVIEW Master
1 2
Slave
1 2
• Goal
8 3
• Virtual Chassis = Group of switches which appears
3 6
as a single router or bridge Master
VFL
VFL 7 4
• Key Points
• Single Point of management 4 5 8 5
• Single Logical Switch

• Redundancy and resiliency supported across the
switches
• No STP/VRRP between Access and Core switches
• Optimized bandwidth usage
• Upgrade via ISSU (to minimize network impact) • How It Works?
• No license needed • Switches inter-connected via dedicated or optional
SFP+, QSFP ports
• Mesh or Ring topology
VIRTUAL CHASSIS - TOPOLOGIES
4 x OS6360 8 x OS6360 4 x OS6465 8 x OS6560 8 x OS6570
On 24/48
port models
OS6360 OS6465 OS6560 OS6570

Up to 2 stacking SFP ports Up to 2 VFL stacking ports Up to 2 VFL member ports 6570M-U28X/-U28XD
10G VFL ports 1G SFP ports (model P6/P12) Local stacking via dedicated 2x1G/10G SFP+ ports de
1G/10G SFP+ ports 20G VFL ports liaison montante/VFL
(model P28, TE28) and/or Remote stacking via
the 2 last 10G SFP+ ports
OS9900 8 x OS6865/OS6860/E/N
OS6860E/N/OS6865
Up to 2 VFL member ports
For 10Gbps For 40Gbps Up to 8 VFL member ports
2 x OS9900 OS99-XNI-U24/48 OS99-CNI-U8 Local stacking via
Native 40G QSFP on CMM with OS99-XNI-U12Q dedicated 20G VFL ports
40G-to-10G splitter cable OS99-XNI-P12Q and/or Remote stacking via
Native 40G QSFP ports on CMM
10G SFP+ ports
2 x 2 ports
For 100Gbps
OS99-CNI-U8
Native QSFP28 ports
VIRTUAL CHASSIS - TOPOLOGIES
OS6900-X/T48C6/X48C6/V48C8/C32E/X24C2/T24C2

OS6900
10G SFP+ for 40Gbps
Native 40G QSFP+
For 100Gbps
Native QSFP28 ports
VFL
OS6900-V72 / OS6900-C32

For 40Gbps
Native 40G QSFP+
For 100Gbps
Native QSFP28 ports
Support of 2,3,.. up to 6 in Partial or fully Mesh topology

OS6900-Q32 / OS6900-X72
• OS6900-X20/X40/T20/T40/Q32/X72 Up to 16 VFL member ports

models can be mixed in a VC of up to 6 elements For 10Gbps
Native 10G SPF+ ports
• OS6900-V72/C32(E)/X48C6/T48C6/V48C8/X24C2/T24C2 4 x 10G SFP+ with 40G-to-10G splitter cable on native QSFP
models can be mixed in a VC of up to 6 elements ports
For 40Gbps
• The OS6900-X48C4E does not support a VC configuration. Native 40G QSFP ports
VIRTUAL CHASSIS TOPOLOGY MANAGER
• VC topology managed by ISIS-VC
• Private TLV report the switch’s capability and numbering
• Exchange IS-IS HELLO for adjacencies and updates
• Maintains a loop-free topology for BUM traffic
• Determines the shortest path to each other element
• Builds the topology and maintains a forwarding database
• Break equal-cost ties in a deterministic manner ala SPBM
IS-IS HELLO I’m Chassis-2, my status is up, my
I’m Chassis-1, my status is up,
type X, my role is master role is slave, my master is 1, type X
Master Slave
1 2
Slave
Slave
3 6
OK, chassis-2 is type X.

Then all work in X mode.
4 5
Slave Slave
ROLES AND ELECTIONS
• Master and slaves communicate to ensure that the slaves have up-to date copies of the
master’s image files and configuration files.
• Reboot required after a slave update (new images and configuration files).
Master/Slave election
based on virtual chassis
protocol (ISIS-VC) IS-IS VC
Master Slave
Highest chassis priority value 1 2
Slave Slave
Longest chassis uptime 3 6
(if difference in uptime >10 mn)
4 5
Smallest Chassis ID value
Slave Slave
Smallest chassis MAC address

VIRTUAL CHASSIS TAKEOVER/FAILOVER
• Takeover/Failover
• Only master reloads, no impact on slaves, no traffic impact except related to master
• “MAC retention” is always enabled
• When the master reloads or fails, the slaves reelect a new master
• New master election is locally computed based on known partner keys
• The new master will confirm to its slaves the decision
• When the “original” master comes back, no election will be processed, and the “new” Master will
retain its Master role
Master Fails New Master elected Recovery of the original Master

Master Slave Master Slave Master
1 2 2 1 2
Slave Slave Slave Slave Slave Slave

3 6 3 6 3 6
4 5 4 5 4 5
Slave Slave Slave Slave Slave Slave
VIRTUAL CHASSIS SPECIFICATIONS
Extract from the technical documentation

« OmniSwith AOS Release 8 Specifications Guide »
VIRTUAL CHASSIS - AUTO VFL PORT
• Goal
• Automatically detect whether an auto VFL port can
become VFL
• Dynamically assign VFL ID to auto VFL port which can N vcsetup.cfg Y
exists?
become VFL
• Aggregate multiple auto VFL ports that can become
VFL and are connected to the same remote chassis
Default set of auto Auto VFL process
VFL eligible ports runs only on port
• Default set of auto VFL eligible ports (First bootup of brand-new explicitly configured
chassis from factory) as auto VFL port
Switch Model Auto VFL eligible ports
OS9900 Static VFL only

OS6900 X and T Last 5 ports of each chassis (including ports in expansion
* Auto VFL detection process will run only on auto VFL ports. Both ends
slots) regardless of SFP/QSFP presence on those ports.
of the link must be auto VFL ports for an auto VFL port to be able to
OS6900-V72/C32/X/T48C6 - The last 5 ports of the chassis. become VFL.
OS6860 - OS6860N Dedicated VFL ports.

OS6465-P28 Ports 27/28.
OS6560-24X4/-P24X4/-48X4/-P48X4 Dedicated VFL ports and last two 10G SFP+ ports on
(P)24X4/(P)48X4.
OS6360-24 - OS6360-48 OS6360-24 ports models - Ports 27/28.
OS6360-48 ports models - Ports 51/52.
VIRTUAL CHASSIS - SPLIT CHASSIS
• Failures on VFL links cause potential MAC/IP • RCD protocol will detect this split topology.
duplication
• 2 mechanisms
Virtual Chassis
• Out of Band: EMP Remote Chassis Detection (RCD)
• In Band: VC Split Protocol
Master Master
Slave
• EMP Remote Chassis Detection (RCD

• A switch sends an announcement whenever its
chassis VC information changes
The former Slave chassis will shutdown all its front-panel user ports to prevent duplicate IP
and chassis MAC addresses in the network.
Virtual Chassis
The Slave's chassis status will be modified from Running to Split-Topology to indicate this
Reboot with all
Master Master
Slave Interfaces second pseudo-master chassis is not operational at this point
down
EMP EMP
If the VFL comes back up, the former Slave chassis will reboot and rejoin the virtual chassis
port port
OS6860E topology assuming its Slave role again
RCD OS6900
protocol OS9900
Management network
RCD use the following IP addresses in order of preference

1. CMM IP address stored in NVRAM (if configured)
2. Chassis EMP IP address
VIRTUAL CHASSIS - SPLIT CHASSIS
Helper Switch
In Band: VC Split Protocol Protection Mode
Master role
All Interfaces
Link Aggregation shutdown
Helper Switch Except VFL & LAG
AOS support
Potential
OS6860
duplicate MAC/IP
MASTER MASTER
SLAVE
VSCP
ACCESS
Link Aggregation
Building 1 Building 2
Platforms Supported in R8
MASTER SLAVE
ACCESS
Extract from C os8_cli_87R2-revA

Building 1 Building 2
• Requires an upstream or downstream device to act as helper switch Use the virtual-chassis split-protection admin-state and virtual-chassis split-
protection linkagg commands to enable VCSP and create the VCSP link aggregate
• Proprietary protocol called “VC Split Protocol” on the VC.
• VCSP LAG towards the helper switch Use the virtual-chassis split-protection helper admin-state and virtual-chassis
split-protection helper linkagg commands to enable the VCSP helper and create
• Every VC member switch recommended to have one port as part of the the VCSP helper link aggregate on the helper switch
VCSP LAG to the helper device Extract from OmniSwitch AOS Release 8 Switch Management Guide
IN SERVICE SOFTWARE UPGRADE (ISSU)
• Goal
• Used to upgrade the software on a VC with minimal
network disruption
3
• Each element is upgraded individually 1
Master – Chassis ID 1
Slave – Chassis ID = 2
• Step by Step
issu-dir Directory
• Upload new code, vcsetup.cfg and vcboot.cfg Issu_dir Directory
in a new directory (ex. issu_dir) vcboot.cfg
vcboot.cfg vcsetup.cfg code
• Launch the dedicated issu command
vcsetup.cfg
• The image and configuration files are then
Slave – Chassis ID = 3
copied to all of the Slaves code
2
• The Slaves are then reloaded from the ISSU
directory in order from lowest to highest Issu_dir Directory
chassis ID code
vcboot.cfg vcsetup.cfg
REMOTE CLI ACCESS THROUGH ANY MEMBER ON A VC
• A user can access to remote CLI console of any • Supported Platforms:
VC with secure shell protocol (SSH). • OS9900, OS6900, OS6860N, OS6860/OS6865,
OS6560, OS6465, OS6360.
ssh-chassis <username>@<chassis-id>
User is connected to master chassis (ID =1)
User tries to access chassis ID 2
-> ssh-chassis admin@2 1

Executing: ssh [email protected]
([email protected]) Password: 2
-> show virtual-chassis topology

Legend: Status suffix "+" means an added unit after last saved topology
Local Chassis: 2
Oper Config Oper
Chas Role Status Chas ID Pri Group MAC-Address
-----+------------+---------------+--------+-----+------+------------------
1 Master Running 1 100 0 2c:fa:a2:61:3a:2d
2 Slave Running 2 100 0 2c:fa:a2:60:ff:6b
VIRTUAL CHASSIS - CONFIGURATION
VIRTUAL CHASSIS CONFIGURATION
Step by Step
Switch Bootup
• Main use case
N Y
vcsetup.cfg exists?
Disable Auto
configuration Y
on boot
VC Mode
Auto Vcsetup
AUTO-VC VFL : AUTO or
created
Static Management
Auto VC consists of the following: VC created automatically

1. Auto VFL • Chassis ID and Group ID
(Start in certified mode)
2. Auto Chassis ID Assignment
Step by Step
• VFL: AUTO or STATIC Management
Assign a Chassis ID
Assign a Chassis Group ID and a Priority
Configure VFL link & ports -Automatic or static
Restart Chassis to Virtual-Chassis Directory

Step by Step
Assign a Chassis ID
Assign a Chassis ID
Must be different for each switch belonging to the Virtual Chassis
Chassis 1 Chassis 2
1 2
Assign a Chassis Group ID and a Priority

Assign a Chassis Group number
Must be the same on all the switches belonging to the Virtual Chassis
Define a Priority
Between 0 to 255, switch with the highest priority is elected Master
Chassis 1 (Priority: 200) Chassis 2 (Priority: 100) 1
1 2
Step by Step
Configure Automatic VFL mode Configure Static VFL link & ports
Specify ports that are designated as VFLs Create VFL ID
and software will automatically assign VFL IDs. Specify its member ports

1/2/1
VFL 2/2/1
1 2
1/2/2 2/2/2
Reload the switches

Reload both chassis from the directory containing the vcsetup.cfg & vcboot.cfg files

VFL
1 2
VIRTUAL CHASSIS SYNCHRONIZATION
VIRTUAL CHASSIS SYNCHRONIZATION- EXAMPLE
-> write memory
RAM
WORKING CERTIFIED
MASTER
RUNNING
CONFIGURATION
-> show running-directory

WORKING CERTIFIED
CONFIGURATION STATUS SLAVE
CMM Mode : VIRTUAL-CHASSIS
MONO CMM, … …
Flash Between CMMs : NOT SYNCHRONIZED, WORKING CERTIFIED
Running Configuration : SYNCHRONIZED SLAVE
VIRTUAL CHASSIS SYNCHRONIZATION - EXAMPLE
-> copy running certified
RAM
WORKING CERTIFIED
MASTER
RUNNING
CONFIGURATION
WORKING CERTIFIED
SLAVE
… …
WORKING CERTIFIED
SLAVE
VIRTUAL CHASSIS SYNCHRONIZATION - EXAMPLE
-> copy flash-synchro
1 2
RAM
WORKING CERTIFIED WORKING CERTIFIED

RUNNING
CONFIGURATION
CMM Mode : VIRTUAL-CHASSIS
WORKING CERTIFIED WORKING CERTIFIED MONO CMM,

Certify/Restore Status: CERTIFIED
… SYNCHRONIZATION STATUS
Flash Between CMMs : SYNCHRONIZED,
WORKING CERTIFIED WORKING CERTIFIED
-> write memory flash-synchro - This command can also be used to synchronize the virtual chassis
THANK YOU
OmniSwitch R8
Virtual Chassis-6360
How to
✓ This lab is designed to familiarize you with the Virtual Chassis feature (VC)
and its configuration.
Contents
1 Configure a Virtual Chassis of two switches ............................................... 2
1.1. Objective ............................................................................................ 2
1.2. Management ......................................................................................... 3
2 Virtual Chassis Monitoring.................................................................... 6
2
1 Configure a Virtual Chassis of two switches
1.1. Objective
3
1.2. Management
- Assign a globally unique chassis identifier to the switch 6360A and enable the switch to operate in virtual
chassis mode
sw5 (6360-A) -> show virtual-chassis topology
Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
1 Master Running 1 100 0 94:24:e1:7c:82:1d
sw5 (6360-A) -> virtual-chassis chassis-group 1

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
sw5 (6360-A) -> show configuration vcm-snapshot chassis-id 1

! Virtual Chassis Manager:
virtual-chassis chassis-id 1 configured-chassis-id 1
virtual-chassis vf-link-mode static
virtual-chassis chassis-id 1 chassis-group 1
!
! PLEASE DO NOT MODIFY THE AREAS OF [SAVED INFO xxx]
! [SAVED INFO VC IDs] 1
!
! IP:
- Force the 6360-A to be the master chassis, assign a highest chassis priority to it:
sw5 (6360-A) -> virtual chassis-id 1 configured-chassis-priority 200

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
Notes:
A reload is mandatory to take account the chassis priority

It may take several minutes to complete..
4
Notes:
Wait until complete restart. (* close to 4 mn in lab context)
Tue Jun 22 03:04:41 : qosNi Info INFO message:

+++ VC Takeover in progress.
+++ VC Takeover complete.
Chassis Supervision: CMM has reached the ready state [L8]

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- Assign a globally unique chassis identifier to the switch 6360B and enable the switch to operate in virtual
chassis mode
sw6 (6360-B) -> show virtual-chassis topology

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
1 Master Running 1 100 0 94:24:e1:7c:79:65
sw6 (6360-B) -> virtual-chassis chassis-id 1 configured-chassis-id 2

sw6 (6360-B) -> virtual-chassis chassis-group 1

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- Check the result
sw6 (6360-B) -> show configuration vcm-snapshot chassis-id 2

! IP:
Notes:
A reload is mandatory to take account the new chassis -id
sw6 (6360-B) -> write memory
WARNING - Virtual chassis topology change detected. Chassis 1 missing!

Configuration associated with missing chassis will be erased permanently!
Confirm to continue (Y/N) : y

5
The command write memory is protected by issuing a warning to prevent or warn purging the configuration of
the elements that are missing. Chassis id has been changed in this case.
sw6 (6360-B) -> reload from working no rollback-timeout

It may take several minutes to complete..
Notes:
Wait until complete restart.
Tue Jun 22 03:04:41 : qosNi Info INFO message:
Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- Configure member ports for the VFL on 6360-A:
sw5 (6360-A) -> virtual-chassis vf-link-mode auto

sw5 (6360-A) -> virtual-chassis auto-vf-link-port 1/1/27
sw5 (6360-A) -> virtual-chassis auto-vf-link-port 1/1/28
sw5 (6360-A) -> show configuration vcm-snapshot chassis-id 1

virtual-chassis vf-link-mode auto
virtual-chassis auto-vf-link-port 1/1/27
virtual-chassis chassis-id 1 configured-chassis-priority 200
! IP:
- Configure member ports for the VFL on 6360-B:
sw6 (6360-B) -> virtual-chassis vf-link-mode auto

sw6 (6360-B) -> virtual-chassis auto-vf-link-port 2/1/27
sw6 (6360-B) -> virtual-chassis auto-vf-link-port 2/1/28
sw6 (6360-B) -> show configuration vcm-snapshot chassis-id 2

! IP:
6
- Activate the corresponding interface

sw5 (6360-A) -> interfaces 1/1/27-28 admin-state enable
Notes:
On the 6360-B, INTERFACE 2/1/27 and INTERFACE 2/1/28 automatically LINK UP and the switch Reboot.
- Wait for a moment after reboot (*reboot: close to 5 mn in lab context)

o Message will be display on 6360-A.
Fri Oct 1 06:46:47 : intfCmm Mgr INFO message:

+++ Link 2/1/27 operationally up
Fri Oct 1 06:46:56 : isisVc vcprot INFO message:

+++ isisVcUpdateVcNodes@7059: Adding peer chassisId 1 (mac 94:24:e1:7c:79:f5)
+++ isisVcUpdateVcNodes@7421: New Master: chassisId 1 chassisMac 94:24:e1:7c:79:f5
Fri Oct 1 06:46:57 : vcmCmm ipc INFO message:

+++ CMM:vcmCMM_peer_connected@2494: Remote endpoint (chassis 1, slot 65) [L4]
2 Virtual Chassis Monitoring
- Check the virtual-chassis topology:
Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
2 Slave Running+ 2 100 1 94:24:e1:7c:79:65
Notes:
suffix “+”, if any VC element is detected as “Running” but not configuration saved
- Save the configuration and Check the virtual-chassis topology and Copy running to certified:

Tue Jun 22 04:00:05 : flashManager Main INFO message:

+++ Verifying image directory working on CMM flash
Please wait...
Tue Jun 22 04:00:41 : ChassisSupervisor bootMgr INFO message:

+++ Copy running to certified: Synchronizing chassis 2
Tue Jun 22 04:00:49 : ChassisSupervisor MipMgr INFO message:
+++ Copy running to certified succeeded; Secondary synchronization succeeded
7
- Check the result

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
2 Slave Running 2 100 1 94:24:e1:7c:79:65
- Display the vcsetup.cfg file content on the master

sw5 (6360-A) -> cat /flash/working/vcsetup.cfg
!========================================!
! File: /flash/working/vcsetup.cfg !
!========================================!
virtual-chassis chassis-id 1 configured-chassis-priority 200
!
!
! IP:
- Display the different ports belonging to the VFL link, type:
sw5 (6360-A) -> show virtual-chassis vf-link
VFLink mode: Auto
Primary Config Active Def Speed

Chassis/VFLink ID Oper Port Port Port Vlan Type
-------------------+----------+---------+-------+-------+---------+-----------
1/0 Up 1/1/27 2 2 1 10G
2/0 Up 2/1/27 2 2 1 10G
sw5 (6360-A) -> show virtual-chassis vf-link member-port
VFLink mode: Auto
Chassis/VFLink ID Chassis/Slot/Port Oper Is Primary

-------------------+------------------+----------+-------------
1/0 1/1/27 Up Yes
1/0 1/1/28 Up No
2/0 2/1/27 Up Yes
2/0 2/1/28 Up No
Notes:
The “Is Primary” field defines the primary port of the virtual fabric link.
8
- Verify the consistency of system-level mandatory parameters between the two chassis:
-
sw5 (6360-A) -> show virtual-chassis consistency
Legend: * - denotes mandatory consistency which will affect chassis status
licenses-info - A: Advanced; B: Data Center;
Config Oper Oper Config

Chas Chas Chas Hello Control Control
Chas* ID Status Type* Group* Interv Vlan* Vlan License*
------+------+---------+-------+------+-------+--------+--------+----------
1 1 OK OS6360 1 15 4094 4094 A
2 2 OK OS6360 1 15 4094 4094 A
Notes:
The two chassis in the same Virtual-Chassis group must maintain identical configuration and operational
parameters.
- You can access to the secondary VC by typing the following:
sw5 (6360-A)-> ssh-chassis admin@2

([email protected])
***********************
* *
* Welcome To Rlab LAN *
* Pod 20 Switch 6 *
* 6360-B *
* *
***********************
Password: switch
- Although the prompt is the same, you are now connected to the secondary VC. Type the following:
sw5 (6360-A)-> show virtual-chassis topology

Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
1 Master Running 1 200 1 2c:fa:a2:05:cd:71
2 Slave Running 2 100 1 2c:fa:a2:05:cd:a9
- Look at the Local Chassis parameter. Now it says 2, which means you are connected to the secondary VC.
log
- Type the following to return to the master VC:
sw5 (6360A) -> logout

logout
Connection to 127.10.2.65 closed.
- Disable all unused interfaces:

sw5 (6360-A) -> interfaces 1/1/1-26 admin-state disable
sw5 (6360-A) -> interfaces 2/1/1-26 admin-state disable
9
- Check that the HTTP service is enabled (ex. 6360-A):

Pod11sw3 login: admin
Password: switch
Sw5 (6360-A) -> show aaa authentication

[/TRUNCATED]
Service type = Http
[/TRUNCATED]
- As you can see here, HTTP authentication is enabled, and the first authentication server to be polled is
the local database. If it is not, enable it via the command : aaa authentication http local
Notes
By default, the WebView is enabled on the OmniSwitch but you are not allowed to authenticate. On the
Remote-Lab, the WebView access has already been enabled.
- Check the WebView status:
Sw5 (6360-A) -> show webview

- Opening the WebView from the Windows Desktop, open a Web Browser (ex. Firefox, Chrome)
- In the URL area, type : https://10.4.pod#.5

-
Login to the WebView with the admin credentials:
-
User Name : admin
Password : switch
Language : English
- After a successful connection, the dashboard page appears

- Visualize your chassis In the horizontal menu bar at the top of the page, select Physical, then in the
"Chassis management" column, click on "Chassis visualization".
OMNISWITCH R8
VLAN MANAGEMENT
OBJECTIVES
• Understand the VLAN features

• Setup Static and Dynamic VLAN
• Configure Static and dynamic Ports assignment
• Configure inter VLAN routing
• Configure VLAN Tagging
VLAN MANAGEMENT
• Goal
• Logically segment a Local Area Network (LAN) into
different broadcast domains
• Ease of network management
• Provides a more secure network
Vlan 30
• How it works
• Ports become members of VLANs by
• Static Configuration Vlan 50
Vlan10 Vlan 60
• Mobility/with or without Authentication *
• 802.1q
* With authentication : Seen in the following chapter (Access Guardian)

VLAN MANAGEMENT - STATIC VLAN MEMBERSHIP
• Goal
• The initial configuration for all OmniSwitch consists
of a default VLAN 1 and all switch ports are initially
assigned to this VLAN
• Ports can be statically assigned to VLANs. 1/1/1

• When a port is assigned to a VLAN, a VLAN port VLAN 1
association (VPA) is created and tracked by VLAN 1/1/2
management switch software
VLAN 3
VLAN 4
VLAN 5
1/1/4
VLAN 6
1/1/6
VLAN MANAGEMENT - STATIC VLAN MEMBERSHIP
Configuration –Step by step
Defining a VLAN
-> vlan 2
Assigning Ports to a VLAN

-> vlan 2 members port <chassis/slot/port> untagged
Optional commands
-> vlan 4 admin-state enable
-> vlan 4 name Engineering
Use quotes around string if the VLAN name contains multiple words with spaces between them
-> vlan 10-15 100-105 200 name “Training Network”
Monitoring
-> show vlan 4
-> show vlan members
-> show ip interface
VLAN MANAGEMENT - DYNAMIC VLAN MEMBERSHIP
• Goal
• VLAN is assigned depending on the device or the

user
• Device oriented : VLAN according to traffic criteria VLAN 1
(MAC@, etc…)
• User oriented: Authenticated VLAN (IEEE 802.1x for VLAN 2
enhanced security) *
VLAN 3
VLAN 4
VLAN 5
VLAN 6
* With authentication : Seen in the following chapter (Access Guardian)

• How it works
• When traffic is received on a unp port:
• The packets are examined to determine if their content matches any of the VLAN rules configured on the
switch . If so, the mobile port is assigned to that VLAN
• Upon receiving a frame, Source Learning compares the frame with VLAN Policies in Order
Classification
Rules
UNP Port classification rules

1. Port/Linkagg
2. Domain
3. MAC address
Precedence
4. MAC-OUI
5. MAC address range
6. LLDP
7. Auth-type
8. IP address
9. VLAN tag
• Device oriented : VLAN according to traffic criteria (MAC@, etc…)
• Unp classification rules Configuration (R8) – step by step
UNP profile
Enabling a mobile port VLAN ID
-> unp port 1/1/1 port-type bridge Policy List
ACL QoS
Configure UNP profile
*
-> unp profile employee Location
Period
Map the vlan to UNP
* Policy list, location and period will be seen
in the following chapter (Access Guardian)
unp profile employee map vlan 20
• Device oriented : unp according to traffic criteria (MAC@, etc…)
• unp classification rules Configuration – step by step
• When classification is enabled but authentication is disabled or fails,UNP classification rules are appliedto
the traffic received on the UNP port.
• MAC Address rule UNP Port classification rules

1. Port/Linkagg
unp classification mac-address mac_address profile1 profile_name
2. Domain
Eg: -> unp classification mac-address 00:11:22:33:44:55 profile1 employee
3. MAC address
4. MAC-OUI
• Ip adress rule 5. MAC address range

6. LLDP
unp classification ip-address ip_address mask mask profile1 profile_name
7. Auth-type
Eg: -> unp classification ip-address 10.0.0.20 mask 255.255.0.0 profile1 employee
8. IP address
9. VLAN tag
• Mac range rule

unp classification mac-address-range low_mac_address high_mac_address profile1 profile_name
Eg: -> unp classification mac-address-range 00:11:22:33:44:55 00:11:22:33:44:66 profile1 employee
• Device oriented: unp according to traffic criteria (MAC@, etc…)
• unp classification rules Configuration (R8) – step by step
• Configuring Binding Rules for UNP Profiles
• Combination of one or more individual rules all of which a device has to match
1 Port + MAC address + IP address
2 Port + MAC address
3 Port + IP address
4 Domain ID + MAC address + IP address
• Eg : Binding rule that combines a MAC address rule, an IP address rule, and a port rule
-> unp classification mac-address 00:11:22:33:44:55 ip-address 10.0.0.20 mask 255.255.0.0 port 1/1/1 profile1 employee
• Configuring Extended Classification Rules for UNP Profiles

• List of individual rules and assigns the list a name and a precedence value.
A device must match all of the rules specified in the extended rule list.
-> unp classification-rule ext-r1 precedence 255
-> unp classification-rule ext-r1 profile1 employee
-> unp classification-rule ext-r1 port 1/1/10
-> unp classification-rule ext-r1 vlan-tag 10
• “ext-r1” rule combines a port rule and vlan tag type rule
• Precedence: Extended rule > Binding Rule > Simple Rule

Example of Device oriented: unp according to traffic criteria (MAC@ range)
• Create the required VLANs

-> vlan 10 admin-state disable name vlan10-block
UNP Port -> vlan 20 admin-state enable name vlan20-corporate
Employee
• Create the required UNP profile and map the profile to VLAN 20
No Auth -> unp profile corporate
-> unp profile corporate map vlan 20
Classification • Create another UNP profile that will serve as a default profile
Rules and map the profile to VLAN 10
-> unp profile def_unp
-> unp profile def_unp map vlan 10
UNP Profile
• Create a MAC range classification rule and associate the rule to
the “corporate” UNP profile
-> unp classification-rule rule1 mac-address-range 08:00:27:00:98:0A 08:00:27:00:98:FF
Default -> unp classification-rule rule1 profile1 corporate
UNP Profile
• Enable UNP on the user port that will connect to user device
-> unp port 1/1/1 port-type bridge
Block
• Set the default UNP profile on the user port
-> unp port 1/1/1 default-profile def_unp
INTER VLAN ROUTING
INTER VLAN ROUTING
• IP interfaces are associated with VLANs
• IP routing is active as soon as at least one IP interface is associated with a VLAN
1/1/2
VLAN 20
Virtual Router
The operational status of a VLAN
remains inactive as long as no active
port is associated with this VLAN
1/1/6
VLAN 60
-> ip interface <int_name> address <ip address/mask> vlan <vlan_id>

INTER VLAN ROUTING
• Virtual Router
Gateway for Device VLAN 20
ip interface Data address 10.1.20.254 mask 255.255.255.0 vlan 20

Total 2 interfaces
1/1/2 Name IP Address Subnet Mask Status Forward Device
VLAN 20 --------------+-------------+----------------+--------+--------+--------
Data 10.1.20.254 255.255.255.0 UP NO vlan 20
Voice 10.1.60.254 255.255.255.0 UP NO vlan 60
Virtual Router
-> show vlan 20
Name : data,
Type : Static Vlan,
Administrative State : enabled,
Operational State : enabled,
IP Routing : enabled,
IP MTU : 1500
-> show vlan 20 members

1/1/6 port type status
---------+---------+--------------
VLAN 60 1/1/2 untagged forwarding
Gateway for Device VLAN 60

ip interface Voice address 10.1.60.254 mask 255.255.255.0 vlan 60
802.1Q – VLAN TAGGING
802.1Q – VLAN TAGGING
• Aggregates multiple VLANs across Ethernet links
• Combines traffic from multiple VLANs over a single link
• Encapsulates bridged frames within standard IEEE 802.1Q frame
• Enabled on fixed ports
• Tags port traffic for destination VLAN
Tagged Frames
IEEE 802.1Q – TAGGED VLANS
• VLAN Tag • 802.1P

• 802.3 MAC header change • Three-bit field within 802.1Q header
• 4096 unique VLAN Tags (addresses) • Allows up to 8 different priorities
• VLAN ID == GID == VLAN Tag • Feature must be implemented in hardware
VLAN ID (12 Bits)

802.1p (3 bits)
“Modified 802.3 MAC”
DA SA Ethertype, Priority, Tag
4 Bytes
802.1Q - CONFIGURATION
-> vlan 2-4

-> vlan 2-4 members port 1/1/24 tagged
VLAN 4
VLAN 4
VLAN 3
VLAN 3
VLAN 278 VLAN 278
1/1/24 1/1/24
-> show vlan members VLAN 2

VLAN 2
DYNAMIC VLAN MEMBERSHIP
DYNAMIC VLAN MEMBERSHIP - AUTHENTICATED METHOD
How it works Authentication Method
• MAC-based (non-supplicant)
• Applies to users connected on or
• 802.1x-based (supplicant)
authenticated ports { "user"
User-Password="xxxxxx"
• Users must authenticate through 802.1x RADIUS Access-Request }
Filter-ID = "UNP-name"
client RADIUS Access-Accept + UNP name
• Authentication is based on either RADIUS,

LDAP or TACACS+ UNP R8
VLAN INTERNET
• Successful login: 30 ONLY VLAN ID
The client is associated GUEST Policy List

with the correct UNP MEDIUM LOW ACL QoS
BWDTH PRIORITY
Restrict the network access based on
the location of the user/device
Location Chassis/Slot/Port on which the user is
VLAN NO HR, Period
attached Switch Name on which the
20 FINANCE DB user is attached
EMPLOYEE Switch Location String, identifying a
group of Switches
MEDIUM MEDIUM
BWDTH PRIORITY Specifies the days and times during
which a device can access the network
* 802.1X and Mac authentication will be seen in more details in the following chapter (Access Guardian)
THANK YOU
OmniSwitch R8
VLANs
How to
✓ Manage VLANs on the OmniSwitches
Contents
1 Topology ........................................................................................ 2
2 Creating a VLAN ............................................................................... 2
3 Creating Additional VLANs ................................................................... 7
4 Dynamic VLAN Membership ................................................................ 11
5 Deleting VLANs & IP interfaces ............................................................ 14
2
VLANs
1 Topology
Below the topology that will be used during this lab:
2 Creating a VLAN
VLANs provide the ability to segregate a network into multiple broadcast domains. Additionally, Virtual Router
ports (or IP Interfaces) can be assigned to VLANs to allow traffic to be switched at Layer 3.
- In its untagged configuration, the switch has only one VLAN, the VLAN 1. This is the default VLAN and all
ports are initially associated with it. This VLAN CANNOT be deleted, but it can be disabled if desired.
- Let’s run the command to see the VLANs that exist on the switch as well as information on a single VLAN
(ex. 6360-A):
sw5 (OS6360-A) -> show vlan
stree mble src
vlan type admin oper 1x1 flat auth ip tag lrn name
-----+-----+------+------+------+------+----+-----+-----+------+----------
1 std on off on on off off off on VLAN 1
3
VLANs
- To display information on a specific VLAN:

sw5 (6360-A) -> show vlan 1
Name : VLAN 1,
Type : Static Vlan,
Administrative State : enabled,
Operational State : disabled,
IP Routing : disabled,
IP MTU : 1500
- Notice the VLAN Administrative State is enabled, however its Operational State is disabled. Without
members the VLAN will be Operationally down.
Notes
You can also list the ports and their associated VLAN (notice that the status of all the ports is “inactive”, so the
Vlan is operationally down):
-> show vlan members
- Enter the following command on the switch (OS6360-A):

sw5 (6360-A) -> show vlan members
vlan port type status
--------+------------+------------+--------------
1 1/1/1 untagged inactive
- Display the VLAN assignment on a specific port (ex. port 1/1):

sw5 (6360-A) -> show vlan members port 1/1/1
vlan type status
--------+-----------+---------------
1 untagged inactive
- In order to have IP connectivity to a VLAN interface (not required for connectivity to other
clients/servers within a VLAN), an IP address (IP interface) must be assigned to a Virtual Router port and
associated to that VLAN. This IP address can then be used for IP connectivity as well as Layer 3
switching.
4
VLANs
- To create the IP interface (ex. int_1 = IP interface name, 192.168.10.5 = IP@ of the IP Interface):
sw5 (6360-A) -> ip interface int_1 address 192.168.10.5/24

Total 3 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 DOWN NO unbound
- The Device status is unbound. It is because the IP interface has not been associated to a VLAN yet.
- To bind the IP Interface (ex. int 1) to a VLAN (ex. VLAN 1):
sw5 (6360-A) -> ip interface int_1 vlan 1
Notes
The last 2 commands can be merged into a single command:
-> ip interface int_1 address 192.168.10.5/24 vlan 1
- Check that the IP Interface is now associated to the VLAN 1:

Total 3 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 DOWN YES vlan 1
- If Status = DOWN, it indicates no active ports or devices have been associated with the VLAN that the IP
interface has been assigned to. If an IP interface is DOWN, it cannot be connected to, will not reply to
PING requests nor will it be advertised in any router updates. This will not affect the Layer 2 broadcast
domain, however.
- Let’s activate a port in VLAN 1 to change the status to enable:
sw5 (6360-A) -> interfaces 1/1/1 admin-state enable
sw5 (6360-A) ->

Mon Jun 21 23:31:44 : intfCmm Mgr INFO message:
Tips
The equipment connected to the port 1/1/1 of the 6360-A is the Client 5 virtual machine:
- Then check the port status:

vlan type status
--------+-----------+---------------
1 untagged forwarding
-
5
VLANs
- By default, all ports (including the port 1/1/1) belong to VLAN 1, so the VLAN 1 will become active.
- Run the command to check that the status of the IP interface is UP:
Total 3 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 UP YES vlan 1
Now that the VLAN has an active port, let’s modify the IP information of the Client 5, and ping the IP
interface associated with VLAN 1.
- Open the virtual machine Client 5 and set its IP address:
Windows Desktop
Double-click on VMware
vSphere
Select the Client5 in the list
Click on Console tab
Double click on Network

Connections
6
VLANs
Select the network connection

Pod
Click on Internet Protocol

(TCP/IP)
Select Use the following IP

address
- IP address: 192.168.10.105
- Subnet mask:
255.255.255.0
- Default gateway:
192.168.10.5 (The IP address
of VLAN 1 virtual router)
- From Client 5, open a command prompt and ping the switch’s VLAN 1 Virtual Router IP address. You
should now have IP connectivity:
7
VLANs
3 Creating Additional VLANs

Currently, there is only the default VLAN created on the switch (except for the VLAN 4001, which is a VLAN used
for the R-Lab administration). The following steps will provide information on creating another VLAN, enabling
IP on the VLAN, moving ports into the VLAN, and forwarding IP packets between VLANs.
- To begin, let’s create a new VLAN and assign an IP address to that VLAN as done previously:
sw5 (6360-A) -> vlan 50
sw5 (6360-A) -> ip interface int_50 address 192.168.50.5/24 vlan 50
- Let's look at what we have configured so far:

Total 4 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 UP YES vlan 1
int_50 192.168.50.5 255.255.255.0 DOWN NO vlan 50

------+-------+-------+------+------+------+------------------
1 std Ena Ena Ena 1500 VLAN 1
50 std Ena Dis Ena 1500 VLAN 50
- Why the status of the IP interface int_50 is DOWN?

> ___________________________________________________________________________________
- Assign the VLAN 50 to the port 1/1/2 where Client 9 is connected:

sw5 (6360-A) -> vlan 50 members port 1/1/2 untagged

Total 4 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 UP YES vlan 1
int_50 192.168.50.5 255.255.255.0 DOWN NO vlan 50

vlan type status
--------+-----------+---------------
50 untagged inactive
sw5 (6360-A) -> interface 1/1/2 admin-state enable
Mon Jun 21 23:38:46 : intfCmm Mgr INFO message:

8
VLANs

Total 4 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_1 192.168.10.5 255.255.255.0 UP YES vlan 1
int_50 192.168.50.5 255.255.255.0 UP YES vlan 50
- Assign an IP address to the Client 9:
Windows Desktop
vSphere

Connections
9
VLANs

Pod

(TCP/IP)

address
- IP address: 192.168.50.55
- Subnet mask:
255.255.255.0
- Default gateway:
192.168.50.5 (The IP address
of VLAN 50 virtual router)
10
VLANs
The following diagram represents the current configuration.
By default, the switch will route packets between VLAN 1 and VLAN 50 using the IP interfaces that you have
created.
- Check the routing table on the switch:

sw5 (6360-A) -> show ip routes
+ = Equal cost multipath routes

Total 5 routes
Dest Address Gateway Addr Age Protocol

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 3d16h LOCAL
192.168.10.0/24 192.168.10.5 00:11:04 LOCAL
192.168.50.0/24 192.168.50.5 00:04:03 LOCAL
- From client 9, open a command prompt and ping the client 5. You should now have IP connectivity:
11
VLANs
4 Dynamic VLAN Membership

- In this exercise, VLAN is assigned depending on the device.
- Device oriented: VLAN according to traffic criteria (In this example base on MAC@).
- To begin, let’s create a new VLAN:

sw5 (6360-A) -> vlan 40
- As we haven't yet managed the DHCP server at this stage in the training, we'll assign a static IP address
to client 6. Assign an IP address to the Client 6:
Windows Desktop
vSphere
Select the Client 6 in the list.

Power on if need. (Right click)

Connections
Or
12
VLANs

Pod

(TCP/IP)

address
- IP address: 192.168.40.106
- Subnet mask:
255.255.255.0
And click on OK
Click on Support and details
And note the mac adress
- Enable interface 2/1/1 where is connected the client 6

13
VLANs
- Check Vlan and status on the port

sw5 (6360-A) -> sh vlan members port 2/1/1
vlan type status
--------+-----------+---------------
- Check Mac-learning table for the port 2/1/1. (example with pod 5 client 6)
sw5 (6360-A) -> show mac-learning port 2/1/1
Legend: Mac Address: * = address not valid,
Mac Address: & = duplicate static address,
Domain Vlan/SrvcId[ISId/vnId] Mac Address Type Operation Interface

------------+----------------------+-------------------+------------------+-------------+-------------------------
VLAN 1 00:50:56:90:ee:0a dynamic bridging 2/1/1
Total number of Valid MAC addresses above = 1
- Configure UNP profile

sw5 (6360-A) -> unp profile employee
- Map the vlan to UNP

sw5 (6360-A) -> unp profile employee map vlan 40
- Configure a unp classification rule based on mac address. In this command, mac address is the client 6 of
pod5.in your case, check result on show mac-learning command done previously
sw5 (6360-A) -> unp classification mac-address 00:50:56:90:ee:0a profile1 employee
- Check unp user

sw5 (6360-A) -> sh unp user
No UNP Ports found
- Enable UNP on the user port that will connect to user device
sw5 (6360-A) -> unp port 2/1/1 port-type bridge
- Flush the port

sw5 (6360-A) -> unp user flush port 2/1/1
- Check unp user

sw5 (6360-A) -> sh unp user
User
Port Username Mac address IP (V4/V6) Vlan Profile Type Status
-------+--------------------+-----------------+------------------------+----+--------------------------------+----+-----------
2/1/1 00:50:56:90:ee:0a 00:50:56:90:ee:0a - 40 employee Bridge Active

vlan type status
--------+-----------+---------------
40 unpUntag forwarding
14
VLANs
5 Deleting VLANs & IP interfaces

- Before continuing with the other labs, remove the previous configuration: delete the VLAN 50, and the
IP interfaces (int_1 and int_50).
sw5 (6360-A) -> no ip interface int_50
sw5 (6360-A) -> no vlan 50
Notes
VLAN 1 cannot be deleted. It is only possible to deactivate.
- Check that the VLAN 50 and the IP interfaces have been correctly deleted:
------+-------+-------+------+------+------+------------------
1 std Ena Ena Dis 1500 VLAN 1

Total 2 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
- Remove the previous configuration about unp classification
sw5 (6360-A) -> sh configuration snapshot DA-UNP

! DA-UNP:
unp profile "employee"
unp profile "employee" map vlan 40
unp port 2/1/1 port-type bridge
unp port 2/1/1 port-template bridgeDefaultPortTemplate
unp classification mac-address 00:50:56:90:ee:0a profile1 "employee"
sw5 (6360-A) -> no unp classification mac-address 00:50:56:90:ee:0a
sw5 (6360-A) -> no unp port 2/1/1
sw5 (6360-A) -> no unp profile "employee"
sw5 (6360-A) -> sh configuration snapshot DA-UNP

! DA-UNP:

vlan type status
--------+-----------+---------------
OMNISWITCH R8
D I A G N O S T I C TO O L S
OBJECTIVES
• Use the Switch & Command Logging utilities

• Use the Remote MONitoring (RMON) application
• Enable the Port Mirroring feature
• Enable the Port Monitoring feature
• Check the Switch Health
• Use the sFlow Application
SWITCH LOGGING
SWITCH LOGGING OUTPUT
• Event logging utility
• Useful in maintaining and servicing the switch sw1 (6900-A) -> show swlog
Operational Status : Running
File Size per file : 1250 Kbytes,
Log Device 1 : console flash,
• Switch events can be logged to Syslog FacilityID : local0(16),
Hash Table entries age limit : 60 seconds,
• Switch console Switch Log Preamble : Enabled,
Switch Log Debug, : Disabled
-> swlog output console Switch Log Duplicate Detection : Enabled,
Console Display Level : info,
RFC5424 Format Logging : Disabled,
• Local text file Swlog Threshold : 90 percent
-> swlog output flash
swlog output socket console enable
• Configurable default file size 1250 Kbytes
When this command is enabled, syslog server
• Multiple remote devices (syslog) 12 max will be restarted and allowing send Console
-> swlog output socket ipaddr 168.23.9.100 log to remote Syslog servers
• Loopback0 have to be configured
SWITCH LOGGING FILES
• Switch logging are stored in /flash directory
sw1 (6900-A) -> ls -l
drwxr-xr-x 2 admin user 4096 Jun 7 09:15 app-signature
• Up to 7 Swlog logs files can be stored in the drwxr-xr-x
-rw-r--r--
2 admin
1 admin
user
user
4096
255
Jun
Jun
7
7
07:57
09:11
certified
hwinfo
/flash directory starting (from swlog_chassis1 to 1.6) -drwxr-xr-x 2 admin user 16384 Dec 18 2013 lost+found
drwxr-xr-x 2 admin user 4096 Feb 10 2016 network
drwxr-xr-x 3 admin user 4096 Apr 23 2015 pmd
drwxr-xr-x 7 admin user 4096 Jun 7 07:57 switch
• An Swlog archive can store up to 40 files drwxr-xr-x
-rw-r--r--
2 admin
1 root
user
root
4096
560111
Jun
Jun
8
10
10:53
12:50
swlog_archive
swlog_chassis1
-rw-r--r-- 1 root root 1280031 Jun 10 12:44 swlog_chassis1.0
• Configuring the Switch Logging File Size -rw-r--r-- 1 root root 1280027 Jun 10 12:12 swlog_chassis1.2
-> swlog output flash-file-size 12500 -rw-r--r-- 1 root root 1280094 Jun 10 11:41 swlog_chassis1.4
(in bytes)
DISPLAYING SWITCH LOGGING RECORDS
• Clear the log files contents
-> swlog clear
• Clear both the log files contents and event logs

-> swlog clear all
• Displaying Switch Logging Records
-> show swlog sw1 (6900-A) -> show swlog
Operational Status : Running
Syslog FacilityID : local0(16),
Switch Log Preamble : Enabled,
Switch Log Debug, : Disabled
Switch Log Duplicate Detection : Enabled,
Console Display Level : info,
RFC5424 Format Logging : Disabled,
Swlog Threshold : 90 percent
sw1 (6900-A) -> show log swlog

-> show log swlog /flash/swlog_chassis1.7 not found!
Displaying file contents for '/flash/swlog_chassis1.6'
2017 Jun 10 10:43:46 Pod18sw1 Switch log file reached 100%, overwritten !!!
2017 Jun 10 10:43:46 Pod18sw1 swlogd: ospf_0 INFO debug2(7) (11654):(3157):ENTER select
usec=870000, lastMs=264773690, curMs=264773820.
2017 Jun 10 10:43:46 Pod18sw1 swlogd: SSAPP main info(5) sending trap for swlog failure trap
2017 Jun 10 10:43:47 Pod18sw1 swlogd: rip_0 INFO debug2(7) (9046):(1779):ripRun: ENTER select
usec=998000, lastMs=264774578, curMs=264774630.
SWITCH LOGGING SEVERITY LEVEL
• Default severity level is “info”. The numeric equivalent for the level “info” is 6
• It is also possible to assign different severity levels to different switch applications (some
of the events will be filtered out of the display)
SWITCH LOGGING APPLICATION ID LEVELS OF REPORTING
• Specific applications may have different levels of reporting and can be specified by their
application ID or by their numeric equivalent
show swlog appid ?
^
ALL <string>
SWLOG PMD ChassisSupervisor flashManager MIP_GATEWAY
ConfigManager capManCmm vc_licManager vcmCmm SSTIME SSAPP
mrvld capManSig fabric portMgrCmm vfcm intfCmm dafcCmm
linkAggCmm VlanMgrCmm ipmscmm pvlanCmm isis_spb_0 isisVc
stpCmm AGCMM slCmm mirMonSFlowCmm ipv4 ipv6 ipsecSys ipsec
tcamCmm qosCmm vstkCmm eoamCmm erpCmm NTP udpRelay
remoteConfig AAA havlanCmm SES rmon WEBVIEW trapmgr radCli
ldapClientCmm tacClientCmm healthCmm svcCmm lldpCmm udldCmm
evbCmm mpls saaCmm SNMP csEventMonitor bfdcmm mvrpCmm
dhcp6r messageService dhcpv6Srv dhcpSrv grm bcdcmm lpCmm
DG_CMM qmrCmm iprm_0 vrrp_0 ospf_0 flashManagerNI capManNi
vcmNi portMgrNi bcd vfcn intfNi dafcNi linkAggNi VlanMgrNi
stpNi erpNi vstkNi fdbmgr1 slNi healthNi ipni ip6ni
mirMonSFlowNi tcamni qosNi ipmsni svcNi evbNi lldpNi udldNi
bfdni mvrpNi AGNI DG_NI nipktrly loamNi eoamNi fdbmgr4 lpNi
fdbmgr3
SWITCH LOGGING APPLICATION ID
• Example of levels of reporting management for OSPF
• All sub application
sw1 (6900-A) -> swlog appid ospf_0 subapp all level 8 or sw1 (6900-A) -> swlog appid ospf_0 subapp all level debug3
• Only for the hello message

sw1 (6900-A) -> swlog appid ospf_0 subapp hello level debug3
sw1 (6900-A) -> swlog appid ospf_0 subapp ?

ALL <num> <string>
1=ERROR 2=WARNING 3=RECV 4=SEND
5=FLOOD 6=SPF 7=LSDB 8=RDB 9=AGE
10=VLINK 11=REDIST 12=SUMMARY
13=DBEXCH 14=HELLO 15=AUTH 16=STATE
17=AREA 18=INTF 19=CONFIG 20=INFO
21=SETUP 22=TIME 23=MIP 24=TM
25=RESTART 26=HELPER 27=HOST
28=AUTOCONFIG
• Timestamps
• show log swlog [timestamp mm/dd/yyyy hh:mm:ss]
2017 Jun 10 10:43:59 Pod18sw1 swlogd: ospf_0 AREA debug2(7) (11654):(3254):[curTime=251171s] Flooding area 0.0.0.0
2017 Jun 10 10:43:59 Pod18sw1 swlogd: ospf_0 TIME debug2(7) (11654):(1259):Intf addr 172.16.17.1, curTime = 251171, helloTimer = 251497, deadTimer = 75447
• Application
• show log swlog |grep [appid] |grep [subapp] …
sw1 (6900-A) -> show log swlog |grep ospf
2017 Jun 10 10:43:46 Pod18sw1 swlogd: ospf_0 INFO debug2(7) (11654):(3157):ENTER select usec=870000, lastMs=264773690, curMs=264773820.
2017 Jun 10 10:43:47 Pod18sw1 swlogd: ospf_0 INFO debug2(7) (11654):(3163):EXIT select with n=0, lastMs=264773690, curMs=264773820, drcTimeGetMs=264774691
2017 Jun 10 10:43:47 Pod18sw1 swlogd: ospf_0 INFO debug2(7) (11654):(3157):ENTER select usec=999000, lastMs=264774690, curMs=264774691.
• Reverse
• To display logs from the most recent to the oldest
• show log swlog [timestamp mm/dd/yyyy hh:mm:ss] [slot chassis/slot] [reverse]
READABLE CUSTOMER EVENT LOGS
• OmniSwitch is now designed to provide Readable Customer Event information about
important events on the Switch
• User-friendly, consistent and customer readable format.
• Use the following CLI commands to view Readable Customer Events.

• swlog appid command with level event to filter switch logging information for events
swlog appid all subapp all level event
• To display customer event logs, enter the following command:

show log events
• The log output is in the following format:
• <SWLOG TIMESTAMP> : <CMM>/<NI> : <MODULE_NAME> : <LOG_DESCRIPTION>
2019 Apr 28 19:17: 8.83 : CMM : ChassisSupervisor : chassisTrapsAlert - CERTIFY w/ FLASH SYNCHRO process started
COMMAND LOGGING
OVERVIEW
• Command Logging
• Logs commands and output
• Different than command history
• Displays additional information
• Creates command.log file in /flash directory
• Command results stored in command.log
• Deleting command.log deletes log history
• Cannot be deleted while command logging is enabled
• Stores 100 most recent commands
• Must be enabled
-> command-log enable/disable
-> swlog remote command-log enable/disable
EXAMPLE
-> show command-log
Command : vlan 68 router ip 168.14.12.120
UserName : admin
Date : MON APR 28 01:42:24
Ip Addr : 128.251.19.240
Result : SUCCESS
Command : vlan 68 router ip 172.22.2.13
UserName : admin
Date : MON APR 28 01:41:51
Ip Addr : 128.251.19.240
Result : ERROR: Ip Address must not belong to IP VLAN 67 subnet
Command : command-log enable
UserName : admin
Date : MON APR 28 01:40:55
Ip Addr : 128.251.19.240
Result : SUCCESS
UserName : admin
Date : MON APR 28 11:13:13
Ip Addr : console
Result : SUCCESS
-> show command-log status

CLI command logging: Enable
PORT MIRRORING
PORT MIRRORING
• Overview • Ports supported
• Copies all incoming and outgoing traffic from one • Ethernet, Fast/ Gigabit Ethernet, 10/ 40 Gigabit
switch port to another Ethernet
• Destination port could be local (same switch) or • Port requirements - must be of identical capacity
remote (different switch)
• Provides the ability to perform a packet capture
• Specifications
-> port mirroring <id> source <s/s/p> destination <s/s/p>

-> port-mirroring 1 source 1/1/2-6 1/1/9 1/3/5 destination 1/2/4
PORT MIRRORING
• Port-mirroring Sessions and Destination Ports
• On the 6860(E), 6860N, 6865, 6900 (all) in 8.9R3.
• The same destination port can be used in different port mirroring sessions and the maximum port-mirroring
sessions has been increased from 2 to 4.
• There is a limit of 4 Mirror-to-port (MTP) indexes.
• Bi-directional counts as two MTP indexes for each destination port in the session.
• If a destination port is configured on multiple sessions and has the same source port mirror direction as those sessions the
MTP index will only be counted once.
-> port-mirroring source destination
• Port Mirroring - Remote Over Linkagg

• Remote port mirroring over a link aggregate is now supported on the OS6560. (in 8.9R3)
-> port-mirroring destination linkagg
PORT MONITORING
PORT MONITORING
• Captures data and stores in Sniffer format on switch
• Ports supported
• Ethernet, Fast/ Gigabit Ethernet, 10/40 Gigabit Ethernet
• Captures first 64-bytes of frame
• Session supported per switch or stack: 1
• Default file size:
• R8: 64 KB (max = 2 MB)
• Round-Robin or stop capture when max storage reached
• Cannot use port monitoring and mirroring on same port
• Data stored in compliance with the ENC file format (Network General Sniffer Format)
• 6 – session ID
-> show port monitor file
• Session can be paused, resumed, disabled and associated with a timeout
-> port monitoring 6 source 1/2/3 enable

REMOTE MONITORING
REMOTE MONITORING - RMON
• RMON probes are used to collect, interpret and forward statistical data about network
traffic from designated active ports in a LAN segment
• Can be monitored using OmniVista
• 4 groups supported:
• Ethernet Statistics – Gather Ethernet port statistics (e.g. port utilization, error statistics)
• History Group - Stores sampling such as utilization and error count
• Alarms Group – Compare samplings to thresholds (e.g. absolute or relative, rising and falling thresholds)
• Events Group – Controls generation a notification to NMS station
-> rmon probes alarm enable Probe’s Owner: Analyzer-p:128.251.18.166 on Slot 1, Port 35
History Control Buckets Requested = 2
-> rmon probes stats enable History Control Buckets Granted = 2
-> show rmon probes history 30562 History Control Interval = 30 seconds
History Sample Index = 5859
Entry 10325
Flavor = History, Status = Active
Time = 48 hrs 53 mins,
System Resources (bytes) = 601
SYSTEM HEALTH
OVERVIEW
• Monitors switch resource utilization and thresholds
• Switch-level Input/Output
• Memory and CPU Utilization Levels
• Most recent utilization level (percentage)
• Average utilization level over the last minute (percentage)
• Average utilization level over the last hour (percentage)
• Maximum utilization level over the last hour (percentage)
• Threshold level
-> show health
sw8 (6860-B) -> show health
CMM Current 1 Min 1 Hr 1 Day
Resources Avg Avg Avg
--------------------+---------+-------+-------+-------
CPU 11 13 11 0
Memory 57 57 57 0
SFLOW
SFLOW - NETWORK MONITORING TECHNOLOGY
• Industry standard with many vendors • sFlow data applications
• Delivering products with sFlow support (RFC 3176) • Detecting, diagnosing and fixing network problems
• Gives visibility in to the activity of the network • Real time congestion management
• Provides network usage information and network • detecting unauthorized network activity (DOS)
wide view of usage and active routes • Usage accounting and billing
• Used for measuring network traffic, collecting, • Understanding application mix (web, DNS etc.)
storing and analyzing the traffic data • Route profiling and peering optimization
• Capacity planning
OmniSwitch
Forwarding tables
sFlow Agent
Sampling
Interface counters
Switching ASICs
Network
OVERVIEW
• Traffic flows monitoring and sampling technology embedded within switches
• sFlow Agent software process running as part of the switch software
• sFlow Collector which receives, analyses the monitored data (3rd Party software)
• sFlow Collector makes use of SNMP to communicate with a sFlow agent in order to configure sFlow
monitoring on the device (switch)
sFlow
sFlow
sFlow
sFlow
Packet Header In/out if Sampling params Forwarding User ID URL Counters

Rate Src 802.1p/Q Src/Dst
pool Dst 802.1p/Q Radius
Next hop TACACS
Src/dst mask
AS path
Communities
SWITCH CONFIGURATION
• One agent to represent whole switch
->• ip service source-ip {Loopback0 | interface-name} sflow
AGENT
->• show sflow agent
• Represents the remote collector {destination IP address + port} RECEIVER

• Encodes samples into UDP datagrams
•-> sflow receiver 1 name Server1 address 192.168.1.100
-> sflow receiver 2 name server2 address 172.30.130.102
• One Sampler for each interface

• Collects packet samples
-> sflow sampler 1 port 1/1/6 receiver 1 rate 5 sample-hdr-size 64 SAMPLER
• One Poller for each interface
-> sflow poller 1 port 1/1/6 receiver 1 interval 20 POLLER
• Collects counter samples
-> show sflow receiver
-> show sflow sampler
-> show sflow poller
THANK YOU
OmniSwitch R8
Switch maintenance and Diagnostics tools
How to
✓ This lab is designed to familiarize you with some basic troubleshooting and
debugging tools on an OmniSwitch.
Contents
1 Switch Logging ................................................................................. 2
2 Readable Customer Event Logs.............................................................. 3
3 Command Logging ............................................................................. 4
4 Port Mirroring .................................................................................. 5
5 Port Monitoring ................................................................................ 5
6 Health ........................................................................................... 7
7 RMON............................................................................................ 7
2
1 Switch Logging
Switch Logging can be used to track informational or debugging messages from the switch. This is
dependent upon the severity level set for a particular process. Logging can be configured to send its output
to flash, console, or an external server. By default, switch logging is enabled
- On the 6860-A, type the following:
sw7 (6860-A) -> show swlog
Operational Status : Running,
Switch Log Debug : Disabled,
Console Display Level : info
- You should see that logging is running and sending its output to both flash and the console. It does not
mean that all messages will be displayed on the console, only messages matching the severity level, by
default, informational (6). Logging can be disabled if desired.
- Type the following:
sw7 (6860-A) -> swlog disable
sw7 (6860-A) -> show swlog

Operational Status : Not Running,
Switch Log Debug : Disabled,
Console Display Level : info
- To re-enable logging enter :

sw7 (6860-A) -> swlog enable
- The logging feature has a number of application IDs. These IDs are used to determine which process
generated the logging message and at what severity level. Consult the user guide for a list of processes
and associated severity levels. By default all processes are set to a severity level of 6, which is
informational, as indicated above. All logging messages are stored in the swlog*.log files and can be
viewed right on the switch.
sw7 (6860-A) -> show log swlog
Notes
Use CTRL+C keys to stop the display of the file.
You may also use show log swlog | grep “string to find” or show log swlog timestamp mm/dd/yy
hh:mm:ss to find specific information on the log file.
3
2 Readable Customer Event Logs
AOS is now designed to provide Readable Customer Event information about important events on the
OmniSwitch in a user-friendly, consistent and customer readable format. A new set of CLI commands are
introduced to view Readable Customer Events. Unlike AOS Syslog, Readable Customer Event feature provides
logs for the most significant switch events
- On the 6860-A, type the following:
sw7 (6860-A) -> swlog appid all subapp all level event
- To display customer event logs, enter the following command.

sw7 (6860-A) -> show log events
2019 Jul 15 20:26:27.515 : CMM : vc_licManager : Demo License will expire on date: 7/14/2019
2019 Jul 15 20:26:53.212 : CMM : ChassisSupervisor : chassisTrapsAlert - Power supply is OK: PS 1
2019 Jul 15 20:26:53.213 : CMM : ChassisSupervisor : chassisTrapsAlert - All power supplies OK
2019 Jul 15 20:26:53.213 : CMM : ChassisSupervisor : The switch was restarted by the user
2019 Jul 15 20:26:53.213 : CMM : ChassisSupervisor : chassisTrapsAlert - CMM startup completed
2019 Jul 15 20:27:35.755 : CMM : stpCmm : STP instance 1: Bridge has become new Root
2019 Jul 15 20:27:50.148 : CMM : vcmCmm : Virtual Chassis: Chassis 1 Role changed to Master
2019 Jul 15 20:27:50.148 : CMM : vcmCmm : Virtual Chassis: Chassis 1 Status changed to Running
2019 Jul 15 20:27:50.149 : CMM : ChassisSupervisor : Sending VC Takeover to NIs and applications [L6]
2019 Jul 15 20:27:52.299 : CMM : ChassisSupervisor : System Ready
2019 Jul 15 20:37:21.569 : CMM : stpCmm : STP instance 112: Bridge has become new Root
2019 Jul 15 20:39:47.696 : CMM : intfCmm : Link 1/2/1 operationally up
2019 Jul 15 20:39:51.772 : CMM : stpCmm : STP instance 112: Root port change detected
2019 Jul 15 20:47: 3.234 : CMM : intfCmm : Link 1/2/1 operationally down
2019 Jul 15 20:47: 4.370 : CMM : stpCmm : STP instance 112: Bridge has become new Root
2019 Jul 15 20:49:32.102 : CMM : intfCmm : Link 1/2/1 operationally up
...
- Compare the output of this command with the show log swlog from the previous section
Notice the difference in the output of both commands
The show log events command has the following output:
<SWLOG TIMESTAMP>: <CMM>/<NI>: <MODULE_NAME>: <LOG_DESCRIPTION>

4
3 Command Logging
Like switch logging, commands entered on the OmniSwitch can captured to a log file. These can then be
reviewed later to see what changes have been made. This is a very valuable tool, especially when modifying
the switch configuration.
sw7 (6860-A) -> show command-log
sw7 (6860-A) -> command-log enable
- Let's create and delete a couple of VLAN's to demonstrate:

sw7 (6860-A) -> vlan 4-5
sw7 (6860-A) -> no vlan 4-5
sw7 (6860-A) -> show command-log

Command : no vlan 4-5
UserName : admin
Date : Tue Feb 11 03:54:58
Ip Addr : console
Result : SUCCESS
Command : vlan 4-5

UserName : admin
Date : Tue Feb 11 03:54:53
Ip Addr : console
Result : SUCCESS

UserName : admin
Date : Tue Feb 11 03:53:33
Ip Addr : console
Result : SUCCESS
- You should now see the commands you entered displayed on the screen with information about the time
and where they were entered from, such as a console or TELNET session.
- To disable it enter :
sw7 (6860-A) -> command-log disable
5
4 Port Mirroring
Port mirroring can be configured to copy traffic from one or multiple ports to another. The destination port
would normally have a traffic analyzer connected.
- Let’s create a mirroring session to copy traffic from one port to another.
sw7 (6860-A) -> port-mirroring 1 source port 1/1/1 destination port 1/1/10
sw7 (6860-A) -> port-mirroring 1 enable
sw7 (6860-A) -> show port-mirroring status 1
Session Mirror Mirror Unblocked RPMIR Config Oper

Destination Direction Vlan Vlan Status Status
----------+-----------+--------------+----------+---------+----------+---------
1. 1/1/10 - NONE NONE Enable On
----------+-----------+--------------+----------+---------+----------+---------
Mirror
Source
----------+-----------+--------------+----------+---------+----------+---------
1. 1/1/1 bidirectional - - Enable On
- To remove a port mirroring session, enter :

sw7 (6860-A) -> no port-mirroring 1
The maximum number of mirroring sessions is limited to two.
5 Port Monitoring
Port Monitoring makes it possible to capture traffic being sent to and from a port and store it in /flash in
".enc" (or Sniffer) format. The data is stored in a file named pmonitor.enc by default, but this can be
modified. The file can then be transferred off the switch and viewed in detail using a traffic analyzer. It is
also possible to display the output directly to the console or to a telnet session.
- Start a port monitoring session :
sw7 (6860-A) -> port-monitoring 1 source port 1/1/1 enable
sw7 (6860-A) -> show port-monitoring status
Sess Mon. Mon. Over Oper. Admin Capt. Max. File

Src Dir write Stat Stat Type Size Name
-----+-------+----+-----+------+------+-------+------+-----------------------
1. 1/1/1 Bi ON ON ON Brief 64K /flash/pmonitor.enc
- Generate traffic from client by issuing pings to any reachable address.

- The session can be paused and resumed if necessary, type the following:
sw7 (6860-A) -> port-monitoring 1 pause

-----+-------+----+-----+------+------+-------+------+-----------------------
1. 1/1/1 Bi ON OFF ON Brief 64K /flash/pmonitor.enc
sw7 (6860-A) -> port-monitoring 1 resume

sw7 (6860-A) -> port-monitoring 1 disable
WARNING:
Monitored data is available in file /flash/pmonitor.enc
6
- You should now see a message indicating that it has finished writing the capture file. The data is stored in
a file called pmonitor.enc in the /flash directory.
sw7 (6860-A) -> ls -l
total 7948
-rw-r--r-- 1 admin user 4053444 Jan 1 2021 UAppSig.upgrade_kit
drwxr-xr-x 2 admin user 4096 Jan 5 2021 bootflash
drwxr-xr-x 2 admin user 4096 Jan 1 00:06 certified
-rw-r--r-- 1 admin user 66402 Feb 11 03:54 command.log
drwxr-xr-x 2 admin user 4096 Dec 4 17:20 diags
-rw-r--r-- 1 admin user 526184 Dec 4 17:20 eeprom
drwxr-xr-x 5 admin user 4096 Jan 1 00:04 externalCPU
drwxr-xr-x 2 admin user 4096 Feb 8 01:19 foss
-rw-r--r-- 1 admin user 239 Feb 8 01:20 hwinfo
drwxr-xr-x 2 admin user 4096 Jan 1 2021 labinit
drwxr-xr-x 2 admin user 16384 Dec 4 17:21 lost+found
drwxr-xr-x 2 admin user 4096 Jan 5 2021 network
drwxr-xr-x 3 admin user 4096 Jan 5 2021 pmd
-------r-- 1 root root 4835 Feb 11 04:09 pmonitor.enc
drwxrwx--- 2 root admins 4096 Jan 1 00:00 python
-rw-r--r-- 1 admin user 2848 Jan 2 21:45 snapall
drwxr-xr-x 6 admin user 4096 Jan 1 00:01 switch
-rw-r--r-- 1 admin user 735660 Jan 1 2021 swlog
drwxr-xr-x 2 admin user 4096 Feb 8 01:21 swlog_archive
-rw-r--r-- 1 admin user 740893 Feb 11 04:09 swlog_chassis1
-rw-r--r-- 1 admin user 1280009 Feb 7 19:13 swlog_chassis1.0
drwxr-xr-x 2 admin user 4096 Jan 5 2021 system
-------r-- 1 root root 4835 Feb 11 02:06 test.cap
-rw-r--r-- 1 admin user 594809 Jan 1 2021 u-boot.8.2.1.R01.255.tar.gz
-rw-r--r-- 1 admin user 3453 Jan 1 2021 u-boot_copy
drwxr-xr-x 2 admin user 4096 Feb 8 01:20 working
- To display the capture, enter :

sw7 (6860-A) -> show port-monitoring file
Destination | Source | Type | Data
-------------------------------------------------------------------------------
01:80:C2:00:00:00 | E8:E7:32:F6:16:20 | 2700 | 00:27:42:42:03:00:00:02:02:7C
01:80:C2:00:00:00 | E8:E7:32:F6:16:20 | 2700 | 00:27:42:42:03:00:00:02:02:7C
01:80:C2:00:00:00 | E8:E7:32:F6:16:20 | 2700 | 00:27:42:42:03:00:00:02:02:7C
01:80:C2:00:00:00 | E8:E7:32:F6:16:20 | 2700 | 00:27:42:42:03:00:00:02:02:7C
01:80:C2:00:00:00 | E8:E7:32:F6:16:20 | 2700 | 00:27:42:42:03:00:00:02:02:7C
- Use the ‘?’ to display additional parameters. How would you change the name of the capture file?
sw7 (6860-A) -> show port-monitoring ?
^
STATUS FILE
- When done, delete the monitoring session.


-----+-------+----+-----+------+------+-------+------+-----------------------
1. 1/1/1 Bi ON OFF ON Brief 64K /flash/pmonitor.enc
sw7 (6860-A) -> no port-monitoring 1

7
6 Health
The Health feature can be used to gather basic information on the state of the switch such as CPU, memory
and traffic utilization information.
sw7 (6860-A) -> show health
CMM Current 1 Min 1 Hr 1 Day
----------------------+---------+-------+-------+-------
CPU 7 7 7 6
Memory 64 64 64 64
sw7 (6860-A) -> show health slot 1/1

Slot 1/ 1 Current 1 Min 1 Hr 1 Day
----------------------+---------+-------+-------+-------
CPU 9 7 7 6
Memory 65 65 65 65
Receive 0 0 0 0
Receive/Transmit 0 0 0 0
7 RMON
Remote Monitoring can be used to gather statistics for displaying in OmniVista or other NMS solutions.
Make sure that interface 1/1/1 is enabled so you can get these statistics.
-> interfaces 1/1/1 admin-state enable
sw7 (6860-A) -> show rmon probes
Chassis/
Entry Slot/Port Flavor Status Duration System Resources
-------+----------+---------+-----------+------------+----------------
1001 1/1/1 Ethernet Active 74:21:55 300 bytes
sw7 (6860-A) -> show rmon probes history
Chassis/
-------+----------+---------+-----------+------------+----------------
1 1/1/1 History Active 74:22:28 5470 bytes
sw7 (6860-A) -> show rmon probes stats
Chassis/
-------+----------+---------+-----------+------------+----------------
8

sw7 (6860-A) -> show rmon probes 1001
Probe's Owner: Switch Auto Probe on Chassis 1, Slot 1, Port 1, ifindex 1001
Entry 1001
Flavor = Ethernet, Status = Active,
Time = 74 hrs 23 mins,
System Resources (bytes) = 300
OMNISWITCH R8
POWER OVER ETHERNET (POE)
OBJECTIVES
• Setup the Power over Ethernet (PoE) feature

• Monitor the Power over Ethernet (PoE)
information
POE SPECIFICATIONS
POWER OVER ETHERNET
• OmniSwitch switches with PoE capabilities can provide power to a large range of
equipments (ex: IP phones, access points, PTZ cameras,…)
• PoE priority and configurable maximum power per port for power allocation
• Dynamic PoE Allocation: Provide only the amount of power needed by powered devices (PD) up to
the total energy budget for the most efficient power consumption possible
Property 802.3af 802.3at Type 802.3bt Type 802.3bt Type

(802.3at Type 1) "PoE" 2 "PoE+" 3 "4PPoE"]/"PoE++" 4 "4PPoE"/"PoE++"
Power available at the PD 12.95 W 25.50 W 51 W 71 W
Maximum power delivered by the EPS 15.40 W 30.0 W 60 W 100 W
Maximum current Imax 350 mA 600 mA 600 mA per pair 960 mA per pair
Three power class levels Four power class Six power class levels Eight power class levels
Energy Management
(1-3) levels (1-4) (1-6) (1-8)
Category 3 and
Supported cabling Category 5 Category 5 Category 5
Category 5
POWER OVER ETHERNET - OMNISWITCH 6360
Budget Power over Ethernet Specifications
OMNISWITCH 6360
OS6360-(P)10/10 A
OS6360-(P)24, (PH24), (P24X)
Power over Ethernet Budget
OS6360-(P)48, (P48X)
Note: The OS6360 – P10A does not support FPoE/PPoE

POWER OVER ETHERNET - OMNISWITCH 6860/6860N
OMNISWITCH 6860/6860E OMNISWITCH 6860N
OS6860(E)-(P)24 OS6860N-P48M
OS6860(E)-(P)48
OS6860N-P48Z
OS6860E-P24Z8
OS6860N-P24Z8
POWER OVER ETHERNET- OMNISWITCH 6560
OS6560
Software AOS 8 base
10M/100M/1G/2,5G
User ports 802.3at/bt
95W POE (Up to 95W on a port)
OS6560-P24X4 OS6560-P24Z24
Multi Gig
Model OS6560-P24X4 Model OS6560-P24Z24

24 x 10/100/1G Base-T POE+ ports 24 x 100/1G/2,5G Base-T ports
2 x SFP 1G ports POE (802.3af/bt)
4 x SFP+ 1/10G ports (Up to 95W on a port)
OS6560-48X4
OS6560-P24Z8 OS6560-P48Z16 OS6560-P48X4
Model OS6560-P24Z8 Model OS6560-P48Z16 Model OS6560-P48X4

16 x 10/100/1000 Base- ports 32 x 10/100/1000 Base-T ports 48 x 10/100/1000 Base-T ports
(802.3af/at) POE (802.3af/at) POE (802.3af/at)
8 x 1G / 2,5G Base-T ports (Up to 30W on a port) (Up to 30W on a port)
POE (802.3af/at/bt) 16 x 100/1G/2,5G Base-T ports 2 x SFP ports
(Up to 95W on a port) POE (802.3af/at/bt) POE (802.3af/at/bt)
(Up to 95W on a port)
Model OS6560-48X4
48 x 10/100/1000 Base-T ports
2 x SFP ports
POE (802.3af/at/bt)
POWER OVER ETHERNET – OMNISWITCH 6465
OMNISWITCH 6465
OS6465-P6
OS6465-P12
OS6465-P28
POWER OVER ETHERNET – OMNISWITCH 6865
OMNISWITCH 6865
OS6865-P16X
OS6865-U28X
OS6865-U12X
POE MANAGEMENT ON AOS R8
POE MANAGEMENT
• Displays the power supplies hardware information and current status:
-> show powersupply
Total PS
Chassis/PS Power Type Status Location
-----------+---------+--------+--------+-----------
1/1 920 AC UP Internal
Total 920
• Setting the PoE Operational Status

-> lanpower slot 1/1 service start
• Reactivating / Deactivating power to one port

-> lanpower port 1/1/1 admin-state enable
• Setting the maximum amount of inline power

-> lanpower port 1/1/24 power 18000 for one port (in mW)
-> lanpower slot 1/1 maxpower 400
for a slot (in W)
POE MANAGEMENT
• Setting the PoE Operational Status on a Port
• Disabled by default
-> lanpower port 1/1/1 admin-state enable
• Setting Port Priority Levels (Low, High, Critical)

• Default priority level for a port is low
• Low: In the event of a power management issue, inline power to low-priority ports is interrupted
first
• High: This value is used for port(s) that have important, but not mission-critical, devices attached.
If other ports in the chassis have been configured as critical, inline power to high-priority ports is
given second priority.
• Critical: In the event of a power management issue, inline power to critical ports is maintained as
long as possible
-> lanpower port 1/1/6 priority critical

POE MANAGEMENT
• Setting the Capacitor Detection Method
• Not compatible with IEEE specification 802.3af
• It should only be enabled to support legacy IP phones
-> lanpower slot 1/1 capacitor-detection enable
• Setting Priority Disconnect Status

• Used by the system software in determining whether an incoming PD will be granted or denied
power when there are too few watts remaining in the PoE power budget for an additional device
-> lanpower slot 1/1 priority-disconnect enable

POE MONITORING
-> show lanpower slot 1/1
Port Maximum(mW) Actual Used(mW) Status Priority On/Off Class
----+-----------+---------------+-----------+---------+-------+--------
1 60000 12500 Powered On Low ON *
--------------------------------------------------------------------
15 30000 0 Powered Off Low OFF
16 30000 0 Powered Off Low OFF
17 30000 0 Searching Low ON
--------------------------------------------------------------------
ChassisId 1 Slot 1 Max Watts 450
56.5 Watts Actual Power Consumed
450 Watts Total Power Budget Used
0 Watts Total Power Budget Available
1 Power Supply Available
BPS power: Not Available
POE POWER MANAGEMENT
• Fast PoE : 6360, 6860E, 6860N, 6865
• Note: OS6360 – P10A does not support FPoE
• Used to provide PoE power a few seconds after powering up the chassis
• Allows the chassis to immediately provide PoE power to any connected device after powering up
without waiting for the chassis to finish booting
• Fast PoE requires an upgraded FPGA/CPLD
• Extract :Release note 8.7.R1

-> lanpower fpoe {enable | disable}
• Perpetual PoE : 6360, 6860E, 6860N, 6865
• Note: OS6360 – P10A does not support PPoE.
• Provides uninterrupted power to the connected device (PD) even when the switch is restarting or
recharging, such as during a soft restart
-> lanpower ppoe {enable | disable}
• Perpetual PoE requires an upgraded FPGA/CPLD (see release note)

Delayed-feature - 6560, 6465 and 6360
• This feature is used to introduce a delay in lanpower on system bootup.This delay is used
to start a lanpower after some specific delay to leave some time for system stability.
• To enable Delayed – start feature with specific delay value

-> lanpower slot 1/1 delayed-start enable seconds <num>
<num> - specific delay value in seconds in multiples of 5. Value should be within 120 to 600 seconds
Notes
• Start the lanpower service before enabling the
• To disable the Delayed- start feature delay start feature.
• It is mandatory to do write memory to reflect this
->lanpower slot 1/1 delayed-start disable command on bootup.
• Lanpower service starts after the delay timer
expiry
• To display the delayed-start configurations
• User can force stop the delay timer by applying
->show lanpower slot <chassis/slot> / all delayed-start lanpower service stop command on boot while
on the period of delay-timer is activated
On boot while delayed lanpower timer is running, status in “Show lanpower slot </>/all status” is updated
with “Delayed” with time • Fpoe and Ppoe is not supported on enabling this
feature.
THANK YOU
OMNISWITCH R8
L I N K A G G R E G AT I O N G R O U P S
OBJECTIVES
• Understand the Link Aggregation operation on

AOS based switches
• Learn how to configure
• Static Link Aggregation
• Dynamic Link Aggregation
• Load Balancing Control
OVERVIEW
• Goal
• Method of aggregating (combining) more than 2 ports/links so that the switch will “see” them as
one logical link
• Advantages of Link Aggregation

• Scalability
• Reliability
• Ease of Migration
Logical Link can be statically assigned to any VLAN

802.1q can be configured on the logical aggregated link
• Provides an aggregated link
(multiple physical links combined into one logical link)
SPECIFICATIONS
Static (OmniChannel) or Dynamic (IEEE 802.3ad/LACP)
STATIC VS. DYNAMIC
• Difference between Static and Dynamic
• Static
• Port parameters MUST be exactly the same at both ends and within the group
• same speed (e.g., all 10 Mbps, all 100 Mbps, all 1 Gigabit, or all 10 Gigabit)
• Only works between Alcatel-Lucent OmniSwitches
• Dynamic
• IEEE 802.3ad LACP
• LACP will negotiate the optimal parameters for both ends using LACPDU (Link Aggregation Control Protocol
Data Unit)
• Ports must be of the same speed within the same aggregate group
• It also works between two different devices such as switches, servers and storage systems.
STATIC LINK AGGREGATION GROUPS - CLI
• Creating a Static Aggregate Group
-> linkagg static agg <agg_num> size <size> admin-state enable
• Adding Ports to a Static Aggregate Group
-> linkagg static port < Chassis/slot/port> agg <agg_num>
• Removing Ports from a Static Aggregate Group
-> no linkagg static port <Chassis/slot/port>
DYNAMIC LINK AGGREGATION GROUPS - CLI
• Configuring a Dynamic Link Aggregation Group
-> linkagg lacp agg <agg_num> size <size> admin-state enable
-> linkagg lacp agg <agg_num> actor admin-key <actor_admin_key>
• Assigning ports to the Dynamic Link Aggregation Group
-> linkagg lacp port <chassis/slot/port> actor admin-key <actor_admin_key>
MONITORING
• Static & Dynamic Link Aggregation Groups can be used for VLAN tagging (802.1q)
-> vlan <vlan_id> members linkagg <agg_num> untagged
-> vlan <vlan_id> members linkagg <agg_num> tagged
• Useful monitoring commands:

-> show linkagg
Number Aggregate SNMP Id Size Admin State Oper State Att/Sel Ports
------+----------+--------+-----+-------------+------------+-------------
1 Static 40000001 8 ENABLED UP 2 2
2 Dynamic 40000002 4 ENABLED DOWN 0 0
4 Static 40000005 2 DISABLED DOWN 0 0
-> show linkagg <agg_num> port </Chassis/slot/port>

LINK AGGREGATION STATISTICS
LINK AGGREGATION STATISTICS
• To display the statistics for a linkagg, all the physical ports in the linkagg are identified,
and relevant statistics are aggregated and displayed for various show commands.
Command Usage
show linkagg counters Displays statistics collected for the type and number of packets
transmitted and received on link aggregate ports.
show linkagg traffic Displays the total number of packets and bytes that are received and
transmitted on link aggregate ports.
show linkagg accounting Displays statistics collected for packets transmitted and received on
link aggregate ports.
show linkagg port Displays information about link aggregation ports.
LOAD BALANCING CONTROL
HASHING CONTROL ALGORITHM Source
Address
Destination
Address
• Hashing Control
• Control over the hashing mode
Server #
• Link Aggregation
• ECMP Brief Mode
• Server Load Balancing
• Two hashing algorithms available
Source Destination UDP/TCP
• Brief Mode Address Address Port
• UDP/TCP ports not included
• Only Source IP and destination IP addresses
are considered
Server #
-> hash-control brief
Extended Mode
• Extended
• UDP/TCP ports to be included in the hashing Switch Default Hasing Mode
algorithm 9900 extended
• Result in more efficient load balancing 6900 brief
-> hash-control extended [ udp-tcp-port | no] 6860 extended
6865 extended
6560 extended
6465 brief
6360 brief
LOAD BALANCING MULTICAST ON LINK AGGREGATION
GROUPS
• Multicast traffic is by default forwarded through the primary port of the Link Aggregation
Group
• User has the option to enable hashing for non-unicast traffic, which will load balance the
non-unicast traffic across all ports in the Link Aggregation Group
• If non-ucast option is not specified, link aggregation will only load balance unicast packets
THANK YOU
OmniSwitch R8
Link Aggregation
How to
✓ This lab is designed to familiarize you with Dynamic link aggregation.
Contents
1 Topology ........................................................................................ 2
2 Link Aggregation – Dynamic between 6860’s .............................................. 2
2.1. Create a Dynamic Link Aggregation .............................................................. 2
2.2. Test the configuration ............................................................................. 4
3 Link Aggregation – Dynamic between 6860-A and 6900-A ............................... 6
4 Link Aggregation – Dynamic between 6900-A and 6900-B ............................... 8
4.2. Test the configuration ............................................................................ 10
2
Link Aggregation
1 Topology
Link Aggregation provides the ability to combine multiple physical ports into a single logical port for added
throughput and redundancy; this can be done statically using OmniChannel or dynamically using the IEEE
802.3ad (LACP) protocol.
2 Link Aggregation – Dynamic between 6860’s
2.1. Create a Dynamic Link Aggregation

- Now, we will define a dynamic link aggregate, assign the group ID 78 and size it at 2 ports.
• sw7 (6860-A)
• sw8 (6860-B)
3
Link Aggregation
- On both switch, type:
sw7 (6860-A) -> linkagg lacp agg 78 size 2 actor admin-key 78
sw8 (6860-B) -> linkagg lacp agg 78 size 2 actor admin-key 78
sw7 (6860-A) -> show linkagg
-------+-------------+---------+----+------------+--------------+-------------
sw8 (6860-B) -> show linkagg
-------+-------------+---------+----+------------+--------------+-------------
- Notice we have no ports associated, using the actor admin key assigned to the link aggregation, let's
associate the ports:
- Ports are associated to a dynamic link aggregation using the actor admin key. Although in the above
example the actor admin key matches the link agg number, this is not a requirement as the admin key
has local significance only.
sw7 (6860-A) -> linkagg lacp port 1/1/23-24 actor admin-key 78
sw8 (6860-B) -> linkagg lacp port 1/1/23-24 actor admin-key 78
- Now, connect the switches by activating linkagg interfaces:
sw8 (6860-B) -> interfaces 1/1/23-24 admin-state enable
- Check the result

-------+-------------+---------+----+------------+--------------+-------------
78 Dynamic 40000078 2 ENABLED UP 2 2
-------+-------------+---------+----+------------+--------------+-------------
4
Link Aggregation
sw7 (6860-A) -> show linkagg agg 78
Dynamic Aggregate
SNMP Id : 40000078,
Aggregate Number : 78,
SNMP Descriptor : Dynamic Aggregate Number 78 ref 40000078 size 2,
Name : ,
Admin State : ENABLED,
Operational State : UP,
Aggregate Size : 2,
Number of Selected Ports : 2,
Number of Reserved Ports : 2,
Number of Attached Ports : 2,
Primary Port : 1/1/23,
Port Selection Hash : Source Destination Ip,
Wait To Restore Time : 0 Minutes
LACP
MACAddress : [2c:fa:a2:0e:62:5c],
Actor System Id : [00:00:00:00:00:00],
Actor System Priority : 0,
Actor Admin Key : 78,
Actor Oper Key : 78,
Partner System Id : [00:00:00:00:00:00],
Partner System Priority : 0,
Partner Admin Key : 0,
Partner Oper Key : 78
sw8 (6860-B) -> show linkagg agg 78
Dynamic Aggregate
SNMP Id : 40000078,
Name : ,
Aggregate Size : 2,
LACP
MACAddress : [e8:e7:32:d4:84:20],
Actor System Id : [00:00:00:00:00:00],
Actor Oper Key : 78,
2.2. Test the configuration

- By default, the linkagg is associated with vlan 1. to increase security, assign another default vlan to it
and an IP address to this VLAN :
sw7 (6860-A) -> vlan 278
sw7 (6860-A) -> vlan 278 members linkagg 78 untagged
5
Link Aggregation
sw8 (6860-B) -> vlan 278

sw8 (6860-B) -> ip interface int_278 address 172.16.78.8/24 vlan 278
sw8 (6860-B) -> vlan 278 members linkagg 78 untagged
sw7 (6860-A) -> show vlan 278 members

port type status
----------+-----------+---------------
0/78 untagged forwarding
sw8 (6860-B) -> show vlan 278 members

port type status
----------+-----------+---------------
Total 4 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
int_278 172.16.78.7 255.255.255.0 UP YES
sw8 (6860-B) -> show ip interface

Total 4 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
- Try to make a ping between both 6860

sw7 (6860-A) -> ping 172.16.78.8
PING 172.16.78.8 (172.16.78.8) 56(84) bytes of data.

64 bytes from 172.16.78.8: icmp_seq=1 ttl=64 time=12.4 ms
--- 172.16.78.8 ping statistics ---

6 packets transmitted, 6 received, 0% packet loss, time 5001ms
rtt min/avg/max/mdev = 0.685/2.686/12.466/4.373 ms
- To demonstrate the redundancy capabilities, experiment with removing a link and monitor the results of your pings tests
Tips
You can use the command ping <dest_ip_address> count <number> to send more than 6 pings.
To break a ping sequence, press the key CTRL+C
To simulate a link failure, you can bring down the corresponding interface :
interface chassis/slot/port admin-state disable (6860)
- Save the configuration

6
Link Aggregation
3 Link Aggregation – Dynamic between 6860-A and 6900-A
- Now, we define a dynamic link aggregate on 6900-A and 6860-A, assign the group ID 17 and size it at 2
ports even if there is only one port available. – (For future extension)
sw1 (6900-A) -> linkagg lacp port 1/1/5 actor admin-key 17

-------+-------------+---------+----+------------+--------------+-------------

-------+-------------+---------+----+------------+--------------+-------------
- Now, connect the switches by activating the linkagg interfaces:

sw1 (6900-A) -> show linkagg agg 17 port
Chassis/Slot/Port Aggregate SNMP Id Status Agg Oper Link Prim

-------------------+----------+--------+----------+----+-----+-----+----
1/1/5 Dynamic 1005 ATTACHED 17 UP UP YES

-------------------+----------+--------+----------+----+-----+-----+----
7
Link Aggregation
- Additional VLAN creation

o Currently, only VLAN 1 is bridged between 6900-A and 6860-A
o Change the default VLAN
sw1 (6900-A) -> vlan 217

port type status
----------+-----------+---------------
0/17 default forwarding
sw1 (6900-A) -> show ip interface vlan 217

Total 1 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
int_217 172.16.17.1 255.255.255.0 UP YES vlan 217
sw7 (6860-A) -> vlan 217


Total 1 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
int_217 172.16.17.7 255.255.255.0 UP YES vlan 217

port type status
----------+-----------+---------------
0/17 default forwarding
- Check the result

-------+-------------+---------+----+------------+--------------+-------------

-----+-------------+---------+----+------------+--------------+-------------
- Try to make a ping 6900-A from 6860-A
sw7 (6860-A) -> ping 172.16.17.1

8
Link Aggregation

4 Link Aggregation – Dynamic between 6900-A and 6900-B
- Now, we define a dynamic link aggregate on 6900-A and 6900-B, assign the group ID 12 and size it at 2
ports.
- Please note that for sw1 (6900-A), some PODs are equipped with the new 6900T24C2 switch (SW1), while
others are equipped with a 6900T20 or X20 models. This has an impact on the ports used in the rest of
the exercise, so we'll start by checking the type of switch on your POD.
- Type the following command to determine the type of switch used in the POD.
sw1 (6900-A) -> show chassis
Local Chassis ID 1 (Master)

Model Name: OS6900-T24C2,
Module Type: 0xa06230a,
Description: 24 10GBASET 2 100G,
Part Number: 904316-90,
Hardware Revision: 03,
Serial Number: JSZ232102541,
Manufacture Date: Jun 1 2023,
Admin Status: POWER ON,
Operational Status: UP,
Number Of Resets: 14,
MAC Address: 78:24:59:2b:32:ab
9
Link Aggregation
- If the result for model name is OS6900-T24C2, the ports used will be: 1/1/25-26,
- Otherwise, if the result is OS6900-T20 or X20, the ports used will be: 1/2/1-2
- in this lab, we have got a OS6900-T24C2, so commands are the following one

- In case of OS6900-T20 or X20:

- Then, check then the linkagg
-------+-------------+---------+----+------------+--------------+-------------
- Manage the second switch

-------+-------------+---------+----+------------+--------------+-------------
- Now, connect the switches by activating the linkagg interfaces:

sw1 (6900-A) -> interfaces 1/1/25-26 admin-state enable or interfaces 1/2/1-2 admin-state enable

-------------------+----------+--------+----------+----+-----+-----+----
1/1/26 Dynamic 1026 ATTACHED 12 UP UP NO
Or

-------------------+----------+--------+----------+----+-----+-----+----
sw2 (6900-B) -> show linkagg agg 12 port

-------------------+----------+--------+----------+----+-----+-----+----
10
Link Aggregation
- Additional VLAN creation

o Currently, only VLAN 1 is bridged between 6900-A and 6860-A
o Change the default VLAN
sw1 (6900-A) vlan 212
sw1 (6900-A) ip interface int_212 address 172.16.12.1/24 vlan 212
sw1 (6900-A) vlan 212 members linkagg 12 untagged

port type status
----------+-----------+---------------

Total 1 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
int_212 172.16.12.1 255.255.255.0 UP YES vlan 212
sw2 (6900-B) -> vlan 212

sw2 (6900-B) -> show ip interface vlan 212

Total 1 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
int_212 172.16.12.2 255.255.255.0 UP YES vlan 212

port type status
----------+-----------+---------------
- Check the result

-------+-------------+---------+----+------------+--------------+-------------

-------+-------------+---------+----+------------+--------------+-------------
- Try to make a ping between 6900-B to 6900-A
sw2 (6900-B) -> ping 172.16.12.1
- Save the configuration on both switches

OmniSwitch R8
Link Aggregation
How to
✓ Create Dynamic Aggregation Links
Contents
1 Topology ........................................................................................ 2
2 Creating a Dynamic Link Aggregation ...................................................... 3
2.1. Creating a Dynamic Link Aggregation between the 6360 virtual chassis
and the 6860-A ...................................................................................... 3
2.1.1. On the 6360 virtual chassis ................................................................................ 3
2.1.2. On the 6860-A ............................................................................................... 4
3 Testing the configuration .................................................................... 7
2
Link Aggregation
1 Topology
throughput and redundancy. In this lab, you will create dynamic link aggregation using the IEEE 802.3ad (LACP)
protocol on AOS Release 8.
In this lab, you are going to create a new link aggregation between the 6360 Virtual Chassis and 6860-A. The link
aggregation 78 (Vlan 278) has been already created between the 2 OS6860s for in the network core.
Furthermore, for security reason, the client wants to avoid using the VLAN1 (the default VLAN). Thus, the
default VLAN on the link aggregation will be the VLAN 57.
3
Link Aggregation
2 Creating a Dynamic Link Aggregation
2.1. Creating a Dynamic Link Aggregation between the 6360 virtual chassis and the 6860-A
2.1.1. On the 6360 virtual chassis
- Now, we will define a dynamic link aggregate, assign the group ID 7 and configure its size to 2:
sw5 (OS6360-A) -> linkagg lacp agg 7 size 2 actor admin-key 7
Notes: Actor Admin Key

The link aggregation number and ports are associated to a dynamic link aggregation using the actor admin key.
Although in the above example the actor admin key matches the link aggregation number, this is not a
requirement as the admin key has local significance only.
- Check the link aggregation status on the OS6360-A:

-------+----------+---------+----+------------+--------------+-------------
- Notice we have no ports associated to the link aggregation 7 :
- Using the actor admin key assigned to the link aggregation, associate the ports 1/1/3 and 2/1/4 to the
linkagg 7:
- Enable the ports:

4
Link Aggregation
- Now 2 ports are linked to the link aggregation, but the link aggregation is still DOWN, because the
configuration on the other side (on the 6860-A) has not been done yet.
-------+-------------+---------+----+------------+--------------+-------------

-------------------+----------+--------+----------+----+-----+-----+----
2.1.2. On the 6860-A
- Create the link aggregation 7:

sw7 (OS6860-A) -> linkagg lacp agg 7 size 2 actor admin-key 7
Notes: Actor Admin Key

The link aggregation number and ports are associated to a dynamic link aggregation using the actor admin key.
Although in the above example the actor admin key matches the link agg number, this is not a requirement as
the admin key has local significance only.
- Associate the port 1/1/3 and 1/1/4 to the link aggregation 7:

sw7 (OS6860-A) -> linkagg lacp port 1/1/3-4 actor admin-key 7
- Enable the ports:

sw7 (OS6860-A) -> interface 1/1/3-4 admin-state enable
- Check the link aggregation status on the OS6860-A:

sw7 (OS6860-A) -> show linkagg
-------+-------------+---------+----+------------+--------------+-------------
Notes: Link Aggregation 17? 78?

On the 6860-A, 3 link aggregations are available: the new one you created (linkagg 7), plus 2 other link
aggregations (17 and 78) used to connect the switch to the 6900 and 6860-B (Core network part). These two
other aggregations have already been created on a previous lab or via a configuration download at the
beginning of the course depending on the course you are taking.
5
Link Aggregation
- Check the link aggregation properties on the 6860-A:

Dynamic Aggregate
SNMP Id : 40000007,
Name : ,
Aggregate Size : 2,
LACP
MACAddress : [2c:fa:a2:0e:62:49],
Actor System Id : [00:00:00:00:00:00],
Actor Oper Key : 7,
Agg-Down/Violation Reason: None,
6
Link Aggregation
- Check the link aggregation properties on the 6360 Virtual Chassis:

Dynamic Aggregate
SNMP Id : 40000007,
Name : ,
Aggregate Size : 2,
LACP
MACAddress : [94:24:e1:7c:79:6f],
Actor System Id : [00:00:00:00:00:00],
Actor Oper Key : 7,
Agg-Down/Violation Reason: None,
- By default, a link aggregation is associated with the VLAN 1 (default VLAN).

- For security reason, the client wants to avoid using the VLAN 1 as the network data VLAN. So, the VLAN
associated with link aggregation 7 must be modified:
o On the 6360-A:
sw5 (6360-A) -> vlan 57

port type status
----------+-----------+---------------
o On the 6860-A:
sw7 (OS6860-A)-> vlan 57
sw7 (OS6860-A)-> vlan 57 members linkagg 7 untagged

port type status
----------+-----------+---------------
7
Link Aggregation
3 Testing the configuration

In order to test the link aggregation, we will launch a ping between 2 clients connected on each side (Client 5
on the 6360 Virtual Chassis, Client 7 on the 6860-A), then we will simulate a failure on the link aggregation.
Infrastructure
- Put the Client 7 in the VLAN 57 (6860-A):

sw7 (OS6860-A)-> vlan 57 members port 1/1/1 untagged
sw7 (OS6860-A)-> interfaces 1/1/1 admin-state enable
- Put the Client 5 in the VLAN 57 (6360-A):

Sw5 (OS6360-A)-> vlan 57 members port 1/1/1 untagged
Sw5 (OS6360-A)-> interfaces 1/1/1 admin-state enable
Client 5
Double-click on VMware vSphere

Connections
8
Link Aggregation

Pod

(TCP/IP)

address
- IP address: 192.168.57.105
- Subnet mask: 255.255.255.0
Client 7
Double-click on VMware vSphere

Connections

Pod

(TCP/IP)

address
- IP address: 192.168.57.107
- Subnet mask: 255.255.255.0
- From client 5, launch a continuous ping (-t option) to the Client 7:

C:\Program Files […]\Tools> ping -t 192.168.57.107
9
Link Aggregation
- To demonstrate the redundancy capabilities, put a port (belonging to the link aggregation) down, and
monitor the results of your pings tests.
sw7 (6860-A) -> interface 1/1/3 admin-state disable
sw7 (6860-A) -> show linkagg port

-------------------+----------+--------+----------+----+-----+-----+----
1/1/3 Dynamic 1003 CONFIGURED NONE DOWN DOWN UNK
- Once finished, reactivate the port 1/1/3:

OmniSwitch R8
802.1q
How To
✓ Apply 802.1q tagging on link aggregation and ports
Content
1 Topology ........................................................................................ 2
2 Enabling the 802.1Q Tagging ................................................................ 2
2.1. Tagging a Link ....................................................................................... 2
2.1.1. On the 6360 Virtual Chassis ............................................................................... 2
2.1.2. On the 6860-B ............................................................................................... 2
2.2. Creating Additional VLANs ........................................................................ 3
2.3. Configuring 802.1Q on Ports ...................................................................... 4
3 Testing the Configuration .................................................................... 6
2
802.1q
1 Topology
In a Layer 2 environment the Ports is used for bridging traffic across a physical connection between
switches. In an IEEE 802.1Q environment, the Default VLAN for the port is bridged, and all the other VLANs
will have the IEEE 802.1Q tag inserted for proper VLAN association at the remote side.
2 Enabling the 802.1Q Tagging
2.1. Tagging a Link

In this part, we are going to configure the link between the 6360 Virtual Chassis and the 6860-B.
2.1.1. On the 6360 Virtual Chassis
- Activate the port 2/1/3 on the 6360 Virtual Chassis (linked to the 6860-B):
- Create the VLAN 58, then modify the VLAN on the port 2/1/3 from the default VLAN to VLAN 58:
sw5 (6360-A) -> vlan 58
sw5 (6360-A) -> show vlan 58 member

port type status
----------+-----------+---------------
2/1/3 untagged inactive
2.1.2. On the 6860-B

- Activate the port 1/1/3 on the 6860-B (linked to the 6360 Virtual Chassis):
sw8 (6860-B) -> interfaces 1/1/3 admin-state enable
3
802.1q
- Create the VLAN 58, then modify the VLAN on the port 1/1/3 from the default VLAN to VLAN 58:
sw8 (6860-B) -> vlan 58
sw8 (6860-B) -> vlan 58 members port 1/1/3 untagged

port type status
----------+-----------+---------------
1/1/3 untagged forwarding
2.2. Creating Additional VLANs

Currently, only 2 VLANs are bridged:
- VLAN 57 between the 6860-A and the 6360 Virtual Chassis
- VLAN 58 between the 6860-B and the 6360 Virtual Chassis
- Create the VLANs 20 and 30 on the 3 switches (Virtual Chassis of 6360-A, 6860-A et 6860-B) :
sw5 (6360-A) -> vlan 20
sw5 (6360-A) -> vlan 30
sw7 (6860-A) -> vlan 20

sw7 (6860-A) -> vlan 30
sw8 (6860-B) -> vlan 20

sw8 (6860-B) -> vlan 30
The gateway for the VLAN 20 will be created on the 6860-A.

The gateway for the VLAN 30 will be created on the 6860-B.
- Assign an IP interface to these 2 new VLAN on the correspondent switches:

- Check the configuration:

Total 6 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
Loopback0 192.168.254.8 255.255.255.255 UP YES Loopback0
---
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
int_30 192.168.30.8 255.255.255.0 DOWN NO vlan 30

Total 7 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
---
int_20 192.168.20.7 255.255.255.0 DOWN NO vlan 20
int_217 172.16.17.7 255.255.255.0 UP YES vlan 217
int_278 197.16.78.7 255.255.255.0 UP YES vlan 278
4
802.1q
- The IP interfaces status is DOWN. Why?

----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
2.3. Configuring 802.1Q on Ports

- Our VLAN 20 and 30 IP interfaces are currently down because we have no members in the two VLANs.
Remember, if there are no members of a VLAN the IP interface is not only down but will not be
advertised to the Layer 3.
- Normally, to have Layer 2 connectivity between the two switches for all three VLANs, three physical
links would be required. However, we will configure 802.1Q tagging to carry data from all VLANs over
physical link.
- For now, no port has been assigned neither to VLAN 20 nor VLAN 30.
- Tag the VLANs 20 and 30 on the link between the 3 switches (in red on the diagram below):
sw5 (6360-A) -> vlan 20 members linkagg 7 tagged

sw5 (6360-A) -> vlan 20 members port 2/1/3 tagged


sw8 (6860-B) -> vlan 20 members linkagg 78 tagged

sw8 (6860-B) -> vlan 20 members port 1/1/3 tagged
5
802.1q
- Check the VLAN-port association on each switch:

Notes: The ports status available in the tables below depend on the STP root bridge election. Could be different on your pod.
o On the 6360-A:
port type status
----------+-----------+---------------
2/1/3 qtagged forwarding
0/7 qtagged forwarding

port type status
----------+-----------+---------------

vlan type status
--------+-----------+---------------
20 qtagged forwarding
o On the 6860-A:
port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
o On the 6860-B:
port type status
----------+-----------+---------------
1/1/3 qtagged blocking

port type status
----------+-----------+---------------
1/1/3 qtagged blocking
sw8 (6860-B) -> show vlan members port 1/1/3

vlan type status
--------+-----------+---------------
20 qtagged blocking
30 qtagged blocking
If we take, for example, the port 1/1/3 on the 6860-B, we can see that it is carrying tagged information for
VLANs 20 and 30 and bridging the VLAN 58.
Reminder
A physical port always has 1 VLAN (the default VLAN for the port) that bridges traffic (level 2)
6
802.1q
3 Testing the Configuration

Let’s see what happens when we modify the Client VM IP addresses, move them to the VLAN 20 and VLAN 30,
and ping them each other.
- Let’s assign the port of each Client VM to the appropriate VLAN, and modify their IP addresses as
described below:
o Client 5:
vlan type status
--------+-----------+---------------
Modify the IP information of client 5 to match the following:

IP Address: 192.168.20.105
Mask: 255.255.255.0
Default Gateway: 192.168.20.7 (VLAN 20 IP Interfaces)
o Client 6:
vlan type status
--------+-----------+---------------
Modify the IP information of client 6 to match the following:

IP Address – 192.168.30.106
Mask – 255.255.255.0
Default Gateway – 192.168.30.8 (VLAN 30 IP Interfaces)
- Check that the Client 5 (VLAN 20) can reach its gateway (ping 192.168.20.7)
- Check that the Client 6 (VLAN 30) can reach its gateway (ping 192.168.30.8)
7
802.1q
- How are the Clients VM exchange between each other (Layer 2 or Layer 3)?
----------------------------------------------------------------------------------------------------------------------------- -
----------------------------------------------------------------------------------------------------------------------------- -
- Are packets being bridged? Routed? Both?

----------------------------------------------------------------------------------------------------------------------------- -
----------------------------------------------------------------------------------------------------------------------------- -
- Save the configuration and Copy running to certified all the switches managed

sw8 (6860-B) -> write memory flash-synchro
OMNISWITCH R8
S PA N N I N G T R E E
OBJECTIVES
• Understand the implementation of Spanning

Tree on AOS-based switches
- STP modes
- STP protocols
• Learn how to implement
- 1x1 and FLAT mode
- Spanning Tree Protocol 802.1D/802.1w
PRIORITY: 32768
STP REMINDER SW-A (MAC@: aa)
1/1/1 1/1/2
F - DP ROOT BRIDGE F - DP
• Goal
• Self-configuring algorithm that
maintains a loopfree topology
on a network 1/1/1 F - RP F - RP 1/1/1
SW-B (MAC@: bb) 1/1/2 1/1/5
• Provides helps to provide data X SW-C (MAC@: cc)
F - DP BLK- ALT
path redundancy and network PRIORITY: 32768 PRIORITY: 32768
scalability
• How it works
• Supports two Spanning Tree operating modes:
• flat (single STP instance per switch) flat
1/1/1 VLAN 1 1/1/1
• per-VLAN (single STP instance per VLAN) SW-A (MAC@: aa) 1/1/2 VLAN 2 1/1/2 SW-B (MAC@: bb)
X
(By default on OmniSwitch) 1/1/3 VLAN 3 1/1/3
X
• Supports three Spanning Tree operating protocols:

Per-VLAN
• STP: Convergence time : 50 secs 1/1/1 VLAN 1 1/1/1
SW-A (MAC@: aa) 1/1/2 VLAN 2 1/1/2 SW-B (MAC@: bb)
• RSTP: Convergence time : < 1 sec 1/1/3 VLAN 3 1/1/3
• MSTP: < 1 sec ->

STP REMINDER
• Specification
• IEEE 802.1s - Default Port Path Costs

16-bit Port Path Cost PPC 32-bit Port Path Cost PPC
IEEE Recom. IEEE Recom.
Link Speed Link Speed
Value – 16 bit Value – 32 bit
10 Mbps 100 10 Mbps 2,000,000
100 Mbps 19 100 Mbps 200,000
1 Gbps 4 1 Gbps 20,000
10 Gbps 2 10 Gbps 2,000

PRIORITY: 32768
MAC@ : E8:E7:32:56:45:C4
STP REMINDER
-> show spantree
SW-A (MAC@: aa)
VLAN STP Protocol Priority
-----+--------+---------+--------------
1 ON RSTP 32768 (0x8000)
1/1/1 RP -FW DP FW
per vlan (1x1) - load balancing 20

30
ON
ON
RSTP
RSTP
20000 (0x4e20)
32768 (0x8000)
1/1/2
PRIORITY: 32768 VLAN 20

MAC@ : E8:E7:32:56:45:C4
ROOT BRIDGE
SW-A (MAC@: aa) DP ALT - BLK
1/1/1 1/1/1
1/1/5 1/1/2
SW-B (MAC@: cc) SW-C (MAC@: bb)
D- FW ROOT BRIDGE D -FW
1/1/2 DP FW RP-FW
1/1/1
MAC@ : E8:E7:32:CD:63:D3 MAC@: E8:E7:32:D4:85:0D
PRIORITY: 20000 PRIORITY: 32768
VLAN 1, 20, 30
PRIORITY: 32768
MAC@ : E8:E7:32:56:45:C4
1/1/1 SW-A (MAC@: aa)

RP -FW 1/1/1 RP - FW -> show spantree
1/1/5 1/1/2
SW-B (MAC@: cc) X SW-C (MAC@: bb)
DP-FW RP -FW VLAN STP Protocol Priority
D -FW 1/1/1 1/1/2 -----+--------+---------+---------------
1 ON RSTP 32768 (0x8000)
MAC@ : E8:E7:32:CD:63:D3 ALT- BLK MAC@: E8:E7:32:D4:85:0D 20 ON RSTP 32768 (0x8000)
PRIORITY: 32768 PRIORITY: 32768 30 ON RSTP 20000 (0x4e20)
-> show spantree VLAN 30
Spanning Tree Path Cost Mode : AUTO

ROOT BRIDGE
VLAN STP Status Protocol Priority ALT -BLK 1/1/1 1/1/1 DP FW
-----+-------------+---------+-------------- 1/1/5 1/1/2
1 ON RSTP 32768 (0x8000) SW-B (MAC@: cc) SW-C (MAC@: bb)
20 ON RSTP 32768 (0x8000)
30 ON RSTP 32768 (0x8000) RP-FW DP-FW
MAC@ : E8:E7:32:CD:63:D3 MAC@: E8:E7:32:D4:85:0D
PRIORITY: 32768 PRIORITY: 20000
STP CONFIGURATION
STP CONFIGURATION
STEP BY STEP
Mode selection
Protocol selection
Bridge ID, Priority and Path Cost
Set the path cost mode

STP CONFIGURATION
STEP BY STEP
Mode selection
Select Mode
-> spantree mode {flat | per-vlan}
Monitor
-> show spantree mode
Spanning Tree Global Parameters
Current Running Mode : Per VLAN,
Current Protocol : N/A (Per VLAN),
Path Cost Mode : AUTO,
Auto VLAN Containment : N/A
Cisco PVST+ mode : Disabled
VLAN Consistency check: Disabled
STP CONFIGURATION
STEP BY STEP
Protocol selection
Select protocol
-> spantree [cist | vlan vlan_id] protocol {stp | rstp | mstp}
Check the protocol selected

-> show spantree
VLAN STP Status Protocol Priority

-----+--------------- +--------+--------------
1 ON RSTP 32768 (0x8000)
20 ON RSTP 32768 (0x8000)
30 ON RSTP 32768 (0x8000)
STP CONFIGURATION
STEP BY STEP A bridge or port priority value. The valid range for the
bridge priority is 0–65535.
The valid range for the port priority is 0–15.
Bridge ID, Priority and Path Cost If MSTP is the active flat mode protocol, enter a value that
is a multiple of 4096 (for example, 4096, 8192, 12288).
Configure the bridge and port priority

spantree [cist | msti msti_id | vlan vlan_id] [port chassis/slot/port[-port2]
| linkagg agg_id[-agg_id2]] priority priority
Ex: ->spantree vlan 20 priority 20000
Ex: ->spantree vlan 200 port 2/1/1 priority 15
Configure the path cost

spantree cist {port chassis/slot/port[-port2] | linkagg agg_id[-agg_id2]}
path-cost path_cost
Path cost 0 -> 65535 for 16-bit

0 –> 200000000 for 32-bit - Default:0
STP CONFIGURATION
STEP BY STEP
Disabled
Spanning Tree Port Status Blocking
Displays Spanning Tree port information < 1 sec

Learning
-> show spantree ports [forwarding | blocking | active | configured]
-> show spantree ports Forwarding // Discarding
VLAN Port Oper Status Path Cost Role Loop Guard Note
-----+-------+------------+---------+------+----------+------
1 1/1/1 FORW 4 DESG DIS
1 1/1/2 DIS 0 DIS DIS
Displays Spanning Tree bridge information for a per-VLAN mode VLAN instance
-> show spantree vlan [vlan_id]
-> show spantree 20 ports active

Spanning Tree Port Summary for VLAN 20
Oper Path Desig Prim. Op Op
Port St Cost Cost Role Port Cnx Edg Desig Bridge ID Note
------+----+------+------+----+-----+---+---+------------------------+----
1/1/3 BLK 4 3 ALT 1/1/3 PTP NO 8000-e8:e7:32:cd:63:d3
1/1/4 FORW 4 0 ROOT 1/1/4 PTP NO 4E20-e8:e7:32:d4:85:0d
STP CONFIGURATION
STEP BY STEP
Set the path cost mode

16-bit when STP/RSTP protocol is active
spantree path-cost-mode {auto | 32bit}
32-bit when MSTP protocol is active

-> spantree path-cost-mode auto
32-bit regardless of which protocol is active

-> spantree path-cost-mode 32bit
THANK YOU
OmniSwitch R8
Spanning Tree Protocol (STP)
How to
✓ Configure the Spanning Tree Protocol (STP) options on an OmniSwitch.
Contents
1 Topology ........................................................................................ 2
2 Managing the Spanning Tree Protocol ...................................................... 2
2.1. Changing the priority of the 6860-A ............................................................. 2
2.2. Identifying the port status ........................................................................ 3
2.3. Testing the redundancy ........................................................................... 6
3 Using the 1x1 Spanning Tree Mode ......................................................... 8
3.1. Configuring the Priority............................................................................ 9
3.2. Verifying the Configuration ....................................................................... 9
3.2.1. Verifying the VLAN 20 Configuration..................................................................... 9
3.2.2. Verifying the VLAN 30 Configuration................................................................... 11
2
1 Topology
The Spanning Tree Protocol (STP) is an important concept to understand in a bridged network.
2 Managing the Spanning Tree Protocol
2.1. Changing the priority of the 6860-A
- Customer wants to have the 6860-A as root bridge for vlan 20 and vlan 30
To achieve this, change the priority of the 6860 to ensure that:
sw7 (6860-A) -> spantree vlan 20 priority 20000
sw7 (6860-A) -> sh spantree

Vlan STP Status Protocol Priority
-----+----------+--------+--------------
1 ON RSTP 32768 (0x8000)
20 ON RSTP 20000 (0x4e20)
30 ON RSTP 20000 (0x4e20)
57 ON RSTP 32768 (0x8000)
217 ON RSTP 32768 (0x8000)
278 ON RSTP 32768 (0x8000)
4094 OFF RSTP 32768 (0x8000)
3
2.2. Identifying the port status

- Check the Spanning Tree Protocol Status for VLAN 20 on the 3 switches (6360, 6860-A and 6860-B):
o On the 6360-A:
sw5 (6360-A) -> show spantree vlan 20
Spanning Tree Parameters for Vlan 20
Spanning Tree Status : ON,
Protocol : IEEE Rapid STP,
mode : Per VLAN (1 STP per Vlan),
Priority : 32768 (0x8000),
Bridge ID : 8000-94:24:e1:7c:82:1d,
Designated Root : 8000-2c:fa:a2:0e:62:3f,
Cost to Root Bridge : 3,
Root Port : Slot 0 Interface 7,
TxHoldCount : 3,
Topology Changes : 6,
Topology age : 02:56:49,
Last TC Rcvd Port : 2/1/3,
Last TC Rcvd Bridge : 8000-e8:e7:32:d4:84:03,
Current Parameters (seconds)
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
Parameters system uses when attempting to become root
System Max Age = 20,
System Forward Delay = 15,
System Hello Time = 2
o On the 6860-A:
Priority : 20000 (0x4E20),
Bridge ID : 8000-2c:fa:a2:0e:62:3f,
Root Port : None,
TxHoldCount : 3,
Last TC Rcvd Port : Slot 0 Interface 7,
Last TC Rcvd Bridge : 8000-94:24:e1:7c:82:1d,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
o On the 6860-B:
sw8 (6860-B) -> show spantree vlan 20
Priority : 32768 (0x8000)
Bridge ID : 8000-e8:e7:32:d4:84:03,
TxHoldCount : 3,
4

Last TC Rcvd Bridge : 8000-2c:fa:a2:0e:62:3f,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
This gives you the configured STP parameters of VLAN 20. Notice the mode (Per VLAN or 1X1), meaning
each VLAN runs a separate STP instance.
Additionally, take note of the Bridge ID and the Designated Root. If they are the same, your switch is the
Root Bridge for VLAN 20.
According to the information retrieved from the commands above:

- The root bridge switch is the 6860-A.
- The 6860-B is at a cost of 3 away the root bridge switch, we can deduce that the Root Bridge is the
upstream neighbor on port 0 /78.(linkagg)
- We can also deduce from the above output that our STP is relatively stable, it has been 03:01:19
hours since the last topology change (Topology Age) and we have only had 5 Topology changes
By default, the bridge priority is 32768 (0x8000). Since all priorities are identical by default, the switch
with the lowest MAC address is selected as the root bridge (in this example, the 6860-A has the lowest
MAC address).
- One port should be in blocking mode to prevent a loop:

sw5 (6360-A) -> show spantree vlan 20 ports
Spanning Tree Port Summary for Vlan 20
Oper Path Desig Prim. Op Op Loop
Port St Cost Cost Role Port Cnx Edg Guard Desig Bridge ID Note
--------+----+-------+-------+----+--------+---+---+------+----------------------+------
1/1/1 FORW 4 3 DESG 1/1/1 PTP EDG DIS 8000-94:24:e1:f0:f6:39
2/1/3 BLK 4 3 ALT 2/1/3 PTP NO DIS 8000-94:24:e1:e8:b4:13
0/7 FORW 3 0 ROOT 1/1/3 PTP NO DIS 4E20-e8:e7:32:d4:88:23

--------+----+-------+-------+----+--------+---+---+------+----------------------+------
0/7 FORW 3 0 DESG 1/1/3 PTP NO DIS 4E20-e8:e7:32:d4:88:23
0/78 FORW 3 0 DESG 1/1/23 PTP NO DIS 4E20-e8:e7:32:d4:88:23
5
sw8 (6860-B) -> show spantree vlan 20 ports

--------+----+-------+-------+----+--------+---+---+------+----------------------+------
1/1/3 FORW 4 3 DESG 1/1/3 PTP NO DIS 8000-94:24:e1:e8:b4:13
0/78 FORW 3 0 ROOT 1/1/23 PTP NO DIS 4E20-e8:e7:32:d4:88:23
sw5 (6360-A) -> show spantree ports blocking

Vlan Port Oper Status Path Cost Role Loop Guard Note
-----+--------+-------------+---------+-------+----------+------
20 2/1/3 BLK 4 ALT DIS
Also, notice that only one side of the link(s) has a port or link aggregation with the status BLK (blocking).
This ensures the neighbor(s) are still able to initiate a topology change in the event of a failure.
- Fill up the following diagrams:
For VLAN 20
For VLAN 30
- What determines which side of the link is blocking?

----------------------------------------------------------------------------------------------------------------------------- ------
----------------------------------------------------------------------------------------------------------------------------- ------
6
2.3. Testing the redundancy
- Put the client 8 is in the VLAN 20.

Notes
The Client 5 is already in the VLAN 20. If not, type: sw5 (6360-A) -> vlan 20 members port 1/1/1 untagged
- Activate the interface:

- Configure the network interface of the Client 8 with the following information:
Client 8:
IP address = 192.168.20.108
Subnet mask = 255.255.255.0
Default Gateway = 192.168.20.7
- Start a continuous ping between client connected across an uplink (e.g between client 8 and client 5):
Client 8:
C:\> ping –t 192.168.20.105
- Once your ping is successful, remove the connection between the 6360 virtual Chassis and the 6860-A:
sw5 (6360-A) -> linkagg lacp agg 7 admin-state disable
- Relaunch the commands above, and notice how quickly Rapid STP recovers from a link failure:
Priority : 20000 (0x4E20),
Bridge ID : 8000-2c:fa:a2:0e:62:3f,
Root Port : None,
TxHoldCount : 3,
7

Last TC Rcvd Bridge : 8000-e8:e7:32:d4:84:03,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

-----+--------+-------------+---------+-------+----------+------

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
0/7 DIS 0 0 DIS 1/1/1 NS NO DIS 0000-00:00:00:00:00:00
0/78 FORW 3 0 DESG 1/1/23 PTP NO DIS 8000-2c:fa:a2:0e:62:3f

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
1/1/1 FORW 4 3 DESG 1/1/1 PTP EDG DIS 8000-e8:e7:32:d4:84:03
1/1/3 FORW 4 3 DESG 1/1/3 PTP NO DIS 8000-e8:e7:32:d4:84:03
0/78 FORW 3 0 ROOT 1/1/23 PTP NO DIS 8000-2c:fa:a2:0e:62:3f

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
1/1/1 DIS 0 0 DIS 1/1/1 NS NO DIS 0000-00:00:00:00:00:00
2/1/3 FORW 4 3 ROOT 2/1/3 PTP NO DIS 8000-e8:e7:32:d4:84:03
0/7 DIS 0 0 DIS 1/1/1 NS NO DIS 0000-00:00:00:00:00:00
- Has our Topology age changed?

----------------------------------------------------------------------------------------------------------------------------- ------
- Has the Root port changed?

----------------------------------------------------------------------------------------------------------------------------- ------
Tips
Remember that anytime there is a physical change, the STP will make the network infrastructure re-converge.
8
- What will happen when we re-connected the disconnected port?

----------------------------------------------------------------------------------------------------------------------------- -

-----+--------+-------------+---------+-------+----------+------
sw5 (6360-A) -> linkagg lacp agg 7 admin-state enable

-----+--------+-------------+---------+-------+----------+------
30 0/7 BLK 3 ALT DIS
3 Using the 1x1 Spanning Tree Mode

By default, an OmniSwitch uses the 1x1 or Per VLAN Spanning Tree mode. That means there’s a separate
instance of Spanning Tree for each VLAN.
As the default parameters are the same for each VLAN (base MAC address, cost links, etc…), the status of
each port is the same for each VLAN. To take advantage of the 1x1 mode and provide load-balancing, it may
be necessary to modify bridge priority to have a predictable behavior.
For example, this design would be interesting, considering that the blocked port for each VLAN is different:
Here, the 6360 VC is the access switch and 6860s are core switches. The 6360 VC has a dual attachment to
the 6860s to provide redundancy. The goal is to have one of the uplinks up for VLAN 20 and the other one for
VLAN 30.
9
3.1. Configuring the Priority

- To achieve this, change the priority of the 6860 to ensure that:
- The 6860-A is root bridge for VLAN 20. (Already done on part 2.1), restore default priority for VLAN 30
- The 6860-B root bridge for VLAN 30.

Sw8 (6860-B)-> spantree vlan 30 priority 20000
3.2. Verifying the Configuration
3.2.1. Verifying the VLAN 20 Configuration

- Check the priority for the instance VLAN 20:
o On the 6860-A:
sw7 (6860-A) -> show spantree
Vlan STP Status Protocol Priority
-----+----------+--------+--------------
1 ON RSTP 32768 (0x8000)
20 ON RSTP 20000 (0x4e20)
30 ON RSTP 32768 (0x8000)
57 ON RSTP 32768 (0x8000)
217 ON RSTP 32768 (0x8000)
278 ON RSTP 32768 (0x8000)
4094 OFF RSTP 32768 (0x8000)

Priority : 20000 (0x4E20),
Bridge ID : 4E20-2c:fa:a2:0e:62:3f,
Designated Root : 4E20-2c:fa:a2:0e:62:3f,
Root Port : None,
TxHoldCount : 3,
Last TC Rcvd Bridge : 8000-94:24:e1:7c:82:1d,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
----

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
0/7 FORW 3 0 DESG 1/1/4 PTP NO DIS 4E20-2c:fa:a2:0e:62:3f
0/78 FORW 3 0 DESG 1/1/23 PTP NO DIS 4E20-2c:fa:a2:0e:62:3f
10
o On the 6860-B:
Priority : 20000 (0x4E20),
Bridge ID : 8000-e8:e7:32:d4:84:03,
Designated Root : 4E20-94:24:e1:e8:b4:13,
Root Port : None,
TxHoldCount : 3,
Last TC Rcvd Bridge : 8000-94:24:e1:f0:f6:39,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
1/1/1 FORW 4 3 DESG 1/1/1 PTP EDG DIS 8000-e8:e7:32:d4:84:03
1/1/3 BLK 4 3 ALT 1/1/3 PTP NO DIS 8000-94:24:e1:7c:82:1d
0/78 FORW 3 0 ROOT 1/1/23 PTP NO DIS 4E20-2c:fa:a2:0e:62:3f
o On the 6360:
Priority : 32768 (0x8000),
Bridge ID : 8000-94:24:e1:f0:f6:39,
Designated Root : 4E20-94:24:e1:e8:b4:13,
Root Port : 2/1/3,
TxHoldCount : 3,
Last TC Rcvd Bridge : 8000-94:24:e1:e8:b4:13,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

-------+----+-------+-------+----+-------+---+---+------+----------------------+------
1/1/1 DIS 0 0 DIS 1/1/1 NS NO DIS 0000-00:00:00:00:00:00
2/1/3 FORW 4 3 DESG 2/1/3 PTP NO DIS 8000-94:24:e1:7c:82:1d
0/7 FORW 3 0 ROOT 2/1/4 PTP NO DIS 4E20-2c:fa:a2:0e:62:3f
11
3.2.2. Verifying the VLAN 30 Configuration

o On the 6860-B:
sw8 (6860-B) -> show spantree
o On the 6860-A:
Sw7 (6860-A) -> show spantree
o On the 6360-A (VC):

Sw5 (6360-A) -> show spantree
Sw5 (6360-A) -> show spantree vlan 30
Sw5 (6830-A) -> show spantree vlan 30 ports
OMNISWITCH R8
M U LT I P L E S PA N N I N G T R E E P R O T O C O L ( M S T P )
OBJECTIVES
• Understand the Multiple STP Protocol (MSTP)

• Learn how to implement it
MSTP REMINDER - GOAL MST Region1
• Goal
• Possibility to map several VLANs to one instance
(IEEE 802.1s standard
CIST
MSTI
• How it works
• Multiple Spanning Tree Region concept CST

(Based on RSTP)
• Allows to map one or more VLANs to a single

Spanning Tree instance
CIST
• Multiple Spanning Tree Instance (MSTI)
MSTI
• Interoperates with IEEE Common Spanning Tree CIST

protocols
MSTI MST Region2
• FLAT 802.1D
• FLAT 802.1w MST Region3
MSTP REMINDER – STP INSTANCES
PHYSICAL TOPOLOGY
VLAN 1
• How it works VLAN 10
VLAN 20
VLAN 30
• Instead of running one STP VLAN 40
Instance for every VLAN, VLAN 50
MSTP runs a number of VLAN 60
LOGICAL TOPOLOGIES
VLAN-independent STP instances
(= logical topologies) INSTANCE 0 (= MSTI 0)
• The administrator maps each VLAN

to the most appropriate STP instance,
also called MSTI (MST Instance)
VLAN 1 VLAN 10
VLAN 20
INSTANCE 1 (= MSTI1) INSTANCE 2 (= MSTI 2)
Note: If a VLAN is not mapped to any MSTI,

it is associated to the MSTI 0 (aka IST)
VLAN 30 VLAN 40 VLAN 50 VLAN 60

MSTP REMINDER - REGION MST Region1
MSTI 0= IST <> VLAN 1
• How it works
MST Region2
• A MSTP region is IST
• A collection of switches
• Sharing the same view of physical topology
REGION
CIST 1
• Partitioning into the same set of logical topologies REVISION
MSTI NB: 1
• MSTP Region seen as one switch for IST
the rest of the world CST
• Rest of the world only “aware” of the CST instance 0 REGION 2 /

CSTI NB: 1
REVISION
• Forwards traffic for VLANs which are not covered by MSTI
any MSTI
• CST interacts with STP outside the region Achieve
this by representing the region as one Virtual
IST
spantree MST Region3
• MST region sees the outside world via its CIST/ CST REGION 3
interaction only REVISION NB: 1
MSTP REMINDER - INTRA REGION CIST 0 = VLAN 1
MSTI 1 = VLAN 11 to 13
MSTI 2 = VLAN 14 to 16
• How it works MSTI 3 = VLAN 17 to 20
Root spantree
• BPDUs are carried through the network via the MSTI CIST 0
0 (aka IST, Internal Spanning Tree) MSTI 1
• Root switch sends out BPDUs with maximum hop
count which is decremented at each switch as BPDUs
are forwarded. At 0 hop, the BPDUs are discarded
• One BPDU is exchanged for all instances over default
VLAN
• MSTP BPDUs are sent on every port
• The maximum hop count supported is 40, default is VLAN 11 to 20 tagged
20
Root spantree Root spantree

MSTI 3 MSTI 2
Note: If a VLAN is not mapped to any MSTI,

it is associated to the MSTI 0 (aka IST)
MSTP REMINDER - SPECIFICATION
• Specification
• Instance 0
• Always configured on any 802.1s switch
• Common and Internal Spanning Tree instance
• CIST
• By default, all VLANs are mapped to the CIST
• Up to 16 other instances are supported by Alcatel-Lucent AOS

• Multiple Spanning Tree Instance – MSTI
MSTP CONFIGURATION
MSTP CONFIGURATION
Step by Step
Select the Flat Spanning Tree mode
Select the MSTP protocol
Configure MST regions (name, revision level)
Configure MSTIs
Map VLANs to MSTI
Manage Switch Priority

MSTP CONFIGURATION
Step by Step
Select the Flat Spanning Tree mode

Change Spanning Tree mode to flat mode
SW2
-> spantree mode flat SW1
SW3
Select the MSTP protocol

Change Spanning Tree protocol to MSTP
-> spantree protocol mstp
MSTP CONFIGURATION
Step by Step
Configure MST regions (name, revision level)
Create a MSTP region

To belong to the same region, switches must
SW1 SW2
have the same:
REGION_1
Region name REVISION NB: 1
Revision level
SW3
VLAN to MSTI mapping
-> spantree mst region name {mst_region_name}

-> spantree mst region revision level 1
-> spantree msti {msti_id}
-> spantree msti {msti_id} vlan {vlan_id}
MSTP CONFIGURATION
Step by Step
Configure MSTIs
Every switch has a CIST (= MSTI 0)

Create additional MSTI MSTI 0
SW1 SW2
MSTI 1
Required to segment VLANs into separate instances MSTI 2
REGION_1
REVISION NB: 1
SW3
-> spantree msti {msti_id}

MSTP CONFIGURATION
Step by Step
Map VLANs to MSTI
Assign the VLANs to the MSTIs

MSTI 1 <> VLAN 20 SW1 SW2
Non assigned VLANs are mapped to MSTI 2 <> VLAN 30
the MSTI 0 (CIST) CIST 0 <> OTHER VLANS
REGION_1
REVISION NB: 1
SW3

MSTP CONFIGURATION
Step by Step
Manage Switch Priority

MSTI 1 <> VLAN 20
Configure the switch priority value for MSTI 2 <> VLAN 30 SW1 SW2
CIST 0 <> OTHER VLANS RB RB
each switch
REGION_1
REVISION NB: 1
Used to determine which switch will be
RB SW3
Root spantree
Tips: Manage switches priority values to have a

different switch assumes the Root spantree role for each MSTI
Ex
SW 1 SW 2 SW 3
MSTI 0 (CIST) 32768 32768 16384
MSTI 1 16384 32768 32768
MSTI 2 32768 16384 32768
CONFIGURING MSTP - MONITORING
Monitoring -> show spantree msti 3
Spanning Tree Parameters for Msti 3
Spanning Tree Status: ON,
Protocol: IEEE Multiple STP,
mode: FLAT (Single STP),
Priority: 4099 (0x1003),
spantree ID: 1003-00:d0:95:bd:2a:e2,
Designated Root: 1003-00:d0:95:bd:2a:e2,
Cost to Root spantree: 0,
Root Port: None,
Next Best Root Cost: 0,
Next Best Root Port: None,
Hold Time: 1,
Topology Changes: 5,
Topology age: 00:06:50,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
-> show spantree mst region

Configuration Name : myregion,
Revision Level : 1,
Configuration Digest : 0x45929389 64c56251 6c821b64 d0862c32,
Revision Max hops : 20,
Cist Instance Number :0
CONFIGURING MSTP - EXAMPLE
-> spantree mode flat -> spantree mode flat
-> spantree protocol mstp -> spantree protocol mstp
Example 1 -> spantree mst region name myregion ->

->
spantree
spantree
mst region name myregion
mst region revision 1
-> spantree mst region revision 1
-> spantree cist protocol mstp -> spantree cist protocol mstp
-> spantree msti 1 -> spantree msti 1
-> spantree msti 1 VLAN 1-15 -> spantree msti 1 VLAN 1-15
-> spantree msti 2 -> spantree msti 2
-> spantree msti 2 VLAN 16-20 -> spantree msti 2 VLAN 16-20
-> spantree cist priority 4096 -> spantree cist priority 8192
-> spantree msti 1 priority 4096 -> spantree msti 1 priority 8192
-> spantree msti 2 priority 8192 -> spantree msti 2 priority 4096
-> spantree msti 1 1/1/1 priority 1 -> spantree msti 1 1/1/2 priority 1
Mapping:
Root spantree VLAN 1 -> instance 0 (CIST)

CSTI 0 VLAN 1 to 15 -> instance 1 Root spantree
MSTI 1 VLAN 16 to 20 -> instance 2 MSTI 2
1/1/1 1/1/2
VLAN 1 to 20
1/1/11 1/1/22
SwitchA VLAN 1 to 15 Root spantree
MSTI 2
Example 1 1/1/1 1/1/2
X
1/1/11
X SwitchB
1/1/22
Root spantree VLAN 16 to 20

CSTI 0
MSTI 1
SwitchA-> show spantree mst port 1/1/1 SwitchB-> show spantree mst port 1/1/2
MST Role State Pth Cst Edge Boundary Op Cnx Vlans MST Role State Pth Cst Edge Boundary Op Cnx Vlans
---+------+-----+--------+----+--------+------+--------- ---+------+-----+--------+----+--------+------+---------
0 DESG FORW 20000 NO NO PTP 0 ROOT FORW 20000 NO NO PTP
1 DESG FORW 20000 NO NO PTP 1-15 1 ROOT FORW 20000 NO NO PTP 1-15
2 ALT BLK 20000 NO NO PTP 2 DESG FORW 20000 NO NO PTP
SwitchA-> show spantree mst port 1/1/11 SwitchB-> show spantree mst port 1/1/22
MST Role State Pth Cst Edge Boundary Op Cnx Vlans MST Role State Pth Cst Edge Boundary Op Cnx Vlans
---+------+-----+--------+----+--------+------+--------- ---+------+-----+--------+----+--------+------+---------
0 DESG FORW 20000 NO NO PTP 100 0 ALT BLK 20000 NO NO PTP 100
1 DESG FORW 20000 NO NO PTP 1 ALT BLK 20000 NO NO PTP
2 ROOT FORW 20000 NO NO PTP 16-20 2 DESG FORW 20000 NO NO PTP 16-20
Priority Switch A Switch B Switch C
Mapping:
Example 2 VLAN 1 -> instance 0 (CIST) CIST 4096 32768 32768

VLAN 2 and 3 -> instance 1
MIST 1 32768 4096 32768
VLAN 4 and 5 -> instance 2
MIST 2 32768 32768 4096
Root spantree
Switch B MSTI 1
Switch B
2/1/1 2/1/3 2/1/1 2/1/3

Traffic Load Sharing
VLAN 2 and 3 VLAN 4 and 5

3/1/2
Root spantree
MSTI 2
1/1/2 3/1/1 3/1/2 1/1/2
1/1/3 1/1/3 3/1/1
Switch A Switch C Switch A Switch C

THANK YOU
OmniSwitch R8
Multiple Spanning Tree Protocol
How to
✓ This lab is designed to familiarize you with the Multiple Spanning Tree
Protocol (MSTP) on an OmniSwitch.
Contents
1 Topology ........................................................................................ 2
2 Multiple Spanning Tree ....................................................................... 3
2
1 Topology
3
2 Multiple Spanning Tree

802.1s is an IEEE standard allowing for multiple STP instances to be configured on the switch. It is similar in
operation to 1X1 mode, but allows for multiple VLANs to be assigned to a single STP instance.
- To configure MSTP, spanning tree has to be configured first in flat mode:

sw5 (6360-A) -> spantree mode flat
sw8 (6860-B) -> spantree mode flat
- Then set the protocol to mstp :

sw5 (6360-A) -> spantree mst region name lab_region
sw5 (6360-A) -> spantree mst region revision-level 1
sw5 (6360-A) -> spantree protocol mstp
sw7 (6860-A) -> spantree mst region name lab_region

sw7 (6860-A) -> spantree mst region revision-level 1
sw7 (6860-A) -> spantree protocol mstp
sw8 (6860-B) -> spantree mst region name lab_region

sw8 (6860-B) -> spantree mst region revision-level 1
sw8 (6860-B) -> spantree protocol mstp
sw8 (6860-B) -> show spantree cist

Spanning Tree Parameters for Cist
Protocol : IEEE Multiple STP,
mode : FLAT (Single STP),
Auto-Vlan-Containment: Enabled ,
Priority : 32768 (0x8000),
Bridge ID : 8000-e8:e7:32:b3:3c:f9,
CST Designated Root : 8000-2c:fa:a2:aa:34:9f,
Cost to CST Root : 20004,
Designated Root : 8000-94:24:e1:7c:82:41,
TxHoldCount : 3,
Last TC Rcvd Bridge : 8000-e8:e7:32:d9:b4:b9,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
sw5 (6360-A) -> show spantree cist

Priority : 32768 (0x8000),
Bridge ID : 8000-94:24:e1:7c:82:41,
Root Port : 1/1/24,
TxHoldCount : 3,
4

Last TC Rcvd Bridge : 8000-e8:e7:32:7d:0e:40,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
sw7 (6860-A) -> show spantree cist

Priority : 32768 (0x8000),
Bridge ID : 8000-e8:e7:32:d9:b4:b9,
TxHoldCount : 3,
Last TC Rcvd Bridge : 8000-94:24:e1:7c:82:41,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
Tips
Notice the Cost to Root Bridge values in the example above. Multiple STP uses a 32-bit Path Cost value vs the
16-bit path cost value that 802.1d/802.1w use by default.
Notes
The commands above set the switch to flat mode, configured a Multiple STP region name and revision level,
and finally enabled the IEEE MSTP protocol. 1X1 and MSTP cannot be configured at the same time; and the
switch must be configured in flat Spanning Tree mode.
- Now, check to see how 802.1s operates with just the single default STP instance, called the Common
and Internal Spanning Tree (CIST):
sw5 (6360-A) -> show spantree cist vlan-map
Cist
Name : ,
VLAN list : 1-4094
sw7 (6860-A) -> show spantree cist vlan-map

Cist
Name : ,
VLAN list : 1-4094
sw8 (6860-B) -> show spantree cist vlan-map

Cist
Name : ,
VLAN list : 1-4094
5
- You should see that all VLANs belong to the CIST instance, the CIST instance is created by default and all
VLANs on the switch are mapped to it by default.
- Now, create 2 additional STP instances and map the appropriate VLANs to them. Type the following:
sw5 (6360-A) -> spantree msti 1
sw5 (6360-A) -> spantree msti 1 vlan 20

sw8 (6860-B) -> spantree msti 1

sw8 (6860-B) -> spantree msti 2
sw8 (6860-B) -> spantree msti 1 vlan 20
sw8 (6860-B) -> spantree msti 2 vlan 30
sw5 (6360-A) -> show spantree msti vlan-map
Cist
Name : ,
VLAN list : 1-19,21-29,31-4094
Msti 1
Name : ,
VLAN list : 20
Msti 2
Name : ,
VLAN list : 30
sw7 (6860-A) -> show spantree msti vlan-map
Cist
Name : ,
VLAN list : 1-19,21-29,31-4094
Msti 1
Name : ,
VLAN list : 20
Msti 2
Name : ,
VLAN list : 30
sw8 (6860-B) -> show spantree msti vlan-map
Cist
Name : ,
VLAN list : 1-19,21-29,31-4094
Msti 1
Name : ,
VLAN list : 20
Msti 2
Name : ,
VLAN list : 30
Notes
Vlan 20 and 30 have been removed from the CIST and associated with a Multiple Spanning Tree Instance (MSTI).
We could have of course associate several VLAN to the same MSTI
6
- Now, check the root bridge for the MSTI's :

sw5 (6360-A) -> show spantree msti 1
Priority : 32769 (0x8001),
Bridge ID : 8001-94:24:e1:7c:82:41,
Root Port : None,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32770 (0x8002),
Bridge ID : 8002-94:24:e1:7c:82:41,
Root Port : None,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32769 (0x8001),
Bridge ID : 8001-e8:e7:32:d9:b4:b9,
TxHoldCount : 3,
Last TC Rcvd Bridge : 0000-00:00:00:00:00:00,
7
Max Age = 20,

Forward Delay = 15,
Hello Time = 2

Priority : 32770 (0x8002),
Bridge ID : 8002-e8:e7:32:d9:b4:b9,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
sw8 (6860-B) -> show spantree msti 1

Priority : 32769 (0x8001),
Bridge ID : 8001-e8:e7:32:b3:3c:f9,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32770 (0x8002),
Bridge ID : 8002-e8:e7:32:b3:3c:f9,
8

TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
- Check what ports are in blocking state on the switches

sw5 (6360-A) -> show spantree msti ports blocking
sw8 (6860-B) -> show spantree msti ports blocking
- Notice that both MSTIs have the same root bridge. Load balancing can be achieved by changing the
priority of bridge for different MSTI as we have done with RSTP:
sw7 (6860-A) -> spantree msti 1 priority 16384
sw8 (6860-B) -> spantree msti 2 priority 16384
Notes
Priority has to be multiple of 4096 (8192, 12288, 16384, …, 61440)

Priority : 16385 (0x4001),
Bridge ID : 4001-e8:e7:32:d9:b4:b9,
Designated Root : 4001-e8:e7:32:d9:b4:b9,
Root Port : None,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32769 (0x8001),
Bridge ID : 8001-94:24:e1:7c:82:41,
TxHoldCount : 3,
9
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32769 (0x8001),
Bridge ID : 8001-e8:e7:32:b3:3c:f9,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 32770 (0x8002),
Bridge ID : 8002-94:24:e1:7c:82:41,
Designated Root : 4002-e8:e7:32:b3:3c:f9,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

10
Priority : 32770 (0x8002),
Bridge ID : 8002-e8:e7:32:d9:b4:b9,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2

Priority : 16386 (0x4002),
Bridge ID : 4002-e8:e7:32:b3:3c:f9,
Root Port : None,
TxHoldCount : 3,
Max Age = 20,
Forward Delay = 15,
Hello Time = 2
Tips
Note, in Multiple Spanning Tree the bridge priority is the assigned Bridge Priority value PLUS the MSTI instance
value
- Check what ports are in blocking state on the swicthes

sw8 (6860-B) -> show spantree msti ports blocking
- To continue with next labs, revert spanning tree in 1x1 mode :

sw5 (6360-A) -> spantree mode per-vlan
sw8 (6860-B) -> spantree mode per-vlan
sw5 (6360-A) -> no spantree mst region name

sw7 (6860-A) -> no spantree mst region name
sw8 (6860-B) -> no spantree mst region name
11
sw5 (6360-A) -> no spantree msti 1

sw8 (6860-B) -> no spantree msti 1

sw8 (6860-B) -> no spantree msti 2

OMNISWITCH R8
M U LT I P L E V L A N R E G I S T R AT I O N P R O T O C O L ( M V R P )
OBJECTIVES
• Learn the MVRP Basics

• Implement MVRP in the OmniSwitches
OVERVIEW
• MVRP
• IEEE 802.1ak
• Implements the MRP Protocol
• Multiple Vlan Registration Protocol
• Controls and signals dynamic VLAN registration entries across the bridged network
• Close to the GVRP protocol
• Standards-based Layer 2 network protocol
• Re-declaration during topology change (only for affected VLANs)
• Flushing of learnt attributes during topology change

DESCRIPTION
•.1q
• Declarations & registrations follow the path

defined by STP topology
• Once a port receives a MVRP PDU VLAN10 VLAN10
• Becomes a member of the advertised VLAN
• Shares all information in the PDU with all switches VLAN11
VLAN11
participating in MVRP in the switching network by
propagating/transmitting out of other forwarding ports in
that STP instance •Static VLAN •Dynamic VLAN (GVRP/ MVRP)
• MVRP sends one PDU that includes the state of

all 4094 VLANs on a port
• MVRP VLAN advertisement can be triggered by

group mobility VLANs
•TCN, VLAN11
• MVRP also includes the transmission of a TCN for

individual VLANs VLAN10 VLAN11
CLI CONFIGURATION
• MVRP is supported only in STP flat mode
-> mvrp {enable | disable}
• Enables/Disables MVRP on a switch globally

-> mvrp port chassis/slot/port[–port2] {enable | disable}
• Enables or disables MVRP on specific ports on the switch
-> mvrp linkagg agg_id[-agg_id2] {enable | disable}
• Enables or disables MVRP on specific aggregates on the switch

-> mvrp maximum-vlan vlan_limit
• Configures the maximum number of dynamic VLANs that can be created by MVRP.
-> mvrp {port chassis/slot/port[– port2] | linkagg agg_id[-agg_id2]} registration {normal | fixed | forbidden}
• Configures the MVRP registration mode for specific ports or aggregates.

CLI CONFIGURATION
• Configures the applicant mode of specific ports on the switch. The applicant mode
determines whether MVRP PDU exchanges are allowed on a port depending on the Spanning
Tree state of the port
-> mvrp {port chassis/slot/port[–port2] | linkagg agg_id[-agg_id2]} applicant {participant | non-participant | active}
CLI CONFIGURATION
MVRP Timers
• mvrp timer join
-> mvrp {port chassis/slot/port[–port2] | linkagg agg_id[-agg_id2]}
timer join timer_value
* The valid range is 250 milliseconds to 1073741773 milliseconds.
• mvrp timer leave

timer leave timer_value
• mvrp timer leaveall

timer leaveall timer_value
• mvrp timer periodic-timer

timer periodic-timer timer_value
* The valid range is 1 to 2147483647 milliseconds
CLI MONITORING
Summary of the commands used for verifying the MVRP configuration
THANK YOU
OmniSwitch R8
Multiple VLAN Registration Protocol
How to
✓ This lab is designed to familiarize you with the MVRP feature and learn
how to configure it through the CLI.
Contents
1 Topology ........................................................................................ 2
2 Use MVRP ....................................................................................... 3
2.1. Configure the maximum number of VLANs ...................................................... 3
2.2. Create some dynamic VLANs ...................................................................... 3
2.3. Delete VLAN ......................................................................................... 5
2.4. Revert to 1x1 RSTP mode ......................................................................... 6
2
1 Topology
MVRP has to be globally enabled on a switch before it can start forwarding MVRP frames.
In order to have MVRP enabled, switch must be in spanning-tree flat mode.
- At this step our network is configure with STP 1x1, but to enable MVRP we have to be in flat mode.
- To configure STP flat mode type:
sw8 (6860-B) -> spantree mode flat
- To enable MVRP type:

all -> mvrp enable
Tips
MVRP can be enabled on ports regardless of whether it is globally enabled or not. However, for the port to
become an active participant, MVRP must be globally enabled on the switch. By default, MVRP is disabled on
the ports. To enable MVRP on a specified port, use the mvrp port command
- Enable MVRP on trunk links of all switches:

sw5 (6360-A) -> mvrp linkagg 7 enable
sw5 (6360-A) -> mvrp port 2/1/3 enable

sw8 (6860-B) -> mvrp port 1/1/3 enable

sw8 (6860-B) -> mvrp linkagg 78 enable
Notes
MVRP can be configured only on fixed, 802.1 Q and aggregate ports. It cannot be configured on mirror, mobile,
VPLS Access, and VLAN Stacking User ports.
3
2 Use MVRP
2.1. Configure the maximum number of VLANs

A switch can create dynamic VLANs using MVRP. By default, the maximum number of dynamic VLANs that
can be created using MVRP is 256. If the VLAN limit to be set is less than the current number of dynamically
learned VLANs, then the new configuration will take effect only after the MVRP is disabled and enabled
again on the switch. If this operation is not done, the VLANs learned earlier are maintained.
- To modify the maximum number of dynamic VLANs the switch is allowed to create, use the command:
sw5 (6360-A) -> mvrp maximum-vlan 150
sw7 (6860-A) -> mvrp maximum-vlan 150
sw8 (6860-B) -> mvrp maximum-vlan 150
2.2. Create some dynamic VLANs

- On 6360-A, create a new VLAN 40 :
sw5 (6360-A) -> vlan 40

- Now let’s have a look on the information on the 6860s :
sw7 (6860-A) -> show mvrp linkagg 7 statistics

Aggregate ID 7:
New Received : 22,
Join In Received : 40,
Join Empty Received : 156,
Leave Received : 0,
In Received : 0,
Empty Received : 162820,
Leave All Received : 1,
New Transmitted : 20,
Join In Transmitted : 47,
Join Empty Transmitted : 192,
Leave Transmitted : 0,
In Transmitted : 0,
Empty Transmitted : 188111,
LeaveAll Transmitted : 0,
Failed Registrations : 66,
Total Mrp PDU Received : 42,
Total Mrp PDU Transmitted : 46,
Total Mrp Msgs Received : 654,
Total Mrp Msgs Transmitted : 1239,
Invalid Msgs Received : 0
sw8 (6860-B) -> show mvrp port 1/1/3 statistics

Port 1/1/3:
New Received : 2,
Join In Received : 50,
Join Empty Received : 124,
Leave Received : 0,
In Received : 0,
Empty Received : 111328,
Leave All Received : 1,
New Transmitted : 22,
Join In Transmitted : 48,
Join Empty Transmitted : 124,
Leave Transmitted : 0,
In Transmitted : 0,
4
Empty Transmitted : 147226,

LeaveAll Transmitted : 0,
Failed Registrations : 48,
Total Mrp PDU Received : 29,
Total Mrp PDU Transmitted : 36,
Total Mrp Msgs Received : 528,
Total Mrp Msgs Transmitted : 981,
Invalid Msgs Received : 0
- Look at the port configuration :
sw7 (6860-A) -> show mvrp linkagg 7

MVRP Enabled : yes,
Registrar Mode : normal,
Applicant Mode : active,
Join Timer (msec) : 600,
Leave Timer (msec) : 1800,
LeaveAll Timer (msec) : 30000,
Periodic Timer (sec) : 1,
Periodic Tx status : disabled
sw7 (6860-A) -> show mvrp linkagg 7 last-pdu-origin

Port Last-PDU Origin
-------+--------------------
0/7 94:24:e1:7c:75:f3
- Notice that VLAN 40 has been automatically created :

------+-------+-------+------+------+------+------------------
40 dyn Ena Ena Dis 1500 VLAN 40
250 pvlan-p Ena Dis Dis 1500 PVLAN 250
251 pvlan-c Ena Dis Dis 1500 PVLAN 251
252 pvlan-i Ena Dis Dis 1500 PVLAN 252
sw8 (6860-B) -> show vlan

------+-------+-------+------+------+------+------------------
40 dyn Ena Dis Dis 1500 VLAN 40
250 pvlan-p Ena Dis Dis 1500 PVLAN 250
251 pvlan-c Ena Dis Dis 1500 PVLAN 251
252 pvlan-i Ena Dis Dis 1500 PVLAN 252
Notes
The VLAN type is then Dynamic
5
- And those ports have been dynamically tagged:

port type status
----------+-----------+---------------
1/1/4 dynamic forwarding
0/5 dynamic forwarding

port type status
----------+-----------+---------------
1/1/3 dynamic forwarding
0/5 dynamic blocking
Notes
VLAN are automatically created and port tagged, but of course, there’s no ip interface creation nor association
with MSTI.
2.3. Delete VLAN
- Check the status of VLAN 40 on 6360:

------+-------+-------+------+------+------+------------------
4094 vcm Ena Ena Dis 1500 VCM IPC
- It’s a standard VLAN (comparing with dynamic VLAN on 6860.
- Now delete the VLAN 40 on 6360:
sw5 (6360-A) -> no vlan 40
- What happens to it ?
sw5 (6360-A) -> no vlan 40

ERROR: Dynamic vlan 40 cannot be deleted
Tips
The mvrp status is equal to the dyn. That means the VLAN 40 has been automatically re-created.
- Now disable mvrp on the 3 switches:
all -> mvrp disable

sw5 (6360-A) -> mvrp port 2/1/3 disable
6

------+-------+-------+------+------+------+------------------
4094 vcm Ena Ena Dis 1500 VCM IPC
- The VLAN 40 has now disappear as mvrp is disabled.
2.4. Revert to 1x1 RSTP mode

- For the next lab, it will be easier to continue with per-vlan STP :
sw8 (6860-B) -> spantree mode per-vlan
OMNISWITCH R8
CONSISTENT AOS NETWORK SECURITY
OBJECTIVES
• Understand and implement the following

features
- DOS Protection
- UDP Relay
- Authentication Trap Mode
- ARP poisoning
- Port Mapping
- Storm Control
- Learned Port Security
DOS PROTECTION
DOS FILTERING
• Ability to filter the following DoS attacks
• Ping of Death, SYN attack, Land attack, Teardrop, Bonk, Boink, Pepsi
• Detect ARP flooding
• QoS rate-limits ARP packets to the CPU
• Detect any packet with invalid source or destination IP address
• A packet matching specific criteria well be marked at “Invalid-IP”
• Detect Multicast IP and MAC address mismatch
• Detect Ping overload
• System measures the rate of ICMP requests received over a period of 5 seconds,
and detects a DoS attack if the measured rate exceeds 100 pkts/sec
• Detect packets received with a source address of 127.0.0.1
• Traps can be configured or QM can be used to Quarantine device
• Ability to detect port scanning based on packet thresholds
UDP RELAY
GENERIC UDP PORT RELAY
• To enable UDP Relay for a specified UDP service ports
-> ip udp relay port port_num [description description]
• To support for service name and custom ports
-> ip udp relay service {tftp | tacacs | ntp | nbns | nbdd | dns} [description description]
• To specify a VLAN on which traffic destined for the specified UDP service port is forwarded
-> ip udp relay {service {tftp | tacacs | ntp | nbns | nbdd | dns} | port port_num
[description description]} vlan vlan_id[-vlan_id2]
• To specify the UDP server IP address to which traffic destined for a UDP port is forwarded
as unicast packets.
-> ip udp relay {service {tftp | tacacs | ntp | nbns | nbdd | dns} | port port_num
[description description]} address ip_address
GENERIC UDP PORT RELAY
• To display the generic UDP relay service configuration
-> show ip udp relay [service {tftp | tacacs | ntp | nbns | nbdd | dns} | port port_num]
• To display the current statistics for each UDP port relay service.
-> show ip udp relay statistics [service {tftp | tacacs | ntp | nbns | nbdd | dns}]
[port [port_num]]
-> show ip udp relay -> show ip udp relay statistics

Service Name Port IP Address Vlans Services Port Service Pkts Recvd Pkts Sent Dst Vlan/IP Address Svc
---------------------+------+--------------+---------+--------- -----+--------------+---------------+-----------+----------------------+------
DNS port 53 20 53 DNS port 0 0 20
TFTP port 69 69 TFTP port 0
AUTHENTICATION TRAP MODE
AUTHENTICATION TRAP MODE
• The OmniSwitch can be configured to send both a standard and private authentication
trap.
• If mode is set to standard (default): only the standard authenticationFailure notification will be sent.
• If mode is set to private: only alaAuthenticationFailure notification failure will be sent.
• If mode is set to both: authenticationFailure and alaAuthenticationFailure notifications will be sent.
• The alaAuthenticationFailure includes the IP address of the client causing the

authentication failure.
• The following CLI command is associated with this feature:

snmp authentication-trap mode {standard | private | both}
ARP
ARP DEFENSE MECHANISM
• Prevents the CPU from receiving multiple unresolved next hop requests
• Creates a drop-entry as soon as it attempts to resolve an ARP for the purpose

of forwarding traffic
• The entry is removed either
when the ARP is resolved,

or
after 12 attempts have been made, once every 5 secs. (~1 minute)
• Duplicate request received during the time the switch is attempting to resolve the ARP is
dropped
• Avoids CPU utilization climb and destabilizing the switch while next-hop is being resolved
ARP POISONING DETECTION
• Detects the presence of a ARP-Poisoning host on the network
• Identifies unsolicited ARP Replies from an attacker, false ARP requests and unsolicited
ARP replies
• Sends out ARP Requests for certain configurable restricted addresses and its own interface
addresses
• Reply to all ARP Requests for its IP Interface address, but will not learn the ARP mapping of the
source from such packets
• ARP Reply will be accepted only if the Switch had originated a corresponding ARP Request
• Logs the event and send a trap
1. ARP Poisoning by a host that
ARP Poisoning Examples Man in the middle replies to all ARP Requests
THU JAN 24 16:34:38 : NS (123) alert message:
+++ +++++++++++++++++++++++++++++++++++++++++++++++
+++ ARPADDRESSSCAN source detected on 1/7... 2. ARP Requests from an Attacker
+++ Trigger Operation... Impersonation
+++ Interval Count Sensitivity
+++ ---------------------------------------------
+++ 5 5 50 3. Unsolicited ARP Replies from an
+++ Traffic Statistics... MAC Flooding Attacker
+++ Packet-Type Direction Count
+++ ---------------------------------------------
+++ ARP_REP OUT 0
+++ ARP_REQ IN 71
+++ +++++++++++++++++++++++++++++++++++++++++++++++
ARP POISONING DETECTION
• Adding an ARP Poison restricted address
• Maximum of two IP addresses per IP interface
-> ip dos arp-poison restricted-address 192.168.100.152
• Displaying the number of attacks detected for configured ARP poison restricted-addresses
-> show ip dos arp-poison
WED JAN 30 16:15:35 : IP (15) info message:

+++ 1/0 ARP poisoning REPLY from 192.168.60.100.
-> show ip dos arp-poison

IP Address Attacks Attacks
--------------------+-----------
192.168.1.1 0 0
192.168.1.2 0 0
192.168.60.100 2
ADDRESS RESOLUTION PROTOCOL (ARP)
• The switch stores the hardware address in its ARP cache (ARP table)
• The table contains a list of IP addresses and their corresponding MAC addresses
• Entries in the table are used to translate 32-bit IP addresses into 48-bit Ethernet or IEEE
802.3 hardware addresses
• Dynamic addresses remain in the table until they time out (Default 300 sec.)
• Static entries are permanent and are created using the IP address of the entry followed by
its physical (MAC) address
-> arp 171.11.1.1 00:05:02:c0:7f:11
• Use the alias keyword to specify that the switch will act as an alias (proxy) for this IP
address.
-> arp 171.11.1.1 00:05:02:c0:7f:11 alias
LOCAL PROXY ARP
• Allows the network administrator to configure proxy functionality on the switch
• Enables proxy ARP on a per VLAN basis
• All ARP requests received on VLAN member ports are answered with the MAC address of
the VLAN’s virtual IP router port
Switch B Normal ARP
ARP
Local Proxy ARP
ARP
Switch A Switch C
PC 1 PC 2
192.168.10.101 192.168.10.102
-> ip interface name [address ip_address] [mask subnet_mask] [admin [enable | disable]] [vlan vid]
[forward | no forward] [local-proxy-arp | no local-proxy-arp] [eth2 | snap] [primary | no primary]
PROXY ARP FILTERING
• Extended Proxy ARP Filtering
• Blocks the switch from providing ARP replies for the specified IP address(es).
• It is generally used in conjunction with the Local proxy ARP application
• By default, no ARP filters exist in the switch
-> arp filter ip_address [mask mask] [vid] [sender | target] [allow | block]
-> arp filter 198.0.0.0 mask 255.0.0.0 sender block
-> show arp filter

PORT MAPPING
MAC FORCED FORWARDING
PORT MAPPING
• Goal
• Defining 2 set of ports & controlling the
communication within each set Port Mapping Session 1
• Up to 8 Port Mapping sessions
• Ports can only belong to a single session - except uni. 1/3/1
network pts 1/3/2 2/1/16
1/3/3 2/1/17
• Uni-directionnal 1/3/4
• User-port User Network

• no direct user-to-user traffic Ports Ports
• only user-to-network
• Network-port
• network-to-user & network-to-network
Platform Supported
• Bi-directional
• User-port Release 8
• no direct user-to-user traffic
• only user-to-network
• Network-port
• no direct network-to-network traffic
• only network-to-user
PORT MAPPING
• Creating a Mapping Session
-> port-mapping session_id [user-port {slot chassis/slot | chassis/slot/port[-port2] | linkagg agg_id}]
[network-port {slot chassis/slot | chassis/slot/port[-port2] | linkagg agg_id}]
Examples
• Enables, disables a port mapping session -> port-mapping 3 user-port 1/2/3 network-port 1/6/4
-> port-mapping 4 user-port 1/2/5-8
-> port-mapping session_id {enable | disable} -> port-mapping 5 user-port 1/2/3 network-port slot 3
• Creates a port mapping session with the user ports,

network ports, or both user ports and network ports
-> port-mapping session_id [user-port {slot chassis/slot | chassis/slot/port[-port2] | linkagg agg_id}]
[network-port {slot chassis/slot | chassis/slot/port[-port2] | linkagg agg_id}]
• Displaying the status of one or more port mapping sessions

-> show port-mapping [session_id] status
• Displaying the configuration of one or more port mapping sessions

-> show port-mapping [session_id]
MAC FORCED FORWARDING
IP1 - MAC1
MAC FORCED FORWARDING Access Router
DHCP Server
• Described in RFC 4562 1- DHCP ACK – option 3
• Control unwanted broadcast traffic and host-to-host Router IP/Gateway = IP1
communication 2 - ARP Reply

IP1 is MAC1 Aggregation
• Implements an ARP proxy function that
• Prohibits MAC address resolution between hosts located IP1-MAC1 mapping
within the same subnet but at different customer Proxy ARP: MAC1
premises IP1-MAC1 mapping
Proxy ARP: MAC1
• In effect directs all upstream traffic to an IP gateway Subnet
providing IP connectivity between these same hosts
10.0.0.0/8
• Dynamic Proxy ARP uses:
• Port Mapping Port Mapping
• DHCP snooping User/network ports
• Local proxy ARP
• Description IPA IPB
• Once a DHCP lease is offered to a L2 client, stores the MACA MACB
ARP cache ARP cache
router IP advertised in the DHCP ACK IPA -> MAC1
IPB -> MAC1
• An ARP reply with the access router @MAC is sent for all
subsequent ARP requests to the access router or to any
other IPs in the same VLAN/subnet
MAC FORCED FORWARDING - CLI/WEBVIEW
-> port-mapping 1 user-port 1/1/1-2 network-port linkagg 8
-> port-mapping 1 dynamic-proxy-arp enable
-> dhcp-snooping vlan 20 admin-state enable
-> port-mapping 1 enable
-> show port-mapping

SessionID USR-PORT NETWORK-PORT
-----------+----------------+------------------
1 1/1/1 0/8
1 1/1/2
-> show port-mapping status

SessionID Direction Status Unknown Unicast DPA Status
------------+-----------------+----------+------------------+------------
1 bi enable flood enable
-> show ip dynamic-proxy-arp
Router IP Vlan Mac-Address Port

-----------------+----------------+-------------------+------------------
STORM CONTROL
STORM CONTROL
• Configures the flood rate settings on a single port, a range of ports, or an entire Network
Interface (NI)
-> interfaces {slot chassis/slot| port chassis/slot/port[-port2]} flood-limit {bcast | mcast | uucast | all} rate
{pps pps_num| mbps mbps_num | cap% cap_num | enable | disable | default} [low-threshold low_num]
• Configures the action on a single port, a range of ports, when the port reaches the storm
violated state
interfaces {slot chassis/slot| port chassis/slot/port[-port2]} flood-limit {bcast | mcast | uucast | all} action
{shutdown | trap | default}
LEARNED PORT SECURITY
• Mechanism for controlling network device access on one or more switch ports
• Limit the amount of time source learning occurs on all LPS ports
• Limit the max number of L2 addresses that can be learned on a port. (Dynamic or Static)
• Limit the L2 address learning for the specific period of time
• Supported on Fixed, Mobile, 802.1Q tagged, Authenticated, 802.1X

• Not supported on Link Aggregate ports
MAC-1
• Violation options
• Block only traffic that violates LPS port restrictions
• -> authorized traffic is forwarded on the port MAC Limit
• Shutdown the port Or
MAC List
• Steps to Configuring LPS:

• Enable LPS on a port MAC-2
• Set the number of learned Mac’s
• Set the time limit for LPS
• Select the violation mode
LEARNED PORT SECURITY - CONFIGURATION
• Configuring LPS on a port
-> port-security port {chassis/slot/port[-port2] } [admin-state {enable | disable | locked}]
• Disables all learning on the port. Existing MAC addresses are retained but no additional learning of
addresses, except for static MAC addresses, is allowed
• Disabling LPS on a port

-> no port-security port <chassis/slot/port>
• In case of violation, two possible actions can be taken: filtering or shutdown

-> port-security port <chassis/slot/port> violation [shutdown | restrict/ discard]
• Shutdown. Stops all traffic on a port after violation
• Filtering. Only stops traffic from violating device
• Specifying the maximum number of source MAC addresses that an LPS port is allowed to
learn.
-> port-security port chassis/slot/port[-port2] maximum number
• Configures the amount of time, in minutes, to allow source learning on all LPS ports.
-> port-security learning-window minutes
• Configuring the maximum number of filtered MAC addresses that can be learned on the LPS
port(s)
-> port-security port chassis/slot/port[-port2] maximum number
• Maximum number of mac addresses allowed is 1

• Maximum number of mac address filtered is 5
• Default violation is restricted
• Configuring of a list of authorized source MAC addresses
-> port-security port chassis/slot/port[-port2] mac-range [low mac_address | high mac_address]
• up to eight MAC ranges per port.
• Converting the dynamically learned MAC addresses on the LPS port(s) to static MAC
addresses
-> port-security {port chassis/slot/port[-port2] | chassis} convert-to-static
• The following set of commands enables LPS on port 1/1/1, converting dynamically learned
MAC address of currently attached device to static. When another device is connected to
port 1/1, a violation occurs and this port will be shutdown
-> port-security port 1/1/1 admin-state enable
-> port-security port 1/1/1 maximum 1
-> port-security port 1/1/1 violation shutdown
-> port-security port 1/1/1 convert-to-static enable
• Displays Learned Port Security configuration and table entries
-> show port-security
Port : 1/1/15
Operation Mode : DISABLED,
Max Bridged MAC allowed : 1,
Max Filtered MAC allowed : 5,
Low End of MAC Range : 00:00:00:00:00:00,
High End of MAC Range : ff:ff:ff:ff:ff:ff,
Violation Setting : RESTRICT,
MAC VLAN MAC TYPE

-------------------+------+-------------------
00:20:95:00:fa:5c 1 STATIC
• Clears all port violations on the switch for the given port
-> clear violation port { chassis/slot/port[-port2] | linkagg agg_id[-agg_id2]}
LEARNED PORT SECURITY - L2 NOTIFICATION
• Provides notification of newly learned bridged MAC addresses after the port matches the
specified threshold amount
-> port-security port chassis/slot/port[-port2] learn-trap-threshold number
• Sends a trap for every MAC learned after the threshold is reached. It contains:
• MAC address
• Slot/Port
• VLAN
• Date & Time
Packet loss due to LPS port learning
• Objective
• Avoids packet loss due to LPS port learning by reinjecting the packets received from clients back to
the forwarding path of the switch.
• Hence by default all the packets trapped on LPS port will be reinjected back to the switch once the MAC is
successfully learned.
• Can also be customized to filter and inject packets matching specific protocol types or UDP source
and destination ports.
[no] port-security [port <c/s/p1[-p2]>] pkt-relay Enables packet relay feature on a single or range of LPS ports.
port-security pkt-relay protocol {udp}|{icmp} |{igmp} Configures the protocol filter criteria for packet relay feature.
port-security pkt-relay protocol {udp [src-port <port1[-port2]>]} Configures the UDP source ports as the criteria for packet relay.
port-security pkt-relay protocol {udp [dst-port <port1[-port2]>]} Configures the UDP destination ports as the criteria for packet relay.
show port-security port Displays the packet relay configuration on the port.lost in LPS. If the packet should be allowed. it must be re-injected
into the forwarding path, currently, it is discarded.
THANK YOU
OmniSwitch R8
Port Mapping
How to
✓ This lab is designed to familiarize you with the concept of Port Mapping.
Contents
1 Topology ........................................................................................ 2
2 Bi-Directional Port-Mapping ................................................................. 3
2.1. Prerequisites configuration ....................................................................... 3
2.2. Manage port mapping .............................................................................. 5
3 Configuring Multiple ports ................................................................... 5
4 Remove management ......................................................................... 6
5 Summary ........................................................................................ 6
2
Port Mapping
1 Topology
Port Mapping is a security feature, which controls communication between peer users. Each session comprises
a session ID, a set of user ports, and/or a set of network ports. The user ports within a session cannot
communicate with each other and can only communicate via network ports.
A port mapping session can be configured in the unidirectional or bidirectional mode. In the unidirectional
mode, the network ports can communicate with each other within the session. In the bidirectional mode, the
network ports cannot communicate with each other. Network ports of a unidirectional port mapping session
can be shared with other unidirectional sessions but cannot be shared with any sessions configured in the
bidirectional mode.
3
Port Mapping
2 Bi-Directional Port-Mapping
2.1. Prerequisites configuration
- Manage a VLAN 50 on 6860-A, 6860-B and 6360-A.

sw5 (6360-A) -> vlan 50
sw7 (6860-A) -> vlan 50
sw8 (6860-B) -> vlan 50
- Configure an IP interface for VLAN 50 on all switches in the 192.168.50.X/24 subnet replacing the 'X' with
your switch number
- Tag the vlan 50 on the linkagg 7 on 6360-A and 6860-A

- Tag vlan 50 on port 2/1/3 on 6360-A and port 1/1/3 on 6860-B

- Check your management

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------

Total 3 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
int_50 192.168.50.5 255.255.255.0 UP YES vlan 50
4
Port Mapping

Total 6 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
int_20 192.168.20.7 255.255.255.0 UP YES vlan 20
int_278 172.16.78.7 255.255.255.0 UP YES vlan 278
int_50 192.168.50.7 255.255.255.0 UP YES vlan 50

Total 5 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
int_30 192.168.30.8 255.255.255.0 UP YES vlan 30
int_50 192.168.50.8 255.255.255.0 UP YES vlan 50
- Manage ports 1/1/1 and 1/1/2 on 6360-A as default to VLAN 50.
sw5 (6360-A) -> vlan 50 members port 1/1/1-2 untagged

port type status
----------+-----------+---------------
1/1/1 default inactive
1/1/2 default inactive
sw5 (6360-A) -> interface 1/1/1-2 admin-state enable
port type status

----------+-----------+---------------
1/1/1 default forwarding
- Manage Client 5 and Client 9 PC as following
Client 5 Client 9
IP address : 192.168.50.105 IP address : 192.168.50.109
Subnet mask : 255.255.255.0 Subnet mask : 255.255.255.0
Default Gateway : 192.168.50.5 Default Gateway : 192.168.50.5
5
Port Mapping
- Ensure you can ping all IP interfaces from the clients PC
- From client 5 and client 9, ping 192.168.50.5, 192.168.50.7 and 192.168.50.8
2.2. Manage port mapping
- Check port mapping configuration on 6360-A
sw5 (6360-A) -> show port-mapping

-----------+----------------+------------------
- Create a first session which will map the linkagg 7
sw5 (6360-A) -> port-mapping 1 user-port 1/1/1 network-port linkagg 7
- From client PC on port 1/1/1 , ping both remote switches.
- You should find that you can only ping 6860-A as it is the one at the remote end of linkagg 7.
- Create a second session which will map port 1/1/2 to port 2/1/3:
sw5 (6360-A) -> port-mapping 2 user-port 1/1/2 network-port 2/1/3
- From client 9 on port 1/1/2. You should now be able to ping 6860-B but not 6860-A.
3 Configuring Multiple ports
- Ports can be added to existing mapping session

-----------+----------------+------------------
1 1/1/1 0/7
2 1/1/2 2/1/3
sw5 (6360-A) -> port-mapping 1 user-port 2/1/1


-----------+----------------+------------------
1 1/1/1 0/7
1 2/1/1
2 1/1/2 2/1/3
6
Port Mapping

-----------+----------------+------------------
1 1/1/1 0/7
1 2/1/1
2 1/1/2 2/1/3
2 2/1/2
- A port can only be a member of one mapping session:

ERROR: port user already part of an existing PMAP session
4 Remove management
sw5 (6360-A) -> no port-mapping 1

sw5 (6360-A) -> no port-mapping 2
sw5 (6360-A) -> no vlan 50
sw7 (6860-A) -> no vlan 50

sw8 (6860-B) -> no vlan 50

sw8 (6860-B) -> no ip interface int_50
5 Summary
Port Mapping is a security feature, which controls communication between peer users. Each session comprises
a session ID, a set of user ports, and/or a set of network ports. The user ports within a session cannot
communicate with each other and can only communicate via network ports.
OmniSwitch R8
Learned Port Security
How to
✓ This lab is designed to familiarize yourself with Learned Port Security
feature.
Contents
1 Topology ........................................................................................ 2
2 Learned Port Security ........................................................................ 3
2.1. Configure the switch to learn maximum one mac address ................................... 3
2.2. Configure the switch port to accept the traffic only from currently attached device ... 4
2.3. Port violation........................................................................................ 5
2
1 Topology
The LPS feature is used in networks to prevent employees to use small basic switches or hub in the enterprise
network. This can grandly help IT stuff to efficiently manage network security.
Learned Port Security provides controls over the source learning function on an OmniSwitch.
- On the 6860B, create client VLAN and assign interfaces
sw8 (6860-B) -> vlan 180

- On the 6860-B, assign port 1/1/8 to vlan 180 and activate the interface:

- On the 6560-A, activate the interfaces 1/1/1 and 1/1/8, and assign an IP address to VLAN 1:

- Start client 3 and configure as below:

Client 3:
IP address = 192.168.180.50
Subnet mask = 255.255.255.0
- Try to ping the gateway (192.168.180.8) from client 3 and 6560-A.
- On the 6860-B, check the mac addresses learned on port 1/1/8:
sw8 (6860-B) -> show mac-learning port 1/1/8

ID = ISID/Vnid/vplsid
Domain Vlan/SrvcId[:ID] Mac Address Type Operation Interface

------------+----------------------+-------------------+------------------+-------------+-----------------
--------
VLAN 180 00:0c:29:44:aa:3b dynamic bridging 1/1/8
VLAN 180 2c:fa:a2:95:8f:9f dynamic bridging 1/1/8
VLAN 180 2c:fa:a2:95:8f:ad dynamic bridging 1/1/8
Notes
In this example above, there’s 3 mac addresses: 1 from client 3 and 2 from 6560. The 6560 uses different mac
addresses for Layer 2 traffic, like LLDP or STP and another one, the chassis base mac address for Layer3 traffic
associated with VLAN 1 IP interface.
3
2 Learned Port Security
2.1. Configure the switch to learn maximum one mac address

By default, port security allows the switch to learn only a single MAC address and then binds that MAC
address to the port. When the number of filtered MAC addresses learned on the port reaches the maximum,
either the port is disabled (Shutdown Violation mode) or MAC address learning is disabled (Restrict Violation
mode). By default, MAC address learning is disabled (filtering). When LPS is enabled on switch ports with
one single mac address, it will prevent users to plug a basic switch or hub to the network, please note that
you can specify up to 100 mac addresses to be learned per port by LPS.
- Enable LPS on port 1/1/8 of 6860-B:
sw8 (6860-B) -> port-security port 1/1/8 admin-state enable
- Once again try to ping the gateway from both client 3 and 6560 (it should fail).
- Display information about port security and learned mac addresses:
sw8 (6860-B) -> show port-security port 1/1/8
Port: 1/1/8
Admin-State : ENABLED,
Operation Mode : ENABLED,
Max MAC bridged : 1,
Trap Threshold : DISABLED,
Violation : RESTRICT,
Max MAC filtered : 5,
Violating MAC : NULL,
Pkt-Relay : DISABLED
MAC VLAN MAC TYPE OPERATION

-------------------------+--------+-----------------+-----------------
2c:fa:a2:95:8f:ad 180 dynamic bridging
00:0c:29:44:aa:3b 180 dynamic filtering
2c:fa:a2:95:8f:9f 180 dynamic filtering
- The first mac address seen is normally bridged but the others are filtered. There’s more chance for
Layer 2 traffic to be bridged than other Layer 3 traffic.
- To ensure no Layer2 traffic, disable unnecessary protocols on 6860-B port 1/1/8:
sw8 (6860-B) -> spantree vlan 180 port 1/1/8 disable

sw8 (6860-B) -> show spantree ports active
sw8 (6860-B) -> lldp all chassis lldpdu disable

sw8 (6860-B) -> show lldp config
- To Flush the mac-address from the mac-learning table

sw8 (6860-B) -> mac-learning flush vlan 180 port 1/1/8 dynamic
4
- Once again try to ping the gateway from both client 3 and 6560-A
- Now it should remain only 2 mac addresses: one from client 3 and another one from the IP interface of
VLAN 1 in 6560-A.
sw8 (6860-B) -> show mac-learning port 1/1/8

ID = ISID/Vnid/vplsid
Domain Vlan/SrvcId[:ID] Mac Address Type Operation Interface

------------+----------------------+-------------------+------------------+-------------+-----------------
--------
VLAN 180 00:0c:29:44:aa:3b dynamic filtering 1/1/8
VLAN 180 2c:fa:a2:95:8f:ad dynamic bridging 1/1/8
Notes
Here, the Client 3 mac address is bridged, the 6560A is filtered. Thus we can ping the gateway from client 3
but not from 6560-A.
2.2. Configure the switch port to accept the traffic only from currently attached device
In order to allow only one dynamically learned mac address on a switch LPS port (only fixe ports), we will
use convert-to-static parameter with port-security. The currently attached devices mac address will be
associated to this LPS port and one static entry will be created in mac address table. This means that only
this device will be allowed on that port.
Please notice that the device must be learned on the LPS port before to enter the command port-security
convert-to-static
- To convert the dynamically learned MAC addresses to static addresses on a specific LPS port at any time
irrespective of the source learning time window, use the port-security convert-to-static command as
shown below:
sw8 (6860-B) ->port-security port 1/1/8 convert-to-static
- Analyze carefully the output of the command shown below, you can see that the currently attached
device mac address is learned on the specified port and the type of the entry is permanent (static).
sw8 (6860-B) ->show mac-learning port 1/1/8


------------+----------------------+-------------------+------------------+-------------+-----------
VLAN 180 00:50:56:90:ac:77 static bridging 1/1/8
VLAN 180 2c:fa:a2:aa:34:9f dynamic filtering 1/1/8

5
2.3. Port violation

By default, the port violation is restricted, that means traffic from unallowed mac addresses is filtered. We
can change it to shutdown, That means port is shutdown if more that one mac address is seen in our case.
- Configure the shutdown of the port in case of violation and indicate the max number of filtered mac
address to 0 (that means the port will be shutdown if more than 1 mac address is learned on it).
sw8 (6860-B) -> port-security port 1/1/8 violation shutdown

sw8 (6860-B) -> port-security port 1/1/8 max-filtering 0
sw8 (6860-B) -> show port-security port 1/1/8
Port: 1/1/8
Admin-State : ENABLED,
Operation Mode : ENABLED,
Max MAC bridged : 1,
Trap Threshold : DISABLED,
Violation : SHUTDOWN,
Max MAC filtered : 0,
Violating MAC : NULL,
Pkt-Relay : DISABLED
MAC VLAN MAC TYPE OPERATION

-------------------------+--------+-----------------+-----------------
2c:fa:a2:95:8f:ad 180 static bridging
Notes
In the example above, the switch mac address age out, so as there’s only the client 3 mac address learnt on the
port, is still forwarding
- Try to ping again the gateway from both client 3 and 6560-A. You should see a warning message on the
6860-B :
Thu Jan 1 00:28:35 : AGCMM AG-Lps INFO message:

+++ AGCMM_INFO:(1715.553)lpsPortViolation[554]Port-security Violation on PORT 1/1/8 : Shutting down port
Thu Jan 1 00:28:35 : intfCmm Mgr INFO message:

+++ Link 1/1/8 operationally down
- By default, there’s a timer of 300 seconds to clear automatically the violation
sw8 (6860-B) -> show violation

* = Link Agg ID
LAG ID/ Recovery Recovery
Port Source Action Reason WTR Time Max/Remain
----------+----------+------------------+-------------+-----+--------------+--------------
1/1/8 AG admin down lps shutdown 0 300 10/10
6
- To change this value of 300 seconds, type:
sw8 (6860-B) -> show violation-recovery-configuration port 1/1/8

Global Violation Trap : Enabled
Global Recovery Maximum : 10
Global Recovery Time : 300
Port Recovery Max Recovery Time
----------+-------------+---------------
1/1/7 10 300
sw8 (6860-B) ->violation port 1/1/8 recovery-time 30
sw8 (6860-B) ->show violation-recovery-configuration port 1/1/8
Global Violation Trap : Enabled
Global Recovery Maximum : 10
Global Recovery Time : 300
Port Recovery Max Recovery Time
----------+-------------+---------------
1/1/7 10 30
- You may also manually recover from a violation:
sw8 (6860-B) -> clear violation port 1/1/8
- Finally, to disable port security, enter:
sw8 (6860-B) -> no port-security port 1/1/8

sw8 (6860-B) -> interfaces 1/1/8 admin-state disable
sw3 (6560-A) -> interfaces 1/1/8 admin-state disable

OMNISWITCH R8
DUAL-HOME LINKS (DHL)
OBJECTIVES
• List the Dual-Home Link (DHL) advantages

• Identify the Dual-Home Link (DHL) specification
per switch model
• Summarize the Dual-Home Link (DHL)
configuration step
•NORMAL STATE (BOTH LINKS UP)
DUAL-HOME LINK REMINDER •AGGREGATION OR CORE LAYER
• Goal
• High availability feature •DHL
• Provides fast failover between Core/Aggregation and •LinkA VLANs •LinkB VLANs
Access switches without using STP •ACCESS LAYER
• How it works
• DHL Active-Active splits VLANs between two active
links
• The forwarding status of each VLAN is modified by
DHL to prevent network loops and maintain •FAILED STATE (ONE LINK DOWN)
connectivity to the core when one of the links •AGGREGATION OR CORE LAYER
•DHL
•LinkA VLANs •LinkA & LinkB VLANs
•ACCESS LAYER
DUAL-HOME LINK SPECIFICATIONS
• DHL is supported on the following platforms:
•AGGREGATION OR CORE LAYER
•DHL
• Only one session per switch is allowed.
•LinkA VLANs •LinkB VLANs
• Each session has only two links (linkA and linkB).
•ACCESS LAYER
• A physical port or a link aggregate (linkagg) ID
could be a DHL link.
• The same port or link aggregate is not
configurable as both linkA or linkB.
• DHL is not supported on mobile, 802.1x-enabled,
GVRP, or UNI ports
DHL TIMERS & MAC-FLUSHING
• Pre-Emption timer
• Amount of time to wait before a failed link that has
recovered can resume servicing VLANs
•AGGREGATION CORE LAYER
• 0 to 600 seconds OR
• Mac Address Flushing

• Spanning Tree is automatically disabled on DHL ports
• Problem: No topology change after changeover of DHL •DHL
links
•LinkA VLANs •LinkB VLANs
• 3 options are available to avoid staling MAC address
entries •ACCESS LAYER
• None (default): The staled MAC address entries are kept in the MAC table
• MVRP Enhanced:
• Joins only VLAN that are maps on DHL link
• When DHL link fails, the other link issues joins message with « new » flags set
• When DHL link recovers, the link issues new joins to reestablish connectivity
• RAW Flooding
• List of MAC addresses learned on non-DHL port for all VLAN assigned to DHL links
• Send a broadcast frame with source MAC address from that list on redundant
DHL links in case of failure, or on the primary in case of recovery.
MAC ADDRESS FLUSHING MVRP ENHANCED
SW2 1/3 SW3
1/2
1/1 1/1
•VLAN 2 •MVRP Join +
SW2 1/3 SW3
•VLAN 1 • « New » flag
1/2
1/1 1/1
•DHL SW1
•VLAN 1 •VLAN 2 •(VLAN 2)
SW1
RAW FLOODING
•(VLAN 2)
SW2 1/3 SW3
@MAC Port VLAN 1/2

1/1 1/1
SW 2 1/3 2
•VLAN 2 •Bdcst
•VLAN 1 • @SRC:
@MAC Port VLAN
SW 3 1/1 2
SW1
•(VLAN 2)
DUAL-HOME LINK REMINDER
Comparison between different solutions
STP 802.3Ad LACP DHL Active-Active
50% Bandwidth 100% Bandwidth 100% Bandwidth

Link redundancy Link redundancy Link redundancy
Switch redundancy Switch redundancy Switch redundancy
Convergence time Convergence time Convergence time
DHL CONFIGURATION
DHL CONFIGURATION
Step by Step
Create a DHL session
Map the Link A/B & Ports/Linkagg
Map the VLANs to the LinkB
Enable the DHL Session
Activate the “RAW” MAC-Flushing or MVRP Enhanced

DHL CONFIGURATION
Step by Step
Create a DHL session

Create the DHL Session LinkA
Unique ID LinkB
-> dhl 1 Linkagg 1 1/1/2

SW1
Map the VLANs to the LinkB -> dhl 1 linka linkagg 1 linkb port 1/1/2
Identify 2 ports/link aggregates

Map one to LinkA
Map the other one to LinkB
Example with port
-> dhl 1 linka port 1/1/3 linkb port 1/1/4
Example with linkagg
-> dhl 1 linka linkagg 1 linkb linkagg 2

DHL CONFIGURATION
Step by Step
Map the VLANs to the LinkB

Map a set of VLANs to LinkB LinkB: 30
LinkA: all the other VLANs
The other VLANs will be automatically mapped to LinkA
Linkagg 1 1/1/2
-> dhl 1 vlan-map linkb 30 SW1
Enable the DHL Session

Enable the DHL session (admin-state enable)
-> dhl 1 admin-state enable

-> dhl 1 mac-flushing raw
-> dhl 1 mac-flushing mvrp
THANK YOU
OmniSwitch R8
Dual Home Link Active-Active
How to
✓ Setup the high availability Dual-Home Link Active-Active feature.
Contents
1 Topology ........................................................................................ 2
2 Configuring the Prerequisites ............................................................... 3
2.1. Prerequisite: Creating a linkagg from 6360 VC to 6860-B .................................... 3
2.2. Assigning VLANs on the Link Aggregations ...................................................... 4
2.3. Tag the VLAN 20 and 30 on the link aggregation ............................................... 4
2.4. Tag the VLAN 57 on the link aggregation 78 .................................................... 5
3 Configuring the DHL Active-Active link .................................................... 5
3.1. DHL session Creation ............................................................................... 5
4 DHL Active-Active Monitoring ............................................................... 6
2
1 Topology
The customer wants to configure the dual home link solution instead of the STP.
Dual-Home Link (DHL) provides fast failover between core and edge switches without implementing Spanning
Tree.
A DHLActive-Active configuration consists of the following components:

- A DHL session. Only one session per switch is allowed.
- Two DHL links associated with the session (link A and link B).
- A physical switch port or a logical link aggregation (linkagg) ID are configurable as a DHL link.
- A group of VLANs (or pool of common VLANs) in which each VLAN is associated (802.1q tagged) with both
link A and link B.
- A VLAN-to-link mapping that specifies which of the VLANs each DHL link will service.
This mapping prevents network loops by designating only one active link for each VLAN, even though both links
remain active and are associated with each of the common VLANs.
When one of the 2 active DHL links fails or is brought down, the VLANs mapped to that link are then forwarded
on the remaining active link to maintain connectivity to the core. When the failed link comes back up, DHL
waits a configurable amount of time before the link resumes forwarding of its assigned VLAN traffic.
DHL linkA and linkB must belong to the same default VLAN.
3
2 Configuring the Prerequisites
2.1. Prerequisite: Creating a linkagg from 6360 VC to 6860-B
- For the purpose of the lab, create a link aggregation between the 6360 VC and the 6860-B:
o 6360 VC
-------+-------------+---------+----+------------+--------------+-------------

ERROR: Port cannot be added to Linkagg, please remove other configuration on this port
- Untag the vlan on this port to be able to add it to the linkagg

vlan type status
--------+-----------+---------------
sw5 (6360-A) -> no vlan 58 members port 2/1/3

sw5 (6360-A) -> no vlan 58

vlan type status
--------+-----------+---------------


o 6860-B
sw8 (6860-B) -> show vlan members port 1/1/3
vlan type status
--------+-----------+---------------
sw8 (6860-B) -> no vlan 58 members port 1/1/3
sw8 (6860-B) -> no vlan 58

4
-------+-------------+---------+----+------------+--------------+-------------
2.2. Assigning VLANs on the Link Aggregations

- Change default VLAN on the link aggregation (the client does not want to use the VLAN 1):
sw8 (6860-B) -> vlan 57

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
2.3. Tag the VLAN 20 and 30 on the link aggregation


port type status
----------+-----------+---------------

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
0/8 tagged forwarding
5

port type status
----------+-----------+---------------
2.4. Tag the VLAN 57 on the link aggregation 78


port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
0/7 untagged blocking
3 Configuring the DHL Active-Active link
3.1. DHL session Creation

- Configure a DHL session with the identifier 1 on the 6360-A (VC):
sw5 (6360-A) -> dhl 1
- Configure 2 links (link-A and link-B) for the DHL session:

sw5 (6360-A) -> dhl 1 linka linkagg 7 linkb linkagg 8
Notes
Spanning Tree is disabled on all the DHL enabled ports
- Map VLANs to link-B:

sw5 (6360-A) -> dhl 1 vlan-map linkb 30
- Enable the DHL session:

sw5 (6360-A) -> dhl 1 admin-state enable
6
4 DHL Active-Active Monitoring

- Display the global status of the DHL configuration:
sw5 (6360-A) -> show dhl
Legends: PE - Pre-Emption
Session Session Admin Oper PE MAC Active MAC
ID Name State State Time Flushing Flushing
(sec) Technique Technique
----------+---------------------------------+-------+------+-------+----------+--------------
1 DHL-1 up up 30 none none
Total number of sessions configured = 1
- Displays information about specific DHL session 1:

sw5 (6360-A) -> show dhl 1
DHL session name : DHL-1
Admin state : up,
Operational state : up,
Pre-emption time(sec) : 30,
Mac Flushing : none,
Active MAC flushing : none,
LinkB Vlan Map : 30,
Protected Vlans : 20 30 57
LinkA:
Port : 0/7,
Operational State : up,
Unprotected Vlans : none,
Active Vlans : 20 57
LinkB:
Port : 0/8,
Active Vlans : 30
- Displays information about a specific DHL link:

sw5 (6360-A) -> show dhl 1 linka
LinkA:
Port : 0/7,
Protected Vlans : 20 30 57,
Active Vlans : 20 57
sw5 (6360-A) -> show dhl 1 linkb

LinkB:
Port : 0/8,
Protected Vlans : 20 30 57,
Active Vlans : 30
- Display information about protected VLANs:

port type status
----------+-----------+---------------
0/8 qtagged dhl-blocking

port type status
----------+-----------+---------------
7
- Check the Client 5 configuration with the following parameters:

Client 5:
IP address = 192.168.20.105
Subnet mask = 255.255.255.0
- Activate the “RAW” MAC-Flushing method:

sw5 (6360-A) -> dhl 1 mac-flushing raw
- From Client 5, start a continuous ping to the VLAN 20 IP interface (created on the 6860-A):
C:\> ping –t 192.168.20.7
- The VLAN 20 is blocked on the link aggregation to avoid a loop. Thus, the traffic goes from 6360-A to
6860-A via the link aggregation 7:
port type status
----------+-----------+---------------
- Now disable the link aggregation 7 on the 6360-A while the ping is still running:
sw5 (6360-A) -> linkagg lacp agg 7 admin-state disable
- Did you notice any packet loss? ---------------------------------------------------------------------------------------
- Check VLAN 20 members:

port type status
----------+-----------+---------------
0/7 qtagged inactive
- Stop the ping and enable the link aggregation 7 on the 6360-A:
sw5 (6360-A) -> linkagg lacp agg 7 admin-state enable
- Check VLAN 20 members:

port type status
----------+-----------+---------------
Notes
It can takes a few seconds for the VLAN 20 to be forwarded back on the link aggregation 8: when the failed link
comes back up, DHL waits a configurable amount of time (default: 30 secs) before the link resumes forwarding
of its assigned VLAN traffic.
- Save configuration:
OMNISWITCH R8
V I RT U A L R O U T E R R E D U N D A N C Y P R O TO C O L (VRRP)
OBJECTIVES
• Describe the VRRP feature on AOS switch

• List the management step to implement it
VRRP REMINDER
VRRP REMINDER
• Goal
• Business continuity solution for default gateway
redundancy
• Protocol for electing a switch as the master virtual Master
router Backup
• Dynamic fail over in the forwarding responsibility Multicast - 224.0.0.18
if the Master becomes unavailable
Virtual Router IP
• RFCs Supported
• RFC 2338 – Virtual Router Redundancy Protocol
Subnet
• RFC 2787 – Definitions of Managed Objects for
the Virtual
Default gateway = Virtual Router IP
Virtual MAC address: 00-00-5E-00-01-{VRID}

VRRP REMINDER
Load balancing Outgoing Traffic Virtual Router ID = 1
Virtual Router ID = 2
Master 1 Backup 1
Backup 2 Master 2
Subnet
Def GW = Def GW =
VR 1 IP address VR 2 IP address
* Two virtual routers with their hosts splitting traffic between them
VRRP REMINDER
• VRRP Tracking
• Base set of tracking policies supported:
• ADDRESS
• IPV4-INTERFACE
• IPV6-INTERFACE
• PORT 2
• VLAN
Master 1 Pri = 100 1/1/3 1/1/1 Backup 1 Pri = 80
3 R1 Virtual Router ID = 1
VLAN 20 (int_20) R2 4
Backup 1 Pri = 70
Master 1 Pri = 80
1 5
Default Route
New route if port 1/1/3 goes down

VRRP CONFIGURATION STEPS
VRRP – BASIC CONFIGURATION STEP
Step by step
Creates a VRRP virtual router for IP addresses

ip vrrp 1 interface int_20
Specifying an IP Address for a Virtual Router

ip vrrp 1 interface int_20 address 192.168.20.254
Enabling a Virtual Router

ip vrrp 1 interface int_20 admin-state enable
Monitor the result

show ip vrrp
show ip vrrp 1
show ip vrrp statistics
* At least two virtual routers must be configured on the LAN—a master router and a backup router.
VRRP – FULL CONFIGURATION STEP
Step by step
Creates a VRRP virtual router for IP addresses

Configuring Virtual Router Priority
- Role of each router
- Selection of backup routers
Setting Pre-emption
- Allow by default
- may be disabled “no pre-empt”
Configuring the Advertisement Interval

- In VRRP version 2 virtual routers (same VRID) may
configured to use the same interval value
ip vrrp 1 interface int_20 priority 100 preempt interval 100
Specifying an IP Address for a Virtual Router

ip vrrp 1 interface int_20 address 192.168.20.254
Enabling a Virtual Router
ip vrrp 1 interface int_20 admin-state enable
VRRP – CREATING VRRP TRACKING POLICIES
VRRP Tracking Policies
2
Master 1 Pri = 100 1/1/3 Backup 1 Pri = 80
1/1/1
Create tracking Policy ID (3)
Virtual Router ID = 1
3 R1 VLAN 20 (int_20) R2 3
Enabled for a port or IP address,

or Vlan, or address Backup 1 Pri = 70
Master 1 Pri = 80
1 4
Associated a Tracking Policy with

VRRP a Virtual Router
-> ip vrrp track 3 admin-state enable priority 30 port 1/1/3

-> ip vrrp 1 interface int_20 track-association 3
-> ip vrrp track 4 admin-state enable priority 50 address 20.1.1.3
-> ip vrrp 6 interface ipv4-100 track-association 4
THANK YOU
OmniSwitch R8
Virtual Router Redundancy Protocol (VRRP)
How to
✓ Configure the VRRP protocol in Release 8
Contents
1 Topology ........................................................................................ 2
2 Configuring the VRRP ......................................................................... 3
3 Configuring the Master / Backup............................................................ 8
2
1 Topology
The Virtual Router Redundancy Protocol is a standard router redundancy protocol which provides redundancy by
eliminating the single point of failure inherent in a default route environment. The VRRP router, which controls
the IP address associated with a virtual router is called the master router and is responsible for forwarding
virtual router advertisements. If the master router becomes unavailable, the highest priority backup router
transitions to the master state.
3
2 Configuring the VRRP

- Check Vlan ports member for vlan 20 and vlan 30 :
port type status
----------+-----------+---------------
0/8 tagged dhl-blocking
sw5 (6360-A) -> sh vlan 30 members

port type status
----------+-----------+---------------
0/7 tagged dhl-blocking
- Note : If it is not correct, manage them as following :
Ex : sw5 (6360-A) -> vlan 20 members port 1/1/1 untagged

…
o On 6860-A

Total 7 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
---
int_20 192.168.20.7 255.255.255.0 UP YES vlan 20
int_217 172.16.17.7 255.255.255.0 UP YES vlan 217
int_278 197.16.78.7 255.255.255.0 UP YES vlan 278
---

Total 10 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
---
int_20 192.168.20.7 255.255.255.0 UP YES vlan 20
int_217 172.16.17.7 255.255.255.0 UP YES vlan 217
int_278 172.16.78.7 255.255.255.0 UP YES vlan 278
int_30 192.168.30.7 255.255.255.0 UP YES vlan 30
---
sw7 (6860-A) -> ip vrrp 1 interface int_20

sw7 (6860-A) -> ip vrrp 1 interface int_20 address 192.168.20.254
sw7 (6860-A) -> ip vrrp 1 interface int_20 admin-state enable
Thu Nov 14 16:53:50 : vrrp_0 proto INFO message:
+++ Virtual router enabled IPv4 VRID=1
4

o On 6860-B

Total 6 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
--
int_218 172.16.18.8 255.255.255.0 UP YES vlan 218
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
int_30 192.168.30.8 255.255.255.0 UP YES vlan 30

Total 9 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
---
int_20 192.168.20.8 255.255.255.0 UP YES vlan 20
int_218 172.16.18.8 255.255.255.0 UP YES vlan 218
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
int_30 192.168.30.8 255.255.255.0 UP YES vlan 30
---
sw8 (6860-B) -> ip vrrp 1 interface int_20

sw8 (6860-B) -> ip vrrp 1 interface int_20 address 192.168.20.254
sw8 (6860-B) -> ip vrrp 1 interface int_20 admin-state enable



5
- Check the VRRP status:

sw7 (6860-A) -> show ip vrrp 1
Virtual Router VRID = 1 on INTERFACE = int_20
Version = V2
Admin. Status = Enabled
Priority = 100
Preempt = Yes
Adv. Interval = 100
Virtual MAC = 00-00-5E-00-01-01
IP Address(es)
sw7 (6860-A) -> show ip vrrp 2

Version = V2
Priority = 100
Preempt = Yes
Adv. Interval = 100
Virtual MAC = 00-00-5E-00-01-02
IP Address(es)
192.168.30.254
sw8 (6860-B) -> show ip vrrp 1

Version = V2
Priority = 100
Preempt = Yes
Adv. Interval = 100
Virtual MAC = 00-00-5E-00-01-01
IP Address(es)
192.168.20.254
sw8 (6860-B) -> show ip vrrp 2

Version = V2
Priority = 100
Preempt = Yes
Adv. Interval = 100
Virtual MAC = 00-00-5E-00-01-02
IP Address(es)
192.168.30.254
- In the steps above, we have created 2 VRRP instances 1 and 2 (VRRP 1, VRRP 2), and associated it with
respectively VLAN 20 and 30 (VRRP 1 > VLAN 20, VRRP 2 > VLAN 30). We have then associated a Virtual IP
address of 192.168.20.254 to VRRP 1 and 192.168.30.254 to VRRP 2 which both VRRP instances will
share.
- Also take note of the Virtual MAC address. This is the address that the router will use in the active state
for all the responses. This prevents end stations from having to re-arp to their router in the event of a
failure:
sw7 (6860-A) -> show ip vrrp statistics
Checksum Errors : 0,
Version Errors : 0,
VRID Errors : 0
Interface
VRID Name State UpTime Become Master Adv. Rcvd
----+--------------------------------+----------+----------+-------------+----------
1 int_20 Master 98575 1 0
2 int_30 Master 81058 1 0
6
sw8 (6860-B) -> show ip vrrp statistics

Version Errors : 0,
VRID Errors : 0
Interface
----+--------------------------------+----------+----------+-------------+----------
1 int_20 Backup 44764 0 448
2 int_30 Backup 34581 0 346
- From the “statistics” command, we can see that the 6860-A is the active virtual router. Since all
priorities are equal, the lowest router ID is the selection criteria.
- The DHCP server has not been configured with these gateway addresses, so to perform this test we need
to switch back to static addresses by setting the gateway for clients 5 and 9.
- Now let's change our default gateway for clients 5 and 9 :
Client 5:
IP address = 192.168.20.105
Subnet mask = 255.255.255.0
Client 9:
IP address = 192.168.30.109
Subnet mask = 255.255.255.0
- Check the table on the switches

------------+----------------------+-------------------+------------------+-------------+-----------------
VLAN 20 00:50:56:90:22:3c dynamic bridging 1/1/1


------------+----------------------+-------------------+------------------+-------------+-----------------
--------
VLAN 30 00:50:56:90:05:d4 dynamic bridging 1/1/2

7
Tips > MAC address table empty

If the MAC address table is empty, generate some traffic from the client connected on the switch (ex. 6360
MAC@ table empty > from the Client 9, launch a ping to its gateway (192.168.30.8).
- From the client 5, try to ping the client 9:

C:\> ping 192.168.30.109
- Now check the content of the client 5 ARP cache:

C:\> arp -a
- Notice that the “Physical Address” which corresponds to the IP address 192.168.20.254 is the VRRP
interface MAC address (VRRP instance 1 > VLAN 20).
- Now start a continuous ping to VRRP interface (192.168.20.254) from the client 5 …
C:\> ping –t 192.168.20.254
- … Then remove the master VRRP gateway (in this example 6860-A). We will simply reboot the switch
(don’t forget to save!):
6860-A -> write memory
6860-A -> reload from working no rollback-timeout
- Notice how quickly the DHL switch from one link to the other, and how fast the Backup VRRP becomes
master. Check the VRRP status on 6860-B:
Version Errors : 0,
VRID Errors : 0
Interface
----+--------------------------------+----------+----------+-------------+----------
1 int_20 Master 6205571 1 62003
2 int_30 Master 6195388 1 61900
Tips > Pre-Emption

Once 6860-A has rebooted, notice that 6860-B remains the Master since we do not have the preempt option
enabled.
8
3 Configuring the Master / Backup

To manually configure which will be the Master and which will be the Backup, the priority of the VRRP instance
can be modified. The higher the value, the higher the priority will be to be elected as Master.
- To provide load balancing between both 6860, we will configure the 6860-A to be Master on VLAN 20,
and the 6860-B to be Master on VLAN 30.
- The default priority is 100. Let’s put a priority of 150 for VRRP 1 on 6860-A, and a priority of 150 for
VRRP 2 on 6860-B:
Warning
THE VRRP INSTANCE MUST BE DISABLED BEFORE CHANGING THE PRIORITY
sw7 (6860-A) -> ip vrrp 1 interface int_20 admin-state disable

sw7 (6860-A) -> ip vrrp 1 interface int_20 priority 150
Version Errors : 0,
VRID Errors : 0
Interface
----+--------------------------------+----------+----------+-------------+----------
1 int_20 Master 1895 1 3
2 int_30 Backup 112204 0 1122
sw8 (6860-B) -> ip vrrp 2 interface int_30 admin-state disable

sw8 (6860-B) -> ip vrrp 2 interface int_30 priority 150
Version Errors : 0,
VRID Errors : 0
Interface
----+--------------------------------+----------+----------+-------------+----------
1 int_20 Backup 6356865 1 62164
2 int_30 Master 2228 1 3
OMNISWITCH R8
I P I N T E R FA C E S
OBJECTIVES

features
- IP interfaces
- Loopback0 Interface
- Static routes
- RIP
- Applying an ACL on the EMP port
IP INTERFACE
OVERVIEW
• IP is enabled by default on the OmniSwitch switches
• IP forwarding is enabled when at least one IP interface is configured on a VLAN
• IP Interfaces have the following characteristics:
• The subnet mask can be expressed in dotted decimal notation (255.255.0.0) or with a slash (/)
followed by the number of bits in the mask (192.168.10.1/24).
• A forwarding router interface sends IP frames to other subnets. A router interface that is not
forwarding can receive frames from other hosts on the same subnet.
• The first interface bound to a VLAN becomes the primary interface for that VLAN.
• Create a new IP Interface
-> ip interface <int_name> address <ip address/mask> vlan <vlan_id>
• Display the list of the IP Interfaces

LOOPBACK0
LOOPBACK0
• Goal
• Identify a consistent address for network management purposes
• Not bound to any VLAN
• Always remain operationally active (as long as at least one VLAN is active)
• To identify a Loopback0 interface, enter Loopback0 for the interface name
-> ip interface Loopback0 address 100.10.1.1
• Automatically advertised by RIP and OSPF protocols when the interface is created (not by BGP)
• Use
• RP (Rendez-Vous Point) in PIMSM
• sFlow Agent IP address
• Source IP of RADIUS authentication
• NTP Client
• BGP peering
• OSPF router-id
• Switch and Traps Identification from an NMS station (i.e OmniVista)
CUSTOM IP INTERFACE/LOOPBACK0 FOR IP SERVICE
• To configure a source IP address as the outgoing IP interface for an IP service
• Any IP interface/ loopback
• In the particular VRF based on an application specific command
[vrf vrf_name] ip service source-ip {Loopback0 | interface_name} [tftp] [telnet] [tacacs]
[swlog] [ssh] [snmp] [sflow] [radius] [ntp] [ldap] [ftp] [dns] [all]
sw5 (6360-A) -> ip service source-ip loopback0 snmp
sw5 (6360-A) -> show ip service source-ip

Legend: - no explicit configuration
Application Interface-name
-------------+--------------------------------
dns -
ftp -
ldap -
ntp -
radius -
sflow -
snmp Loopback0
ssh -
swlog -
tacacs -
telnet -
tftp - -
STATIC / DYNAMIC ROUTING
STATIC VS DYNAMIC ROUTING
• Static Routes
• Entered manually by the network administrator
• Anytime the network topology changes, administrator must update the routes
• Static routes always have priority over dynamic routes
• Suitable for environments where network traffic is relatively predictable and where network
design is relatively simple
• Dynamic Routing –( RIP, OSPF, …)

• Allows network to updates routes quickly and automatically without the administrator having to
configure new routes
• Routing protocols describe
• How to send updates?
• What information is in the updates?
• When to send updates?
• How to locate the recipients of the updates?
STATIC ROUTES
STATIC ROUTES - OVERVIEW
• Gateway or NextHop address is mapped to a particular interface on the switch
• Associated interface needs to be up and running
• By default, static routes have preference over dynamic routes
• Priority can be set by assigning a metric value

-> ip static-route <Destination Network>/<Mask> gateway <host> [METRIC | BFD-STATE | NAME | TAG | NO]
STATIC ROUTES - CONFIGURATION
• Specify a static route to the destination IP address 134.1.21.0
-> ip static-route 134.1.21.0/24 gateway 10.1.1.1
• Specify a default route

-> ip static-route 0.0.0.0/0 gateway 10.1.1.1
• Configure a default-route metric
-> ip static-route 0.0.0.0/0 gateway 1.1.1.1 metric 1
• Configure a backup default-route

-> ip static-route 0.0.0.0/0 gateway 2.2.2.2 metric 2
STATIC ROUTES - MONITORING
• Display the IP Router Database
-> show ip router database
Legend: + indicates routes in-use
b indicates BFD-enabled static route
i indicates INTERFACE static route
r indicates recursive static route, with following address in brackets
Total IPRM IPv4 routes: 3

Destination Gateway INTERFACE Protocol Metric Tag Misc-Info
---------------------+---------------+--------------------------------+--------+-------+----------+-----------
+ 10.0.0.0/24 10.4.15.254 EMP STATIC 1 0
+ 10.4.15.0/24 10.4.15.1 EMP LOCAL 1 0
+ 127.0.0.1/32 127.0.0.1 Loopback LOCAL 1 0
Inactive Static Routes
Destination Gateway Metric Tag Misc-Info
--------------------+-----------------+------+----------+-----------------
r 0.0.0.0/0 1.1.1.1 1 0
• Display the IP Routes

-> show ip routes

Total 1 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:37:17 LOCAL
RECURSIVE STATIC ROUTE
• Assign static routes with the next hop being the same as a route learned through a routing
protocol
• Recursive static routes

• Nexthop (or gateway) address no longer must be tied to a particular INTERFACE
• Capability to tie the destination route to the best route used to reach a particular host
• May be an INTERFACE or a dynamically learned route (i.e. BGP, OSPF, RIP, etc)
• May change over time
-> ip static-route <Destination Network>/<Mask> follows <host> [METRIC | NAME | TAG | NO]
RECURSIVE STATIC ROUTE - CLI
-> ip static-route 172.30.0.0/16 follows 2.2.2.2 metric 1
Legend: + indicates routes in-use
* indicates BFD-enabled static route
Destination Gateway Interface Protocol Metric Tag Misc-Info
-------------------+------------------+-----------+---------+--------+-------+-----------
+ 2.2.2.2/32 192.168.100.253 vlan100 RIP 2 0
+ 10.1.20.0/24 10.1.20.1 vlan20 LOCAL 1 0
+r 172.30.0.0/16 192.168.100.253 vlan100 STATIC 1 0 [2.2.2.2]
+ 192.168.100.0/24 192.168.100.1 vlan100 LOCAL 1 0
Destination Gateway Metric +r 172.30.0.0/16 10.1.20.2 vlan20 STATIC 1 0 [2.2.2.2]
--------------------+-----------------+---------
r 172.20.0.0/16 3.3.3.3 1
The gateway to reach the 2.2.2.2 network has changed through RIP;
* = BFD Enabled static route so, the gateway to reach the 172.30.0.0 network has also changed
Total 5 routes
Dest Address Subnet Mask Gateway Addr Age Protocol

----------------+------------------+------------------+---------+-----------
2.2.2.2 255.255.255.255 192.168.100.253 16:52:44 RIP
10.1.20.0 255.255.255.0 10.1.20.1 00:09:27 LOCAL
127.0.0.1 255.255.255.255 127.0.0.1 17:55:33 LOCAL
172.30.0.0 255.255.0.0 192.168.100.253 00:08:06 NETMGMT
192.168.100.0 255.255.255.0 192.168.100.1 17:54:09 LOCAL 2.2.2.2 255.255.255.255 10.1.20.2 00:07:28 RIP
ROUTING INFORMATION PROTOCOL (RIP)
ROUTING INFORMATION PROTOCOL - AOS SPECIFICATIONS
• RIP - Routing Information Protocol
• Supports IPv4
• Distance Vector Protocol (uses hop count to determine best path)
• Hop count limit of 16 is considered unreachable (prevents loops)
• Maximum network diameter = 15
• Generates updates every 30 seconds
• Updates contain all of the router’s routing table
• Routes timeout after 180 seconds

• Uses UDP port 520
• Maximum packet size is 512 bytes
• 20 Route Updates
• Poison reverse increases size

of routing updates
• Valid and poisoned routes are included in the updates
• Metrics only involve hop count

ROUTING INFORMATION PROTOCOL - CLI COMMANDS
Minimum configuration
-> ip load rip
-> ip rip interface if_name admin-state enable
-> ip rip admin-state enable
-> ip route-map rip_1 sequence-number 50 action permit

-> ip route-map rip_1 sequence-number 50 match ip-address 0.0.0.0/0
-> ip redist local into rip route-map rip_1 admin-state enable
-> ip redist static into rip route-map rip_1 admin-state enable
More details in next chapter for Redistribution

STOP Only learned RIP routes and Loopback0 interface are advertised by default.
Local and or static routes must be redistributed.
CLI COMMANDS
-> ip rip interface int_name send-version [v2 / v1 / v1compatible / none]

-> ip rip interface int_name recv-version [v1 / v2 / both / none]
-> ip rip interface int_name metric #
-> ip rip interface int_name auth-type [none / simple / MD5]
-> ip rip update-interval seconds
-> show ip rip

-> show ip rip peer
-> show ip rip interface
-> show ip rip interface int_name
ROUTING INFORMATION PROTOCOL - MONITORING
• Display the RIP Routes
-> show ip rip routes
Destination Mask Gateway Metric
------------------+------------------+----------------+-------
50.50.50.0 255.255.255.0 50.50.50.1 1
• Display the RIP Peers

-> show ip rip peer
Total Bad Bad Secs since
IP Address Recvd Packets Routes Version last update
----------------+------+-------+------+-------+-----------
100.10.10.1 1 0 0 2 3
• Display the IP Interfaces redistributed in RIP

-> show ip rip interface
Intf Admin IP Intf Updates
Interface vlan status status sent/recv(bad)
name
----------------+-----+----------+----------+---------------
30.30.30.1 30 enabled enabled 5/5(0)
ROUTING INFORMATION PROTOCOL - TIMERS
• Update
• Default at 30 - range 1..120
• The time interval between advertisements sent on an interface
• AOS to enforce the constraint that update cannot exceed 1/3 of invalid
-> ip rip update-timer 45 Default 30
• Invalid
• The time interval before an active route expires (and enters the “garbage” state)
• AOS to enforce the constraint that invalid cannot be less than 3x of update
-> ip rip invalid-timer 270 Default 180

ROUTING INFORMATION PROTOCOL - TIMERS
• Garbage
• The time interval before an expired route (which is in the “garbage” state)
is removed from the RIB.
• During the “garbage” interval measured by the garbage timer,
the router advertises the prefix with a metric of INFINITY
-> ip rip garbage-timer 180 Default 120
• Hold-down
• The time interval during which a route remains in the hold-down state.
Whenever a route is seen from the same gateway with a higher metric
than the route in the RIB, the route goes into hold-down.
• This excludes route updates with an INFINITY metric
-> ip rip holddown-timer 10 Default 0
APPLYING AN ACL ON THE EMP PORT
APPLYING AN ACL ON THE EMP PORT
• This feature allows for applying an ACL on the EMP port of the switch.
• It enables policy-based routing on the EMP ports.
• The configuration is enabled using the empacl policy-list type.

• Only for IP condition in PBR policy rule.
• The following condition and action are supported in this release:
• Policy condition with Source IPv4 and Destination IPv4 addresses
• Policy action with PBR
• Only a single empacl policy list with multiple policy rules is supported.
• The following CLI commands are associated with this feature:
-> policy list list_name type empacl
THANK YOU
OMNISWITCH R8
O P E N S H O R T E S T PAT H F I R S T ( O S P F ) - F U N D A M E N TA L S
OBJECTIVES
• Understand the role of a Router ID

• Summarize the different states an OSPF router
goes through
OSPF > OVERVIEW
• Routing Protocol
• Interior Gateway Protocol
• Overcome RIP deficiencies & scalability problems
• Link-State Routing (LSR) Protocol
• Shortest Path First Algorithm
• Widely used in large enterprise networks
• RFC 2328
SPECIFICATIONS
ROUTER IDENTITIES
• Router Identities = Router ID
• Each OSPF router has a unique ID within the OSPF network

• ID included in any OSPF messages sent by the OSPF router
ID = 1.1.1.1 ID = 2.2.2.2 ID = 3.3.3.3

• Router ID can be (in order of priority):
• Manually defined
• The IP address of the router’s Loopback0 interface
• Highest IP address from one of its active interfaces
ID = 4.4.4.4 ID = 5.5.5.5
FINDING NEIGHBOURS
R1 State R1 R2 R2 State
• Exchange Process
Down Hello Down
Init Init
Hello
2-Way 2-Way
Hello
Exstart (cont. R1 ID) Exstart
- Hello interval: 10 seconds
Exchange Hello Exchange (keep-alive function)
(cont. R2 ID)
Loading Loading
- Dead interval: 40 seconds
Full Full
• Down State
• Router have not exchanged any OSPF information
• Init State
• A destination router has received a new router’s hello packet
• Adds it to its neighbour list
• 2-Way State
• The new router receives a unidirectional reply from the destination router
• Adds the destination router to its neighbour list
DESIGNATED & BACKUP DESIGNATED ROUTERS
• Once in 2-Way State, the routers elect a Designated Router (DR) and a Backup Designated
Router (BDR)
• 1 DR and 1 BDR for each broadcast segment
• Role
• Maintaining the LSDB (Link State DataBase) Update (dst @: 224.0.0.5) 3
R1 R2 R3
• Receiving and disseminating update
to the routers on the segment 2
DR BDR DROther
Update
VLAN 1 (dst @: 224.0.0.6)
DROther 1
New link!
R4
• DR & BDR Election
• The DR & BDR are elected according to the following parameters:
1• IP interface priority (highest priority)
2• Router ID (highest value)
ID = 1.1.1.1 ID = 2.2.2.2 ID = 3.3.3.3
Priority = 250 Priority = 200 Priority = 150
• If the DR fails,
DR BDR DROther
• The BDR is promoted to DR
• Another Router (DROther) is promoted to BDR
DROther DROther
ID = 4.4.4.4 ID = 5.5.5.5
Priority = 100 Priority = 50
• Election > Exstart State
• DR & BDR form adjacencies with the other OSPF routers
R1 State Hello R2 State

• Router ID
Init • IP Int./Rtr Priority Init
2-Way 2-Way
Hello
Exstart • Router ID Exstart
• IP Int./Rtr Priority
• Highest router ID becomes the master and start the exchange process
ID = 1.1.1.1 ID = 2.2.2.2 ID = 3.3.3.3
Priority = 250 Priority = 200 Priority = 150
SLAVE
DR BDR DROther
DROther DROther
MASTER
ID = 4.4.4.4 ID = 5.5.5.5
Priority = 100 Priority = 50
• OSPF routers are ready to share link state information!

SHARING ROUTING INFORMATION
• Sharing Link State information > Exchange State
• Database Description (DBD) packets which contains
• ID of the advertising router
• Cost of the advertising router
• Sequence number of the link
MASTER SLAVE
R4 R1 (DR)
R4 DBD R1 (DR)
• ID Adv. Router
Init • Cost Adv Router Init
• Seq nb
2-Way 2-Way
Exstart Exstart
LSAck
Exchange Exchange
• Loading information in the Database > Loading State
• If the master has more up-to-date information than the slave,
• Slave sends a Link State Request (LSR) to the master
• Master then sends a Link State Update (LSU) with detailed information of the links
• Slave incorporate information in its local database
• Slave sends a Link State Acknowledge (LSAck) to the master MORE
MASTER SLAVE
UP-TO-DATE
• If slave has more up-to-date information, INFO R4 R1 (DR)
• It will repeat the Exchange and Loading states

R4 R1 (DR)
Init LSR Init
2-Way 2-Way
Exstart LSU Exstart
Exchange Exchange
Loading LSAck Loading
State
SHARING ROUTING INFORMATION Down

Init
2-Way
• Master & Slave synchronized > Full State
Exstart
• Incremental updates after entering a full state Exchange
• In case of Update (ex. new route discovered) Loading
3
Full
R1 R2 R3
DR BDR DROther
2
VLAN 1
DROther
1
1 A new network is discovered by R4 R4
2 R4 sends a multicast to the DR and the BDR (destination @: 224.0.0.6)

The DR and the BDR update their LSDB (based on the received information)
3 The DR informs the other routers on the segment about the change
(destination @: 224.0.0.5 = all OSPF routers)
• Metrics/Cost
• Indicates the overhead required to send packets out a particular interface
• Cost is calculated:
• From the root node to every other node in the network
• Using the metric cost of the outgoing interfaces
• Cost can be set on a per-interface basis

• Routers can disagree about the cost on a network link
• Can result in asymmetric routing in the network
THANK YOU
OMNISWITCH R8
O P E N S H O R T E S T PAT H F I R S T ( O S P F ) – A R E A S
OBJECTIVES
• Define an OSPF Area

• Summarize the different LSA types
• List the OSPF Area types
• Learn how to redistribute local & external
routes
OVERVIEW
OVERVIEW
• An OSPF network can be divided in sub-domains called areas
• A router within an area maintains a topological database for the area to which it belongs
• The router does not have information about the topology outside of its area
Without Areas With Areas

THE SPF IS RUNNING
TOO OFTEN!
AREA 0
CORE I’M RECEIVING TOO
MANY LSAS!
DISTRIBUTION
… … ACCESS … …
AREA 1 AREA 2
MY ROUTING TABLE IS TOO BIG
I’M RUNNING LOW ON MEMORY!
OVERVIEW
• Main benefit of creating areas > reduce the number of routes to propagate
• If divided in areas, an OSPF network must have:
• A Backbone Area
• Distributes information between areas
• Must be contiguous (if not, virtual links can be configured)
• Non-backbone area(s) directly connected to the backbone area
• Area are identified by an area ID (32 bits dotted decimal format):

• Backbone area > 0.0.0.0
• Other areas > W.X.Y.Z (ex. 1.1.1.1) AREA 0.0.0.0 (BACKBONE AREA)
… …
AREA 1.1.1.1 AREA 2.2.2.2
ROUTER TYPES
BACKBONE ROUTER (BB) & INTERNAL ROUTER (IR)
• Routers that are entirely within the backbone area are called Backbone Router (BB)
• Routers that are wholly within an area are called Internal Routers (IR)
AREA 0.0.0.0 (BACKBONE AREA)
BB
IR … IR IR … IR
AREA 2.2.2.2
AREA 1.1.1.1
AREA BORDER ROUTER (ABR)
• Router that attaches multiples areas (backbone + other areas)
• Condense the topological information of their attached areas for distribution to the
backbone
• The backbone in turn distributes the information to the other areas
• Main function
• Summarize sub networks found throughout the OSPF system
ABR
AREA 0.0.0.0 …
AREA 1.1.1.1
AUTONOMOUS SYSTEM BOUNDARY ROUTER (ASBR)
• Router that is running multiple routing protocols
• Serves as a gateway
• Able to import and translate different protocols into OSPF (redistribution)
EXTERNAL DOMAIN
RIP
ASBR
AREA 0.0.0.0 …
AREA 1.1.1.1
LSA TYPES
LSA – TYPE 1 > ROUTER LSA
• Each router within the area floods router LSA
• Aim: provide a list with all the directly connected links
• A router LSA always stays within the area
• Generated by every router
R2
R1 R3
AREA 0.0.0.0
Each router sends a LSA – Type 1 to each other with all its directly connected links
LSA – TYPE 2 > NETWORK LSA
• Only generated by DR (multi-access network)
• A network LSA always stays within the area
• Aim: send ID of all the routers connected to the multi-access network
R2 DR
R3
R1
AREA 0.0.0.0
The DR generates a LSA – Type 2 in the Area 0

Contains the directly connected routers:
R1
R3
LSA – TYPE 3 > SUMMARY LSA
• Generated by the ABR
• Aim: inform other areas about networks from an area
AREA 0.0.0.0
R3
LSA – TYPE 1 ABR (1)

ABR (2)
R1 R2 LSA – TYPE 3 LSA – TYPE 3
…
NEW …
ROUTE R4 R5
AREA 2.2.2.2 AREA 1.1.1.1
R1 floods the new route information via a LSA – Type 1 (Router LSA) in the Area 2
Reminder: LSA – Type 1 stays within the area!
ABR (1) creates an LSA – Type 3 (Summary LSA) and flood it into the area 0
This LSA is flooded into all the other areas
LSA – TYPE 5 > EXTERNAL LSA
• Generated by the ASBR
• Aim: redistribute external routes into OSPF
AREA 0.0.0.0
R3
AREA 2.2.2.2
ABR (2)
LSA – TYPE 5 LSA – TYPE 5
ASBR … R2
…
RIP R4 R5
EXTERNAL DOMAIN AREA 1.1.1.1
The ASBR redistributes the RIP routes into OSPF via a LSA – Type 5 – External LSA
The LSA – Type 5 – External LSA is flooded into all the other areas
LSA – TYPE 4 > SUMMARY ASBR LSA
• Generated by the ABR
• Aim: inform other routers where to find the ASBR
• Includes the ASBR Router ID
AREA 0.0.0.0
R3
AREA 2.2.2.2
ABR (2)
ASBR … R2
…
R4 R5
RIP
AREA 1.1.1.1
EXTERNAL DOMAIN
The ASBR flips a bit in the LSA-Type 1 to identify itself as ASBR

When the ABR (1) receives the LSA, it creates a LSA Type 4 – Summary ASBR LSA and flood it into the area 0
This LSA is flooded into all the other areas
LSA – TYPE 7 > NSSA LSA
• Used for specific area type: Not-So-Stubby-Area (explained later)
• LSA - Type 5 are not allowed in NSSA areas
• LSA – Type 7 carries exact same information as LSA – Type 5 but is not blocked in NSSA areas
AREA 0.0.0.0
AREA 2.2.2.2
(NSSA AREA) R3

ABR (2)
ASBR … R2
…
RIP R4 R5
AREA 1.1.1.1
EXTERNAL DOMAIN
The ASBR redistributes the RIP routes into OSPF via a LSA – Type 7 – External LSA (because Area 2 is NSSA)
The ABR (1) convert the LSA – Type 7 to LSA – Type 5, then flood it into all the other areas
*LSA-Type 6 are not explained in this course as they are not used in today’s infrastructures
AREA TYPES
STANDARD AREA
AREA 0 STANDARD AREA 1
R1 R2 R3
EXTERNAL
TYPE 1/2 TYPE 1/2
DOMAIN
TYPE 3
TYPE 5
TYPE 4
• Router Types
• R2 = Area Border Router (ABR)
• R3 = Autonomous System Boundary Router (ASBR)
• LSA Types
• Type 1 & 2 LSAs are flooded between routers in the same area
• Type 3 & 5 are flooded throughout the backbone and all standard areas
• Type 4 LSAs are injected into the backbone by the ABR of an area which contains an ASBR
STUB AREA
• External routes are not forwarded in a stub area
AREA 0 STUB AREA 1
R1 R2 R3
TYPE 1/2 TYPE 1/2

TYPE 3
DEFAULT
• Router Types
• R2 & R3 share a common stub area
• LSA Types
• Type 5 LSAs are not propagated into the stub area
• Instead, R2 (ABR) injects a Type 3 LSA containing a default route into the stub area (« through itself »)
• Type 4 LSAs are not propagated into the stub area
TOTALLY STUBBY AREA
• External routes + Type 3 LSAs are not forwarded in a Totally Stubby area
AREA 0 TOTALLY STUBBY AREA 1
R1 R2 R3
TYPE 1/2 TYPE 1/2
DEFAULT
• Router Types
• R2 & R3 share a common stub area
• LSA Types
• Like stub areas, totally stubby areas do not receive Type 4 & Type 5 LSAs from their ABRs
• Neither do the Type 3 LSAs
• All routing out of the area relies on a single default route injected by the ABR
NOT SO STUBBY AREA (NSSA)
• Stub & Totally Stubby Areas
• Pro: Convenient to reduce the resource utilization of routers (no external routes to process)
• Con: Neither type can contain an ASBR (as types 4 & 5 LSAs not authorized)
AREA 0 NSSA 1
R1 R2 R3
EXTERNAL
TYPE 1/2 TYPE 1/2
DOMAIN
TYPE 5 TYPE 7
TYPE 4
• Router Types
DEFAULT
• R3 = Autonomous System Boundary Router (ASBR)
• LSA Types
• Type 7 LSAs = Type 5 LSAs in disguise
• This allows an ASBR to advertise external links to an ABR
ROUTES REDISTRIBUTION
• Allows to learn and advertise IPv4 routes between different protocols
• Uses route maps to:
• Determine which routes are allowed/denied access to the network
EXTERNAL DOMAIN
• Modify route parameters before they are redistributed
RIP
• STEP 1: Configuring Route Maps 192.168.1.0/24
192.168.2.0/24
• A Route Map is composed of
AREA 0.0.0.0
• Action ASBR
• Route map name
• Sequence number
• Action: permit/deny
• Match EXAMPLE: REDISTRIBUTION OF 192.168.1.0 ONLY
• Criteria that a route must match
• Action statement is applied to the route ROUTE MAP
- ACTION: PERMIT
• Set - MATCH: 192.168.1.0/24
• Modify route information before being redistributed - SET: NOT USED
• Applied if - ACTION: DENY
• All the route-map criteria is met
- MATCH: 192.168.2.0/24
• The action permits redistribution
- SET: NOT USED
• STEP 2: Configuring Route Redistribution
• Redistribution from source protocol to destination protocol
• Source protocol: from which the sources are learned
• Destination protocol: from which the sources are redistributed
EXTERNAL DOMAIN EXAMPLE: REDISTRIBUTION OF 192.168.1.0 ONLY
RIP STEP 1 > ROUTE MAP

- ACTION: PERMIT
192.168.1.0/24 - MATCH: 192.168.1.0/24
REDISTRIBUTION 192.168.2.0/24 - SET: NOT USED
- ACTION: DENY
ASBR - MATCH: 192.168.2.0/24
- SET: NOT USED
AREA 0.0.0.0 STEP 2 > ROUTES REDISTRIBUTION

- RIP INTO OSPF
- ROUTE MAP (CONFIGURED IN STEP 1)
• Redistribution configured > Router becomes ASBR

OSPF CONFIGURATION
OSPF CONFIGURATION
Step by Step
Loading the Software
Creating an Area
Specifying an Area Type
Creating an OSPF Interface
Assigning an Interface to an Area
Redistributing Local & External Routes
Enabling OSPF
OSPF CONFIGURATION
Step by Step
Loading the Software

Load the OSPF Software into the running configuration
Creating an Area
Create the OSPF area(s)
AREA 0 AREA 1
Specifying an Area Type

When creating an area, an area type can be specified (Normal/Stub/NSSA)
OSPF CONFIGURATION
Step by Step
Creating an OSPF Interface

Once areas established, interfaces need to be created and assigned to the areas
AREA 0 AREA 1
Assigning an Interface to an Area

Each Interface must then be assigned to an Area
AREA 0 AREA 1
OSPF CONFIGURATION
Step by Step
Redistributing Local & External Routes

If necessary, configure the redistribution of local and/or external routes
REDIST. REDIST.
AREA 0 AREA 1
RIP
EXTERNAL DOMAIN
Enabling OSPF
Enable the OSPF Software previously loaded
OSPF CONFIGURATION
0) CONFIGURING THE ROUTER-ID
SW-> ip router router-id 192.168.254.7
1) LOADING THE SOFTWARE

INT 1 INT 2
SW-> ip load ospf
AREA 0
2) CREATING AN AREA
SW-> ip ospf area 0.0.0.0
3) SPECIFYING AN AREA TYPE

SW-> ip ospf area 1.1.1.1 type normal
4) CREATING AN OSPF INTERFACE

SW-> ip ospf interface int_1
5) ASSIGNING AN INTERFACE TO AN AREA

SW-> ip ospf interface int_1 area 0.0.0.0
SW-> ip ospf interface int_1 admin-state enable (R8)
OSPF CONFIGURATION
4) CREATING AN OSPF INTERFACE
SW-> ip ospf interface int_2 INT 1 INT 2
5) ASSIGNING AN INTERFACE TO AN AREA AREA 0 AREA 1

SW-> ip ospf interface int_2 area 1.1.1.1
SW-> ip ospf interface int_2 admin-state enable
6) REDISTRIBUTING LOCAL & EXTERNAL ROUTES

SW-> ip route-map RipIntoOspf sequence-number 10 action permit
SW-> ip route-map RipIntoOspf sequence-number 10 match ip-address 192.168.254.0/24 permit
SW-> ip redist rip into ospf route-map RipIntoOspf admin-state enable
7) ENABLING OSPF
SW-> ip ospf admin-state enable
REDIST. REDIST.
AREA 0 AREA 1
RIP
EXTERNAL DOMAIN
THANK YOU
OMNISWITCH R8
O P E N S H O R T E S T PAT H F I R S T ( O S P F )
A D VA N C E D F E AT U R E S & M O N I T O R I N G
OBJECTIVES
• Identify the advantages of ECMP in OSPF

• Choose when to use the Summarization
• Choose when to use the Aggregation
• Summarize the Graceful Restart feature
• Enable the Simple/MD5 Authentication
• Determine when to use the Virtual Link feature
• List the main OSPF monitoring commands
OSPF FEATURES
OSPF & ECMP
• Aka ECMP (Equal Cost Multi-Path) Routing
• Next-hop packet forwarding to a single destination can occur over multiple “best paths”
• Works for routes with

• Same destination
• Same metric
• Different next-hops
• ECMP Per-Flow Load Balancing

• Distributes packets across multiple links based on L3 routing information
• Router discovers multiple paths to a destination > Routing table updated with multiple entries
• Multiple paths used for multiple sources-destination host pairs
• Up to 4 ECMP routes supported

*Per packet Load Balancing is not supported
SUMMARIZATION
• By default, OSPF doesn’t summarize anything
• OSPF Summarization advantages
• Smaller routing tables
• Less LSA flooding
• Less bandwith, memory & CPU usage
• Summary routes are carried by LSA – Type 3 (Summary LSA)
• Internal routes summarization done on the ABR
WITH SUMMARIZATION
AREA 0.0.0.0
192.168.0.0/23 VIA ABR
ABR
WITHOUT SUMMARIZATION
192.168.0.0/24 VIA ABR
192.168.0.0/24 192.168.1.0/24 192.168.1.0/24 VIA ABR
AREA 1.1.1.1
AGGREGATION
• Internal routes: Summarization > External routes: Aggregation
• Same advantages as Summarization
• Smaller routing tables
• Less LSA flooding
• Less bandwith, memory & CPU usage
• Aggregated routes are carried by LSA – Type 5 (External ASBR LSA)
• External routes aggregation done on the ASBR
WITH SUMMARIZATION
AREA 0.0.0.0
192.168.0.0/23 VIA ABR
ASBR
WITHOUT SUMMARIZATION
192.168.0.0/24 VIA ABR
192.168.0.0/24 192.168.1.0/24 192.168.1.0/24 VIA ABR
EXTERNAL DOMAIN
OSPF INTERFACE AUTHENTICATION
• If authentication enabled, neighbours can communicate only if:
• They use the same type of authentication
• They have a matching password or key
• 2 types of authentication:
• Simple
• Uses simple clear-text passwords
• MD5
• Encrypted authentication, uses a key and a password
VIRTUAL LINK
• Reminder: all areas must be connected to the backbone area (Area 0)
• Not possible? Solution: Virtual Link
• A Virtual Link is used:

• To connect an area to the backbone through a non-backbone area
• To connect 2 parts of a partitioned backbone through a non-backbone area
• The crossed area is called Transit Area

AREA 0.0.0.0 AREA 2.2.2.2 AREA 0.0.0.0 AREA 0.0.0.0
VIRTUAL LINK VIRTUAL LINK
AREA 1.1.1.1 = TRANSIT AREA AREA 1.1.1.1 = TRANSIT AREA
ip ospf virtual-link <transit-area> <router-id>

MONITORING
MONITORING
• OSPF Log levels can be modified:
• To monitor the OSPF operation
• To troubleshoot an issue on OSPF
• Modifying Log levels allows to have more (or less) information about a specific
protocol/feature (ex. OSPF) in the logs
SEVERITY LEVELS FOR AOS R8

MONITORING
Example of Severity Level modification
• All OSPF sub applications
SW-> swlog appid ospf_0 subapp all level 8
[OR]
SW-> swlog appid ospf_0 subapp all level debug3
• Only the Hello messages

SW-> swlog appid ospf_0 subapp hello level debug3
• For information, below the list of the sub applications

SW-> swlog appid ospf_0 subapp ?
ALL <num> <string>
1=ERROR 2=WARNING 3=RECV 4=SEND 5=FLOOD 6=SPF 7=LSDB
8=RDB 9=AGE 10=VLINK 11=REDIST 12=SUMMARY
13=DBEXCH 14=HELLO 15=AUTH 16=STATE 17=AREA 18=INTF
19=CONFIG 20=INFO 21=SETUP 22=TIME 23=MIP 24=TM
25=RESTART 26=HELPER 27=HOST 28=AUTOCONFIG
MONITORING
Example
• Infrastructure
SW1 SW2
• Problem: SW1 & SW2 are not in FULL state!

SW1 SW2
# of Events = 4, # of Events = 4,
# of Init State Neighbors = 0, # of Init State Neighbors = 0,
# of 2-Way State Neighbors = 0, # of 2-Way State Neighbors = 0,
# of Exchange State Neighbors = 0, # of Exchange State Neighbors = 0,
# of Full State Neighbors = 0, # of Full State Neighbors = 0,
# of type-9 LSAs on this interface = 0, # of type-9 LSAs on this interface = 0,
• Modify the log level to have the maximum verbosity

SW1 -> swlog appid ospf_0 subapp all level debug3
MONITORING
Example
• Check the logs
SW1 -> show log swlog | grep ospf_0
[TRUNCATED]
2017 Oct 20 09:58:57 SW1 swlogd: ospf_0 HELLO debug2(7) [1508493537.082626]
(4226):(457): HELLO from 192.168.0.2 discarded...invalid helloInterval 10
[TRUNCATED]
• Check the Hello Interval on both switches

SW1 SW2
Hello Interval (seconds) = 20, Hello Interval (seconds) = 10,
• The Hello Interval value is not the same on both switches!

• Solution: put the same value on both switches
• Result: SW1 SW2
# of Init State Neighbors = 0, # of Init State Neighbors = 0,
# of 2-Way State Neighbors = 0, # of 2-Way State Neighbors = 0,
# of Exchange State Neighbors = 0, # of Exchange State Neighbors = 0,
# of Full State Neighbors = 1, # of Full State Neighbors = 1,
THANK YOU
OMNISWITCH R8
G L O B A L R O U T I N G P R O TO C O L S R E D I S T R I B U T I O N
OBJECTIVES
• Understand the layer 3 route redistribution

concept on AOS based switches
• Implement an appropriate route redistribution
in a network with its different options, then
monitor the rule statements
OVERVIEW OF ROUTE MAP
Route Redistribution
• Redistribute routes from a source protocol RIB to a destination protocol RIB
• Source protocol can be BGP, RIP, OSPF, Local or Static
• Destination protocol can be BGP, RIP or OSPF
Source IP ROUTE MANAGER

Routing
Protocol
RIB
Destination
Routing
Protocol
REDIST ROUTE MAP
OVERVIEW OF ROUTE MAP -> show ip router database

Legend: +
b
i
indicates
indicates
indicates
routes in-use
BFD-enabled static route
interface static route
Route Redistribution
Destination Gateway Interface Protocol Metric Tag Misc-Info

---------------------+---------------+-----------+--------+-------+----------+--------------
+ 10.0.0.0/24 10.4.116.254 EMP STATIC 1 0
+ 10.4.16.0/24 10.4.116.254 EMP STATIC 1 0
+ 10.4.116.0/24 10.4.116.7 EMP LOCAL 1 0
+ 127.0.0.1/32 127.0.0.1 Loopback LOCAL 1 0

Destination Gateway Metric Tag Misc-Info
Local
IPRM --------------------+-----------------+------+----------+-----------------
Static
(IP Route Manager)
RIP
OSPF
BGP 1
IS-IS -> show ip redist
Source Routing
RIB
(Routing
Protocol Information
Base)
-> show ip route-pref
Local 3 Redist
Protocol Route Preference Value
------------+------------------------
Local 1
Static Route Best (preferred) routes Static 2
RIP Map OSPF
ISISL1
110
115
OSPF ISISL2 118
RIP 120
BGP
IS-IS 2 EBGP
IBGP
Import
190
200
210
Destination Routing
Protocol -> show ip routes
-> show ip routes FIB

+ = Equal cost multipath routes (Forwarding
Total 1 routes Information RIB - Routing Information Base
Base)
Dest Address Gateway Addr Age Protocol FIB – Forwarding Information Base
------------------+-------------------+----------+-----------
ROUTE MAP - DEFINITION
• Route map
• Criteria that is used to control redistribution of routes between protocols
• Defined by configuring route map statements
• Route Map and Statements
• Action
• Route map name
• Sequence number
• Action, redistribution is permitted or denied based on criteria
• Match
• Criteria that a route must match
• Action statement is applied to the route
• Set
• Modify route information before redistributed into the receiving protocol
• Applied if
• All the route-map criteria is met and
• The action permits redistribution
ROUTE MAP - CONFIGURATION
-> ip route-map myroute-map? ACTION MATCH SEQUENCE-NUMBER SET
• ACTION
• Match • PERMIT
• DENY • SET
• IP-ADDRESS • METRIC 1
• IP-NEXTHOP Action • EFFECT
• IPV4-INTERFACE • ADD
• IPV6-ADDRESS • SUBTRACT
• REPLACE
• IPV6-INTERFACE Match • NONE
• IPV6-NEXTHOP
• METRIC-TYPE
• METRIC Set… • INTERNAL
• ROUTE-TYPE Route-Map • EXTERNAL
• LEVEL2 • TAG
• LEVEL1
• COMMUNITY
• INTERNAL
• EXTERNAL • LOCAL-PREFERENCE
• TAG IP • LEVEL
access- Redist- • LEVEL1-2
• LEVEL2
list control • LEVEL1
• IP ACCESS-LIST
• ACCESS-LIST-NAME • REDIST-CONTROL
• IP-ADDRESS/MASK • ALL-SUBNETS
• NO-SUBNETS
• AGGREGATE
NEW REDISTRIBUTION - COMMANDS
• Route map criteria specification
ip route-map route-map-name [sequence-number number] action {permit | deny}
ip route-map route-map-name [sequence-number number] match ip-address {access-list-name |

ip-address/prefixLen} [redist-control {all-subnets | no-subnets | aggregate}] [permit | deny]
ip route-map route-map-name [sequence-number number] set metric metric [effect {add |subtract |
replace | none}]
• Rip redistribution
->ip redist {local | static | ospf | isis | bgp} into rip route-map route-map-name
• OSPF redistribution
->ip redist {local | static | rip | isis | bgp} into ospf route-map route-map-name
ROUTE MAP - ACCESS LIST CREATION
• Convenient way to add multiple IPv4 or IPv6 addresses to route-maps
• Maximum 200 per switch
• Create the Access List name
-> ip access-list access-list-name
• Define access-list statements
-> ip access-list access-list-name address address/mask [action {permit | deny}]
[redist-control {all-subnets | no-subnets | aggregate}]
-> ip access-list ipaddr2

-> ip access-list ipaddr2 address 16.24.2.1/16
-> ip access-list ipaddr2 address 16.24.2.1/16 action deny redist-control allsubnets
-> ip route-map test sequence-number 50 match ip-address ipaddr2
ROUTE MAP - SEQUENCING & DENY STATEMENTS
• Operation
-> ip route-map myroutemap sequence-number 1 action deny
-> ip route-map myroutemap sequence-number 1 match ip-address 10.0.0.0/8 redist-control all-subnets permit
-> ip route-map myroutemap sequence-number 2 action permit
-> ip route-map myroutemap sequence-number 2 match ip-address 0.0.0.0/0 redist-control all-subnets permit
• -> ip redist static into rip route-map myroutemap
• Route 10.10.0.0/16 will match sequence-number 1

• Since one of the actions is deny, switch stops processing and does not redistribute the route
• Route 11.11.0.0/16 will not match sequence-number 1

• Therefore, the processing goes to sequence-number 2 where there is a match and both actions are permit
• Switch stops processing and redistributes the route
ROUTE MAP - SEQUENCING & DENY STATEMENTS
-> ip route-map routemap1 sequence-number 50 action permit
-> ip route-map routemap1 match ip-address 10.0.0.0/8
-> ip route-map routemap1 match tag 4
-> ip route-map routemap1 match tag 5
-> ip route-map routemap1 match ip-address 10.0.0.0/8 redist-control all-subnets permit
-> ip route-map routemap1 sequence-number 50 set metric 1 effect add
Means match the subnet

10.0.0.0/8 and [tag 4 or tag 5]
ROUTE MAP - MONITORING
-> show ip redist
Source Destination
Protocol Protocol Status Route Map
------------+------------+---------+--------------------
LOCAL4 OSPF Enabled ospf_ext
-> show ip access-list

Access Lists: configured: 1 max: 200
Address / Redistribution
Name Prefix Length Effect Control
--------------------+------------------+-------+------------
extip 172.0.0.0/8 permit aggregate
-> show ip route-map

Route Maps: configured: 1 max: 200
Route Map: ospf_ext Sequence Number: 50 Action permit
match ip accesslist extip
ROUTE MAP CONFIGURATION - EDITING & DELETING
• Deletes a specific route map set or match entry
-> no ip route-map rip_1 sequence-number 50 set metric 1 effect add
• Deletes route map all sequence number of 50 in the rip_1 route map
-> no ip route-map rip_1 sequence-number 50
• Deletes the route map rip_1

-> no ip route-map rip_1
Notes: The “no” version of the command that specifies a match or set parameter only deletes that
parameter from the route-map. If a sequence-number is included but no match or set
parameters, then only that specific route-map is deleted. If the command only has a route-
map-name, then the entire route-map is deleted.
THANK YOU
OmniSwitch R8
OSPF
How to
✓ Implement a OSPF backbone area configuration, different types of areas,
authentication and virtual links on an OmniSwitch.
Contents
1 Topology ........................................................................................ 3
2 Configuration .................................................................................. 4
2.1. Client VLAN Configuration......................................................................... 4
2.2. Configure connections between 6860B and 6900-B ............................................... 4
3 OSPF Backbone ................................................................................ 5
3.1. OSPF Backbone Logical Diagram .................................................................. 5
3.2. Configuration........................................................................................ 5
3.2.1. Loopback interface configuration ........................................................................ 6
3.3. Verification .......................................................................................... 8
4 OSPF Areas ................................................................................... 12
4.1. OSPF Areas Logical Diagram ..................................................................... 12
4.2. Configuration....................................................................................... 13
4.3. Verification ......................................................................................... 13
4.4. Configuration....................................................................................... 15
4.5. Verification ......................................................................................... 15
4.6. Virtual-link configuration (on both switches) ................................................. 18
4.6.1. Configure the backbone area on switch 6900-B and 6860-B ........................................ 18
4.6.2. Create Virtual-link ....................................................................................... 19
4.6.3. Verify the working of the virtual-link.................................................................. 19
2
OSPF
4.7. Let’s add VLANs 20 and 30 into our OSPF network in Area 3.3.3.3......................... 23
4.8. On the 6860s create and configure Area 3.3.3.3: ............................................. 23
4.9. Verify the correct operation of the OSPF setup with the following commands: ......... 24
5 OSPF Redistribution ......................................................................... 28
6 Access to the DATA server ................................................................. 31
7 OSPF Authentication ........................................................................ 34
7.1. Simple Authentication ............................................................................ 34
7.2. MD5 Authentication ............................................................................... 34
8 Stub Area .................................................................................... 35
8.1. OSPF Areas Logical diagram ...................................................................... 35
8.2. Configuration....................................................................................... 36
8.3. Verification ......................................................................................... 37
3
OSPF
1 Topology
Open Shortest Path First routing (OSPF) is a shortest path first (SPF), or link state, protocol. OSPF is an interior
gateway protocol (IGP) that distributes routing information between routers in a single Autonomous System
(AS). OSPF chooses the least-cost path as the best path. OSPF is suitable for complex networks with large
numbers of routers since it provides faster convergence where multiple flows to a single destination can be
forwarded on one or more interfaces simultaneously.
4
OSPF
2 Configuration
2.1. Client VLAN Configuration

- On the 6900-B, create client VLAN and assign an ip interface:
sw2 (6900-B) -> vlan 120

- ON the 6860s, create client VLAN and assign ip interfaces:
sw7 (6860-A) -> vlan 70

sw8 (6860-B) ->vlan 80

sw8 (6860-B) ->vlan 80 members port 1/1/1 untagged
sw8 (6860-B) ->ip interface int_80 address 192.168.80.8/24 vlan 80
sw8 (6860-B) ->interfaces 1/1/1 admin-state enable
2.2. Configure connections between 6860B and 6900-B
- Configure a backbone VLAN
sw2 (6900-B) -> vlan 228

sw8 (6860-B) -> vlan 228
- Create Link Aggregation

sw2 (6900-B) -> linkagg lacp port 1/1/5 actor admin-key 28

sw8 (6860-B) -> linkagg lacp port 1/1/5 actor admin-key 28
- Assign Linkagg to VLAN 228

-
- Configure IP interface to VLAN 228

-
Sw2 (6900-B) -> ip interface int_228 address 172.16.28.2/24 vlan 228

5
OSPF
- Enable interfaces
- Check that you can ping between 6860-B and 6900_B
sw8 (6860-B) -> ping 172.16.28.2
3 OSPF Backbone
All OSPF networks must have an OSPF backbone area configured
3.1. OSPF Backbone Logical Diagram
3.2. Configuration
- Enable OSPF protocol on 2 switches to advertise all local routes. In order to have a complete
connectivity between all switches, OSPF will be used to advertise dynamically all the routes.
- The first step is to load OSPF protocol and to enable OSPF on the newly created IP interfaces. As all
OSPF networks must have a backbone area, this will be created with 0.0.0.0 as the area identifier.
- Then, the relevant OSPF interfaces will be attached to the backbone.

6
OSPF
3.2.1. Loopback interface configuration
- Loopback0 is always advertised, even if there are no users on the switch; no route re-distribution is necessary.
sw1 (6900-A) -> ip interface Loopback0 address 192.168.254.1
- Type the following on the 2 switches:
-> ip load ospf
- Let’s define the router-id and the backbone area on all switches:
sw1 (6900-A) -> ip router router-id 192.168.254.1

sw1 (6900-A) -> ip ospf area 0.0.0.0

sw7 (6860-A) -> ip ospf area 0.0.0.0
- Verify the configuration with the following commands:
sw1 (6900-A) -> show ip ospf
Router Id = 192.168.254.1,
OSPF Version Number = 2,
Admin Status = Disabled,
Area Border Router ? = No,
AS Border Router Status = Disabled,
Route Tag = 0,
SPF Hold Time (in seconds) = 10,
SPF Delay Time (in seconds) = 5,
MTU Checking = Disabled,
# of Routes = 0,
# of AS-External LSAs = 0,
# of self-originated LSAs = 0,
# of LSAs received = 0,
External LSDB Limit = -1,
Exit Overflow Interval = 0,
# of SPF calculations done = 0,
# of Incr SPF calculations done = 0,
# of Init State Nbrs = 0,
# of 2-Way State Nbrs = 0,
# of Exchange State Nbrs = 0,
# of Full State Nbrs = 0,
# of attached areas = 1,
# of Active areas = 0,
# of Transit areas = 0,
# of attached NSSAs = 0,
Default Route Origination = none,
Default Route Metric-Type/Metric = type2 / 1,
BFD Status = Disabled
Opaque Transit Capability = Enabled
Redistribute internal BGP routes = Disabled
sw1 (6900-A) -> show ip ospf area 0.0.0.0
Area Identifier = 0.0.0.0,

Admin Status = Enabled,
Operational Status = Down,
Area Type = normal,
Area Summary = Enabled,
Time since last SPF Run = 00h:06m:50s,
7
OSPF
# of Area Border Routers known = 0,

# of AS Border Routers known = 0,
# of Active Virtual Links = 0,
# of LSAs in area = 0,
# of SPF Calculations done = 0,
# of Incremental SPF Calculations done = 0,
# of Neighbors in Init State = 0,
# of Neighbors in 2-Way State = 0,
# of Neighbors in Exchange State = 0,
# of Neighbors in Full State = 0,
# of Interfaces attached = 0
Attached Interfaces =
- Verify that there are not any interfaces associated with the backbone area yet:
sw1 (6900-A) -> show ip ospf interface

Interface DR Backup DR Admin Oper BFD
Name Address Address Status Status State Status
---------------------+----------------+----------------+--------+------+-------+-----------
- Repeat these commands on 6860-A to check your management.
- Let’s assign the interfaces to the corresponding OSPF area. This is done in two steps. The first one is to
enable the interfaces into OSPF, and then the interfaces are assigned to their corresponding area:
sw1 (6900-A) -> ip ospf interface int_217

sw1 (6900-A) -> ip ospf interface int_217 area 0.0.0.0
sw1 (6900-A) -> ip ospf interface int_217 admin-state enable
sw1 (6900-A) -> ip ospf admin-state enable

8
OSPF
3.3. Verification
- Now that the backbone area has been created on all switches, let’s verify some basic OSPF parameters
on the 2 switches:

Router Id = 192.168.254.1,
Route Tag = 0,
# of Routes = 3,

Router Id = 192.168.254.7,
Route Tag = 0,
# of Routes = 3,
9
OSPF
- Each switch has 1 neighbours in full state meaning there have been route updates exchanged between
them.
sw1 (6900-A) -> show ip ospf area 0.0.0.0

Operational Status = Up,
Area Type = normal,
# of Interfaces attached = 1,
Attached Interfaces = int_217
Sw7 (6860-A) -> show ip ospf area 0.0.0.0

Operational Status = Up,
Area Type = normal,
# of Interfaces attached = 2,
Attached Interfaces = int_217
- Now, let’s verify the routes that are seen by each switch.
Notes
The first command shows the routes learned by the switch using any static or dynamic routing protocol. This is
the global routing table. In this example, only LOCAL and OSPF routes are present.
The second one only shows the OSPF routes learned by the switch

Total 5 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 23:50:27 LOCAL
172.16.12.0/24 172.16.12.1 23:48:39 LOCAL
172.16.17.0/24 172.16.17.1 23:48:36 LOCAL
192.168.254.1/32 192.168.254.1 18:42:00 LOCAL
192.168.254.7/32 172.16.17.7 18:31:05 OSPF
10
OSPF
sw1 (6900-A) -> show ip ospf routes
Domain Domain
Destination/Mask Gateway Metric Name ID Type
---------------------+-----------------+--------+--------+--------+----------
172.16.17.0/24 172.16.17.1 1 Vlan 217 Intra
192.168.254.1/32 0.0.0.0 0 N/A Intra
192.168.254.7/32 172.16.17.7 1 Vlan 217 Intra

Total 8 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d20h LOCAL
172.16.17.0/24 172.16.17.7 1d 0h LOCAL
172.16.78.0/24 172.16.78.7 1d23h LOCAL
192.168.20.0/24 192.168.20.7 23:51:30 LOCAL
192.168.30.0/24 192.168.30.7 20:40:51 LOCAL
192.168.70.0/24 192.168.70.7 20:08:47 LOCAL
192.168.254.1/32 172.16.17.1 19:35:34 OSPF
192.168.254.7/32 192.168.254.7 19:46:06 LOCAL

---------------------+-----------------+--------+--------+--------+----------
172.16.17.0/24 172.16.17.7 1 Vlan 217 Intra
192.168.254.1/32 172.16.17.1 1 Vlan 217 Intra
192.168.254.7/32 0.0.0.0 0 N/A Intra
- Verify that all switches Loopback0 IP addresses are in the routing table. One is LOCAL to the switch
whereas the other two are learned through OSPF.
- Also verify that all other IP interfaces that were configured are also present in the routing table as well.
- Type the following command to verify the Link State DataBase (LSDB)
sw1 (6900-A) -> show ip ospf lsdb
Area Id Type LS Id Orig Router-Id SeqNo Age

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x8000002f 824
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x8000002f 818
0.0.0.0 net 172.16.17.7 192.168.254.7 0x8000002d 818
- At this point, the LSDB should include 3 Link State Advertisements (LSA)
- There are 2 routers in the network setup. Each router sends one LSA (rtr)
- There are 1 network segments in the setup (VLANs 217)

11
OSPF
- There is a Designated Router elected on each network segment. This DR sends one LSA (net)
- Remember that the switch with the highest priority, or in case of a tie, the highest router ID will be
chosen as a Designated Router and the second highest will be the Backup DR. Let’s check the DR and
BDR status on your switch:
Interface Domain Domain DR Backup DR Admin Oper BFD

Name Name ID Address Address Status Status State Status
---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
---
int_217 Vlan 217 172.16.17.7 172.16.17.1 enabled up BDR disabled

---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
---
int_217 Vlan 217 172.16.17.7 172.16.17.1 enabled up DR disabled
- Type the following to save your running configuration as the next labs are built on this configuration.
-> write memory flash-synchro
- You can also save your running configuration in a file on the flash that will be used for the OSPF virtual
link lab.
- Type the following on all Switches:
-> configuration snapshot all save-ospf-backbone

12
OSPF
4 OSPF Areas
4.1. OSPF Areas Logical Diagram
- This second part of the lab is designed to familiarize you with the configuration of an OSPF virtual link
on an OmniSwitch. Virtual links can be used to create a virtual backbone connection on an OmniSwitch.
The idea is to split the origin OSPF Backbone by forming two different independent OSPF Backbones
and then by using the ospf virtual links, we will connect them back again.
Switch1 will be configured with a virtual link to Switch 2 and Switch 7 will be configured with another
virtual link to Switch 8. We will create two transit areas to connect the two ospf backbones.
The area 1.1.1.1 using vlan 212 between the switches 1 and 2 and the area 2.2.2.2 using the vlan 278
between the switches 7 and 8.
13
OSPF
4.2. Configuration
On the 6900-A and 6900-B create and configure Area 1.1.1.1:
sw1 (6900-A) -> ip ospf area 1.1.1.1

sw2 (6900-B) -> ip load ospf

sw2 (6900-B) -> ip interface Loopback0 address 192.168.254.2
sw2 (6900-B) -> ip router router-id 192.168.254.2
sw2 (6900-B) -> ip ospf area 1.1.1.1
sw2 (6900-B) -> ip ospf interface int_212
sw2 (6900-B) -> ip ospf interface int_212 area 1.1.1.1
sw2 (6900-B) -> ip ospf interface int_212 admin-state enable
sw2 (6900-B) -> ip ospf admin-state enable
4.3. Verification
- Verify the correct operation of the OSPF setup with the following commands:
sw1 (6900-A) -> show ip ospf area
Area Id AdminStatus Type OperStatus
---------------+-------------+-------------+------------
0.0.0.0 enabled normal up
sw2 (6900-B) -> show ip ospf area

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------
- Verify that the new routes have been learned by OSPF and are seen by switches:
14
OSPF

Total 6 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 1h LOCAL
172.16.12.0/24 172.16.12.1 1d 1h LOCAL
172.16.17.0/24 172.16.17.1 1d 1h LOCAL
192.168.254.1/32 192.168.254.1 20:45:24 LOCAL
192.168.254.2/32 172.16.12.2 00:00:41 OSPF
192.168.254.7/32 172.16.17.7 20:34:29 OSPF
sw2 (6900-B) -> show ip routes

Total 8 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d21h LOCAL
172.16.12.0/24 172.16.12.2 1d 1h LOCAL
172.16.17.0/24 172.16.12.1 00:01:17 OSPF
172.16.28.0/24 172.16.28.2 21:03:12 LOCAL
192.168.120.0/24 192.168.120.2 21:09:07 LOCAL
192.168.254.1/32 172.16.12.1 00:01:17 OSPF
192.168.254.2/32 192.168.254.2 00:03:47 LOCAL
192.168.254.7/32 172.16.12.1 00:01:17 OSPF

Total 10 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d21h LOCAL
172.16.12.0/24 172.16.17.1 00:07:47 OSPF
172.16.17.0/24 172.16.17.7 1d 1h LOCAL
172.16.78.0/24 172.16.78.7 2d 0h LOCAL
192.168.20.0/24 192.168.20.7 1d 0h LOCAL
192.168.30.0/24 192.168.30.7 21:44:22 LOCAL
192.168.70.0/24 192.168.70.7 21:12:18 LOCAL
192.168.254.1/32 172.16.17.1 20:39:05 OSPF
192.168.254.2/32 172.16.17.1 00:05:09 OSPF
192.168.254.7/32 192.168.254.7 20:49:37 LOCAL
- Verify that in the LSDB new LSAs have been added (sumnet). These LSAs have the information of the
networks that belong to a different area:

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000032 365
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000031 1201
0.0.0.0 net 172.16.17.7 192.168.254.7 0x8000002f 1201
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000003 201
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x80000002 186
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x80000004 196
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x80000002 207
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000002 196
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000001 360
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x80000002 200
15
OSPF
sw2 (6900-B) -> show ip ospf lsdb

----------------+-------+----------------+----------------+------------+-----
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x80000004 254
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x80000002 262
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000002 254
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000001 418
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x80000002 257

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000032 580
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000031 1414
0.0.0.0 net 172.16.17.7 192.168.254.7 0x8000002f 1414
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000003 415
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x80000002 400
4.4. Configuration
On the 6860-A and 6860-B create and configure Area 2.2.2.2:
sw7 (6860-A) -> ip ospf area 2.2.2.2


sw2 (6860-B) -> ip interface Loopback0 address 192.168.254.8
sw2 (6860-B) -> ip ospf area 2.2.2.2
4.5. Verification
- Verify the correct operation of the OSPF setup with the following commands:

---------------+-------------+-------------+------------
16
OSPF

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------
sw2 (6900-B) -> sh ip ospf area

---------------+-------------+-------------+------------
- Verify that the new routes have been learned by OSPF and are seen by switches:

Total 8 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 2h LOCAL
172.16.12.0/24 172.16.12.1 1d 2h LOCAL
172.16.17.0/24 172.16.17.1 1d 2h LOCAL
172.16.78.0/24 172.16.17.7 00:17:23 OSPF
192.168.254.1/32 192.168.254.1 21:15:14 LOCAL
192.168.254.2/32 172.16.12.2 00:30:31 OSPF
192.168.254.7/32 172.16.17.7 21:04:19 OSPF
192.168.254.8/32 172.16.17.7 00:14:45 OSPF

Total 10 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d22h LOCAL
172.16.12.0/24 172.16.12.2 1d 2h LOCAL
172.16.17.0/24 172.16.12.1 00:34:18 OSPF
172.16.28.0/24 172.16.28.2 21:36:13 LOCAL
172.16.78.0/24 172.16.12.1 00:21:14 OSPF
192.168.120.0/24 192.168.120.2 21:42:08 LOCAL
192.168.254.1/32 172.16.12.1 00:34:18 OSPF
192.168.254.2/32 192.168.254.2 00:36:48 LOCAL
192.168.254.7/32 172.16.12.1 00:34:18 OSPF
192.168.254.8/32 172.16.12.1 00:18:36 OSPF

Total 11 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d22h LOCAL
172.16.12.0/24 172.16.17.1 00:38:23 OSPF
172.16.17.0/24 172.16.17.7 1d 2h LOCAL
172.16.78.0/24 172.16.78.7 2d 1h LOCAL
192.168.20.0/24 192.168.20.7 1d 1h LOCAL
192.168.30.0/24 192.168.30.7 22:14:58 LOCAL
192.168.70.0/24 192.168.70.7 21:42:54 LOCAL
17
OSPF
192.168.254.1/32 172.16.17.1 21:09:41 OSPF

192.168.254.2/32 172.16.17.1 00:35:45 OSPF
192.168.254.7/32 192.168.254.7 21:20:13 LOCAL
192.168.254.8/32 172.16.78.8 00:20:00 OSPF

Total 12 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d21h LOCAL
172.16.12.0/24 172.16.78.7 00:15:35 OSPF
172.16.17.0/24 172.16.78.7 00:15:35 OSPF
172.16.28.0/24 172.16.28.8 21:33:14 LOCAL
172.16.78.0/24 172.16.78.8 2d 1h LOCAL
192.168.20.0/24 192.168.20.8 22:07:18 LOCAL
192.168.30.0/24 192.168.30.8 1d 1h LOCAL
192.168.80.0/24 192.168.80.8 21:38:05 LOCAL
192.168.254.1/32 172.16.78.7 00:15:35 OSPF
192.168.254.2/32 172.16.78.7 00:15:35 OSPF
192.168.254.7/32 172.16.78.7 00:15:35 OSPF
192.168.254.8/32 192.168.254.8 00:16:58 LOCAL

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000035 1195
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000036 290
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000033 470
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000006 1015
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000006 111
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x80000006 295
0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x80000005 111
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x80000007 1076
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x80000005 926
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000005 1076
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000004 1195
1.1.1.1 sumnet 172.16.78.0 192.168.254.1 0x80000005 115
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x80000006 295
1.1.1.1 sumnet 192.168.254.8 192.168.254.1 0x80000004 115

----------------+-------+----------------+----------------+------------+-----
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x80000007 1110
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x80000005 959
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000005 1110
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000004 1230
1.1.1.1 sumnet 172.16.78.0 192.168.254.1 0x80000005 150
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x80000006 330
1.1.1.1 sumnet 192.168.254.8 192.168.254.1 0x80000004 150

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000035 1317
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000036 411
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000033 591
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000006 1138
18
OSPF
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000006 231

0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x80000006 418
0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x80000005 231
2.2.2.2 rtr 192.168.254.7 192.168.254.7 0x80000007 137
2.2.2.2 rtr 192.168.254.8 192.168.254.8 0x80000005 100
2.2.2.2 net 172.16.78.7 192.168.254.7 0x80000005 137
2.2.2.2 sumnet 172.16.12.0 192.168.254.7 0x80000008 231
2.2.2.2 sumnet 172.16.17.0 192.168.254.7 0x80000004 411
2.2.2.2 sumnet 192.168.254.1 192.168.254.7 0x80000005 231
2.2.2.2 sumnet 192.168.254.2 192.168.254.7 0x80000008 231

----------------+-------+----------------+----------------+------------+-----
2.2.2.2 rtr 192.168.254.7 192.168.254.7 0x80000007 92
2.2.2.2 rtr 192.168.254.8 192.168.254.8 0x80000005 54
2.2.2.2 net 172.16.78.7 192.168.254.7 0x80000005 92
2.2.2.2 sumnet 172.16.12.0 192.168.254.7 0x80000008 187
2.2.2.2 sumnet 172.16.17.0 192.168.254.7 0x80000004 367
2.2.2.2 sumnet 192.168.254.1 192.168.254.7 0x80000005 187
2.2.2.2 sumnet 192.168.254.2 192.168.254.7 0x80000008 187
4.6. Virtual-link configuration (on both switches)
- With the commands above, we have created the transit areas and attached the relevant interfaces to
them. The next step is to configure the ospf virtual links using these ospf interfaces and areas.
4.6.1. Configure the backbone area on switch 6900-B and 6860-B


19
OSPF
4.6.2. Create Virtual-link
sw1 (6900-A) -> ip ospf virtual-link 1.1.1.1 192.168.254.2
- Where 192.168.254.2 is the Switch2 (6900-B) Loopback0 address, and it’s configured as the Switch2
router-id.
sw2 (6900-B) -> ip ospf virtual-link 1.1.1.1 192.168.254.1
- Where 192.168.254.1 is the Switch1 (6900-A) Loopback0 address, and it’s configured as the Switch1
router-id.
sw7 (6860-A) -> ip ospf virtual-link 2.2.2.2 192.168.254.8
- Where 192.168.254.8 is the Switch2 (6860-B) Loopback0 address, and it’s configured as the Switch8
router-id.
sw8 (6860-B) -> ip ospf virtual-link 2.2.2.2 192.168.254.7
- Where 192.168.254.7 is the Switch7 (6860-A) Loopback0 address, and it’s configured as the Switch7
router-id.
4.6.3. Verify the working of the virtual-link
sw1 (6900-A) -> show ip ospf virtual-link

State
Transit AreaId Router-id Link / Adjacency AuthType OperStatus
----------------+----------------+----------------+----------+------------
1.1.1.1 192.168.254.2 P2P / Full none up
sw2 (6900-B) -> show ip ospf virtual-link

State
----------------+----------------+----------------+----------+------------
1.1.1.1 192.168.254.1 P2P / Full none up
sw7 (6860-A) -> show ip ospf virtual-link

State
----------------+----------------+----------------+----------+------------
2.2.2.2 192.168.254.8 P2P / Full none up
sw8 (6860-B) -> show ip ospf virtual-link

State
----------------+----------------+----------------+----------+------------
2.2.2.2 192.168.254.7 P2P / Full none up
Check connectivity to all routing instances throughout the network.

---------------+-------------+-------------+------------
20
OSPF

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------

---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
---
sw2 (6900-B) -> show ip ospf interface

---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
---

---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
---
sw8 (6860-B) -> show ip ospf interface

---------------------+--------+--------+----------------+----------------+--------+------+-------+--------
sw1 (6900-A) -> show ip ospf route

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
172.16.12.0/24 172.16.12.1 1 Vlan 212 Intra
172.16.17.0/24 172.16.17.1 1 Vlan 217 Intra
172.16.28.0/24 172.16.12.2 2 Vlan 212 Intra
172.16.78.0/24 172.16.17.7 2 Vlan 217 Inter
192.168.254.1/32 0.0.0.0 0 N/A Intra
192.168.254.2/32 172.16.12.2 1 Vlan 212 Intra
192.168.254.7/32 172.16.17.7 1 Vlan 217 Intra
192.168.254.8/32 172.16.12.2 2 Vlan 212 Intra
192.168.254.8/32 172.16.17.7 2 Vlan 217 Intra
21
OSPF
sw2 (6900-B) -> show ip ospf route

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
172.16.12.0/24 172.16.12.2 1 Vlan 212 Intra
172.16.17.0/24 172.16.12.1 2 Vlan 212 Intra
172.16.28.0/24 172.16.28.2 1 Vlan 228 Intra
172.16.78.0/24 172.16.28.8 2 Vlan 228 Inter
192.168.254.1/32 172.16.12.1 1 Vlan 212 Intra
192.168.254.2/32 0.0.0.0 0 N/A Intra
192.168.254.7/32 172.16.12.1 2 Vlan 212 Intra
192.168.254.7/32 172.16.28.8 2 Vlan 228 Intra
192.168.254.8/32 172.16.28.8 1 Vlan 228 Intra
sw7 (6860-A) -> show ip ospf route

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
172.16.12.0/24 172.16.17.1 2 Vlan 217 Inter
172.16.17.0/24 172.16.17.7 1 Vlan 217 Intra
172.16.28.0/24 172.16.78.8 2 Vlan 278 Intra
172.16.78.0/24 172.16.78.7 1 Vlan 278 Intra
192.168.254.1/32 172.16.17.1 1 Vlan 217 Intra
192.168.254.2/32 172.16.78.8 2 Vlan 278 Intra
192.168.254.2/32 172.16.17.1 2 Vlan 217 Intra
192.168.254.7/32 0.0.0.0 0 N/A Intra
192.168.254.8/32 172.16.78.8 1 Vlan 278 Intra
sw8 (6860-B) -> show ip ospf route

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
172.16.12.0/24 172.16.28.2 2 Vlan 228 Inter
172.16.17.0/24 172.16.78.7 2 Vlan 278 Intra
172.16.28.0/24 172.16.28.8 1 Vlan 228 Intra
172.16.78.0/24 172.16.78.8 1 Vlan 278 Intra
192.168.254.1/32 172.16.78.7 2 Vlan 278 Intra
192.168.254.1/32 172.16.28.2 2 Vlan 228 Intra
192.168.254.2/32 172.16.28.2 1 Vlan 228 Intra
192.168.254.7/32 172.16.78.7 1 Vlan 278 Intra
192.168.254.8/32 0.0.0.0 0 N/A Intra

Total 10 routes
------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 4h LOCAL
172.16.12.0/24 172.16.12.1 1d 4h LOCAL
172.16.17.0/24 172.16.17.1 1d 4h LOCAL
172.16.28.0/24 172.16.12.2 00:06:59 OSPF
172.16.78.0/24 172.16.17.7 02:14:28 OSPF
192.168.254.1/32 192.168.254.1 23:12:19 LOCAL
192.168.254.2/32 172.16.12.2 02:27:36 OSPF
192.168.254.7/32 172.16.17.7 23:01:24 OSPF
192.168.254.8/32 +172.16.12.2 00:06:12 OSPF
+172.16.17.7 02:11:50 OSPF
22
OSPF

Total 11 routes
------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d23h LOCAL
172.16.12.0/24 172.16.12.2 1d 4h LOCAL
172.16.17.0/24 172.16.12.1 00:31:41 OSPF
172.16.28.0/24 172.16.28.2 23:30:12 LOCAL
172.16.78.0/24 172.16.28.8 00:06:52 OSPF
192.168.120.0/24 192.168.120.2 23:36:07 LOCAL
192.168.254.1/32 172.16.12.1 02:28:17 OSPF
192.168.254.2/32 192.168.254.2 02:30:47 LOCAL
192.168.254.7/32 +172.16.12.1 00:31:41 OSPF
+172.16.28.8 00:06:52 OSPF
192.168.254.8/32 172.16.28.8 00:06:52 OSPF
sw7 (6860-A) -> sh ip routes

Total 13 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d23h LOCAL
172.16.12.0/24 172.16.17.1 02:31:16 OSPF
172.16.17.0/24 172.16.17.7 1d 4h LOCAL
172.16.28.0/24 172.16.78.8 00:07:15 OSPF
172.16.78.0/24 172.16.78.7 2d 3h LOCAL
192.168.20.0/24 192.168.20.7 1d 3h LOCAL
192.168.30.0/24 192.168.30.7 1d 0h LOCAL
192.168.70.0/24 192.168.70.7 23:35:47 LOCAL
192.168.254.1/32 172.16.17.1 23:02:34 OSPF
192.168.254.2/32 +172.16.17.1 02:28:38 OSPF
+172.16.78.8 00:07:15 OSPF
192.168.254.7/32 192.168.254.7 23:13:06 LOCAL
192.168.254.8/32 172.16.78.8 02:12:53 OSPF
sw8 (6860-B) -> sh ip routes

Total 13 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 5d23h LOCAL
172.16.12.0/24 172.16.28.2 00:07:30 OSPF
172.16.17.0/24 172.16.78.7 00:28:57 OSPF
172.16.28.0/24 172.16.28.8 23:30:43 LOCAL
172.16.78.0/24 172.16.78.8 2d 3h LOCAL
192.168.20.0/24 192.168.20.8 1d 0h LOCAL
192.168.30.0/24 192.168.30.8 1d 3h LOCAL
192.168.80.0/24 192.168.80.8 23:35:34 LOCAL
192.168.254.1/32 +172.16.28.2 00:07:30 OSPF
+172.16.78.7 00:28:57 OSPF
192.168.254.2/32 172.16.28.2 00:07:30 OSPF
192.168.254.7/32 172.16.78.7 02:13:04 OSPF
192.168.254.8/32 192.168.254.8 02:14:27 LOCAL
23
OSPF
4.7. Let’s add VLANs 20 and 30 into our OSPF network in Area 3.3.3.3
4.8. On the 6860s create and configure Area 3.3.3.3:

sw7 (6860-A) -> ip ospf area 3.3.3.3
sw8 (6860-B) -> ip ospf area 3.3.3.3

24
OSPF
4.9. Verify the correct operation of the OSPF setup with the following commands:
---------------+-------------+-------------+------------

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------

---------------+-------------+-------------+------------
- Verify that the new routes have been learned by OSPF and are seen by all switches:

Total 12 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 4h LOCAL
172.16.12.0/24 172.16.12.1 1d 4h LOCAL
172.16.17.0/24 172.16.17.1 1d 4h LOCAL
172.16.28.0/24 172.16.12.2 00:27:15 OSPF
172.16.78.0/24 172.16.17.7 02:34:44 OSPF
192.168.20.0/24 172.16.17.7 00:05:47 OSPF
192.168.30.0/24 172.16.17.7 00:05:32 OSPF
192.168.254.1/32 192.168.254.1 23:32:35 LOCAL
192.168.254.2/32 172.16.12.2 02:47:52 OSPF
192.168.254.7/32 172.16.17.7 23:21:40 OSPF
192.168.254.8/32 +172.16.12.2 00:26:28 OSPF
+172.16.17.7 02:32:06 OSPF

Total 13 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.12.2 1d 4h LOCAL
172.16.17.0/24 172.16.12.1 00:52:02 OSPF
172.16.28.0/24 172.16.28.2 23:50:33 LOCAL
172.16.78.0/24 172.16.28.8 00:27:13 OSPF
192.168.20.0/24 172.16.28.8 00:06:37 OSPF
192.168.30.0/24 172.16.28.8 00:06:23 OSPF

192.168.120.0/24 192.168.120.2 23:56:28 LOCAL
25
OSPF
192.168.254.1/32 172.16.12.1 02:48:38 OSPF

192.168.254.2/32 192.168.254.2 02:51:08 LOCAL
192.168.254.7/32 +172.16.12.1 00:52:02 OSPF
+172.16.28.8 00:27:13 OSPF
192.168.254.8/32 172.16.28.8 00:27:13 OSP

Total 13 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.17.1 02:51:51 OSPF
172.16.17.0/24 172.16.17.7 1d 4h LOCAL
172.16.28.0/24 172.16.78.8 00:27:50 OSPF
172.16.78.0/24 172.16.78.7 2d 3h LOCAL
192.168.20.0/24 192.168.20.7 1d 3h LOCAL
192.168.30.0/24 192.168.30.7 1d 0h LOCAL
192.168.70.0/24 192.168.70.7 23:56:22 LOCAL
192.168.254.1/32 172.16.17.1 23:23:09 OSPF
192.168.254.2/32 +172.16.17.1 02:49:13 OSPF
+172.16.78.8 00:27:50 OSPF
192.168.254.7/32 192.168.254.7 23:33:41 LOCAL
192.168.254.8/32 172.16.78.8 02:33:28 OSPF

Total 13 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.28.2 00:28:21 OSPF
172.16.17.0/24 172.16.78.7 00:49:48 OSPF
172.16.28.0/24 172.16.28.8 23:51:34 LOCAL
172.16.78.0/24 172.16.78.8 2d 3h LOCAL
192.168.20.0/24 192.168.20.8 1d 0h LOCAL
192.168.30.0/24 192.168.30.8 1d 3h LOCAL
192.168.80.0/24 192.168.80.8 23:56:25 LOCAL
192.168.254.1/32 +172.16.28.2 00:28:21 OSPF
+172.16.78.7 00:49:48 OSPF
192.168.254.2/32 172.16.28.2 00:28:21 OSPF
192.168.254.7/32 172.16.78.7 02:33:55 OSPF
192.168.254.8/32 192.168.254.8 02:35:18 LOCAL

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000039 1522
0.0.0.0 rtr 192.168.254.2 192.168.254.2 0x80000007 14
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000039 1337
0.0.0.0 rtr 192.168.254.8 192.168.254.8 0x80000004 1757
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000035 1517
0.0.0.0 net 172.16.28.2 192.168.254.2 0x80000003 14
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000009 442
0.0.0.0 sumnet 172.16.12.0 192.168.254.2 0x80000002 1614
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000008 1158
0.0.0.0 sumnet 172.16.78.0 192.168.254.8 0x80000002 1387
0.0.0.0 sumnet 192.168.20.0 192.168.254.7 0x80000003 373
0.0.0.0 sumnet 192.168.20.0 192.168.254.8 0x80000003 348
26
OSPF
0.0.0.0 sumnet 192.168.30.0 192.168.254.7 0x80000003 373

0.0.0.0 sumnet 192.168.30.0 192.168.254.8 0x80000002 380
0.0.0.0 sumnet 192.168.254.1 192.168.254.2 0x80000004 1747
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x8000000d 82
0.0.0.0 sumnet 192.168.254.7 192.168.254.8 0x80000005 504
0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x8000000c 514
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x8000000b 1583
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x80000009 1613
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000008 503
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000007 622
1.1.1.1 sumnet 172.16.17.0 192.168.254.2 0x80000002 1614
1.1.1.1 sumnet 172.16.28.0 192.168.254.1 0x80000003 82
1.1.1.1 sumnet 172.16.28.0 192.168.254.2 0x80000003 1748
1.1.1.1 sumnet 172.16.78.0 192.168.254.1 0x80000010 82
1.1.1.1 sumnet 172.16.78.0 192.168.254.2 0x80000009 1737
1.1.1.1 sumnet 192.168.20.0 192.168.254.1 0x80000002 417
1.1.1.1 sumnet 192.168.20.0 192.168.254.2 0x80000002 418
1.1.1.1 sumnet 192.168.30.0 192.168.254.1 0x80000002 417
1.1.1.1 sumnet 192.168.30.0 192.168.254.2 0x80000002 418
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x8000000c 82
1.1.1.1 sumnet 192.168.254.7 192.168.254.2 0x80000007 1737
1.1.1.1 sumnet 192.168.254.8 192.168.254.1 0x8000000b 82
1.1.1.1 sumnet 192.168.254.8 192.168.254.2 0x80000007 1737

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x80000039 1614
0.0.0.0 rtr 192.168.254.2 192.168.254.2 0x80000007 105
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000039 1429
0.0.0.0 rtr 192.168.254.8 192.168.254.8 0x80000005 89
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000035 1609
0.0.0.0 net 172.16.28.2 192.168.254.2 0x80000003 105
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000009 535
0.0.0.0 sumnet 172.16.12.0 192.168.254.2 0x80000003 84
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000008 1250
0.0.0.0 sumnet 172.16.78.0 192.168.254.8 0x80000002 1478
0.0.0.0 sumnet 192.168.20.0 192.168.254.7 0x80000003 530
0.0.0.0 sumnet 192.168.20.0 192.168.254.8 0x80000003 503
0.0.0.0 sumnet 192.168.30.0 192.168.254.7 0x80000003 530
0.0.0.0 sumnet 192.168.30.0 192.168.254.8 0x80000002 535
0.0.0.0 sumnet 192.168.254.1 192.168.254.2 0x80000005 84
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x8000000d 175
0.0.0.0 sumnet 192.168.254.7 192.168.254.8 0x80000005 595
0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x8000000c 606
1.1.1.1 rtr 192.168.254.1 192.168.254.1 0x8000000c 55
1.1.1.1 rtr 192.168.254.2 192.168.254.2 0x8000000a 84
1.1.1.1 net 172.16.12.1 192.168.254.1 0x80000008 595
1.1.1.1 sumnet 172.16.17.0 192.168.254.1 0x80000007 715
1.1.1.1 sumnet 172.16.17.0 192.168.254.2 0x80000003 84
1.1.1.1 sumnet 172.16.28.0 192.168.254.1 0x80000003 175
1.1.1.1 sumnet 172.16.28.0 192.168.254.2 0x80000004 84
1.1.1.1 sumnet 172.16.78.0 192.168.254.1 0x80000010 175
1.1.1.1 sumnet 172.16.78.0 192.168.254.2 0x8000000a 84
1.1.1.1 sumnet 192.168.20.0 192.168.254.1 0x80000002 573
1.1.1.1 sumnet 192.168.20.0 192.168.254.2 0x80000002 573
1.1.1.1 sumnet 192.168.30.0 192.168.254.1 0x80000002 573
1.1.1.1 sumnet 192.168.30.0 192.168.254.2 0x80000002 573
1.1.1.1 sumnet 192.168.254.7 192.168.254.1 0x8000000c 175
1.1.1.1 sumnet 192.168.254.7 192.168.254.2 0x80000008 84
1.1.1.1 sumnet 192.168.254.8 192.168.254.1 0x8000000b 175
1.1.1.1 sumnet 192.168.254.8 192.168.254.2 0x80000008 84
27
OSPF

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x8000003a 62
0.0.0.0 rtr 192.168.254.2 192.168.254.2 0x80000007 174
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000039 1496
0.0.0.0 rtr 192.168.254.8 192.168.254.8 0x80000005 157
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000036 56
0.0.0.0 net 172.16.28.2 192.168.254.2 0x80000003 174
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000009 603
0.0.0.0 sumnet 172.16.12.0 192.168.254.2 0x80000003 154
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000008 1316
0.0.0.0 sumnet 172.16.78.0 192.168.254.8 0x80000002 1546
0.0.0.0 sumnet 192.168.20.0 192.168.254.7 0x80000003 627
0.0.0.0 sumnet 192.168.20.0 192.168.254.8 0x80000003 601
0.0.0.0 sumnet 192.168.30.0 192.168.254.7 0x80000003 627
0.0.0.0 sumnet 192.168.30.0 192.168.254.8 0x80000002 633
0.0.0.0 sumnet 192.168.254.1 192.168.254.2 0x80000005 154
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x8000000d 243
0.0.0.0 sumnet 192.168.254.7 192.168.254.8 0x80000005 663
0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x8000000c 673
2.2.2.2 rtr 192.168.254.7 192.168.254.7 0x8000000a 1582
2.2.2.2 rtr 192.168.254.8 192.168.254.8 0x80000008 1545
2.2.2.2 net 172.16.78.7 192.168.254.7 0x80000007 1222
2.2.2.2 sumnet 172.16.12.0 192.168.254.7 0x80000017 629
2.2.2.2 sumnet 172.16.12.0 192.168.254.8 0x8000000b 619
2.2.2.2 sumnet 172.16.17.0 192.168.254.7 0x80000006 1496
2.2.2.2 sumnet 172.16.17.0 192.168.254.8 0x80000002 1546
2.2.2.2 sumnet 172.16.28.0 192.168.254.7 0x80000003 236
2.2.2.2 sumnet 172.16.28.0 192.168.254.8 0x80000003 286
2.2.2.2 sumnet 192.168.20.0 192.168.254.7 0x80000003 627
2.2.2.2 sumnet 192.168.20.0 192.168.254.8 0x80000003 601
2.2.2.2 sumnet 192.168.30.0 192.168.254.7 0x80000003 627
2.2.2.2 sumnet 192.168.30.0 192.168.254.8 0x80000002 633
2.2.2.2 sumnet 192.168.254.1 192.168.254.7 0x8000000b 674
2.2.2.2 sumnet 192.168.254.1 192.168.254.8 0x80000005 664
2.2.2.2 sumnet 192.168.254.2 192.168.254.7 0x8000000e 674
2.2.2.2 sumnet 192.168.254.2 192.168.254.8 0x80000005 664
3.3.3.3 rtr 192.168.254.7 192.168.254.7 0x80000002 639
3.3.3.3 sumnet 172.16.12.0 192.168.254.7 0x80000017 629
3.3.3.3 sumnet 172.16.17.0 192.168.254.7 0x80000006 1496
3.3.3.3 sumnet 172.16.28.0 192.168.254.7 0x80000003 236
3.3.3.3 sumnet 172.16.78.0 192.168.254.7 0x80000008 1316
3.3.3.3 net 192.168.30.8 192.168.254.8 0x80000002 607
3.3.3.3 sumnet 192.168.254.1 192.168.254.7 0x8000000b 674
3.3.3.3 sumnet 192.168.254.2 192.168.254.7 0x8000000e 674
3.3.3.3 sumnet 192.168.254.8 192.168.254.7 0x8000000c 673

----------------+-------+----------------+----------------+------------+-----
0.0.0.0 rtr 192.168.254.1 192.168.254.1 0x8000003a 164
0.0.0.0 rtr 192.168.254.2 192.168.254.2 0x80000007 275
0.0.0.0 rtr 192.168.254.7 192.168.254.7 0x80000039 1598
0.0.0.0 rtr 192.168.254.8 192.168.254.8 0x80000005 258
0.0.0.0 net 172.16.17.7 192.168.254.7 0x80000036 158
0.0.0.0 net 172.16.28.2 192.168.254.2 0x80000003 275
0.0.0.0 sumnet 172.16.12.0 192.168.254.1 0x80000009 705
0.0.0.0 sumnet 172.16.12.0 192.168.254.2 0x80000003 255
0.0.0.0 sumnet 172.16.78.0 192.168.254.7 0x80000008 1419
0.0.0.0 sumnet 172.16.78.0 192.168.254.8 0x80000003 26
0.0.0.0 sumnet 192.168.20.0 192.168.254.7 0x80000003 810
0.0.0.0 sumnet 192.168.20.0 192.168.254.8 0x80000003 783
0.0.0.0 sumnet 192.168.30.0 192.168.254.7 0x80000003 810
0.0.0.0 sumnet 192.168.30.0 192.168.254.8 0x80000002 815
0.0.0.0 sumnet 192.168.254.1 192.168.254.2 0x80000005 255
0.0.0.0 sumnet 192.168.254.2 192.168.254.1 0x8000000d 345
28
OSPF
0.0.0.0 sumnet 192.168.254.7 192.168.254.8 0x80000005 764

0.0.0.0 sumnet 192.168.254.8 192.168.254.7 0x8000000c 775
2.2.2.2 rtr 192.168.254.7 192.168.254.7 0x8000000b 64
2.2.2.2 rtr 192.168.254.8 192.168.254.8 0x80000009 26
2.2.2.2 net 172.16.78.7 192.168.254.7 0x80000007 1324
2.2.2.2 sumnet 172.16.12.0 192.168.254.7 0x80000017 731
2.2.2.2 sumnet 172.16.12.0 192.168.254.8 0x8000000b 720
2.2.2.2 sumnet 172.16.17.0 192.168.254.7 0x80000006 1599
2.2.2.2 sumnet 172.16.17.0 192.168.254.8 0x80000003 26
2.2.2.2 sumnet 172.16.28.0 192.168.254.7 0x80000003 339
2.2.2.2 sumnet 172.16.28.0 192.168.254.8 0x80000003 386
2.2.2.2 sumnet 192.168.20.0 192.168.254.7 0x80000003 810
2.2.2.2 sumnet 192.168.20.0 192.168.254.8 0x80000003 783
2.2.2.2 sumnet 192.168.30.0 192.168.254.7 0x80000003 810
2.2.2.2 sumnet 192.168.30.0 192.168.254.8 0x80000002 815
2.2.2.2 sumnet 192.168.254.1 192.168.254.7 0x8000000b 776
2.2.2.2 sumnet 192.168.254.1 192.168.254.8 0x80000005 765
2.2.2.2 sumnet 192.168.254.2 192.168.254.7 0x8000000e 776
2.2.2.2 sumnet 192.168.254.2 192.168.254.8 0x80000005 765
3.3.3.3 rtr 192.168.254.8 192.168.254.8 0x80000002 730
3.3.3.3 sumnet 172.16.12.0 192.168.254.8 0x8000000b 720
3.3.3.3 sumnet 172.16.17.0 192.168.254.8 0x80000003 26
3.3.3.3 sumnet 172.16.28.0 192.168.254.8 0x80000003 386
3.3.3.3 sumnet 172.16.78.0 192.168.254.8 0x80000003 26
3.3.3.3 net 192.168.30.8 192.168.254.8 0x80000002 788
3.3.3.3 sumnet 192.168.254.1 192.168.254.8 0x80000005 765
3.3.3.3 sumnet 192.168.254.2 192.168.254.8 0x80000005 765
3.3.3.3 sumnet 192.168.254.7 192.168.254.8 0x80000005 764
5 OSPF Redistribution
- It was demonstrated in the two previous parts of the lab how interfaces running OSPF participate in
distributing routing information within the Autonomous System.
- In this part we will manage the other interfaces. For example , int_120 on 6900_B, int_70 on 6860-A
and int_80 on 6860-B are seen are local routes. However, they will not run the OSPF protocol. For
them to be reachable, redistribution will need to be configured.
- To advertise its route, enter:
sw2 (6900-B) -> ip route-map localIntoOspf sequence-number 10 action permit

sw2 (6900-B) -> ip route-map localIntoOspf sequence-number 10 match ip-address 192.168.120.0/24 permit
sw2 (6900-B) -> ip redist local into ospf route-map localIntoOspf admin-state enable
- Check on the 6860 than this new route has been learnt:

Total 13 routes
------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 5h LOCAL
172.16.12.0/24 172.16.12.1 1d 5h LOCAL
172.16.17.0/24 172.16.17.1 1d 5h LOCAL
172.16.28.0/24 172.16.12.2 00:57:07 OSPF
172.16.78.0/24 172.16.17.7 03:04:36 OSPF
192.168.20.0/24 172.16.17.7 00:35:39 OSPF
192.168.30.0/24 172.16.17.7 00:35:24 OSPF
192.168.120.0/24 172.16.12.2 00:01:25 OSPF
192.168.254.1/32 192.168.254.1 1d 0h LOCAL
192.168.254.2/32 172.16.12.2 03:17:44 OSPF
192.168.254.7/32 172.16.17.7 23:51:32 OSPF
192.168.254.8/32 +172.16.12.2 00:56:20 OSPF
+172.16.17.7 03:01:58 OSPF
29
OSPF

Total 15 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.17.1 03:19:34 OSPF
172.16.17.0/24 172.16.17.7 1d 5h LOCAL
172.16.28.0/24 172.16.78.8 00:55:33 OSPF
172.16.78.0/24 172.16.78.7 2d 3h LOCAL
192.168.20.0/24 192.168.20.7 1d 4h LOCAL
192.168.30.0/24 192.168.30.7 1d 0h LOCAL
192.168.70.0/24 192.168.70.7 1d 0h LOCAL
192.168.120.0/24 +172.16.17.1 00:00:37 OSPF
+172.16.78.8 00:00:37 OSPF
192.168.254.1/32 172.16.17.1 23:50:52 OSPF
192.168.254.2/32 +172.16.17.1 03:16:56 OSPF
+172.16.78.8 00:55:33 OSPF
192.168.254.7/32 192.168.254.7 1d 0h LOCAL
192.168.254.8/32 172.16.78.8 03:01:11 OSPF

Total 14 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.28.2 00:57:01 OSPF
172.16.17.0/24 172.16.78.7 01:18:28 OSPF
172.16.28.0/24 172.16.28.8 1d 0h LOCAL
172.16.78.0/24 172.16.78.8 2d 3h LOCAL
192.168.20.0/24 192.168.20.8 1d 0h LOCAL
192.168.30.0/24 192.168.30.8 1d 4h LOCAL
192.168.80.0/24 192.168.80.8 1d 0h LOCAL
192.168.120.0/24 172.16.28.2 00:02:07 OSPF
192.168.254.1/32 +172.16.28.2 00:57:01 OSPF
+172.16.78.7 01:18:28 OSPF
192.168.254.2/32 172.16.28.2 00:57:01 OSPF
192.168.254.7/32 172.16.78.7 03:02:35 OSPF
192.168.254.8/32 192.168.254.8 03:03:58 LOCAL
- Vlan 70 is not known by other switches except the 6860-A

- Vlan 80 is not known by other switches except the 6860-B
- to advertise these routes, enter:
sw7 (6860-A) -> ip route-map localIntoOspf sequence-number 10 action permit

sw7 (6860-A) -> ip route-map localIntoOspf sequence-number 10 match ip-address 192.168.70.0/24 permit
sw7 (6860-A) -> ip redist local into ospf route-map localIntoOspf admin-state enable
sw8 (6860-B) -> ip route-map localIntoOspf sequence-number 10 action permit

sw8 (6860-B) -> ip route-map localIntoOspf sequence-number 10 match ip-address 192.168.80.0/24 permit
sw8 (6860-B) -> ip redist local into ospf route-map localIntoOspf admin-state enable
30
OSPF
- Check on the 6900 than this new route has been learnt:

Total 16 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 5h LOCAL
172.16.12.0/24 172.16.12.1 1d 5h LOCAL
172.16.17.0/24 172.16.17.1 1d 5h LOCAL
172.16.28.0/24 172.16.12.2 01:01:25 OSPF
172.16.78.0/24 172.16.17.7 03:08:54 OSPF
192.168.20.0/24 172.16.17.7 00:39:57 OSPF
192.168.30.0/24 +172.16.17.7 00:39:42 OSPF
192.168.70.0/24 172.16.17.7 00:01:49 OSPF
192.168.80.0/24 +172.16.12.2 00:01:20 OSPF
+172.16.17.7 00:01:20 OSPF
192.168.120.0/24 172.16.12.2 00:05:43 OSPF
192.168.254.1/32 192.168.254.1 1d 0h LOCAL
192.168.254.2/32 172.16.12.2 03:22:02 OSPF

Total 16 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 6d 0h LOCAL
172.16.12.0/24 172.16.12.2 1d 5h LOCAL
172.16.17.0/24 172.16.12.1 01:25:56 OSPF
172.16.28.0/24 172.16.28.2 1d 0h LOCAL
172.16.78.0/24 172.16.28.8 01:01:07 OSPF
192.168.20.0/24 +172.16.28.8 00:40:31 OSPF
192.168.30.0/24 172.16.28.8 00:40:17 OSPF
192.168.70.0/24 +172.16.12.1 00:02:24 OSPF
+172.16.28.8 00:02:24 OSPF
192.168.80.0/24 172.16.28.8 00:01:56 OSPF
192.168.120.0/24 192.168.120.2 1d 0h LOCAL
192.168.254.1/32 172.16.12.1 03:22:32 OSPF
192.168.254.2/32 192.168.254.2 03:25:02 LOCAL
192.168.254.7/32 +172.16.12.1 01:25:56 OSPF
+172.16.28.8 01:01:07 OSPF
192.168.254.8/32 172.16.28.8 01:01:07 OSPF
- Interfaces should be enabled to see them on routing table
sw8 (6860-B) -> interface 1/1/1 admin-state enable

31
OSPF
6 Access to the DATA server
- To have an Internet access for VM clients, a pre-configuration must be done on the OS6900-A
- Manage a VLAN 100 and associated interface on 6900-A
sw1 (6900-A) -> vlan 100

- to advertise this route, enter:
sw1 (6900-A) -> ip route-map localIntoOspf sequence-number 10 action permit

sw1 (6900-A) -> ip redist local into ospf route-map localIntoOspf admin-state enable
- Default route 0.0.0.0/0 on 6900-A is a static route which should be advertised to other switch
Manage a Redistribution of Static routes
sw1 (6900-A) -> ip static-route 0.0.0.0/0 gateway 192.168.100.108

Total 19 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 192.168.100.108 00:00:09 STATIC
10.0.0.51/32 192.168.100.108 00:02:18 STATIC
127.0.0.1/32 127.0.0.1 1d 5h LOCAL
172.16.12.0/24 172.16.12.1 1d 5h LOCAL
172.16.17.0/24 172.16.17.1 1d 5h LOCAL
172.16.28.0/24 172.16.12.2 01:07:37 OSPF
+172.16.17.7 03:12:28 OSPF
----| truncated]
32
OSPF
Notes
The second static route has been managed previously on the conf download to the switch at the beginning of
the training. 10.0.0.51 is the IP address of the DNS.
- The previous section showed how to redistribute a local route. The same can be applied to a static
route.
- To redistribute the static route into OSPF another filter must be created since static routes are not
considered part of the OSPF Autonomous System. Type the following:
sw1 (6900-A) -> ip route-map staticIntoOspf sequence-number 10 action permit

sw1 (6900-A) -> ip route-map staticIntoOspf sequence-number 10 match ip-address 0.0.0.0/0 permit
sw1 (6900-A) -> ip redist static into ospf route-map staticIntoOspf admin-state enable
- Check the result on 6900-B and 6860’s
sw2 (6900-B) -> show ip ospf routes

---------------------+-----------------+--------+--------+--------+----------
0.0.0.0/0 172.16.12.1 1 Vlan 212 AS-Ext (E2)
10.0.0.51/32 172.16.12.1 1 Vlan 212 AS-Ext (E2)
172.16.12.0/24 172.16.12.2 1 Vlan 212 Intra
172.16.17.0/24 172.16.12.1 2 Vlan 212 Intra
172.16.28.0/24 172.16.28.2 1 Vlan 228 Intra
172.16.78.0/24 172.16.28.8 2 Vlan 228 Inter
192.168.20.0/24 172.16.28.8 2 Vlan 228 Inter
192.168.30.0/24 172.16.28.8 2 Vlan 228 Inter
192.168.70.0/24 172.16.12.1 2 Vlan 212 AS-Ext (E2)
192.168.70.0/24 172.16.28.8 2 Vlan 228 AS-Ext (E2)
192.168.80.0/24 172.16.28.8 1 Vlan 228 AS-Ext (E2)
192.168.100.0/24 172.16.12.1 1 Vlan 212 AS-Ext (E2)
192.168.254.1/32 172.16.12.1 1 Vlan 212 Intra
192.168.254.2/32 0.0.0.0 0 N/A Intra
192.168.254.7/32 172.16.12.1 2 Vlan 212 Intra
192.168.254.7/32 172.16.28.8 2 Vlan 228 Intra
192.168.254.8/32 172.16.28.8 1 Vlan 228 Intra

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
0.0.0.0/0 172.16.17.1 1 Vlan 217 AS-Ext (E2)
10.0.0.51/32 172.16.17.1 1 Vlan 217 AS-Ext (E2)
172.16.12.0/24 172.16.17.1 2 Vlan 217 Inter
172.16.17.0/24 172.16.17.7 1 Vlan 217 Intra
172.16.28.0/24 172.16.78.8 2 Vlan 278 Intra
172.16.78.0/24 172.16.78.7 1 Vlan 278 Intra
192.168.20.0/24 192.168.20.7 1 Vlan 20 Intra
192.168.30.0/24 192.168.30.7 1 Vlan 30 Intra
192.168.80.0/24 192.168.30.8 1 Vlan 30 AS-Ext (E2)
192.168.100.0/24 172.16.17.1 1 Vlan 217 AS-Ext (E2)
192.168.120.0/24 172.16.78.8 2 Vlan 278 AS-Ext (E2)
192.168.120.0/24 172.16.17.1 2 Vlan 217 AS-Ext (E2)
192.168.254.1/32 172.16.17.1 1 Vlan 217 Intra
192.168.254.2/32 172.16.78.8 2 Vlan 278 Intra
192.168.254.2/32 172.16.17.1 2 Vlan 217 Intra
192.168.254.7/32 0.0.0.0 0 N/A Intra
192.168.254.8/32 172.16.78.8 1 Vlan 278 Intra
33
OSPF
sw8 (6860-B) -> show ip ospf routes

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
0.0.0.0/0 172.16.78.7 2 Vlan 278 AS-Ext (E2)
0.0.0.0/0 172.16.28.2 2 Vlan 228 AS-Ext (E2)
10.0.0.51/32 172.16.78.7 2 Vlan 278 AS-Ext (E2)
10.0.0.51/32 172.16.28.2 2 Vlan 228 AS-Ext (E2)
172.16.12.0/24 172.16.28.2 2 Vlan 228 Inter
172.16.17.0/24 172.16.78.7 2 Vlan 278 Intra
172.16.28.0/24 172.16.28.8 1 Vlan 228 Intra
172.16.78.0/24 172.16.78.8 1 Vlan 278 Intra
192.168.20.0/24 192.168.20.8 1 Vlan 20 Intra
192.168.30.0/24 192.168.30.8 1 Vlan 30 Intra
192.168.70.0/24 192.168.30.7 1 Vlan 30 AS-Ext (E2)
192.168.100.0/24 172.16.78.7 2 Vlan 278 AS-Ext (E2)
192.168.100.0/24 172.16.28.2 2 Vlan 228 AS-Ext (E2)
192.168.120.0/24 172.16.28.2 1 Vlan 228 AS-Ext (E2)
192.168.254.1/32 172.16.78.7 2 Vlan 278 Intra
192.168.254.1/32 172.16.28.2 2 Vlan 228 Intra
192.168.254.2/32 172.16.28.2 1 Vlan 228 Intra
192.168.254.7/32 172.16.78.7 1 Vlan 278 Intra
192.168.254.8/32 0.0.0.0 0 N/A Intra
- The pfsense server has been configured with Rip protocol.

- Manage RIP dynamic protocol on 6900 (int_100). And then let’s redistribute local route and static routes
to rip.
sw1 (6900-A) -> ip load rip

sw1 (6900-A) -> ip rip interface int_100 admin-state enable
sw1 (6900-A) -> ip rip admin-state enable
sw1 (6900-A) -> ip route-map local sequence-number 10 action permit
sw1 (6900-A) -> ip route-map local sequence-number 10 match ip-address 0.0.0.0/0 permit
sw1 (6900-A) -> ip redist local into rip route-map local admin-state enable
sw1 (6900-A) -> ip redist static into rip route-map local admin-state enable
sw1 (6900-A) -> ip redist ospf into rip route-map local admin-state enable
- Check the result on 6900-A
sw1 (6900-A) -> show ip rip routes

Legends: State: A = Active, H = Holddown, G = Garbage
Destination Gateway State Metric Proto
------------------+-----------------+----+------+------
0.0.0.0/0 +192.168.100.108 A 1 Redist
10.0.0.51/32 +192.168.100.108 A 1 Redist
10.4.21.0/24 +192.168.100.108 A 2 Rip
172.16.12.0/24 +172.16.12.1 A 1 Redist
172.16.17.0/24 +172.16.17.1 A 1 Redist
172.16.28.0/24 +172.16.12.2 A 1 Redist
172.16.78.0/24 +172.16.17.7 A 1 Redist
192.168.20.0/24 +172.16.17.7 A 1 Redist
192.168.30.0/24 +172.16.17.7 A 1 Redist
192.168.70.0/24 +172.16.17.7 A 1 Redist
192.168.80.0/24 +172.16.12.2 A 1 Redist
192.168.100.0/24 +192.168.100.1 A 1 Redist
192.168.100.108 A 2 Rip
192.168.120.0/24 +172.16.12.2 A 1 Redist
192.168.254.1/32 +192.168.254.1 A 1 Redist
192.168.254.2/32 +172.16.12.2 A 1 Redist
192.168.254.7/32 +172.16.17.7 A 1 Redist
192.168.254.8/32 +172.16.12.2 A 1 Redist
34
OSPF
7 OSPF Authentication
7.1. Simple Authentication

- Let’s enable simple authentication between 6900-A and 6860-A.
sw1 (6900-A) -> show ip ospf neighbor
Domain Domain
IP Address Area Id Router Id Name ID State Type
----------------+----------------+----------------+--------+--------+-------+--------
172.16.12.2 1.1.1.1 192.168.254.2 Vlan 212 Full Dynamic
sw1 (6900-A) -> ip ospf interface int_217 auth-type simple

sw1 (6900-A) -> ip ospf interface int_217 auth-key alcatel

Thu Jan 30 01:18:12 : ospf_0 AUTH ERR message:
+++ ospfAuthCheck: Intf 172.16.17.1: Auth type 1 mismatch! recvd pkt = (0)
Domain Domain
----------------+----------------+----------------+--------+--------+-------+--------
sw7 (6860-A) -> ip ospf interface int_217 auth-type simple

sw7 (6860-A) -> ip ospf interface int_217 auth-key alcatel
sw7 (6860-A) -> show ip ospf interface int_217
…
Authentication Type = simple,
Authentication Key = Set,
- Verify that the switches have become neighbors once authentication was enabled on both ends of the
link

Domain Domain
----------------+----------------+----------------+--------+--------+-------+--------
7.2. MD5 Authentication
MD5 is a more secure way of configuring authentication when using OSPF. By using MD5, the keys will be
encrypted, unlike simple passwords. A key number and a key string must be supplied for MD5.
- Let’s enable simple authentication between 6900-A and 6900-B
sw1 (6900-A) -> ip ospf interface int_212 auth-type md5

sw1 (6900-A) -> ip ospf interface int_212 md5 1
sw1 (6900-A) -> ip ospf interface int_212 md5 1 key alcatel
sw2 (6900-B) -> ip ospf interface int_212 auth-type md5

sw2 (6900-B) -> ip ospf interface int_212 md5 1
sw2 (6900-B) -> ip ospf interface int_212 md5 1 key alcatel
35
OSPF
- These two values will be combined and used in the MD5 hashing algorithm for authentication between
the switches. Check your routing tables, neighbors, and interfaces and enable debugging to display any
problems.
sw1 (6900-A) -> show ip ospf interface int_212

…
Authentication Type = md5,

Domain Domain
----------------+----------------+----------------+--------+--------+-------+--------
- Save the configuration; it will be used in the next lab.
-> write memory flash-synchro
8 Stub Area
8.1. OSPF Areas Logical diagram

36
OSPF
8.2. Configuration
- For this Lab, we will add a new 6560 switch to become an internal router for stub area 4.4.4.4
- A router becomes an internal router when it doesn’t have a Backbone connection and is member of only
a single area. For the purposes of the lab, Stub-Switches will be used as an internal router.
Notes
Switches in Stub Areas do not have external routes in their routing database
- Create the connection between 6860-A and 6560-A:
sw7 (6860-A) -> vlan 137


sw3 (6560-A) -> vlan 137
- Create a client vlan on 6560-A:
sw3 (6560-A) -> vlan 60

- Configure stub area 4.4.4.4 in both 6860 and 6560:
sw7 (6860-A) -> ip ospf area 4.4.4.4

sw7 (6860-A) -> ip ospf area 4.4.4.4 type stub
sw3 (6560-A) -> ip load ospf

sw3 (6560-A) -> ip ospf area 4.4.4.4
sw3 (6560-A) -> ip ospf area 4.4.4.4 type stub
- Check areas:

---------------+-------------+-------------+------------
4.4.4.4 enabled stub up
sw3 (OS6560-A) -> show ip ospf area

---------------+-------------+-------------+------------
4.4.4.4 enabled stub up
37
OSPF
8.3. Verification
- Type the following on 6560-A:
Domain Domain
---------------------+-----------------+--------+--------+--------+----------
0.0.0.0/0 172.16.137.7 2 Vlan 137 Inter
172.16.12.0/24 172.16.137.7 3 Vlan 137 Inter
172.16.17.0/24 172.16.137.7 2 Vlan 137 Inter
172.16.28.0/24 172.16.137.7 3 Vlan 137 Inter
172.16.78.0/24 172.16.137.7 2 Vlan 137 Inter
172.16.137.0/24 172.16.137.3 1 Vlan 137 Intra
192.168.20.0/24 172.16.137.7 2 Vlan 137 Inter
192.168.30.0/24 172.16.137.7 3 Vlan 137 Inter
192.168.60.0/24 192.168.60.3 1 Vlan 60 Intra
192.168.254.1/32 172.16.137.7 2 Vlan 137 Inter
192.168.254.2/32 172.16.137.7 3 Vlan 137 Inter
192.168.254.3/32 0.0.0.0 0 N/A Intra
192.168.254.7/32 172.16.137.7 1 Vlan 137 Intra
192.168.254.8/32 172.16.137.7 2 Vlan 137 Inter

Domain Domain
---------------------+-----------------+--------+--------+--------+----------
0.0.0.0/0 172.16.17.1 1 Vlan 217 AS-Ext (E2)
10.0.0.51/32 172.16.17.1 1 Vlan 217 AS-Ext (E2)
172.16.12.0/24 172.16.17.1 2 Vlan 217 Inter
172.16.17.0/24 172.16.17.7 1 Vlan 217 Intra
172.16.28.0/24 172.16.78.8 2 Vlan 278 Intra
172.16.78.0/24 172.16.78.7 1 Vlan 278 Intra
172.16.137.0/24 172.16.137.7 1 Vlan 137 Intra
192.168.20.0/24 192.168.20.7 1 Vlan 20 Intra
192.168.30.0/24 192.168.30.7 1 Vlan 30 Intra
192.168.60.0/24 172.16.137.3 2 Vlan 137 Intra
192.168.80.0/24 192.168.30.8 1 Vlan 30 AS-Ext (E2)
192.168.100.0/24 172.16.17.1 1 Vlan 217 AS-Ext (E2)
192.168.120.0/24 172.16.78.8 2 Vlan 278 AS-Ext (E2)
192.168.120.0/24 172.16.17.1 2 Vlan 217 AS-Ext (E2)
192.168.254.1/32 172.16.17.1 1 Vlan 217 Intra
192.168.254.2/32 172.16.78.8 2 Vlan 278 Intra
192.168.254.2/32 172.16.17.1 2 Vlan 217 Intra
192.168.254.3/32 172.16.137.3 1 Vlan 137 Intra
192.168.254.7/32 0.0.0.0 0 N/A Intra
192.168.254.8/32 172.16.78.8 1 Vlan 278 Intra
- Save the configuration in all switches:
all-> write memory flash-synchro
Notes
On the stub-switch, there should be a default route with a next-hop pointing towards the IP interface of the
backbone switch
How would the stub area be changed into a totally stubby area?
OMNISWITCH R8
G R A C E F U L R E S TA R T
OBJECTIVES
• Describe the Graceful Restart feature

• Learn how to configure it
BGP/OSPF/ISIS - GRACEFUL RESTART
• Router remains on forwarding path when restarting
• Neighbors must participate in graceful restart
• Reverts to normal routing protocol function if network topology change is detected during
graceful restart
• Ex. Router Y continues to list Router X during restart
Router B
Restarting Router X Helping Router Y
Network Segment S
Router A Router C
OSPF Graceful Restart Helping and Restarting Router

GRACEFUL RESTART
• Without graceful restart
Session • If a router restarts:

Down Reinit. Adj • Neighbor reinitializes the adjacency and floods out
SPF recalc. SPF recalc. updated LSAs showing that the restarting router is no
longer part of the network
• All routers in the area must run SPF algorithm to compute
Updated LSA Updated LSA new routes
Restarting Neighbor
Router
• When the restarting router comes up:

Restarting • ISIS/OSPF adjacency is re-established.
Router
SPF recalc. SPF recalc. • Neighbor floods out new LSAs including the routes from
the restarting router
• All routers in the area must run SPF algorithm once again.
Updated LSA Updated LSA Updated LSA This activity results in CMM stress for the routers.
Neighbor • Possible loss of packets due to forwarding loops
GRACEFUL RESTART
• With graceful restart
• Grace LSAs are sent to neighbors either before (planned) or after (unplanned) restart.
• Contain a “grace period”; time in seconds for achieving the OSPF restart.
• May or may not be acknowledged by the neighbors.
• Are “link-local”; only sent to adjacent neighbors
GRACE LSA GRACE LSA
R1 LSACK R2 LSACK R3
RESTARTING ROUTER
• During the restart neighbors act as if nothing happened to the restarting router
• The restarting router is still listed as an adjacency.
• Traffic is forwarded to the restarting router
• The restarting router performs non-stop forwarding
DATA
R1 R2 R3
RESTART PENDING…
GRACEFUL RESTART
• With Graceful restart
• When the restarting router comes up:
• It discovers neighbors and re-establishes adjacencies.
• It synchronizes its LSDB
• It does not send any LSA/LSP because it still has incomplete routing information. If it sent outdated
LSAs/LSPs the neighbors would think that the network had changed forcing them to run SPF calculations
throughout the area
NEIGH. ADJ. NEIGH. ADJ.
R1 GRACE LSA FLUSH R2 GRACE LSA FLUSH R3
LSA LSA
SPF
• When the restarting router has synchronized its LSDB:
• It sends out its updated LSAs/LSP. The neighbors do not run SPF algorithm based on these LSAs/LSPs.
• It purges the grace LSAs/LSPs by setting their age to the maximum value. The neighbors see these LSAs/LSPs
as ‘expired’ and discard them
• In this way the graceful restart has successfully completed
CLI - GRACEFUL RESTART
->ip {ospf/ISIS/BGP} graceful-restart
• Enables graceful restart on the switch

->ip {ospf/ISIS/BGP} restart initiate
• Initiates a planned graceful restart

->ip {ospf/ISIS/BGP} restart-support planned-unplanned / planned-only
• Configures support for the graceful restart feature on an OSPF router
->ip {ospf/ISIS/BGP} restart-helper admin-state enable/disable
• Enables or disables the capability of a router to operate in helper mode in response to a

router performing a graceful restart
->ip {ospf/ISIS/BGP} restart-interval
• Configures the grace period for achieving a graceful OSPF restart
->show ip {ospf/ISIS/BGP} restart
Note: Graceful restart is disabled for OSPF and ISIS and enabled for BGP by default
THANK YOU
OMNISWITCH R8
DHCP
OBJECTIVES

features
- DHCP Client
- DHCP Relay
- DHCP Snooping
- Dynamic ARP Inspection (DAI)
DHCP CLIENT IP INTERFACE
IP INTERFACE
Goal
• The OmniSwitch can be configured with a DHCP Client interface that allows the switch to
obtain an IP address dynamically from a DHCP server
• The DHCP Client interface is configurable on any one VLAN in any VRF instance.
• The DHCP Client interface supports the release and renew functionality according to RFC-2131.
• The Option-60 string can be configured on the OmniSwitch and sent as part of the DHCP
discover/request packet.
-> ip interface dhcp-client [vlan vid] [release | renew] [option-60 string]

Total 4 interfaces
Name IP Address Subnet Mask Status Forward Device
-------------------+---------------+----------------+------+-------+--------
dhcp-client 0.0.0.0 0.0.0.0 UP YES vlan 12
vlan1000 172.25.167.212 255.255.255.224 DOWN NO vlan 1000
DHCP CLIENT IP INTERFACE
-> ip interface dhcp-client vlan 12 • When the switch receives a valid IP address
-> show ip interface dhcp-client lease from a DHCP server:
Interface Name = dhcp-client
SNMP Interface Index = 13600001, • The IP address and the subnet mask (DHCP Option-1)
IP Address = 172.16.12.11,
Subnet Mask = 255.255.255.0, are assigned to the DHCP Client IP interface
Broadcast Address = 172.16.12.255,
Device = vlan 12, • A default static route is created according to DHCP
Encapsulation
Forwarding
=
=
eth2,
enabled,
Option-3 (Router IP Address)
Administrative State
Operational State
=
=
enabled,
up, • The lease is periodically renewed and rebound
Router MAC = 00:e0:b1:80:00:f0, according to the renew time (DHCP Option-58) and
Local Proxy ARP = disabled,
Maximum Transfer Unit = 1500, rebind time (DHCP Option-59) returned by the DHCP
Primary (config/actual)
DHCP-CLIENT Parameter Details
= yes/yes server
Client Status
Server IP
=
=
Active,
172.16.12.102,
• If the lease cannot be renewed within the lease time
Router Address = 172.16.12.1, (DHCP Option-51) returned by the DHCP server, the
Lease Time Remaining = 0 days 5 hour 58 min 14 sec,
Option-60 = OmniSwitch-OS6860, IP address is released
HostName = vxTarget
• The DHCP Client-enabled IP address serves as the
-> show ip routes primary IP address when multiple addresses are
* = BFD Enabled static route configured for a VLAN.
Total 15 routes
Dest Address Subnet Mask Gateway Addr Age Protocol
------------------+-----------------+----------------+----------+---------
0.0.0.0 0.0.0.0 172.16.12.1 00:00:10 NETMGMT
2.2.2.2 255.255.255.255 2.2.2.2 03:54:09 LOCAL
127.0.0.1 255.255.255.255 127.0.0.1 03:55:13 LOCAL
172.16.12.0 255.255.255.0 172.16.12.11 00:00:10 LOCAL
DHCP RELAY
DHCP RELAY
DHCP SERVER
DHCP CLIENT
• Two types of DHCP relay agents: global and per-interface.

• A global relay agent forwards DHCP packets to a global LAN
destination IP address
A per-interface relay agent is configured on a specific LAN SWITCH
IP interface that is bound to a VLAN.

• Only DHCP packets originating from the VLAN that is associated with ROUTER
the interface are forwarded to a destination IP address defined for DHCP RELAY
the interface relay agent. AGENT
• They are mutually exclusive
LAN SWITCH
LAN
DHCP CLIENT DHCP CLIENT

DHCP RELAY
sw8 (6860-B) -> show ip dhcp relay
• By default, the DHCP Relay feature is disabled. IP DHCP Relay :
DHCP Relay Admin Status = Enable,
• When the DHCP Relay feature is enabled, DHCP packets are Forward Delay(seconds)
Max number of hops
= 0,
= 16,
relayed on a global basis or on a per-interface basis. Relay Agent Information = Disabled,

Relay Agent Information Policy = Drop,
DHCP Relay Opt82 Format = Base MAC,
DHCP Relay Opt82 String = e8:e7:32:b3:3c:f9,
ip dhcp relay admin-state {enable | disable PXE support = Disabled,
Relay Mode = Global,
Bootup Option = Disable,
• Global basis configuration sw8 (6860-B) -> show ip dhcp relay statistics
• Configuring the Global Relay Agent Global Statistics :

Reception From Client :
Total Count = 0, Delta = 0
ip dhcp relay destination ip_address Forw Delay Violation :
Max Hops Violation :
ip dhcp relay destination 192.168.100.102 Agent Info Violation :
Invalid Gateway IP :
• Removing the Global Relay Agent Total Count =
Server Specific Statistics :
0, Delta = 0
From Interface Any to Server 192.168.100.102

Tx Server :
no ip dhcp relay destination ip_address Total Count = 0, Delta = 0
InvAgentInfoFromServer:
DHCP RELAY
• Configuring a Relay Agent for an IP Interface IP DHCP Relay :
Forward Delay(seconds) = 0,
Max number of hops = 16,
Relay Agent Information = Disabled,
• To enable/disable the DHCP Relay per-interface mode Relay Agent Information Policy = Drop,
DHCP Relay Opt82 String = e8:e7:32:b3:3c:f9,
-> ip dhcp relay per-interface-mode PXE support = Disabled,
Relay Mode = Per Interface,
-> no ip dhcp relay per-interface-mode
sw8 (6860-B) -> show ip dhcp relay statistics
Global Statistics :
Forw Delay Violation :
Agent Info Violation :
• To Configure the DHCP relay destination address for Total Count = 0, Delta = 0
the
-> specified IP interface
ip dhcp relay interface if_name destination ip_address Total Count = 0, Delta = 0
From Interface int_20 to Server 192.168.100.102
Tx Server :
ip dhcp relay interface int_20 destination 192.168.100.102 InvAgentInfoFromServer:
DHCP SNOOPING
DHCP SNOOPING
• Globally, per VLAN or per port.
• DHCP Snooping feature
DISCOVER
• Filters DHCP packets between untrusted sources and a
trusted DHCP server REQUEST
• Builds and maintains a binding table (database) to track ACK/NAK

access information for external devices
• All DHCP Messages are accepted on trusted ports
OFFER
• Configurable MAC:
• DHCP port status IP:
Lease time:
• Trusted Type:
Un-trusted Port (dynamic or static)
• DHCP traffic is fully allowed VLAN
ifIndex
• Client only (Request only) Trusted Port
• Block (no DHCP traffic allowed) Binding Database
Block DHCP traffic
• Port IP Source Filtering
• on source port - MAC - IP
• Rate Limiting
DHCP SNOOPING
• Layer 2 DHCP Snooping
• Applies DHCP Snooping functionality to bridged DHCP client/server broadcasts
• Does not require an IP interface on ingress VLAN
• Does not require the use of the relay agent to process DHCP packets
• Both L2 and L3 DHCP Snooping are active when DHCP Snooping is globally enabled
• Untrusted ports only accept DHCP Discover and Request messages

• DHCP Offer and ACK are dropped
VLAN x
DHCP Server Untrusted
Untrusted
Trusted Port
Untrusted
Rogue DHCP
Server
DHCP SNOOPING
• Release 8 Platforms Supported
• By default, DHCP Snooping is disabled
• Enables or disables DHCP Snooping for the switch

* os8_cli_87R2-revA.pdf for more options
-> dhcp-snooping admin-state {enable | disable}
• Enables or disables DHCP Snooping on a per VLAN basis

-> dhcp-snooping vlan vlan_id[-vlan_id2] [mac-address-verification|option-82-data-insertion] adminstate {enable| disable}
• mac-address verification: verifying the source MAC address of DHCP packets

with the client MAC address contained in the same packet
• option-82 data-insertion: inserting Option-82 information into DHCP packets.
• Displays the global DHCP Snooping configuration

-> show dhcp-snooping
DHCP SNOOPING
• DHCP Option-82 feature • Default Agent information
• Enables the relay agent to insert identifying • Circuit ID: VLAN ID and slot/port from where the
information into client-originated DHCP packets DHCP packet originated
before the packets are forwarded to the DHCP • Remote ID: MAC address of the router interface
server associated with the VLAN ID specified in the Circuit
ID sub option
Circuit-id
Suboption SubCircuit - id Sub -Circuit id
Type TLV Lenght TLV
Circuit - id Lenght
Lenght
1 20 0 4 VLAN Slot port 1 12 String or Hostname (configurable )
1 byte1 byte 1 byte 1 byte 2 bytes 1 byte 1 byte 1 byte 1 byte 12 bytes (Variable)
Remote-id
•Agent ID
Subremote-id
Suboption TLV
Lenght
Remote-id lenght
2 14 1 12 String or Hostname ( configurable )
1 byte 1 byte 1 byte 1 byte 12 bytes (Variable)

DHCP OPTION 82
• Configures the type of information that is inserted into both the Circuit ID and Remote ID
sub option fields of the Option-82 field
-> dhcp-snooping option-82 format [base-mac | system-name | user-string string | interface-alias | autointerface-alias |
ascii [{ remote-id | circuit-id} {base-mac | cvlan | interface | interface-alias | systemname | user-string string |
vlan} {delimiter string}]]
• Example
-> dhcp-snooping option-82 format user-string “Building B Server”
-> dhcp-snooping option-82 format system-name
-> dhcp-snooping option-82 format base-mac
-> dhcp-snooping option-82 format interface-alias
-> dhcp-snooping option-82 format auto-interface-alias
DHCP SNOOPING
• Displays the global DHCP Snooping configuration
-> show dhcp-snooping
• Displays the ports or VLANs on which IP source filtering is enabled

-> show dhcp-snooping ip-source-filter {vlan | port}
• Displays a list of VLANs that have DHCP Snooping enabled and whether or not MAC address
verification and Option-82 data insertion is enabled for each VLAN
-> show dhcp-snooping vlan
• Displays the trust mode and DHCP Snooping violation statistics for all switch ports and link
aggregates that are filtered by DHCP Snooping
-> show dhcp-snooping port
• Clears the DHCP violation counters.

-> dhcp-snooping clear violation-counters {port chassis/slot/port[-port2]} | slot chassis/slot
| linkagg agg_id | all}
DYNAMIC ARP INSPECTION (DAI)
DYNAMIC ARP INSPECTION (DAI)
• Dynamic ARP Inspection (DAI) serves as a security feature for validating the authenticity of
Address Resolution Protocol (ARP) packets in a network.
• This capability can be used to prevent certain types of "man-in-the-middle" attacks.
• DAI is implemented by combining both DHCP snooping and IP source filtering capabilities
on the OmniSwitch.
• The following CLI commands are associated with this feature:

dhcp-snooping vlan admin-state
dhcp-snooping binding admin-state
dhcp-snooping port trust
dhcp-snooping ip-source-filter admin-state
dhcp-snooping ip-source-filter dynamic-arp-inspection admin-state
show dhcp-snooping ip-source-filter
THANK YOU
OmniSwitch R8
DHCP Server & DHCP Relay
How to
✓ Configure the DHCP Relay feature (aka IP Helper)
Contents
1 Topology ........................................................................................ 2
2 Accessing the DHCP Server .................................................................. 3
3 Testing the DHCP Relay ...................................................................... 5
2
1 Topology
A DHCP server provides dynamic IP addresses on lease for client interfaces on a network. It manages a pool of IP
addresses and information about client configuration parameters. The DHCP server obtains an IP address
request from the client interfaces.
After obtaining the requests, the DHCP server assigns an IP address, a lease period, and other IP configuration
parameters, such as the subnet mask and the default gateway.
The DHCP Relay feature allows UDP broadcast packets to be forwarded across VLANs that have IP routing
enabled.
3
2 Accessing the DHCP Server

When DHCP clients and associated servers do not reside on the same IP network or subnet, a DHCP relay agent
can transfer DHCP messages between them.
- Check if there is a route from the 6860 to the DHCP server (192.168.100.102):

Total 23 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 172.16.17.1 00:00:38 OSPF
10.0.0.51/32 172.16.17.1 00:00:38 OSPF
127.0.0.1/32 127.0.0.1 00:42:20 LOCAL
172.16.17.0/24 172.16.17.7 00:40:53 LOCAL
172.16.18.0/24 +172.16.17.1 00:40:09 OSPF
+172.16.78.8 00:40:09 OSPF
172.16.78.0/24 172.16.78.7 00:40:53 LOCAL
192.168.20.0/24 192.168.20.7 00:40:56 LOCAL
192.168.30.0/24 192.168.30.7 00:40:56 LOCAL
192.168.100.0/24 172.16.17.1 00:25:03 OSPF
192.168.254.1/32 172.16.17.1 00:09:59 OSPF
192.168.254.7/32 192.168.254.7 00:09:56 LOCAL
192.168.254.8/32 172.16.78.8 00:09:45 OSPF
---[ truncated]
sw7 (6860-A) -> ping 192.168.100.102

Total 25 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 +172.16.28.2 04:04:34 OSPF
+172.16.78.7 00:54:01 OSPF
10.0.0.51/32 +172.16.28.2 04:04:34 OSPF
+172.16.78.7 00:54:01 OSPF
127.0.0.1/32 127.0.0.1 1d 4h LOCAL
172.16.12.0/24 172.16.28.2 05:43:00 OSPF
172.16.17.0/24 172.16.78.7 00:54:45 OSPF
172.16.28.0/24 172.16.28.8 05:54:09 LOCAL
172.16.78.0/24 172.16.78.8 1d 0h LOCAL
172.16.137.0/24 172.16.78.7 03:40:30 OSPF
192.168.20.0/24 192.168.20.8 21:22:00 LOCAL
192.168.30.0/24 192.168.30.8 22:04:03 LOCAL
---[ truncated]
192.168.60.0/24 172.16.78.7 03:39:36 OSPF
192.168.70.0/24 192.168.30.7 04:14:18 OSPF
192.168.80.0/24 192.168.80.8 05:54:09 LOCAL
192.168.100.0/24 +172.16.28.2 04:05:56 OSPF
---[ truncated]
sw8 (6860-B) -> ping 192.168.100.102

4
- Configure an IP DHCP relay on each switch:

o On the 6860-A:
sw7 (6860-A) -> ip dhcp relay destination 192.168.100.102
sw7 (6860-A) -> ip dhcp relay admin-state enable
sw7 (6860-A) -> show ip dhcp relay
IP DHCP Relay :
DHCP Relay Opt82 String = e8:e7:32:d4:88:95,
PXE support = Disabled,
o On the 6860-B:
Sw8 (6860-B) -> ip dhcp relay destination 192.168.100.102
Sw8 (6860-B) -> ip dhcp relay admin-state enable
IP DHCP Relay :
DHCP Relay Opt82 String = e8:e7:32:cd:57:f3,
5
- Check that VLANs 20 or 30 are correctly mapped to ports for clients connected to the 6360 virtual
chassis.
port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
Note: if ports are not assigned to the correct VLAN, type the following commands :
o Assign the VLAN 20 or 30 to the clients connected to the 6360 virtual chassis:

3 Testing the DHCP Relay

- Configure clients 5, 6, 9 and 10 to obtain an IP address and DNS server address automatically:
Tips
The IP DHCP relay feature can also be configured
on a per-VLAN basis.
This can be interesting if different DHCP servers
must serve IP addresses for different subnets.
Here, as we have a unique DHCP server, it’s not
necessary.
- Check the IP DHCP relay statistics:

sw7 (6860-A) -> show ip dhcp relay statistics
Global Statistics :
Tx Server :
6
sw8 (6860-B) -> show ip dhcp relay statistics

Global Statistics :
Tx Server :
OMNISWITCH R8
Q U A L I T Y O F S E RV I C E ( Q O S )
OBJECTIVES
• Understand the Quality of Service main principle

• Configure the OmniSwitch for QoS
- Condition
- Action
- Rules
• Monitor the QoS
• Prioritize automatically the IP Phone Traffic
• Policy based routing
• Remote Port Mirroring (RPM)
QOS REMINDER
QOS
• Goal
Basic QOS 802.1p/ToS/DSCP
• Decide which traffic needs preferential treatment * Traffic prioritization
and which traffic can be adequately served with * Bandwidth shaping
* Marking
* Stamping
best effort * Queuing management
Policy Based Routing Filtering

• How it works * Layer 2 and
* Routed traffic redirecting
Layer 3/4 ACLs
• QoS is implemented on the switch through
the use of:
• Port-based QoS configuration Policy Based Mirroring ICMP Policies
• User-defined policies * Mirror traffic based on QoS
* Filtering
* Prioritizing
• Integration with virtual output queuing to manage egress policies
* Rate limiting traffic (security)
congestion
• Auto-QOS configuration
Access Guardian
* User Network Profile
QOS CONFIGURATION
QOS CONFIGURATION
Step by Step
Global Parameters
Configuring Congestion Management
Configuring QoS Port Parameters
Setting Up Policies
Monitoring Policies
Auto-QOS configuration
QOS CONFIGURATION
Global Parameters
Description Command/keyword
By default, QoS is enabled on the switch. If QoS policies are qos enable/disable
configured and applied, the switch attempts to classify and apply
relevant policy actions
Displays global information about QoS configuration show qos config
Resets the QoS configuration to its defaults qos reset
Deletes the pending configuration qos revert
Flushes the configuration qos flush
Apply the configuration qos apply
QOS CONFIGURATION
Step by Step
Configuring Congestion Management Queue Set Profile

Egress QSets QSI QSet Profile 1
Ports Q1 = SP7, 100% BW
Slot 1 Port 1/1 QSI for port 1/1
Q2 = SP6, 100% BW
1 1
2 2 1 Q3 = SP5, 100% BW
3 3 2 Q4 = SP4, 100% BW
4 4 Q5 = SP3, 100% BW
. 5 3
. 6 4 Q6 = SP2, 100% BW
20 7 5 Q7 = SP1, 100% BW
. 8 Q8 = SP0, 100% BW
6
.
7
Slot 2 8 Strict Priority (SP)
1
2
3
4
.
.
12
Eg: QSet Profile 1 ( 8SP)

Port 1/1/1 Port 1/1/1
SP0 Port 1/1/3 SP4 Port 1/1/3
a a b a a
100% 100%
50% 50% 100%
SP0 SP0
b b
100% 100%
Port 1/1/2 Port 1/1/2
QOS CONFIGURATION The following Qset profiles (QSP) are supported:
Step by Step
Configuring Congestion Management

To change the QSP for a specific QSet instance (QSI)
-> qos qsi port 1/2/1 qsp 2

-> qos qsi linkagg 5 qsp 2
* Eg: QSet Profile 2 (1 EF + 7 SP)
Port 1/1/1 Port 1/2/1 Port 1/1/1 Port 1/2/1

EF
a EF
20% b a a
0% b
SP5 80% 20%
b SP5 100%
100% b
100%
Port 1/2
Port 1/2
To change the default QSet profile (QSP 1) to one of the other supported profiles (QSP 2, 3, or 4)
qos qsp system-default 2
QOS CONFIGURATION
Step by Step
Configuring QoS Port Parameters

Examples
To limit the ingress or egress bandwidth for a QoS port
-> qos port [chassis]/slot/port
-> qos port 1/1/1 maximum egress-bandwidth 10M [trusted]
[maximum egress-bandwidth]
[maximum ingress-bandwidth]
Change the 802.1p value to 7 for the port 1/1/1 [default 802.1p value]
[default dscp value]
-> qos port 1/1/1 default 802.1p 7 [default classification {802.1p | tos | dscp}]
[dei {ingress | egress}]
Configure individual ports to recognize 802.1p or ToS

-> qos port 1/1/1 trusted
QOS CONFIGURATION
Step by Step
A policy (or a policy rule) is made up of:
Setting Up Policies 1. a condition
2. an action
INCOMING PACKET
FORWARDING ENGINE
H
E
A ACTION
D PACKET CLASSIFICATION
E
R
CLASSIFIER (POLICY DATABASE)
CONDITION ACTION
---- ----
… …
• Prioritization, Bandwidth
Gets Policies from shaping
L2 (source & dest) • ICMP filtering
• CLI • MAC, VLAN, • ICMP prioritizing, ICMP rate
• Webview • Slot/Port, IPMS Filtering limiting
• PolicyView (OV) • 802.1p/ToS/DSCP marking and
L3/L4 mapping
• Policy Based Routing PBR for
• SIP, DIP, redirecting
• TCP,UDP,IP proto • Routed traffic
• Source TCP/UDP port
• Destination TCP/UDP port • Policy Based Mirroring
• Advanced Layer 2 to 4 Filtering
-> policy condition condition_name
[source ip ip_address [mask netmask]]
QOS CONFIGURATION
[source ipv6 {any | ipv6_address [mask netmask]}
[destination ip ip_address [mask netmask]]
[destination ipv6 {any | ipv6_address [mask netmask]}
[multicast ip ip_address [mask netmask]]
Step by Step [source network group network_group]

[destination network group network_group]
[multicast network group multicast_group]
[destination ip-port port[-port]]
[source tcp-port port[-port]]
Setting Up Policies [destination tcp-port port[-port]]
[source udp-port port[-port]]
[destination udp-port port[-port]]
[ethertype etype]
Create a policy condition [established]
[tcpflags {any | all} flag [mask flag]
• Source TCP/UDP port [service service]
• Destination TCP/UDP port [service group service_group]
[icmptype type]
• Service, service group, TCP flags Layer 4
[icmpcode code]
[ip protocol protocol] ip protocol
[ipv6]
• IP protocol, source IP, multicast IP, destination IP, [tos tos_value tos_mask]
• Source network group, destination network group, [dscp {dscp_value[-value} [dscp_mask]]
multicast network group [source mac mac_address [mask mac_mask]]
• ToS, DSCP, ICMP type, ICMP code Layer 3 [destination mac mac_address [mask mac_mask]]
[source mac group group_name]
[destination mac group mac_group]
• Source MAC, source MAC group, destination MAC, [source vlan vlan_id]
destination MAC group, 802.1p, 802.1p range, [destination vlan vlan_id]
Ethertype, source VLAN, destination VLAN Layer 2 [802.1p 802.1p_value]
[source port slot/port[-port]]
[source port group group_name}
[destination port slot/port[-port]]
• Source port, source port group, destination port,
[destination port group group_name]
destination port group Layer 1 …
Examples
policy condition cond3 source ip 10.10.2.3
policy condition client_traffic source vlan 20
QOS CONFIGURATION
Step by Step
Setting Up Policies
Create a policy group to include into policy condition

Group Description Command/keyword
Policy port group Slot and port number combinations policy port group group_name slot/port[-port] [slot/port[-port]...]
Policy mac group Multiple MAC addresses that may be policy mac group mac_group mac_address [mask mac_mask] [mac_address2
attached to a condition [mask mac_mask2]...]
Policy network group IPv4 source or destination addresses policy network group net_group ip_address [mask net_mask]
Default “switch” group [ip_address2 [mask net_mask2]...]
Includes all IPv4 addresses
configured on the switch
Policy service group TCP or UDP ports or port ranges policy service group service_group service_name1 [service_name2...]
(source or destination)
Examples
-> policy port group techports 1/1/1 3/1/1 3/2/1 3/3/1
-> policy condition cond4 source port group techports
-> policy network group netgroup3 173.21.4.0 mask 255.255.255.0 10.10.5.3
-> policy condition cond5 destination network group netgroup3
-> policy mac group macgrp2 08:00:20:00:00:00 mask ff:ff:ff:00:00:00 00:20:DA:05:f6:23
-> policy condition cond6 source mac group macgrp2
QOS CONFIGURATION
Step by Step
Setting Up Policies
Create a policy action

-> policy action action_name
[disposition {accept | drop | deny}]
ACL (disposition drop) [shared]
Change queuing priority [priority priority_value]
Update TOS/Diffserv and/or 802.1p priority tags [maximum bandwidth bps]
802.1p/TOS/Diffserv marking [maximum depth bytes]
802.1p/TOS/Diffserv mapping [tos tos_value]
Per COS max bandwidth (64K bps) [802.1p 802.1p_value]
Maximum depth [dcsp dcsp_value]
Statistics (# of packets, # of bytes) [map {802.1p | tos | dscp} to {802.1p | tos| dscp} using map_group]
Ingress policing / Egress shaping [permanent gateway ip ip_address]
Port Redirection [port-disable]
Routed Traffic Redirection [redirect port slot/port]
Link Aggregate Redirection [redirect linkagg link_agg]
Port Disable [no-cache]
Mirroring [{ingress | egress | ingress egress | no} mirror slot/port]
Multi-actions support [cir bps [cbs byte] [pir bps] [pbs byte] [counter-color [red-
Ingress Rate Limiting nonred | green-nongreen | green-red |green-yellow | red- yellow]]
Examples
policy action action2 priority 7
policy action SetBits 802.1p 7

QOS CONFIGURATION
Step by Step
Setting Up Policies Does it Match Condition?
Policy action – Action default
Use higher Action policy Use Default Action
Mark, Prioritize,
Actions Defaults Shape Filter, Mirror,…
Description Keyword Default
Whether the flow matching the rule disposition Accept
should be accepted or Denied
QOS CONFIGURATION
Step by Step INCOMING PACKET
PACKET CLASSIFICATION
H
E ACTION
A CONDITION ACTION
D
Setting Up Policies E
---- ----
applies to
R outgoing
POLICY RULE traffic
Create a policy rule
-> policy rule rule_name [enable | disable] [precedence precedence] [condition condition]
[action action] [validity period name | no validity period] [save] [log [log-interval seconds]]
[count {packets | bytes}] [trap | no trap] [default-list | no default-list]
Examples
policy condition c1 source ip 10.10.2.3
policy action a1 redirect port 1/1/2

Sets the precedence for rule r1 and turns on logging
-> policy rule r1 precedence 200 condition c1 action a1 log
QOS CONFIGURATION
Step by Step
Setting Up Policies
Examples
Maps traffic destined for port 3/2 with and 802.1p value of 4 to an 802.1p value of 7
-> policy condition Traffic destination port 1/1/1 802.1p 4 802.1P MAPPING
-> policy action SetBits 802.1p 7
-> policy rule Rule2 condition Traffic action SetBits
Sets traffic from 10.10.2.3 to a priority of 7

-> policy condition cond3 source ip 10.10.2.3 SETTING PRIORITY
-> policy action action2 priority 7
-> policy rule my_rule condition cond3 action action2
Configures a validity period for rule r1

-> policy validity-period vp01 hours 13:00 to 19:00 days monday Friday
-> policy rule r1 validity-period vp01
QOS CONFIGURATION
Step by Step
Monitoring Policies
Displaying the actual number of matches for the configured rules
-> show active policy rule
Policy From Prec Enab Act Refl Log Trap Save Def Matches
R1 cli 0 Yes Yes No No Yes Yes Yes 2
(L2/3): C1 -> QoS_Action1
Rule match counting

2 options to configure rule count
-> policy rule <name> count packets (default)
Every packet matching a rule will be counted in the “matches” column
-> policy rule <name> count bytes
Same but count number of bytes instead of number of packets
QOS CONFIGURATION
Step by Step
Monitoring Policies
Display the QoS statistics
-> show qos statistics
Display global information on the QoS configuration

-> show qos config
Displays the QoS event log. This command also

displays packets dropped by IP source filter entries
-> show qos log
QOS SPECIFICATION
AUTOMATIC PRIORITIZATION
FOR IP PHONE TRAFFIC
QOS CONFIGURATION
• Automatic Prioritization for IP Phone Traffic Switch detects traffic coming from ALU phones
(based on MAC address)
• Enable by default on the switch
MAC Address Range Description
00:80:9F:00:00:00 to 00:80:9F:FF:FF:FF Enterprise IP Phones Range
78:81:02:00:00:00 to 78:81:02:FF:FF:FF Communications IP Phones Range On trusted and
00:13:FA:00:00:00 to 00:13:FA:FF:FF:FF Lifesize IP Phones Range un-trusted ports
48-7A-55-00-00-00 to 48-7A-55-FF-FF-FF ALE 8008 IP Phone MAC Range Mac adress = ALE Phone > Priority 5
Non ALE Phone > Default
• To prioritize the phone traffic instead of merely trusting it

-> qos phones [priority priority_value | trusted]
• To disable automatic IP phone traffic prioritization for the switch

-> qos no phones
• Additional MAC group

• The alaPhones mac group must be redefined
policy mac group alaPhones 00:80:9f:00:00:00 mask ff:ff:ff:00:00:00
POLICY BASED ROUTING
POLICY BASED ROUTING (PBR)
• QoS policies that will override the normal routing mechanism for traffic matching the
policy condition
• Redirect untrusted traffic to a proxy firewalling server
• i.e specific source traffic (e.g. HTTP, FTP) can be redirected to a cache engine
• Virtual inline deployment
• Done in hardware
R2
24.0.0.0/8
191.24.0.0/16 10.0.0.0/8
190.27.3.0/24
20.0.0.0/8
R3
R1 150.21.0.0/16
Redirect traffic from source 20.0.0.0/8 to Firewall

POLICY BASED ROUTING (PBR)
• Conditions
• IP Protocol (i.e. ICMP, TCP, ICMP)
• Source IP address (or network group)
• Destination IP address (or network group)
• Source TCP/UDP port
• Destination TCP/UDP port
• Source TCP/UDP service
• Destination TCP/UDP service
• Source TCP/UDP service group
• Destination TCP/UDP service group
• TOS, DSCP
• Source VLAN
• Source slot/port
• Source slot/port group
• Action
• Define gateway to be used overriding the routing database
• Can be set to local next hop IP or remote hop IP
-> policy action <action_name> permanent gateway ip <ip address>
POLICY BASED ROUTING - EXAMPLE
• All traffic originating in the 10.10.0.0 network is routed through the firewall,
regardless of whether a route exists
-> policy condition Traffic10 source ip 10.10.0.0 mask 255.255.0.0
-> policy action Firewall permanent gateway ip 192.168.99.254
-> policy rule Redirect_All condition Traffic10 action Firewall
Routed back OR Other destinations
192.168.99.254 Firewall/Gateway
Internet
192.168.10.0 192.168.99.0
2/1
Unknown DA
20.10.0.0 10.10.0.0
POLICY BASED ROUTING - EXAMPLE
• Traffic from the firewall is sent back to the switch to be re-routed
• Adding the source port to the condition allows traffic to not get caught in a loop
-> policy condition TrafficFromFW source IP 10.10.0.0 mask 255.255.0.0 source port 2/1/1
-> policy action To_Internet permanent gateway IP 192.168.10.254
-> policy rule Redirect_Internet condition TrafficFromFW action To_Internet
Routed back OR Other destinations
192.168.99.254 Firewall/Gateway
Internet
192.168.10.0 192.168.99.0
2/1
Unknown DA
20.10.0.0 10.10.0.0
REMOTE PORT MIRRORING (RPM)
REMOTE PORT MIRRORING (RPM)
• Allows traffic to be carried over the network to a remote switch
• Achieved by using a dedicated remote port mirroring VLAN
• RPM VLAN has to be configured on the source, destination and intermediate switches
• No other traffic is allowed on that VLAN
• The following types of traffic will not be mirrored:

• Link Aggregation Control Packets (LACP), 802.1AB (LLDP), 802.1x port authentication, 802.3ag
(OAM), Layer 3 control packets, Generic Attribute Registration Protocol (GARP)
SOURCE SWITCH INTERMEDIATE SWITCH DESTINATION SWITCH

DESTINATION PORT
SOURCE PORT
POLICY BASED MIRRORING
• Mirroring is done based on a QoS policy instead of a specific port
• 1 session supported at any given time
• Port Based Mirroring. It can be done on incoming or outgoing traffic or both.
• Policy action mirror
• Mirror traffic based on
• Source & Destination addresses
• Address pairs
• Protocols
• VLAN classification
• Port mirroring and monitoring cannot be configured on the same port
INGRESS, EGRESS, OR BOTH INGRESS & EGRESS PACKETS
POLICY ACTION & PORT ASSIGNMENT
DIRECT TRAFFIC TO MIRROR PORT
MIRRORING POLICY
POLICY BASED MIRRORING
• Example 1
-> policy condition c1 source ip 1.1.1.1
-> policy action a1 ingress egress mirror 1/1/1
-> policy rule r1 condition c1 action a1
-> qos apply
Policy rule r1 will cause all packets with a source IP of 1.1.1.1 to be ingress and egress
mirrored to port 1/1/1
• Example 2
-> policy condition c1 source ip 1.1.1.1
-> policy action a2 ingress egress mirror 1/1/1 disposition drop
-> qos apply
Policy rule r2 drops traffic with a source IP of 1.1.1.1, but the mirrored traffic from
this source is not dropped and is forwarded to port 1/1/1
THANK YOU
OmniSwitch R8
Quality of Service (QoS)
How to
✓ Configure Quality of Service rules on the OmniSwitches R8
Contents
1 Introduction .................................................................................... 2
2 Configuring Port Default 802.1P/ToS/DSCP ............................................... 3
3 Configuring Trusted Ports .................................................................... 3
3.1. Example 1 ........................................................................................... 3
3.2. Example 2 ........................................................................................... 4
4 Configuring the Policies ...................................................................... 4
2
1 Introduction
By default, the QoS feature is enabled on an OmniSwitch. If QoS policies are configured and applied, the switch
will attempt to classify traffic and apply relevant policy actions.
Notes
In this lab, we will not cover all the QoS features. The main objective of this lab is to provide an overview
about how to configure the QoS. For more information, read the Policy Condition Combination table in the
Network Configuration Guide for a list of valid combinations.
Diagram containing all the devices that will be used during this lab:
- Before beginning, reset all the QoS parameters back to default (6360-A):
sw5 (6360-A) -> qos flush
sw5 (6360-A) -> qos apply
sw5 (6360-A) -> show qos config
QoS Configuration
Admin = enable,
Trust ports = no,
Log lines = 10240,
Log level = 6,
Log console = no,
Forward log = no,
User-port filter = spoof ,
User-port shutdown = none,
Phones = trusted,
DEI Mapping = disable,
DEI Marking = disable,
Pending changes = none
3
2 Configuring Port Default 802.1P/ToS/DSCP

By default, the port default values for 802.1p and ToS/DSCP are 0. To change the default 802.1p or ToS/DSCP
settings for a port, use the qos port default 802.1p or qos port default dscp command.
- Change the 802.1p value to 7 for the port 1/1/1:
sw5 (6360-A) -> show qos port 1/1/1
Slot/ Default Default Bandwidth DEI
Port Active Trust P/DSCP Classification Physical Ingress Egress Map Mark Type
-------+-------+-----+------+--------------+----------+-------+------+------+------+-------------
1/1/1 Yes No 0/ 0 DSCP 100M - - No No ethernet-100M
sw5 (6360-A) -> qos port 1/1/1 default 802.1p 7

-------+-------+-----+------+--------------+----------+-------+------+------+------+-------------
1/1/1 Yes No 7/ 0 DSCP 100M - - No No ethernet-100M
Notes
In this example above:
- Any untagged traffic (traffic without any 802.1p settings) arriving on port 1/1/1 will be tagged with an
802.1p value of 7 (highest priority).
- If the port is configured to be untrusted, any tagged traffic will be tagged with an 802.1p value of 7.
- If the port is configured to be trusted, any tagged traffic will preserve the 802.1p value in the flow.
By default, switched ports are untrusted.
3 Configuring Trusted Ports
3.1. Example 1
- To configure individual ports to recognize 802.1p or ToS, use the qos port trusted command with the
desired slot/port number:
sw5 (6360-A) -> qos port 1/1/1 trusted

-------+-------+-----+------+--------------+----------+-------+------+------+------+-------------
1/1/1 Yes +Yes 7/ 0 DSCP 100M - - Yes No ethernet-100M
Notes
In this example above, the qos port trusted command specifies that port will be able to recognize and trust
the 802.1p bits. The global setting is active immediately; however, modifying a port configuration requires qos
apply to activate the change.
4
3.2. Example 2
- In the following example:
o A policy condition “Traffic” is then created to classify traffic containing 802.1p bits set to 4.
o The policy action “SetBits” specifies that the bits will be changed to 7 when the traffic leaves
the switch
o A policy rule called 802.1p_rule puts the condition and the action together.
sw5 (6360-A) -> policy condition Traffic 802.1p 4
sw5 (6360-A) -> policy action SetBits 802.1p 7
sw5 (6360-A) -> policy rule 802.1p_rule condition Traffic action SetBits
Notes
802.1p mapping may also be set for Layer 3 traffic, which typically has the 802.1p bits set to 0.
- In the above example, what would happen if ingress traffic on chassis 1 slot 1 port 1 was tagged with an
802.1p value of 5?
----------------------------------------------------------------------------------------------------------------------------- ------
- To view the QoS configuration:

sw5 (6360-A) -> show policy condition
Condition name : Traffic
802.1p = 4
sw5 (6360-A) -> show policy action

Action name : SetBits
802.1p = 7
sw5 (6360-A) -> show policy rule

Rule name : 802.1p_rule
Condition name = Traffic,
Action name = SetBits
4 Configuring the Policies
Let’s consider that the devices located in the VLAN 20 are employees, and the devices located in the VLAN 30
are contractors. We want to prioritize employees’ traffic over contractors’ traffic.
- To create a policy rule to prioritize the traffic from VLAN 20:

o Create a condition for the traffic that you want to prioritize (ex. client_traffic)
o Create an action to prioritize the traffic as highest priority (ex. priority_5)
o Combine the condition and the action into a policy rule (ex. rule1)
sw5 (6360-A) -> policy condition client_traffic source vlan 20

sw5 (6360-A) -> policy action priority_5 802.1p 5
sw5 (6360-A) -> policy rule rule1 condition client_traffic action priority_5
5
- The rule is not active on the switch until it has been applied:
sw5 (6360-A) -> show active policy rule

Rule name : rule1

Condition name = client_traffic,
Action name = priority_5,
Packets = 163,
Bytes = 10249
- In this following example, any flow coming from the VLAN 20 is sent to a queue supporting its maximum
bandwidth requirement. Via the QoS feature, it is also possible to modify the policy action that you have
created earlier to limit the maximum bandwidth:
sw5 (6360-A) -> policy action priority_5 maximum bandwidth 100k
sw5 (6360-A) -> show policy action priority_5

Action name : priority_5
Maximum bandwidth = 100K,
802.1p = 5
- The bandwidth can be specified in abbreviated units, in this case, 100k (= 100 kilo bytes).
- Check the management:
sw5 (6360-A) -> show policy condition
Condition name : Traffic
802.1p = 4
Condition name : client_traffic

Source VLAN = 20
sw5 (6360-A) -> show policy action

Action name : SetBits
802.1p = 7
Action name : priority_5

Maximum bandwidth = 100K,
802.1p = 5
sw5 (6360-A) -> show policy rule

Rule name : rule1

Action name = priority_5
- To specify a precedence value for a rule, use the policy rule command with the precedence keyword:
sw5 (6360-A) -> policy rule rule1 precedence 1000 condition client_traffic action priority_5
- Launch a ping from client 5 (which is in the VLAN 20) to client 9:

C:\> ping 192.168.20.xx (check ip address allocated dynamically to client 9)
6
- Check the active rule result:

Rule name : rule1
Packets = 12555,
Bytes = 756988,
Green Packets = 6982
As it doesn’t exceed the maximum bandwidth, it should work.

- Now, try to launch a ping by specifying a greater datagram size:
Client5 C:\> ping –l 65000 192.168.20.Xx (check ip address allocated dynamically to client 9)
- Check the active rule result:

Rule name : rule1
Packets = 13527,
Bytes = 1068548,
Green Packets = 7386,
Red Packets = 148
Notes: Green, Yellow, Red?

Tri-Color Marking (TCM) statistics; the number of packets/bytes that are marked Green (low drop precedence),
Yellow (high drop precedence), and Red (always drop).
- Your ping is now using a greater bandwidth, so it shouldn’t work.

- To remove an action parameter or return the parameter to its default, use no with the relevant
keyword:
sw5 (6360-A) -> policy action priority_5 no maximum bandwidth
- By default, rules are enabled. Rules may be disabled or re-enabled through the policy rule command:
sw5 (6360-A) -> policy rule rule1 disable
sw5 (6360-A) -> policy rule 802.1p_rule disable

No active rules
- Once testing is complete, remove the condition, action and rule:

sw5 (6360-A) -> no policy rule rule1
sw5 (6360-A) -> no policy rule 802.1p_rule
sw5 (6360-A) -> no policy action priority_5
sw5 (6360-A) -> no policy action SetBits
sw5 (6360-A) -> no policy condition Traffic
sw5 (6360-A) -> no policy condition client_traffic
7
sw5 (6360-A) ->show active policy rule

No active rules
Tips > Logs

- Logging a rule may also be useful for determining such things as the source of attacks. Often, at least when
initially configuring your rules, it is recommended to use the log option to monitor how your policies are being
used. To log information about flows that match the policy rule rule1: sw5 (6360-A) -> policy rule rule1 log
- To check the logs: sw5 (6360-A) -> show qos log
OMNIVISTA 2500 NMS
SOLUTION OVERVIEW
OBJECTIVES
• Describe the OmniVista 2500 Purpose

• List the OmniVista 2500 Main Features
INTRODUCTION
• OmniVista 2500
• Network Management System (NMS)
• Unified Management / Monitoring / Provisioning of LAN & WLAN devices:
• ALE OmniSwitch Switches
• ALE OmniAccess Stellar Access Points
• 3rd Party Devices
ALE OMNISWITCH
• PROVISION
• MANAGE
• MAINTAIN
OMNIVISTA 2500
3RD 3RD PARTY DEVICES
ALE STELLAR APS

INSTALLATION & ADMINISTRATION
• Installation • Administration
• OmniVista 2500 = Virtual Appliance • Web Interface
OmniVista 2500 NMS
Hypervisors
• VMware ESXi
• VirtualBox
• MS Hyper-V
• KVM
HOME PAGE
• Applications
• Accessible via
a drop down menu
• Dashboard
• Applications widgets
• OV 2500 Home Page
• Quick overview
• Customizable
(add/remove…)
APPLICATIONS
NETWORK CONFIGURATION UNIFIED ACCESS ADMINISTRATION WLAN

- DISCOVERY - VLANS - UNIFIED PROFILE - CONTROL PANEL - SSIDS
- TOPOLOGY - VXLANS - UNIFIED POLICY - PREFERENCES - WIRELESS INTRUSION
- AP REGISTRATION - IP MULTICAST - MULTIMEDIA SERVICES - AUDIT PROTECTION SYSTEM
- SAA - CLI SCRIPTING - PAID ACCOUNT SERVICES - LICENSE (WIPS)
- LOCATOR - POLICYVIEW - OV SYSTEM HEALTH - RF MANAGEMENT
- NOTIFICATIONS - SIP - HEAT MAP
- VM MANAGER - CAPTIVE PORTAL SECURITY UPAM - FLOOR PLAN
- ANALYTICS - GROUPS - USERS AND USER GROUPS - SUMMARY - CLIENT
- APPLICATION VISIBILITY - APP LAUNCH - AUTHENTICATION SERVERS - AUTHENTICATION
- PROVISIONING - REPORT - QUARANTINE MANAGER - GUEST ACCESS
- I OT - RESOURCE MANAGER - BYOD ACCESS
- SETTINGS
MAIN FEATURES
• Unified LAN & WLAN Management

• Essential configuration functions
• Simplified user interface
• Device Inventory / Software Update

• Network devices inventory • PROVISION • BACKUP
• MANAGE • RESTORE
• Devices backup/restore/update • MAINTAIN • UPDATE
MAIN FEATURES
ADMIN
• Notifications
• Display traps generated by the devices
• Perform an action when receiving urgent /
important traps
(send a mail, run an application, forward the trap…)
• Topology
• Topology view of all the discovered devices
• View information about a specific device
• Perform certain actions
(edit/telnet/reboot a device)
MAIN FEATURES
APPLICATION BANDWITH
ANALYTICS
• Analytics
• View of network resources utilization (users, R
devices, applications)
• Reports generation (usage trends, predictive
analysis of future network utilization…)
• Application Visibility
• Identify and restrict usage of applications
that are used by users (ex. Facebook)
• Uses the DPI feature (Deep Packet Inspection)
MAIN FEATURES
HEAT MAP
FLOOR PLAN
• Floor Plan
• Determine optimal placement of access
points in a location
• Heat Map
• Create & Organize Wi-Fi coverage maps
(“Heat Maps”)
GUESTS VLAN, EMPLOYEES VLAN,
MAIN FEATURES RESTRICTED ACCESS FULL ACCESS
• Guest Access & BYOD (Bring Your Own Device)

• Secured guest access management
• BYOD: On boarding of employees' devices
• Captive Portal
• Integrated captive portal with credentials CAPTIVE PORTAL
management (email, social login, Rainbow...)

• External captive portal redirection
GUESTS
EMPLOYEE
DEVICE (BYOD)
MAIN FEATURES
STANDBY
VLAN + RULES
MASTER « CAMERAS »
• High Availability
• 1 OV2500 Master / 1 OV2500 Standby
• Avoid loss of service
• Internet of Things (IoT)

• Automatic discovery of all IoT devices across
the network
VLAN + RULES
• Virtual network segmentation « DOOR LOCKS »
• Information on each IoT device connected

(device type, vendor, network location…)
• Real-time and historical summary of IoT
activity
MAIN FEATURES
3RD PARTY APPLICATION

OMNIVISTA 2500
• Troubleshooting
• Embedded troubleshooting tools
• Rapid isolation of network issues
• APIs
• Northbound RESTful APIs
• Integration of network management functions
with 3rd party ecosystem application
THANK YOU
OmniSwitch R8
OmniVista 2500 NMS-E Access & OmniSwitches Basic Features
How to
✓ Access to the OmniVista 2500 NMS server
✓ Test connectivity between the OmniVista 2500 and the OmniSwitches
✓ Discover & Manage the OmniSwitches from the OmniVista 2500
Contents
1 Introduction .................................................................................... 3
2 Topology ........................................................................................ 3
3 Powering On the OmniVista 2500 NMS Virtual Machine .................................. 4
4 Configuring the SNMP ......................................................................... 6
4.1. Configuring SNMP in the 6360 VC ................................................................. 6
4.2. Configuring SNMP in the 6900-A ................................................................. 12
4.3. Configuring SNMP in the 6900-B ................................................................. 13
4.4. Configuring SNMP in the 6860A .................................................................. 13
4.5. Configuring SNMP in the 6860B .................................................................. 13
4.6. Configuring SNMP in the 6560-A ................................................................. 13
2
5 Discovering the OmniSwitches in the OmniVista 2500 ................................. 14

5.1. Connect to the OmniVista 2500 ................................................................. 14
5.2. Generating & Installing an Evaluation License ................................................ 15
5.3. Generating the Evaluation License .............................................................. 15
5.4. Installing the Evaluation License ................................................................ 16
5.5. Deleting the License File ......................................................................... 17
5.6. Create a Discovery Profile ....................................................................... 17
5.7. Discover the new devices ........................................................................ 17
6 Displaying the Network Topology ......................................................... 18
7 Creating a VLAN and Ip interface ......................................................... 20
3
1 Introduction
Your company has just bought a set of OmniSwitches and wants to manage them using a centralized platform.
The OmniVista 2500 NMS is a management system that will be used to monitor and configure the switches.
In this lab, your task is to the setup the basic parameters needed in the OmniSwitches and OmniVista server to
be able to discover the switches in the OmniVista, and to arrange them on a map so the physical links between
them can be monitored.
2 Topology
The OmniVista 2500 NMS Virtual Appliance has already been deployed in the R-Lab infrastructure. Its initial
parameters (IP address, size of network, license) have also been configured
The OmniVista 2500 server is configured with an IP address of 192.168.100.107/24

4
3 Powering On the OmniVista 2500 NMS Virtual Machine
- Open the vSphere client and log into vCenter:

o Make sure that Use Windows session credentials is checked
o Click on Login button to login into vCenter:
- Select the Virtual Machine PodX_OV (X = R-Lab Number), then right-click on it and select Snapshot ->
Snapshot Manager…:
Warning
THE NAME OF THE VM MAY BE DIFFERENT ACCORDING TO THE OV VERSION INSTALLED IN THE POD.
MAKE SURE THAT YOU ARE SELECTING THE “OV…” VM.
5
- In the Snapshot Manager window, Select OV-Init and click on Go to.
- Click Yes to confirm reverting to the snapshot, then click Close:
- Check the progress in the Status Bar, at the bottom of the screen.
- Once it is completed, right-click on the VM PodX_OV and select Power -> Power On
Tips
It takes 10-15 minutes for the OmniVista 2500 NMS virtual machine to boot up completely. You cannot access it
right away. Continue with the following part to learn how to configure the OmniSwitches parameters. You will
come back to the OmniVista later in this lab.
6
4 Configuring the SNMP

SNMP is the communication protocol between the OmniSwitches and the OmniVista 2500 NMS.
Your task is to configure the SNMP on the access switches (6360 Virtual Chassis).
For the Access training (215) this management has already been done for the core and distribution
switches. Not for training bootcamp (220) and advanced (216)
4.1. Configuring SNMP in the 6360 VC

- Allow access to all management interfaces including SNMP:
sw5 (6360-A) -> aaa authentication default local
sw5 (6360-A) -> aaa authentication snmp local
- Create an SNMP user account, set the read-write rights, and enable the SHA+DES encryption:
sw5 (6360-A) -> user snmpuserv3 read-write all password Superuser01= sha+des
Fri Jun 25 22:53:15 : AAA Switch-Access INFO message:

+++ User snmpuserv3 created by admin.
- Declare the OmniVista Server as management station (ex. IP@ of OV2500 Server: 192.168.100.107):
sw5 (6360-A) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
- We will use the Loopback0 IP interface address for the communication between the OmniVista and the
OmniSwitches. Manage the Loopback0 on the switch:
Total 6 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
EMP-CHAS2 10.4.21.6 255.255.255.0 UP NO EMP
- Select the IP interface as source for the SNMP protocol:

sw5 (6360-A) -> ip service source-ip loopback0 snmp
sw5 (6360-A) -> show ip service source-ip
Application Interface-name
-------------+--------------------------------
dns -
ftp -
ldap -
ntp -
radius -
sflow -
snmp Loopback0
ssh -
swlog -
tacacs -
telnet -
tftp - -
7
- Ping the OmniVista via the source interface Loopback0:
sw5 (6360-A) -> ping 192.168.100.107 source-interface Loopback0

PING 192.168.100.107 (192.168.100.107) from 192.168.254.5 : 56(84) bytes of data.
ping: sendmsg: Network is unreachable
--- 192.168.100.107 ping statistics ---

- As it is not working, check the IP routes table on the switch:

Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 3d19h LOCAL
192.168.254.5/32 192.168.254.5 00:04:58 LOCAL
- There is no route on the OS6360 VC to reach the network 192.168.100.0
- Check the presence of a route to the network 192.168.100.0 on the 6860-A and 6860-B:

Total 22 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 172.16.17.1 00:46:05 OSPF
10.0.0.51/32 172.16.17.1 00:46:05 OSPF
127.0.0.1/32 127.0.0.1 1d 1h LOCAL
172.16.12.0/24 172.16.17.1 02:26:02 OSPF
172.16.17.0/24 172.16.17.7 20:58:27 LOCAL
172.16.28.0/24 172.16.78.8 02:24:53 OSPF
172.16.78.0/24 172.16.78.7 21:03:28 LOCAL
---
192.168.20.0/24 192.168.20.7 18:45:23 LOCAL
192.168.30.0/24 192.168.30.7 18:03:46 LOCAL
---
192.168.100.0/24 172.16.17.1 00:47:26 OSPF
---
192.168.254.1/32 172.16.17.1 02:26:02 OSPF
192.168.254.2/32 +172.16.17.1 02:25:47 OSPF
+172.16.78.8 02:24:30 OSPF
---
192.168.254.7/32 192.168.254.7 02:35:59 LOCAL
192.168.254.8/32 172.16.78.8 02:25:36 OSPF
8

Total 24 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 +172.16.28.2 00:46:49 OSPF
+172.16.78.7 00:46:49 OSPF
10.0.0.51/32 +172.16.28.2 00:46:49 OSPF
+172.16.78.7 00:46:49 OSPF
127.0.0.1/32 127.0.0.1 1d 1h LOCAL
172.16.12.0/24 172.16.28.2 02:25:15 OSPF
172.16.17.0/24 172.16.78.7 02:25:39 OSPF
172.16.28.0/24 172.16.28.8 02:36:24 LOCAL
172.16.78.0/24 172.16.78.8 21:04:10 LOCAL
---
192.168.20.0/24 192.168.20.8 18:04:15 LOCAL
192.168.30.0/24 192.168.30.8 18:46:18 LOCAL
---
192.168.100.0/24 +172.16.28.2 00:48:11 OSPF
+172.16.78.7 00:48:11 OSPF
--
192.168.254.1/32 +172.16.28.2 02:25:15 OSPF
+172.16.78.7 02:25:39 OSPF
192.168.254.2/32 172.16.28.2 02:25:15 OSPF
---
192.168.254.7/32 172.16.78.7 02:26:21 OSPF
192.168.254.8/32 192.168.254.8 02:27:07 LOCAL
- Try to ping the OmniVista from the 6860-A and the 6860-B:

sw8 (6860-B) -> ping 192.168.100.107 source-interface Loopback0

To be able to reach the OmniVista 2500 from the 6360 VC, a default route must be created on it.
Notes > Reminder: Connection between the 6360 VC and the 6860s
The 6360 is connected to both 6860s:
- Connection to the 6860-A through the link aggregation 7 (VLAN 57)
- Connection to the 6860-B through the link aggregation 8 (VLAN 57)
- Create an IP interface for the VLAN 57 on the 6360-A VC:

9
Total 7 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.5 255.255.255.0 UP NO EMP
EMP-CHAS2 10.4.21.6 255.255.255.0 UP NO EMP
int_57 192.168.57.5 255.255.255.0 UP YES vlan 57
- Create an IP interface to the VLAN 57 on the 6860-A:

Total 11 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.7 255.255.255.0 UP NO EMP
int_20 192.168.20.7 255.255.255.0 UP YES vlan 20
int_217 172.16.17.7 255.255.255.0 UP YES vlan 217
int_278 172.16.78.7 255.255.255.0 UP YES vlan 278
int_30 192.168.30.7 255.255.255.0 UP YES vlan 30
int_57 192.168.57.7 255.255.255.0 UP YES vlan 57
---
- Redistribute this local route to ospf

Notes >
For trainee who attend access training (215). Dynamic routing protocol is fully explained on advanced training.
Objective of this command is to update automatically routing table on core switches via ospf protocol.
Some routes are not in the routing table in access training (215) due to a different ospf management on core
like subnet 80,60 ..etc
Before command (route not known on 6900-A table) After command route available (distribute via 0SPF)
10
- Create an IP interface to the VLAN 57 on the 6860-B:

Total 10 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.8 255.255.255.0 UP NO EMP
int_20 192.168.20.8 255.255.255.0 UP YES vlan 20
int_228 172.16.28.8 255.255.255.0 UP YES vlan 228
int_278 172.16.78.8 255.255.255.0 UP YES vlan 278
int_30 192.168.30.8 255.255.255.0 UP YES vlan 30
int_57 192.168.57.8 255.255.255.0 UP YES vlan 57
---

sw8 (6860-B) ip route-map localIntoOspf sequence-number 10 match ip-address 192.168.57.0/24 permit
Notes >
- Launch a ping between the 6360 VC and the 6860-A/6860-B:

sw5 (6360-A) -> ping 192.168.57.7
^C
--- 192.168.57.7 ping statistics ---
sw5 (6360-A) -> ping 192.168.57.8

--- 192.168.57.8 ping statistics ---

- Manage 2 default routes on the 6360 VC:

o One going through the 6860-A (metric 1)
o The other one going through 6860-B (metric 2)
sw5 (6360-A) -> ip static-route 0.0.0.0/0 gateway 192.168.57.7 metric 1
sw5 (6360-A) -> ip static-route 0.0.0.0/0 gateway 192.168.57.8 metric 2
11
- Try to ping the OmniVista internal address from the int_57 interface:
sw5 (6360-A) -> ping 192.168.100.107 source-interface int_57

- As we want to use the Loopback0 to communicate with the OmniVista, launch a ping from the Loopback0
interface:
--- 192.168.100.107 ping statistics ---

- Why is it not working?

----------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
- Check the routes on the 6860-A and 6860-B:

Total 14 routes

------------------+-------------------+----------+-----------
---
192.168.254.1/32 172.16.17.1 1d22h OSPF
192.168.254.2/32 172.16.78.8 1d22h OSPF
192.168.254.7/32 192.168.254.7 1d22h LOCAL
192.168.254.8/32 172.16.78.8 1d22h OSPF
----

Total 16 routes

------------------+-------------------+----------+-----------
----
192.168.254.1/32 172.16.78.7 1d22h OSPF
192.168.254.2/32 172.16.28.2 1d22h OSPF
192.168.254.7/32 172.16.78.7 1d22h OSPF
192.168.254.8/32 192.168.254.8 1d22h LOCAL
-----
There is no return route!
- Create these return route on each 6860: for “192.168.57.5”

sw7 (6860-A) -> ip static-route 192.168.254.5/32 gateway 192.168.57.5
sw8 (6860-B) -> ip static-route 192.168.254.5/32 gateway 192.168.57.5

12

sw7 (6860-A) -> ip route-map "staticIntoOspf" sequence-number 10 action permit
sw7 (6860-A) -> ip route-map staticIntoOspf sequence-number 10 match ip-address 192.168.254.5/32 permit
sw7 (6860-A) -> ip redist static into ospf route-map "staticIntoOspf" admin-state enable
sw8 (6860-B) -> ip route-map "staticIntoOspf" sequence-number 10 action permit

sw8 (6860-B) -> ip route-map staticIntoOspf sequence-number 10 match ip-address 192.168.254.5/32 permit
sw8 (6860-B) -> ip redist static into ospf route-map "staticIntoOspf" admin-state enable
Notes >
Notes
These static routes will be automatically broadcasted on the core network thanks to the routing process
running between the core switches (6900 and 6860).
- Check that the route also appears on the 6900-A:

---
192.168.254.5/32 +172.16.17.7 00:00:10 OSPF
-----
- Try to ping the OmniVista internal address through the Loopback0 interface:

--- 192.168.100.107 ping statistics ---

sw5 (6360-A) ->
4.2. Configuring SNMP in the 6900-A

Sw1 (6900-A) -> aaa authentication default local
Sw1 (6900-A) -> aaa authentication snmp local
Sw1 (6900-A) -> user snmpuserv3 read-write all password Superuser01= sha+des
- Declare the OmniVista Server as management station (ex. IP@ of OV 2500 Server: 192.168.100.107):
Sw1 (6900-A) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
13
4.3. Configuring SNMP in the 6900-B

sw2 (6900-B) -> aaa authentication default local
sw2 (6900-B) -> aaa authentication snmp local
sw2 (6900-B) -> user snmpuserv3 read-write all password Superuser01= sha+des
sw2 (6900-B) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
4.4. Configuring SNMP in the 6860A

Sw7 (6860-A) -> aaa authentication default local
Sw7 (6860-A) -> aaa authentication snmp local
Sw7 (6860-A) -> user snmpuserv3 read-write all password Superuser01= sha+des
Sw7 (6860-A) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
4.5. Configuring SNMP in the 6860B

Sw8 (6860-B) -> aaa authentication default local
Sw8 (6860-B) -> aaa authentication snmp local
Sw8 (6860-B) -> user snmpuserv3 read-write all password Superuser01= sha+des
Sw8 (6860-B) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
4.6. Configuring SNMP in the 6560-A

sw3 (6560-A) -> aaa authentication default local
sw3 (6560-A) -> aaa authentication snmp local
sw3 (6560-A) -> user snmpuserv3 read-write all password Superuser01= sha+des
sw3 (6560-A) -> snmp station 192.168.100.107 snmpuserv3 v3 enable
The Configuration of the OmniSwitches is now complete. The next step consists in discovering the
OmniSwitches in the OmniVista 2500 NMS.
14
5 Discovering the OmniSwitches in the OmniVista 2500

Your next task is the discovery of the OmniSwitches in the OmniVista. The following procedure applies to all
new or existing devices that you want to manage from the platform.
5.1. Connect to the OmniVista 2500

- Launch a Web Browser from the Remote Desktop client and enter the following URL according to the
diagram: https://10.4.Pod#.208:8443.
Notes
The Remote-Lab is configured for the OmniVista 2500 NMS platform to be reached directly from the Windows
Desktop of the access machine, allowing an easier access.
- Launch a web browser from the Windows desktop and enter the following URL (see diagram below):
https://10.4.Pod#.208:8443.
- Enter the credentials (admin/switch), then click on Sign In.

15
- A message box appears to add the license(s)
5.2. Generating & Installing an Evaluation License
An Evaluation License provides full OmniVista 2500 NMS feature functionality, but it is valid only
for 90 Days (starting from the date the license is generated). There is one file that contains all of
the Device (AOS, Third-Party, Stellar APs) and Service Licenses (VM, Guest, BYOD).
In this section, you will learn how to generate and install an evaluation license
Tips > Evaluation License

This part is NOT ONLY dedicated for training. Don’t hesitate to use the same process if you need to generate an
evaluation license for your own testing purpose (lab…).
5.3. Generating the Evaluation License
- From the Windows Desktop, open a new web browser tab/window:
- Copy & Paste the following URL in your RDP session: https://lds.al-enterprise.com/
- Click on OmniVista 2500 NMS
- Enter:
o Customer ID: 99999
o Order Number: evaluation
o Leave the Customer Email field blank
- Click on Submit
- Select the License Type: EVAL-OV2500-ALL-TYPE_1
- Enter the Passcode: omnivista

16
- Click on Submit Entry
- Enter Company Name: ALE (or something else)
- Click on Generate License
- Save the file locally
- By entering your mail you can receive the license information by mail.
5.4. Installing the Evaluation License
- Go back to the OmniVista 2500 NMS webpage:
> Go back to the OV 2500 Web Admin Interface

> Click on Add License
> License File: click on Browse
> Select the license file downloaded in the previous part
> Click on Open
> Click on Submit
Software and/or documentation End-User License Agreement “EULA”

> Check OK (don’t check Enable ProActive Lifecycle Management)
Disable Enable ProActive

Lifecycle Management
Click on OK
- The main Dashboard will be shown once the licenses are applied correctly
17
5.5. Deleting the License File
Once the license file correctly inserted, please delete the file (“EVAL…”) from the
computer.
5.6. Create a Discovery Profile

- Select Network > Discovery > Discovery Profiles:
Click on the “+” button to add a new Discovery profile.
- In the Create Discovery Profile screen, General section, enter the following parameters:
Name: Training
CLI/FTP User Name: admin
CLI/FTP Password: switch
Confirm CLI/FTP Password: switch
- Below the General section, click on SNMP, and enter the following parameters:
SNMP Version: SNMPv3
Timeout (msec): 5000
Retry count: 3
User Name: snmpuserv3
Auth & Priv Protocol: SHA+DES
Auth Password: Superuser01=
Confirm Auth Password: Superuser01=
Priv Password: Superuser01=
Confirm Priv Password: Superuser01=
- Click on Create to finish the creation of the Discovery Profile.
5.7. Discover the new devices

- Select Managed Devices on the left menu and then click on Discover New Devices on the top right.
- Select the “+” button on the right and enter the following parameters:
Start IP: 192.168.254.1
End IP: 192.168.254.8
Subnet Mask: 255.255.255.0
Description: Training Switch
- Click on the box to select the Training profile from Choose Discovery Profiles
- Click on “+” to move it to the right
18
- Click Create and select the ranges from the list (click on the box) and select Discover Now.
- The discovery process will start. Click on Finish when the discovery is completed.
- You should see the discovered devices in the Managed Devices window. You can also find additional
information about the status of the switch, its IP address, the type of switch discovered, and the
firmware version used.
6 Displaying the Network Topology

The last task for this map consists in arranging the switches in a Map. This will allow to monitor the devices
in a better way as the connections between them are always shown and you can easily identify if a link
failure occurs in your network because the links are continuously updated.
- Click on Network > Topology > Physical Network
- On the top right, click on Map Level Action and then on New map
- Give your network map a Name:

Map Name: training-map
- Select and Add all the discovered switches to this map (click on the square and then “+”) or use add item
icone (> or >>)
19
- Then click Create
- Arrange the switches according to the initial diagram so all the links are displayed
Any active link is automatically detected by OmniVista LLDP.
If a link is not being shown in the map, select the switch and look for the Operations window
on the right. Select Poll Device or Poll Link and then wait for a moment to synchronize.
- Left click on a switch to see the various options. From the menu on the right you have the capability to
manage your switches.
Your network can now be managed and monitored from the OmniVista 2500 NMS platform.
20
7 Creating a VLAN and Ip interface

The OmniSwitches that have been discovered in the OmniVista 2500 can now be configured from the
OmniVista web administration page. To demonstrate that, we will create, in this part, a VLAN and its
dedicated IP interface on the OmniSwitch 6900-A, all from the OmniVista.
- Create the VLAN 110 on the 6900-A from the OmniVista 2500 web page:
> Select CONFIGURATION > VLANS > VLAN
> Click on Create VLAN by Devices button
1. Devices Selection
> VLAN IDs: 110
> VLAN(s) Description: SERVERS
> Click on the Add/Remove Devices
> Select the 6900-A (192.168.254.1), then click on > to add it as selected
> Click on OK
> Click on Next
2. VLAN Configuration
> Check that Admin Status = Enabled
> Click on Next
3. Default Port Assignment

> For the switch, click on Add Port
> Select the port 1/1/1
> Click on OK
> Click on Next
4. Q-Tagged Port Assignment

> Click on Next (skip this part)
5. Review
> Review the information
> Click on Create
- Create the IP interface int_110 for this new VLAN 110:

> Select CONFIGURATION > VLANS > IP Interface
> Click on the + button
> Name: int_110
> IP Address: 192.168.110.1
> Subnet Mask: 255.255.255.0
> Device Type: VLAN
> VLAN ID: 110
> Devices: select the OS6900-A (192.168.254.1), then click on > to add it as selected
> Click on Create
- Check that the VLAN and IP interface are now displayed in the 6900-A:

------+-------+-------+------+------+------+------------------
110 std Ena Ena Ena 1500 Servers
--

port type status
----------+-----------+---------------
1/1/1 untagged inactive
21
Total 8 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.1 255.255.255.0 UP NO EMP
int_100 192.168.100.1 255.255.255.0 UP YES vlan 100
int_110 192.168.110.1 255.255.255.0 DOWN NO vlan 110
int_212 172.16.12.1 255.255.255.0 UP YES vlan 212
int_217 172.16.17.1 255.255.255.0 UP YES vlan 217
- Activate the interface 1/1/1 (where Client 1 is connected):


Total 8 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
EMP-CHAS1 10.4.21.1 255.255.255.0 UP NO EMP
int_100 192.168.100.1 255.255.255.0 UP YES vlan 100
int_110 192.168.110.1 255.255.255.0 UP YES vlan 110
int_212 172.16.12.1 255.255.255.0 UP YES vlan 212
int_217 172.16.17.1 255.255.255.0 UP YES vlan 217
- For the next lab, configure the following IP address for the Client 1
Client 1:
IP address = 192.168.110.51
Subnet mask = 255.255.255.0
Preferred DNS Server = 10.0.0.51

Notes >
For trainee who attend access training. Dynamic routing protocol is fully explained on advanced training.
Some routes are not in the routing table in access training (215) due to a different ospf management on core
like subnet 80,60 ..etc
Before command (route not known on 6860-A table) After command route available (distribute via 0SPF)
22
OMNISWITCH R8
ACCESS CONTROL LISTS (ACL)
OBJECTIVES
• Understand the benefits of using ACLs

• Implement ACL on an OmniSwitch switch
• Advanced ACL Groups
• Goal
• QoS policies used to control whether or not packet QOS
flows are allowed or denied at the switch or router
interface Basic QOS 802.1p/ToS/DSCP
* Traffic prioritization
* Marking
* Bandwidth shaping
* Stamping
* Queuing management
• How it works
• Policies for ACLs are created in the same manner as Policy Based Routing Filtering
QoS policies * Layer 2 and
* Routed traffic redirecting
• Customizable Groups for conditions Layer 3/4 ACLs
• Network group
• MAC group Policy Based Mirroring ICMP Policies
• Service group * Mirror traffic based on QoS
* Filtering
* Prioritizing
• Port group policies
* Rate limiting traffic (security)
Access Guardian
* User Network Profile
policy condition
ACCESS CONTROL LISTS (ACL) LAYER 2 ACL

CONDITION KEYWORDS
LAYER 3 ACL
CONDITION KEYWORDS
MULTICAST ACL
CONDITION KEYWORDS
source mac source ip multicast ip
Packet classification source mac group

destination mac
source ipv6
source network group
multicast network
group
destination mac group destination ip destination ip
source vlan destination ipv6 destination vlan
PACKET CLASSIFICATION source port destination network destination port
source port group group destination port group
CONDITION ACTION destination port source ip port destination mac
destination port group destination ip port destination mac group
DISPOSITION FORWARD / BLOCK
ethertype service
---- accept | drop | deny 802.1p service group
OUTGOING TRAFFIC
ip protocol
ipv6
POLICY RULE nh
INCOMING PACKET flow-label
destination port
destination port group
policy action icmptype
icmpcode
accept | drop | deny TOS DSCP
source tcp port
destination tcp port
source udp port
destination udp port
established
Tcpflags
policy rule rule_name [enable | disable] [precedence precedence] [condition condition]

[action action] [validity-period name] [save][log [log-interval seconds]]
[count {packets | bytes}] [trap] [default-list]
policy rule rule_name no {validity-period | save | log | trap | default-list}
no policy rule rule_name

Step by Step
Global Parameters
Setting Up Policies
Configuration Examples
Monitoring Policies
Step by Step
Global Parameters
Description Command/keyword
By default, QoS is enabled on the switch. If QoS policies are qos enable/disable
configured and applied, the switch attempts to classify and
apply relevant policy actions
Resets the QoS configuration to its defaults qos reset
Deletes the pending configuration qos revert
Flushes the configuration qos flush
Apply the configuration qos apply
* By default, flows that do not match any policies are accepted on the switch
PACKET CLASSIFICATION

CONDITION ACTION
---- DISPOSITION ACCEPT OR DENIED
Step by Step POLICY RULE
Setting Up Policies LAYER 2 ACL

CONDITION KEYWORDS
LAYER 3 ACL
CONDITION KEYWORDS
MULTICAST ACL
CONDITION KEYWORDS
source mac source ip multicast ip
1 source mac group source ipv6 multicast network
destination mac source network group group
-> policy port group pgroup1 1/1/1-5 2/1/1-2 destination mac group destination ip destination ip
source vlan destination ipv6 destination vlan
source port destination network group destination port
source port group source ip port destination port group
2 destination port destination ip port destination mac
destination port group service destination mac group
-> policy condition c2 source port group pgroup1 ethertype service group
802.1p ip protocol
ipv6
3 nh
flow-label
policy action a1 disposition accept destination port
destination port group
icmptype
4 icmpcode
TOS DSCP
policy rule rule7 precedence 65535 condition c2 action a1 source tcp port
destination tcp port
source udp port
destination udp port
5 established
Tcpflags
qos apply
Step by Step
Layer 2 ACL
Allows all bridged traffic except for traffic matching the source MAC address and VLAN 5
-> policy condition Cond-Deny-Host1 source mac D4:85:64:EC:33:EF source vlan 5
-> policy action Act-deny-Host1 disposition deny
-> policy rule Rule-Deny-Host1 condition Cond-Deny-Host1 action Act-deny-Host1 log
-> qos apply
Layer 3 ACL
Deny traffic from source IP address included in netgroup1
-> policy network group netgroup1 192.168.82.0 mask 255.255.255.0 192.60.83.0
-> policy condition lab1 source network group netgroup1
-> policy action deny_traffic disposition deny
-> policy rule lab_rule1 condition lab1 action deny_traffic precedence 65535
-> qos apply
Step by Step
Layer 3 ACL
Drop the Traffic with a source IP address of 192.68.82.0, a source IP port of 23, using
protocol 6 on the switch
Allows all bridged traffic except for traffic matching the source MAC address and VLAN 5
-> policy condition addr2 source ip 192.68.82.0 destination tcp-port 23
-> policy action Block disposition deny
-> policy rule FilterL31 condition addr2 action Block
Layer 3 ACL
Flows coming into the switch destined for any of the specified IP in GroupA is allowed
on the switch
-> policy network group GroupA 192.60.22.1 192.60.22.2 192.60.22.0
-> policy condition cond7 destination network group GroupA
-> policy action Ok disposition accept
-> policy rule FilterL32 condition cond7 action Ok
Step by Step
Monitoring Policies
-> show qos statistics
-> show qos config
-> show qos log
-> show active policy rules

ADVANCED ACL SECURITY FEATURES
QOS CONFIGURATION - SECURITY FEATURES
• UserPorts
• Reserved Group
• Used by default to prevent spoofed IP addresses on ports
• Packets received on the port are dropped if they contain a source IP network address that does not match
the IP subnet for the port
-> policy port group UserPorts slot/port[-port] [slot/port[-port]...]
• Done by creating a port group called UserPorts and adding the ports to that group
-> qos user-port {filter | shutdown} {spoof|bgp|bpdu|rip|ospf|vrrp|dvmrp|pim|isis|dhcpserver|dns-reply}
• Profiles can be configured to drop additional traffic such as RIP, OSPF,VRRP, DHCP, DNS,… or BPDUs
• To configure filtering of spoof, rip, ospf , bgp packets
-> policy port group UserPorts 1/1-24 2/1-24 3/1/1 4/1/1
-> qos user-port filter spoof rip ospf bgp
-> show qos log

…
12/17/10 14:27:39 12/17/16 14:27:39 Spoofed traffic triggered user-port shutdown of interface 1/1/21
…
• DropServices
• Reserved Group
• Used in conjunction with UserPorts to drop TCP/UDP packets
• Any services belonging to this group will be dropped if seen on ports included in the UserPorts
group -> policy service tcp135 destination tcp port 135
-> policy service tcp445 destination tcp port 445
-> policy service udp137 destination udp port 137
-> policy service group DropServices tcp135 tcp445 udp137
-> policy port groups UserPorts 1/1/1-24
• Drops all defined traffic seen on ports 1/1/1-24 in the UserPorts group
• Port Disable rule
• Used to administratively disable an interface when matching a policy rule
-> policy condition c1 source tcp port 1-1023
-> policy action a1 port-disable
-> policy port groups UserPorts 1/1/1
• To shutdown port 1/1/1 when packet with source tcp port 1-1023 is received
• ICMP drop rules
• Allows for configuring rules to drop ICMP requests and replies (Pings)
-> policy condition pingEchoRequest source vlan 10 icmptype 8
-> policy action drop disposition drop
-> policy rule noping10 condition pingEchoRequest action drop
Drops all ICMP requests from vlan 10
• TCP connection rules

• Established. Allows established TCP connections
• Tcpflags. Allows examination of specific TCP flags
• Configurable recovery timer that automatically re-enables the port

• When not configured, or configured to 0, the port will not be automatically re-enabled
-> interfaces violation-recovery-time <num>
• Time interval to re-enable the UserPort ports automatically after the UserPort ports are disabled administratively due to receiving a specified
type of traffic
-> interfaces violation-recovery-trap {enable | disable}
• UserPort ports to send out a port violation recovery trap when the UserPorts ports get reenabled after a timeout
• Early ARP discard
• Limitation of number of ARP packets sent to CPU
• ARP packets not destined for switch are not processed
• Enabled by default
• ARPs intended for use by a local subnet, AVLAN, VRRP, and Local Proxy ARP are not discarded
• ARP ACLs
• Source IP address examination in the header of ARP packets
• Directed Broadcasts
• IP datagram sent to broadcast address of subnet the user is not on
• Generates large number of responses to a spoofed host
-> ip directed-broadcast disable
THANK YOU
OmniSwitch R8
Access Control Lists (ACLs)
How to
✓ Setting up Access Control Lists (ACLs) on the OmniSwitches R8
Contents
1 Introduction .................................................................................... 2
1.1. Retrieving client’s information ................................................................... 2
2 Filtering L2 traffic ............................................................................ 3
3 Using the ICMP Filter ......................................................................... 3
4 Filtering HTTP & FTP Traffic ................................................................ 4
4.1. Filtering the FTP Traffic (OmniSwitch 6360 VC) ............................................... 4
4.1.1. Checking the access to the FTP Server .................................................................. 4
4.1.2. Testing the FTP Access .................................................................................... 4
4.2. Filtering the HTTP Traffic ......................................................................... 5
4.3. Filtering the HTTP Traffic ......................................................................... 5
4.4. Testing the Configuration ......................................................................... 5
5 Configuring User ports Security ............................................................. 6
2
1 Introduction
1.1. Retrieving client’s information

For this lab, you will need some information about client 5 and client 9.
- Retrieve the MAC address of the client 5 and 9 available in the 6360 VC MAC address table:
(example the mac address of your client may differ)


------------+----------------------+-------------------+------------------+-------------+-----------------
VLAN 20 00:50:56:90:22:3c dynamic bridging 1/1/1


------------+----------------------+-------------------+------------------+-------------+-----------------
VLAN 30 00:50:56:90:05:d4 dynamic bridging 1/1/2
3
2 Filtering L2 traffic
- First, reset the ACL/QoS configuration to its default settings:
sw5 (6360-A) -> qos reset
- Perform a permanent ping test from Client 5 to the gateway (192.168.20.254):
- Deny all the Layer 2 traffic coming from the Client 5:

sw5 (6360-A) -> policy condition cond1 source mac <Client 5 MAC address>
sw5 (6360-A) -> policy action DenyTraffic disposition deny
sw5 (6360-A) -> policy rule Filter1 condition cond1 action DenyTraffic
- Is the ping still working?

--------------------------------------------------------------------------------------------------------------------------
- Once the test is done, reset the default bridged disposition:

sw5 (6360-A) -> qos reset
3 Using the ICMP Filter

In the following example, we want to forbid an ICMP connection (ping) from the client 5 to the database
server (192.168.110.51).
- Launch a permanent ping from the Client 5 to the database server (192.168.110.51):
- Configure the ICMP filter:

sw5 (6360-A) -> policy condition icmpCondition source mac <Client 5 Mac address> ip-protocol 1 destination
ip 192.168.110.51
sw5 (6360-A) -> policy action icmpAction disposition deny

sw5 (6360-A) -> policy rule icmpRule condition icmpCondition action icmpAction
- Check the ping on the Client 5. What is the result?

----------------------------------------------------------------------------------------------------------------------------- ------
4
4 Filtering HTTP & FTP Traffic

Let’s get back to the use case where the VLAN 20 is dedicated for the employees, and the VLAN 30 is
dedicated for the contractors. Here are the rules that needs to be applied:
Service Grp = Service Grp =

User Type VLAN
HTTP FTP
Employees 20 ALLOW DENY
Contractors 30 DENY ALLOW
4.1. Filtering the FTP Traffic (OmniSwitch 6360 VC)
4.1.1. Checking the access to the FTP Server

- Before configuring the policies, check the FTP access (192.168.100.102):
o From the client 5 (VLAN 20)
From the Windows Command Prompt:

C:\> ftp 192.168.100.102
Client 5 Client 9
- To deny the FTP access for the employees (VLAN 20):

sw5 (6360-A) -> policy condition ftpfromvlan20 source vlan 20 destination ip-port 20-21 ip-protocol 6
sw5 (6360-A) -> policy action deny disposition deny
sw5 (6360-A) -> policy rule deny_ftp_employee condition ftpfromvlan20 action deny precedence 65535
- Check that you don’t have FTP access from the Client 5 (employee, VLAN 20), but it is still working fine
from the Client 9 (contractor, VLAN 30):
4.1.2. Testing the FTP Access

- Check that you don’t have FTP access from the Client 5 (employee, VLAN 20), but it is still working fine
from the Client 9 (contractor, VLAN 30):
/ Client 5 Client 9
FTP
5
4.2. Filtering the HTTP Traffic

- Before configuring the policies, check the HTTP access:
- Notes: Needed to add DNS server or check that the clients have the DNS server entry in the NIC.
Should be ok, provided via dhcp server.
From a web browser (ex. Firefox, Chrome):

URL: www.google.com
Client 5 Client 9
4.3. Filtering the HTTP Traffic

- To deny the HTTP access for the contractors (VLAN 30), create the policy services to identify the port
used by the HTTP protocol:
sw5 (6360-A) -> policy service http1 destination ip-port 80 protocol 6
- Regroup the policy services created in a policy group:

sw5 (6360-A) -> policy service group http from cli http1 http2 http3 http4 http5
- Create the policy condition and the policy rule:

sw5 (6360-A) -> policy condition httpfromvlan30 source vlan 30 destination ip any service group http
sw5 (6360-A) -> policy action deny disposition deny
sw5 (6360-A) -> policy rule deny_http_contractor condition httpfromvlan30 action deny precedence 65535
- Check that you don’t have HTTP access from the Client 9 (contractor, VLAN 30), but it is still working
fine from the Client 5 (employee, VLAN 20):
4.4. Testing the Configuration

- Check that you don’t have HTTP access from the Client 9 (contractor, VLAN 30), but it is still working
fine from the Client 5 (employee, VLAN 20):
/ Client 5 Client 9
HTTP
6
5 Configuring User ports Security

If network protocols, like STP, are not blocked from user ports, a rogue device can use these protocols and
disrupt normal network operation.
- To prevent IP source address spoofing, add ports to the port group called UserPorts:
sw5 (6360-A) -> policy port group Userports 1/1/1-2
Notes
This port group does not need to be used in a condition or rule to be effective on flows and only applies to
routed traffic. Ports added to the UserPorts group will block spoofed traffic while still allowing normal traffic
on the port
- To avoid any loop in the network, any user access port used will be blocked if a Spanning Tree frame is
received:
sw5 (6360-A) -> qos user-port shutdown bpdu
OMNISWITCH R8
ACCESS GUARDIAN
OBJECTIVES
• Describe Access Guardian

• Setup Access Guardian
- Port
- User Network Profile
- Classification Rule / policy
- Port-Templates
- Authentication server (Radius Server)
• Monitor the management
OVERVIEW
Goal
• Role Based Access Control with UNP (Universal Network Profile)
• Auto-sensing, multi-client authentication on a port
OVERVIEW
Authentication Method
How it works MAC-based (non-supplicant)
or
802.1x-based (supplicant)
VLAN ACCESS
10 ALL
EXECUTIVE RADIUS Access-Request
HIGH HIGH
RADIUS Access-Accept + UNP name { "user"
BWDTH PRIORITY User-Password="xxxxxx"
Filter-ID = "UNP-name"
}
VLAN INTERNET
30 ONLY
GUEST
MEDIUM LOW UNP R8

BWDTH PRIORITY VLAN ID VLAN ID
Policy List
Policy List
ACL QoS ACL QoS Restrict the network access based on the
location of the user/device
VLAN NO HR,
20 FINANCE DB Chassis/Slot/Port on which the user is attached
Period Switch Name on which the user is attached
EMPLOYEE Location
Switch Location String, identifying a group of
MEDIUM MEDIUM Switches
BWDTH PRIORITY
Specifies the days and times during
which a device can access the network
OVERVIEW
Example: Access control via UNP - Campus
Students can be authenticated via
Admin and teachers use 802.1X
either 802.1X or MAC based
authentication
Admin
Teacher Student
802.1X - Supplicant Non - Supplicant
1 – 802.1X/EAP Auth. frame sent with user/login 1 - Non-802.1X frame sent

2 - EAP intercepted by switch 2 - Non-802.1X frame intercepted by switch
3 – Switch modifies Radius frame with source MAC 3 - Switch builds auth. Request using source MAC as login/password
4 - Relays authentication frame to Server 4 - Authentication frame is sent to RADIUS Server
5 - Login/password validated 5 - MAC validated
6 - Device moved to appropriate UNP 6 - Device moved to appropriate UNP
7 - Login/password failed 7 - MAC failed
> Device moved to Default UNP for registration > Device moved to Default UNP for registration
Default Admin/Teacher Student

UNP UNP UNP
ACCESS GUARDIAN
OS9900 - OS6900 - OS6860E/N - OS6865
OS6560 - OS6465 - OS6360
ACCESS GUARDIAN FLOW
Device classification policies - Policies conceptual flow
UNP Port L2 Authentication
No No
802.1X MAC
No Auth
enabled ? Enabled?
Yes
No
Supplicant? Yes
Yes
Same branch as
802.1x 802.1x
Server Down Pass Fail

UNP Selection Classification
RADIUS Filter-Id
Rules
Timeout UNP Profile

Not valid UNP
No UNP UNP Profile
No
Server Down Alternate
UNP Profile UNP Profile
Default
UNP Profile
Block Block Block

CONFIGURATION STEPS
CONFIGURATION STEPS
Step by Step
Configure ports
Bridge Port
-> unp {port chassis/slot/port1[-port2] | linkagg agg_id1[-agg_id2]} port-type bridge
-> unp {port chassis/slot/port1[-port2] | linkagg agg_id[-agg_id2]} 802.1x-authentication
-> unp {port chassis/slot/port1[-port2] | linkagg agg_id[-agg_id2]} mac-authentication MAC or 802.1x
or
Classification rules
UNP profile
Example
VLAN ID

Policy List
-> unp port 1/1/1 802.1x-authentication
ACL QoS
-> unp port 1/1/1 mac-authentication
CONFIGURATION STEPS
Step by Step
Configure UNP policy validity-location

-> unp policy validity-location policy_name [port chassis/slot/port[-port2] |
linkagg agg_id[-agg_id2] [system-name system_name] [system-location system_location]
UNP profile
VLAN ID
Policy List
ACL QoS
Example
-> unp policy validity-location ALE-Brest port 1/1/10 Location
-> unp policy validity-location ALE-Brest port 1/1/1-5
Period
CONFIGURATION STEPS
Step by Step
Configure UNP policy validity-period

-> unp policy validity-period policy_name [days days] [months months] [hours
hh:mm to hh:mm] [interval mm:dd:yy hh:mm to mm:dd:yy hh:mm] [timezone zones]]
UNP profile
VLAN ID
Policy List
ACL QoS
Example
unp policy validity-period “Office-Time” Location
unp policy validity-period “Office-Time” days MONDAY
Period
unp policy validity-period “Office-Time” days MONDAY time-zone CET
unp policy validity-period “Office-Time” hours 9:00 to 17:00
CONFIGURATION STEPS
Step by Step
Configure UNP policy list

policy list list_name type unp [enable | disable]
UNP profile
Assigns existing QoS policy rules to the specified QoS policy list VLAN ID
policy list list_name rules rule_name [rule_name2...] Policy List
ACL QoS
Example: the policies already created (ACL chapter)

Location
-> show active policy rule
Rule name : deny_ftp_employee Period
Precedence = 65535,
Condition name = ftpfromvlan20,
-> policy list deny_employees type unp enable

-> policy list deny_employees rules deny_ftp_employee
CONFIGURATION STEPS
Step by Step
Configure UNP profile

-> unp profile profile-name qos-policy-list list_name location-policy policy_name period-policy policy_name
-> unp profile profile_name map vlan vlan_id
Example
-> unp profile employee qos-policy-list deny_employees location-policy ALE-Brest period-policy Office-Time
-> unp profile employee map vlan 20
CONFIGURATION STEPS
L2 Authentication
Step by Step UNP Port
No No
802.1X MAC
No Auth
enabled ? Enabled?
Yes No Yes
Configure supplicant device classification policies Supplicant? Classification
Rules
Yes
-> unp port chassis/slot/port 802.1X- Same branch as
authentication [pass-alternate profile_name] 802.1x 802.1x
Server Down Pass Fail

RADIUS Filter-Id UNP Profile
Configure mac-authentication device classification policies
-> unp port chassis/slot/port mac- Timeout UNP Profile UNP Selection
authentication [pass-alternate profile_name]
Not valid
UNP Classification
No UNP
Rules
UNP Profile
Server Down Alternate

UNP Profile UNP Profile Default
UNP Profile
Block Block
Block
ACCESS GUARDIAN -CONFIGURATION STEPS
Step by Step Name
UNP Template Properties
802.1x authentication
802.1x authentication tx-period Specify the configuration parameters that
802.1x authentication max_req could be enabled on the UNP port/linkagg
802.1x authentication supp-timeout
UNP profile Templates Pass-alternate UNP-profile
Mac-authentication
Mac-authentication pass-alternate
UNP-Template
UNP-profile
Allow-eap
802.1x MAC authent. Classification
authent.
Group-id
Parameters AAA-profile
Bypass
Classification Default Failure-policy
Rules UNP Profile
VLAN
Policy List
Example
-> unp port-template 802.1X-template
Alternate AAA Profile
UNP Profile -> unp port-template 802.1x-template 802.1x-authentication
-> unp port-template 802.1x-template 802.1x-authentication pass-alternate corporate
VLAN Authentication -> unp port 2/1/1 port-template 802.1x-template
Policy List Accounting
-> aaa profile ap-1
-> aaa profile ap-1 device-authentication mac rad1 rad2
-> aaa profile ap-1 device-authentication 802.1x rad1 rad2
-> unp port 1/1/5 aaa-profile ap-1
AAA Profile
-> unp port 1/2/1-5 aaa-profile ap-1
802.1x authentication AAA profiles to define a custom, pre-defined AAA -> unp linkagg 10 aaa-profile ap-1
Captive-portal authentication configuration that can be applied to a specific set -> unp linkagg 2-5 aaa-profile ap-1
Mac authentication of UNP ports or through a Captive Portal profile.
Radius authentication/accounting servers
Syslog servers
CONFIGURATION STEPS
Step by Step
Configure a server as a RADIUS server on the switch
-> aaa radius-server my_radius host 192.168.100.102 key alcatel-lucent
UNP Port
Teacher Configure the switch “my_radius” for 802.1X device authentication /server accounting
802.1X -> aaa authentication 802.1x my_radius -> aaa accounting 802.1x my_radius
enabled ?
Yes
Create the required VLANs
no
-> vlan 10 admin-state disable name vlan10-block
Supplicant? Mac Auth
-> vlan 20 admin-state enable name vlan20-corporate
Yes no
Create the required UNP profile and map the profile to VLAN 10 and 20
802.1x
-> unp profile corporate -> unp profile def_unp
Classification -> unp profile corporate map vlan 20 -> unp profile def_unp map vlan 10
Pass Fail no Enable UNP on ports that will connect to user devices
RADIUS Filter-Id
Default
UNP Profile
Set the default UNP profile on the port
UNP Profile Block -> unp port 1/1/1 default-profile def_unp
Create an edge template to apply UNP port configuration parameters.

No UNP Block -> unp port-template 802.1X-template
Configure the template and define an alternate UNP profile to use if the RADIUS server
Alternate does not return a UNP profile
UNP Profile
-> unp port-template 802.1x-template 802.1x-authentication
-> unp port-template 802.1x-template 802.1x-authentication pass-alternate corporate
Assign the port template to a UNP port
Block -> unp port 1/1/1 port-template 802.1x-template
CONFIGURATION STEPS
Step by Step
Monitoring
Display information about ports configured for 802.1X
show unp chassis/slot/port config
Display a list of all users (supplicants) for one or more 802.1X ports
show unp user chassis/slot/port
Display a list of all non-802.1X users (non-supplicants) learned on one or more 802.1X ports
show unp user chassis/slot/port
Display the Access Guardian status of all users learned on 802.1X ports
show unp user details chassis/slot/port
Displays a list of RADIUS servers configured for MAC based authentication

show unp user chassis/slot/port statistics
CONFIGURATION STEPS
Step by Step
Monitoring
Displays Access Guardian 802.1X device classification policies configured
for 802.1X ports
show unp classification profile
Displays information about the global 802.1X configuration on the switch

show aaa device-authentication 802.1x
Displays information about accounting servers configured for 802.1X port-

based network access control
show accounting 802.1x
Display the Access Guardian status of all users learned on 802.1X ports
Show unp user
AUTHENTICATION SERVER CONFIGURATION
Step by Step
Configure Authentication Server

Configure the RADIUS server to use for device authentication (802.1X, MAC, or Captive Portal)
aaa radius-server server_name host {hostname | ip_address | ipv6_address} [hostname2 | ip_address2 |
ipv6_address2] {key secret | hash-key hash_secret | prompt-key}[salt salt | hash-salt hash_salt] [retransmit
retries] [timeout seconds] [auth-port auth_port] [acct-port acct_port] [vrf-name name] [ssl | no ssl]
Enable the MAC authentication session timer to determine the amount of time the user session
remains active after a successful login (the default time is set to 12 hours).
aaa mac session-timeout enable
Example Parameters Default
-> aaa radius-server my_radius host 192.168.100.102 key alcatel-lucent retries 3

-> aaa authentication 802.1x my_radius seconds 2
-> aaa authentication mac my_radius auth_port 1812
-> aaa accounting 802.1x my_radius
-> aaa accounting mac my_radius acct_port 1813
-> aaa mac session-timeout enable ssl | no ssl No ssl
Step by Step
Choose the source IP interface

Choose the source IP interface used by the application
-> ip service source-ip {Loopback0 | interface-name} [ldap] [tacacs] [radius] [snmp] [sflow]
[ntp] [swlog] [dns] [telnet] [ftp] [ssh] [tftp] [all]
Example
ip service source-ip loopback0 radius
-> show ip service source-ip

Application Interface-Name
-----------------+------------------------
tacacs -
ntp Loopback0
syslog -
ldap-server -
radius Loopback0
ftp -
Step by Step
Manage Authentication server down

Users are moved to a specific profile when RADIUS server is not available.
unp auth-server-down profile1 profile_name
Configures the policy for classifying the device when the authentication server is
not reachable.
unp auth-server-down-timeout seconds
Sets re-authentication time for the device to authenticate again with the RADIUS
server when it is classified according to the auth-server-down policy.
show unp global configuration
Auth Server Down Profile1 = ag_SrvDownPrf,
Auth Server Down Timeout = 60,
* When authentication server becomes reachable Users are re-authenticated

THANK YOU
OmniSwitch R8
Access Guardian
How to
✓ Configure the Access Guardian on OmniSwitch
Contents
1 Introduction .................................................................................... 2
2 Configuring the Access Guardian on the 6360 VC......................................... 3
3 Managing the Access Guardian feature on the 6360 VC ................................. 4
3.1. Declaring the RADIUS Server ...................................................................... 4
3.2. Creating the Policies ............................................................................... 4
3.3. Creating the Policy Lists ........................................................................... 4
3.4. Creating the User Network Profiles .............................................................. 5
3.5. Configuring the User Ports ........................................................................ 5
3.6. Testing the Configuration ......................................................................... 5
3.7. Testing the Radius Configuration................................................................. 5
3.8. Testing the Access Guardian ...................................................................... 6
2
Access Guardian
1 Introduction
During this lab, we will configure the Access Guardian feature on the access switches, the 6360 VC.
Use ACL rules created in the previous lab and apply it in UNP Profiles.
The authentication of the network users will be done via a RADIUS server. On our infrastructure, the RADIUS
server is installed on a virtual machine (name: AAA Training Server), and its IP address is 192.168.100.102.
Once authenticated, a Universal Network Profile (UNP) will be applied to the network users. More
information about the UNP profiles to create is provided in the following pages of this lab.
3
Access Guardian
2 Configuring the Access Guardian on the 6360 VC

In the following parts, we will perform the following tasks on the 6360 VC:
- Declaration of the RADIUS server in the OmniSwitch
- Configure the User Network Profiles which will be applied to the network users:
USER TYPE AUTHENTICATION VLAN UNP POLICY LIST
Employee 802.1x 20 UNP-employee deny_employee
Contractor 802.1x 30 UNP-contractor deny_contractor
Notes:
@MAC Auth: as there are no MAC addresses configured on the RADIUS server, the user will be blocked from
accessing the network via a MAC address authentication.
During this lab, we will use the policies (ACLs) on the 6360 VC configured in the ACLs lab, and apply them to
the employee or contractor once authenticated:
Service Grp = Service Grp =

User Type VLAN
HTTP FTP
Employees 20 ALLOW DENY
Contractors 30 DENY ALLOW

4
Access Guardian
3 Managing the Access Guardian feature on the 6360 VC
3.1. Declaring the RADIUS Server

- Declare the RADIUS Server on the 6360-A:
sw5 (6360-A) -> aaa radius-server my_radius host 192.168.100.102 key alcatel-lucent
sw5 (6360-A) -> aaa device-authentication 802.1x my_radius
sw5 (6360-A) -> aaa device-authentication mac my_radius
sw5 (6360-A) - >aaa accounting 802.1x my_radius
sw5 (6360-A) -> aaa accounting mac my_radius
sw5 (6360-A) -> ip service source-ip Loopback0 radius
3.2. Creating the Policies

- We have already created the policies that we are going to use during this lab (“ACLs” lab) on the 6560.
To check the currently active policies:
Rule name : deny_ftp_employee
Precedence = 65535,
Condition name = ftpfromvlan20,
Action name = deny
Rule name : deny_http_contractor
Precedence = 65535,
Condition name = httpfromvlan30,
Action name = deny
3.3. Creating the Policy Lists

- Create a policy list to deny the FTP access for the employees (VLAN 20):
sw5 (6360-A) -> policy list deny_employees type unp enable
sw5 (6360-A) -> policy list deny_employees rules deny_ftp_employee
- Create a policy list to deny the HTTP access for the contractors (VLAN 30):
sw5 (6360-A) -> policy list deny_contractors type unp enable
sw5 (6360-A) -> policy list deny_contractors rules deny_http_contractor
- Apply the modifications:

5
Access Guardian
3.4. Creating the User Network Profiles

- Create the UNP edge profiles:
sw5 (6360-A) -> unp profile UNP-employee
sw5 (6360-A) -> unp profile UNP-contractor
sw5 (6360-A) -> unp profile UNP-employee qos-policy-list deny_employees
sw5 (6360-A) -> unp profile UNP-contractor qos-policy-list deny_contractors
sw5 (6360-A) -> unp profile UNP-employee map vlan 20
sw5 (6360-A) -> unp profile UNP-contractor map vlan 30
Notes:
A supplicant user (that seeks to authenticate) is authenticated by the RADIUS Server which sends
back the UNP profile name as Filter-Id attibutes (UNP-employee or UNP-contractor).
3.5. Configuring the User Ports

- Configure authentication on port 1/1/1 (Client 5) :
sw5 (6360-A) -> unp port 1/1/1 port-type bridge
sw5 (6360-A) -> unp port 1/1/1 802.1x-authentication
sw5 (6360-A) -> unp port 1/1/1 mac-authentication
3.6. Testing the Configuration

- To verify the profile configuration for a UNP profile (ex. UNP-contractor):
sw5 (6360-A) -> show unp profile UNP-contractor
Profile Name: UNP-contractor
Qos Policy = deny_contractors,
Location Policy = -,
Period Policy = -,
CP Profile = -,
CP State = Dis,
Authen Flag = Dis,
Mobile Tag = Dis,
SAA Profile = -,
Ingress BW = -,
Egress BW = -,
Ingress Depth = -,
Egress Depth = -,
Inact Interval = 10,
Mac-Mobility = Dis,
Kerberos Auth = Dis
- To verify the VLAN mapping for each profile, type:

sw5 (6360-A) -> show unp profile map vlan
Profile Name Vlan
UNP-employee 20
UNP-contractor 30
Total Profile Vlan-Map Count: 2
3.7. Testing the Radius Configuration

- Check that the RADIUS server is properly configured and reachable:
-> aaa test-radius-server my_radius type authentication user employee password password
Testing Radius Server <192.168.100.102/My_radius>
Access-Challenge from 192.168.100.102 Port 1812 Time: 174 ms
Filter-ID = UNP-employee
Access-Challenge from 192.168.100.102 Port 1812 Time: 16 ms
Access-Accept from 192.168.100.102 Port 1812 Time: 18 ms
Returned Attributes
User Name = employee
6
Access Guardian
3.8. Testing the Access Guardian

- Open the Client 5 console from vSphere:
Client 5
Open the Networks
Connections and right-click
on the Pod connection
Click on Properties
Select the Authentication tab
Tips
If the Authentication tab is not available, click on the Start button, Run…, type services.msc and
click Ok. Look for Wired AutoConfig service and start it. Now the Authentication should be
available
7
Access Guardian
- Check the box Enable IEEE

802.1X authentication
- Uncheck the box Cache user

information for subsequent
connections to this network
Click on Settings and uncheck

Validate server certificate.
Keep default authentication

method (Secured password
EAP-MSCHAP v2) and click on
Configure…
Uncheck the box

Automatically use my
windows logon name and
password
Click on OK three times to leave LAN connections properties.
- Reinitialize the port 1/1/1 (where is connected the Client 5):

- Disable and re-enable the network interface from client 5.
- You should get a pop-up asking to connect on the network.
- Logon now with the following credentials:

User name = employee
Password = password
- Check the user status:

sw5 (6360-A) -> show unp user
User
Port Username Mac address IP Vlan Profile Type Status
-------+-------------+-----------------+---------------+----+-------------+------------+-----------
1/1/1 employee 00:50:56:90:f7:ad 192.168.20.86 20 UNP-employee Bridge Active
8
Access Guardian
sw5 (6360-A) -> show unp user status

Port Mac address Profile Name Source Type Status Role Name Role Source CP Kerberos Redirect
Access
-------+-----------------+---------------+-------+------+-------------+---------------+-------------+--+--------+--------
1/1/1 00:50:56:90:f7:ad UNP-employee Radius 802.1x Authenticated deny_employees L2-Profile N N Y
sw5 (6360-A) -> show unp user details

Port: 1/1/1
MAC-Address: 00:50:56:90:f7:ad
SAP = -,
Service ID = 0,
VNID = 0 ( 0. 0. 0),
VPNID = 0 ( 0. 0. 0),
ISID = 0,
Access Timestamp = 08/01/2015 03:00:21,
User Name = employee,
IP-Address = 192.168.20.86,
Vlan = 20,
Authentication Type = 802.1x,
Authentication Status = Authenticated,
Authentication Failure Reason = -,
Authentication Retry Count = 0,
Authentication Server IP Used = 192.168.100.102,
Authentication Server Used = my_radius,
Server Reply-Message = -,
Profile = UNP-employee,
Profile Source = Auth - Pass - Server UNP,
Profile From Auth Server = UNP-employee,
Session Timeout = 0,
Classification Profile Rule = -,
Role = deny_employees,
Role Source = L2-Profile,
User Role Rule = -,
Restricted Access = No,
Location Policy Status = -,
Time Policy Status = -,
QMR Status = Passed,
Redirect Url = -,
SIP Call Type = Not in a call,
SIP Media Type = None,
Applications = None,
Encap Value = -


- Logon now with the following credentials:
User name = contractor
Password = password
- Check the user status:

User
Port Username Mac address IP Vlan Profile Type Status
-------+-------------+-----------------+---------------+----+----------------------+------------+---------
1/1/1 contractor 00:50:56:90:f7:ad 192.168.30.81 30 UNP-contractor Bridge Active
sw5 (6360-A) -> show unp user status

Port Mac address Profile Name Source Type Status Role Name Role Source CP Kerberos Redirect
Access
-------+-----------------+--------------+-------+-------+-------------+-----------------+--+--+--------+--------+--------
1/1/1 00:50:56:90:f7:ad UNP-contractor Radius 802.1x Authenticated deny_contractors L2-Profile N N Y
9
Access Guardian
sw5 (6360-A) -> show unp user details

Port: 1/1/1
MAC-Address: 00:50:56:90:f7:ad
SAP = -,
Service ID = 0,
VNID = 0 ( 0. 0. 0),
VPNID = 0 ( 0. 0. 0),
ISID = 0,
Access Timestamp = 08/01/2015 03:14:52,
User Name = contractor,
IP-Address = 192.168.30.81,
Vlan = 30,
Authentication Type = 802.1x,
Authentication Status = Authenticated,
Authentication Failure Reason = -,
Authentication Retry Count = 0,
Authentication Server IP Used = 192.168.100.102,
Authentication Server Used = my_radius,
Server Reply-Message = -,
Profile = UNP-contractor,
Profile Source = Auth - Pass - Server UNP,
Profile From Auth Server = UNP-contractor,
Session Timeout = 0,
Classification Profile Rule = -,
Role = deny_contractors,
Role Source = L2-Profile,
User Role Rule = -,
Restricted Access = No,
Location Policy Status = -,
Time Policy Status = -,
QMR Status = Passed,
Redirect Url = -,
SIP Call Type = Not in a call,
SIP Media Type = None,
Applications = None,
Encap Value = -
- On client 5
- Go back to the network connection Pod properties, then disable 802.1x on the network interface (from
authentication tab of the LAN connection properties)

10
Access Guardian
- On the switch check the user status:

User
Port Username Mac address IP (V4/V6) Vlan Profile Type Status
-------+--------------------+-----------------+-------------------+----+---------------+------------+-----
------
1/1/1 00:50:56:90:22:3c 00:50:56:90:22:3c 192.168.20.105 20 - Bridge Block
- As there are not any MAC addresses configured on the RADIUS server, then the user is blocked from
accessing the network.

OMNISWITCH R8
L I N K L AY E R D I S C O V E RY P R O T O C O L S ( L L D P )
OBJECTIVES
• Describe how the Link Layer Discovery Protocols

(LLDP) works
• Enable LLDP-MED
OVERVIEW
Goal
• IEEE 802.1AB – Link Layer Discovery Protocol (LLDP)
• Accurate physical topology and device inventory simplifies management and maintenance
L2 discovery protocol
• Exchange information with neighboring devices to build a database of adjacent devices
• Enabled by default on the OmniSwitches
I’m a Switch I’m a Switch port device info

port device info
2/22 Switch xxxx
1/1 IP-phone xxxx
2/1 IP-Phone xxxx
1/2 PC xxxx I’m a Switch
I’m a Switch I’m a Switch 2/12 IP-Phone xxxx
1/3 Switch xxxx
I’m a Switch 2/13 IP-PBX xxxx
I’m a Switch
I’m an IP-Phone I’m a PBX

I’m a PC
I’m a PC
I’m an IP-Phone
PROTOCOL DATA UNIT (LLDP-PDU)
Standard: IEEE 802.1AB
Ethernet Header Link Layer Discovery Protocol Protocol Data Unit (LLDP-PDU)
Port mac Chassis ID Port ID Time To Optional Optional End Of

01:80:c2:00:00:0e
addr.
88:cc TLV TLV Live TLV TLV
…
TLV LLDPPDU TLV
Destination Source Ethertype M M M O O M

addr. addr. For LLDP
Basic Type Length Value (TLV) format
TLV TLV information

TLV header TLV information string
Type string length
7 bits 9 bits 0 – 511 octets
LLDP PDUs
Extensions optional fields
• 802.1: Vlan name, port vlan
• 802.3: MAC Phy
• MED: Power and Capability
• Inventory Management
• Network Policy
MEDIA ENDPOINT DEVICES (LLDP-MED)
NETWORK
POLICY
LOCATION ID
EXTENDED
POWER-VIA-MDI
INVENTORY
CONFIGURATION
• Enabling LLDP PDU flow on a port, slot, or all ports on a switch
-> lldp {slot/port | slot | chassis} lldpdu {tx | rx | tx-and-rx | disable}
• Enabling LLDP notification status

-> lldp {slot/port | slot | chassis} notification {enable | disable}
• Displaying LLDP information

-> show lldp port 1/1/3 remote-system
Remote LLDP nearest-bridge Agents on Local Port 1/1/3:
Chassis e8:e7:32:f6:15:81, Port 1003:

Remote ID = 4,
Chassis Subtype = 4 (MAC Address),
Port Subtype = 7 (Locally assigned),
Port Description = Alcatel-Lucent OS6860 GNI 1/1/3,
System Name = (null),
System Description = (null),
Capabilities Supported = Bridge Router,
Capabilities Enabled = Bridge Router
MONITORING
Displaying LLDP information
-> show lldp system-statistics
-> show lldp [slot|slot/port] statistics
-> show lldp local-system
-> show lldp [slot/port | slot] local-port
-> show lldp local-management-address
-> show lldp config
-> show lldp 1/9 config

----------+-------------------------------------------+---------------------+----------
| Admin | Notify | Std TLV | Mgmt | 802.1 | 802.3 | MED
Slot/Port| Status | Trap | Mask | Address | TLV | Mask | Mask
----------+----------+----------+----------+----------+----------+----------+----------
1/9 Rx + Tx Enabled 0xf0 Enabled Enabled 0x80 0xd0
IP PHONE
(LLDP NETWORK POLICY TLV/MOBILE TAG)
LLDP-MED
• Provides VoIP-specific extensions to base LLDP protocol
• TLVs (Type, Length, Value) for
• Device location discovery to allow creation

of location databases, including the support 1 2
Admin
for Emergency Call Service
Policy: Unkn Policy: Defin
• LAN policy discovery Tagged:
VLAN ID:
No
0
Tagged: Yes
VLAN ID :10
(VLAN, Layer 2 priority, Layer 3 QoS) L2 priority: 5
DSCP: 46
L2 priority:7
DSCP: 46
• Extended and automated power management

for Power over Ethernet devices
• Inventory management
IP Phone
LLDP-MED
Mobile Tag versus 802.1Q Tag
Mobile Tag 802.1Q Tag

Allows mobile ports to receive 802.1Q tagged Not supported on mobile ports
packets
Enabled on the VLAN that will receive tagged Enabled on fixed ports; tags port traffic for
mobile port traffic destination VLAN
Triggers dynamic assignment of tagged mobile Statically assigns (tags) fixed ports to one or
port traffic to one or more VLANs more VLANs
LLDP NETWORK POLICY TLV/MOBILE TAG
OS6860-A 7
1/1/20 1/1/4
151.1.1.0 151.1.1.0
IP Phone 31001
Switch send a LLDP Frame

(OS6860-A) -> vlan 151
(OS6860-A) -> unp profile "voip-temp" mobile-tag
(OS6860-A) -> unp profile "voip-temp" map vlan 151
(OS6860-A) -> unp port 1/1/20 port-type bridge
(OS6860-A) -> unp port 1/1/20 direction both classification trust-tag dynamic-service none
(OS6860-A) -> unp classification lldp med-endpoint ip-phone profile1 "voip-temp"
(OS6860-A) -> lldp network-policy 1 application voice vlan 151 l2-priority 7 dscp 14
(OS6860-A) -> lldp chassis med network-policy 1
(OS6860-A) -> lldp nearest-bridge port 1/1/20 tlv med network-policy enable
(OS6860-A) -> lldp nearest-bridge port 1/1/20 tlv med capability enable
LLDP NETWORK POLICIES
• Specifying whether or not LLDP-MED TLVs are included in transmitted LLDPDUs
-> lldp {slot/port | slot | chassis} tlv med {power | capability | network policy}
{enable | disable}
• Configuring a local Network Policy on the switch for a specific application type
-> lldp network-policy policy_id application { voice | voice-signaling | guest-voice
| guest-voice-signaling | softphone-voice | video-conferencing | streaming-video |
video-signaling } vlan { untagged | priority-tag | vlan-id } l2-priority 802.1p_value
dscp dscp_value
• Associating an existing network policy to a port, slot, or chassis

-> lldp {slot/port | slot | chassis} med network-policy policy_id
EXAMPLE – LLDP-MED
Display the LLDP information of the equipment(s) connected to the switch
-> show lldp remote-system

Remote LLDP Agents on Local Slot/Port 1/14:
Chassis 80:4e:53:c6:00:00, Port 00:80:9f:8e:a4:ab:
Remote ID = 3,
Port Subtype = 3 (MAC address),
Port Description = (null),
System Description = (null), -> show lldp remote-system med inventory
Capabilities Supported = Telephone, Remote LLDP Agents on Local Slot/Port 1/14:
Capabilities Enabled = Telephone,
MED Device Type = Endpoint Class III, Chassis 80:4e:53:c6:00:00, Port 00:80:9f:8e:a4:ab:
MED Capabilities = Capabilities | Power via MDI-PD(33), Remote ID = 3,
MED Extension TLVs Present = Network Policy| Inventory, Hardware Revision = "3GV23021JCDA060921",
MED Power Type = PD Device, Firmware Revision = "NOE 4.20.60",
MED Power Source = PSE, Software Revision = "NOE 4.20.60",
MED Power Priority = Low, Serial Number = "FCN00913901069",
MED Power Value = 5.6 W, Manufacturer Name = "Alcatel-Lucent Enterprise",
Remote port MAC/PHY AutoNeg = Supported Enabled Capability 0xc036, Model Name = "IP Touch 8068",
Mau Type = 1000BaseTFD - Four-pair Category 5 UTP full duplex mode Asset Id = "00:80:9f:8e:a4:ab"
LLDP NETWORK POLICY TLV/MOBILE TAG
IP phone send Multicast LLPD frame
(OS6860-A) -> vlan 151

(OS6860-A) -> unp profile "voip-temp" mobile-tag
(OS6860-A) -> unp profile "voip-temp" map vlan 151
(OS6860-A) -> unp port 1/1/20 port-type bridge
(OS6860-A) -> unp port 1/1/20 direction both classification trust-tag dynamic-service none
(OS6860-A) -> unp classification lldp med-endpoint ip-phone profile1 "voip-temp"
(OS6860-A) -> lldp network-policy 1 application voice vlan 151 l2-priority 7 dscp 14
(OS6860-A) -> lldp chassis med network-policy 1
(OS6860-A) -> lldp nearest-bridge port 1/1/20 tlv med network-policy enable
(OS6860-A) -> lldp nearest-bridge port 1/1/20 tlv med capability enable
1 OS6860-A 7
1/1/20 1/1/4
151.1.1.0 151.1.1.0
IP Phone 31001
2
Switch send a LLDP Frame

THANK YOU
OmniSwitch R8
Link Layer Discovery Protocol
How to
✓ This lab is designed to familiarize you with the Link Layer Discovery
Protocol (LLDP).
Contents
1 Topology ........................................................................................ 2
2 Configure LLDP ................................................................................ 2
2
1 Topology
Link Layer Discovery Protocol (LLDP) is a standard that provides a solution for the configuration issues
caused by expanding networks. LLDP supports the network management software used for complete
network management. LLDP is implemented as per the IEEE 802.1AB standard.
The exchanged information, passed as LLDPDU, is in TLV (Type, Length, Value) format. The information
available to the network management software must be as new as possible; hence, remote device
information is periodically updated.
Notes
LLDP is enabled by default in reception and transmission
2 Configure LLDP
- To control per port notification status about a change in a remote device associated to a port, use the
following command:
sw5 (6360-A) -> lldp port 1/1/3 notification enable

sw8 (6860-B) -> lldp port 1/1/3 notification enable

Tips
LLDP is configured at port level (or NI or chassis), but not at linkagg level.
3
- To control per port management TLV to be incorporated in the LLDPDUs, use the following command
sw5 (6360-A) -> lldp port 1/1/3 tlv management port-description enable
sw8 (6860-B) -> lldp port 1/1/3 tlv management port-description enable
- Verify the LLDP per port statistics by entering the following command:
sw7 (6860-A) -> show lldp statistics
Chas/ LLDPDU LLDPDU LLDPDU LLDPDU LLDPDU TLV TLV Device
Slot/Port Tx TxLenErr Rx Errors Discards Unknown Discards Ageouts
----------+----------+----------+----------+----------+----------+----------+----------+----------
1/1/1 65 0 0 0 0 0 0 0
1/1/3 65 0 65 0 0 0 0 0
1/1/4 66 0 64 0 0 0 0 0
1/1/5 65 0 65 0 0 0 0 0
1/1/6 65 0 65 0 0 0 0 0
1/1/23 65 0 64 0 0 0 0 0
1/1/24 64 0 63 0 0 0 0 0
- To verify the remote system information, use the following command:

sw5 (6360-A) -> show lldp remote-system
Chassis e8:e7:32:f6:15:81, Port 1003:

Remote ID = 4,
Chassis e8:e7:32:fc:23:b3, Port 1004:

Remote ID = 7,

Remote ID = 10,
4

Chassis e8:e7:32:f6:15:81, Port 1004:

Remote ID = 4,
[truncated]
- To display local system information, type the following command:

sw7 (6860-A) -> show lldp local-system
Local LLDP Agent System Data:
Chassis ID Subtype = 4 (MAC Address),
Chassis ID = e8:e7:32:f6:15:81,
System Name = Pod20sw7,
System Description = Alcatel-Lucent Enterprise OS6860E-P24 8.7.98.R03 GA, July 05, 2021.,
Capabilities Enabled = Bridge Router,
LLDPDU Transmit Interval = 30 seconds,
TTL Hold Multiplier = 4,
Reintialization Delay = 2 seconds,
Maximum Transmit Credit = 5 ,
LLDPDUs in Fast Transmission = 4 ,
LLDPDU Fast Transmit Interval= 1 ,
MIB Notification Interval = 5 seconds,
LLDP Nearest-edge Mode = Disabled,
Management Address Type = 1 (IPv4),
Management IP Address = 192.168.254.7,
- The commands below specify the switch to control per port management TLVs to be incorporated in the
LLDPDUs. This will allow to have additional information such as system description, name, capabilities and
management IP address of neighbouring devices.
5
- Type the following on all 3 switches:

all -> lldp chassis tlv management system-name enable
all -> lldp chassis tlv management system-description enable
all -> lldp chassis tlv management system-capabilities enable
all -> lldp chassis tlv management management-address enable
- To display remote system information, enter the following command:

sw5 (6360-A) -> show lldp remote-system
Chassis e8:e7:32:f6:15:81, Port 1003:

Remote ID = 4,
Management IP Address = 192.168.254.7

Remote ID = 7,
System Description = Alcatel-Lucent Enterprise OS6860-24 8.7.98.R03 GA, July 05, 2021.,

Remote ID = 10,
System Description = Alcatel-Lucent Enterprise OS6860-24 8.7.98.R03 GA, July 05, 2021.,
Chassis e8:e7:32:f6:15:81, Port 1004:

Remote ID = 4,
[truncated]
Tips
Compare the output of this command with the same command that was entered before
OMNISWITCH R8
M U LT I C A S T I N T R O D U C T I O N
OBJECTIVES
Upon completion this module, you will be
able to understand and setup the following
features:
• Multicast overview
• IP Multicast Switching (IPMS)
• Internet Group Management Protocol (IGMP)
• Configuration and Monitoring
• Layer 2 Static Multicast & IGMP Relay and
Throttling
• Storm Control & Load balancing multicast on
Link Aggregation
MULTICAST - OVERVIEW
• Similar to broadcast traffic • Unicast sends one packet per destination
• Like selective broadcast • Multicast sends one packet for many
• Only those that request the traffic get it destinations
• Allows a one to many communication rather
than one to one
Unicast
Multicast
MULTICAST - ADVANTAGES & USE
• Conserves Bandwidth
• Uses for multicast
• Resource discovery (OSPF, RIP2, Bootp)
• VLC for video netcasting
• Multipoint file transfer (Starburst Com.)
• Redundant systems (parallel databases)
• Ghosting Software
• Information distribution in data warehousing
MULTICAST - GROUP
• Multicast group
• Set of receivers for a multicast transmission
• Identified by a multicast address
• A user that wants to receive multicast transmissions joins the corresponding multicast group, and
becomes a member of that group
• IP Multicast service is unreliable
• A network must have mechanisms to support such applications in an efficient manner
• After a user joins, the network builds the necessary routing paths so that the user receives
the data sent to the multicast group
MULTICAST - ADDRESSING
• Based on Class “D” IP address values
• From 224.0.0.0 to 239.255.255.255
• Allocated by sending application MAC address derived from IP address
• Least Significant 23 bits of IP address mapped onto MAC address
• IP MultiCast address 224.1.2.3 = 01:00:5E:01:02:03
224.0.0.xxx – Routing protocols and other low level topology discovery and maintenance protocols
Well-Known Class D Address examples
224.0.0.1 All Systems on this Subnet

224.0.0.2 All Routers on this Subnet
224.0.0.4 DVMRP Routers
224.0.0.5 OSPFIGP OSPFIGP All Routers
224.0.0.6 OSPFIGP OSPFIGP Designated Routers
224.0.0.9 RIP2 Routers
224.0.0.13 All PIM Routers
224.0.0.18 VRRP
224.0.0.22 IGMP
224.0.0.19 IPAllL1ISs
224.0.0.20 IPAllL2ISs
224.0.1.xxx – Internetwork control block
232.0.0.0-232.255.255.255 (232/8) Source-Specific Multicast Block
239.xxx.xxx.xxx - Administratively scoped address block
……… (http://www.iana.org/assignments/multicast-addresses)
MULTICAST - ROUTING
• Multicast router knows who wants traffic
Network
• Finds out who is sending the traffic
Backbone
• Delivers traffic only to those who want it
Video
• Routers communicate with each other and users Server
to gather the information Multicast
Switching
• Send traffic where it needs to go
IGMP
• Multicast Routing deals with networks, not Join
switch ports
• If one host on a network joins that group, all hosts
on that network receive the traffic
• In the switch, a network=router port=a VLAN, so
the traffic is broadcast on all ports of each SUBNET
network
MULTICAST - SWITCHING - IPMS
• Only the client which join a multicast group
received the multicast packet, and the multicast
packet stream will not flood to other ports Network
Backbone
where no client joins
• More efficient than multicast routing Video
Server
• NI Tables contain: Multicast
• IP Source Address Switching
• IP Destination Address (group address) IGMP

• Parent source port number Join
• List of ports that need to receive packet

• NIs verify that packet for given destination
address from a certain source arrives on the
parent port
SUBNET
• If true, switch/route packet to all ports in
forwarding list
• If false, drop it
IGMP
IGMP PROTOCOL
• The Internet Group Management Protocol (IGMP) is a simple protocol for the support of IP
multicast
• IGMP is defined in RFC 1112
• IGMP operates on a physical network
• IGMP is used by multicast routers to keep track of membership in a multicast group
• Support for
• Joining a multicast group
• Query membership
• Send membership reports
MULTICAST IGMP IN A NUTSHELL
Multicast stream is required by one or more multicast clients
Receiver_A Receiver_B Receiver_C
Client sends report requesting

multicast group e.g 225.0.0.1
Router detects the match and

One Router (Per LAN) is querier;
transmits multicast stream
sends periodic query messages 225.0.0.1 to the client
Server offers stream on a

multicast address e.g 225.0.0.1
Multicast stream is offered by one or more multicast servers

IGMP VERSIONS
• Protocol used by hosts to send control frames to inform router of the desire to receive
traffic from a MC group
• IGMP v1
• Membership Query
• Membership Report
IGMP membership report group
• IGMP v2
IGMP membership query • Membership Query
• General Query
IGMP Member Report • Group-Specific Query
• V2 Membership report (Fast Leave)
• Leave group
IGMP Leave Group (v2 only) • V1 Membership Report
• IGMP v3
IGMP Query Group (v2 only)
• Membership query
• V3 Membership report (Explicit Host
Tracking)
• V2 Leave group
IGMP Source-Specific Join (v3 only) • V2 Membership report
• V2 Leave group
• V1 Membership report
IGMP - USEFUL TECHNICAL DETAILS
• IGMP is a protocol confined to the local segment of the LAN
• Is never forwarded by any router and thus always has a Time-To-Live (TTL) of 1
• IGMP Host Membership Queries are sent to the "All Systems on this Subnet" class D address
(224.0.0.1)
• IGMP "Leave Group" messages are sent to the "All Routers on this Subnet" class D address
(224.0.0.2)
IPV6 MULTICAST - OVERVIEW
• Multicast Listener Discovery (MLD)
• Used by IPv6 systems (hosts and routers)
• Reporting of IPv6 multicast group memberships to any neighboring multicast routers
• Similar to IGMP for IPv4
• MLD messages are sent with
• Link-local IPv6 Source address
• Hop limit of one
• IPv6 Destination address FF02:0:0:0:0:0:0:16
• MLD Version 1
• Forwarding by IPv6 multicast destination addresses
• MLD Version 2
• Forwarding by source IPv6 addresses and IPv6 multicast destination addresses
• OmniSwitch version supported
• MLDv1 and MLDv2
IPMS
MULTICAST - SWITCHING VS. ROUTING DECISION
• Port list is a combination of hosts and peer routers
• Destination Slot/Port can be is a downstream router or a client
• Destination port could be in same or different VLAN
• If in same VLAN, switch packet
• Use IPMS forwarding table to forward packets to ports
• If in different VLAN, route packet
• Use DVMRP/PIM forwarding table to deliver packets to downstream routers
• Change source MAC address to router port MAC address
• Send packet on destination port
• IPMS
• Intercepts IGMP packets to track membership by port rather than by network
• Two sets of information are combined to tell switches how to forward/route traffic
• Performance is significantly improved because forwarding decisions are made by hardware
• Forwarding tables created by DVMRP, PIM-SM, PIM-DM and IPMS
HOW DOES MULTICAST SWITCHING WORK?
• IP Multicast Switching
• Based on the IGMP query and report messages
that are snooped, the switch forwards multicast
traffic only to the ports that requested it
Group Port Src IP Vlan
226.0.0.4 1/5/22 1.1.1.2 2
• Forwarding Tables created by IGMP Snooping 228.1.1.1 1/2/4 2.2.2.3 34
IGMP Join (228.1.1.1)

1/2/4
1/5/22
Without multicast switching, multicast traffic would be forwarded to the entire VLAN
HOW DOES MULTICAST SWITCHING WORK?
• By maintaining this multicast forwarding table, the switch dynamically forward multicast
traffic only to those interfaces that want to receive it as nominal unicast forwarding does
Forward Mcast
traffic to port on
which the join
Video L3 Multicast message was
Server Switch received
Without multicast switching, multicast traffic would be forwarded to the entire VLAN
CONFIGURING IPMS
• The minimum configuration
-> ip multicast admin-state enable
• Enables or disables IP Multicast Switching and Routing on a specific VLAN or globally
-> ip multicast vlan 10 admin-state enable
• Enables or disables IP Multicast Switching and Routing on a specific VLAN or globally
IPMS is disabled by default

CONFIGURING IPMS
• The minimum configuration
-> ip multicast querying enable
• Enables or disables IGMP querying on a specific VLAN or globally
• Refers to requesting the network's IGMP group membership information by sending out IGMP queries
-> ip multicast querier-forwarding enable

• Enables or disables IGMP querier forwarding on the specified VLAN or on the system if no VLAN is specified
• Querier-forwarding feature should be enabled if a streaming device is connected to a switch, which is not a
querier
• All multicast traffic is sent to the "Querier" switch
CONFIGURING IPMS - OPTIONS
• Configuring IGMP Version
-> ip multicast [vlan vid] version [version]
• Configuring IGMP Query Interval
-> ip multicast [vlan vid] query-interval [seconds]
• Modifying IGMP Query Response Interval

-> ip multicast [vlan vid] query-response-interval [tenths-of-seconds]
• Modifying IGMP Last Member Query Interval

-> ip multicast [vlan vid] last-member-query-interval [tenths-of-seconds]
• Configuring IGMP Expire Router Timeout

-> ip multicast [vlan vid] router-timeout [seconds]
• Enabling Multicast Zapping

-> ip multicast [vlan vid] zapping [{enable | disable}]
IPMS MONITORING
IGMP Group Membership Table Entries
-> show ip multicast group
Total 2 Groups
Group Address Source Address VLAN Port Mode Static Count Life
---------------+---------------+-----+-----+--------+-------+------+-----
225.0.0.101 0.0.0.0 1 1/1/1 exclude no 49 239
225.0.0.102 0.0.0.0 1 1/1/1 exclude no 49 243
239.255.255.250 0.0.0.0 1 1/1/1 exclude no 48 241
239.255.255.250 0.0.0.0 1 1/1/24 exclude no 45 239
• Group Address • Mode

• IP address of the IP multicast group • IGMP source filter mode
• Source Address • Static
• IP address of the IP multicast source • Whether it is a static multicast group or not
• VLAN • Count
• Number of IGMP membership requests made
• VLAN associated with the IP multicast group
• Life
• Port
• Life time of the IGMP group membership
• Slot and port number of the IP multicast group
IPMS MONITORING
IGMP Neighbor Table Entries
-> show ip multicast neighbor
Total 2 Neighbors
Host Address VLAN Port Static Count Life

---------------+-----+-----+-------+------+-----
192.168.10.2 10 1/1/9 no 76 61
192.168.10.3 10 1/1/24 no 75 60
• Host Address • Static

• IP address of the IP multicast neighbor • Whether it is a static IP multicast neighbor or not
• VLAN • Count
• VLAN associated with the IP multicast neighbor • Displays the count of IP multicast neighbor
• Port • Life
• Slot and port number of the IP multicast neighbor • Life time of the IP multicast neighbor
IPMS MONITORING
Forwarding Table
-> show ip multicast forward
Total 2 Forwards
Ingress Egress
Group Address Host Address Tunnel Address VLAN Port VLAN Port
---------------+---------------+---------------+-----+-----+-----+-----
225.0.0.101 192.168.100.10 0.0.0.0 1 2/1/1 1 1/2/24
225.0.0.102 192.168.100.10 0.0.0.0 1 2/1/1 1 1/2/24
• Group Address • VLAN

• IP group address of the IP multicast forward • VLAN associated with the IP multicast forward
• Host Address • Port
• IP host address of the IP multicast forward • Slot and port number of the IP multicast forward
• Tunnel Address
• IP source tunnel address of the IP multicast
forward
L2 STATIC MULTICAST
• Configures a static multicast MAC address and assigns the address to one or more egress
ports
• Packets received on ports associated with the specified VLAN that contain a destination MAC
address that matches the static multicast address are forwarded to the specified egress ports
mac-learning {vlan vlan_id {port chassis/slot/port | linkagg agg_id }}
multicast mac-address multicast_address [group group_id]
mac-learning flush [vlan vlan_id [port chassis/slot/port | linkagg agg_id ]]

multicast [mac-address multicast_address]
• Static multicast MAC addresses maintained in the Source Learning MAC address table
• Assigns the multicast address 01:25:9a:5c:2f:10 to port 1/1/24 in VLAN 20
-> mac-learning vlan 20 port 1/1/24 multicast mac-address 01:25:9a:5c:2f:10
• Assigns a static multicast MAC address to link aggregate ID 2 associated with VLAN 455
-> mac-learning vlan 455 linkagg 2 multicast mac-address 01:95:2A:00:3E:4c
IGMP - RELAY
• IGMP Forwarding to Specific Host in L3 Create the helper address
Environment -> ip multicast helper-address 11.107.61.132
Display Helper address information

• Encapsulates IGMP packets in an IP packet -> show ip multicast
to a special device/server Status = enabled,
Querying = enabled,
Proxying = disabled,
Spoofing = enabled,
• Specifies the destination IP address of a relay host where Zapping = disabled,
IGMP host reports and Leave messages are to be sent Querier Forwarding = enabled,
Flood Unknown = enabled,
Version = 3,
• Notified multicast server forwards a new multicast stream Robustness = 2,
when a subscriber has joined the new group without Query Interval (seconds) = 125,
relying on the L3 multicast network (e.g. PIM) to Query Response Interval (tenths of seconds) = 100,
Last Member Query Interval (tenths of seconds) = 10,
propagate this event Unsolicited Report Interval (seconds) = 1,
Router Timeout (seconds) = 90,
Source Timeout (seconds) = 30,
Max-group = 0,
Max-group action = none
Helper-address = 11.107.61.132
IGMP THROTTLING
• Configures the maximum group limit learned per VLAN, per port or globally
• Global
-> ip multicast max-group [num] [action {none | drop | replace}]
• VLAN
-> ip multicast vlan vid max-group [num] [action {none | drop | replace}]
• Port
• Applicable for all VLAN instances of the port
• Per port limit overrides VLAN and global configuration
-> ip multicast port slot|port max-group [num] [action {none | drop | replace}]
• Actions
• None. Disables the maximum group limit configuration
• Drop. Drops the incoming membership request
• Replace. Replaces an existing membership with the incoming membership request
STORM CONTROL
• Configuration of different thresholds for each type of storm/flood traffic
• Broadcast
• Multicast
• Unknown Unicast
• Thresholds configuration
• rate % num: rate in % of the port speed
• rate mbps num: rate in true mbits per sec
• rate pps num: rate in packet per sec
interfaces {slot chassis/slot| port chassis/slot/port[-port2]} flood-limit {bcast | mcast | uucast | all}
rate {pps pps_num| mbps mbps_num | cap% cap_num | enable | disable | default} [low-threshold low_num]
• Configures the action on a single port, a range of ports, when the port reaches the storm
violated state
interfaces {slot chassis/slot| port chassis/slot/port[-port2]} flood-
limit {bcast | mcast | uucast | all} action {shutdown | trap | default}
LOAD BALANCING MULTICAST ON LINK AGGREGATION
• Multicast traffic is by default forwarded through the primary port of the Link Aggregation
Group
• Option to enable hashing for non-unicast traffic, which will load balance the non-unicast
traffic across all ports in the Link Aggregation
• If non-ucast option is not specified, link aggregation will only load balance unicast packets
-> hash-control {brief | extended [udp-tcp-port] | load-balance non-ucast {enable | disable}}
-> show hash-control

Hash Mode = brief,
Udp-Tcp-Port = disabled
-> show hash-control non-ucast

Non-ucast Hash Status = Disabled
INITIAL MULTICAST PACKET BUFFERING
• Avoids loss of first multicast packets in a routed environment
-> ip multicast initial-packet-buffer admin-state enable (default: disable)
-> ipv6 multicast initial-packet-buffer admin-state enable
• Maximum number of multicast packets that can be buffered by multicast stream

-> ip multicast initial-packet-buffer max-packet (1 to 10) (default: 4)
-> ipv6 multicast initial-packet-buffer max-packet
• Enables or disables initial packet buffering for IPv4 and IPV6 multicast flows on the
specified VLAN or globally on the switch.
-> ip multicast [vlan vlan_id[-vlan_id2]] initial-packet-buffer admin-state {enable | disable}
-> ipv6 multicast [vlan vlan_id[-vlan_id2]] initial-packet-buffer admin-state {enable | disable}

THANK YOU
OmniSwitch R8
Multicast switching
How to
✓ This lab is designed to familiarize you with the IP multicast switching
capability on the OmniSwitch family of products
Contents
1 Toplogy ......................................................................................... 2
2 IP Multicast Switching ........................................................................ 3
2.1. Without IPMS enable ............................................................................... 3
2.2. IP Multicast Switching (IPMS) enable ............................................................ 5
2
Multicast switching
1 Toplogy
Multicast switching is used to efficiently handle multicast traffic by forwarding multicast packets only to the
switch ports that need to receive them
- The configuration for multicast switching is simple, requiring only that the switches be bridged together.
A multicast stream(s) will then be started at the multicast server
- For this lab, we will have 3 clients connected on the same VLAN.
- Check vlan 30 members on 6360-A

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
- Get IP addresses from the clients (ipconfig /all) retrieved from dhcp server.
Client 8:
Client 9:
Client 10:
- Try to ping each client from each other to ensure L2 connectivity

3
Multicast switching
2 IP Multicast Switching
2.1. Without IPMS enable
- Before you begin, notice that Multicast Switching is disabled by default:
sw5 (6360-A) -> show ip multicast

Profile = default,
Status = disabled,
Flood Unknown = disabled,
-----

Profile = default,
Status = disabled,
sw8 (6860-B) -> show ip multicast

Profile = default,
Status = disabled,
- Resets all Layer 2 statistics counters
sw5 (6360-A) -> clear interfaces 2/1/2 l2-statistics

sw8 (6860-B) -> clear interfaces 1/1/1 l2-statistics
sw5 (6360-A) -> show interfaces 2/1/2

Chassis/Slot/Port : 2/1/2
Operational Status : up,
Port-Down/Violation Reason: None,
Last Time Link Changed : Sat Jul 3 04:16:15 2021,
Number of Status Change : 1,
Type : Ethernet,
SFP/XFP : N/A,
Interface Type : Copper,
EPP : Disabled,
Link-Quality : N/A,
MAC address : 94:24:e1:7c:79:6c,
BandWidth (Megabits) : 100, Duplex : Full,
Autonegotiation : 1 [ 1000-F 100-F 100-H 10-F 10-H ],
Long Frame Size(Bytes) : 1552,
Inter Frame Gap(Bytes) : 12,
loopback mode : N/A,
Rx :
Bytes Received : 0, Unicast Frames : 0,
Broadcast Frames: 0, M-cast Frames : 0,
UnderSize Frames: 0, OverSize Frames: 0,
Lost Frames : 0, Error Frames : 0,
CRC Error Frames: 0, Alignments Err : 0,
Tx :
Bytes Xmitted : 0, Unicast Frames : 0,
Lost Frames : 0, Collided Frames: 0,
Error Frames : 0, Collisions : 0,
Late collisions : 0, Exc-Collisions : 0
4
Multicast switching
- Open the “send” application from the client's desktop 8. And fill up as below the tool window.
This tool generates multicast IP packets, with Destination IP address (multicast group) 231.1.1.5 on
stream01.
- Click on start
- As the packets are sent check the counters on the VLAN 30 interfaces of 6360-A :

Last Time Link Changed : Tue Jul 6 23:03:13 2021,
Type : Ethernet,
SFP/XFP : N/A,
EPP : Disabled,
Link-Quality : N/A,
MAC address : 94:24:e1:7c:79:6d,
Rx :
Tx :

5
Multicast switching
Last Time Link Changed : Tue Jul 6 02:14:48 2021,
Type : Ethernet,
SFP/XFP : N/A,
EPP : Disabled,
Link-Quality : N/A,
MAC address : 94:24:e1:7c:82:25,
Rx :
Tx :
- As you can see in the capture below, by default multicast traffic is flooded on all the port on the same
VLAN as the source.
2.2. IP Multicast Switching (IPMS) enable
- Next, enable IP Multicast Switching (IPMS). With IPMS enabled only ports with devices that requested to
see the stream will have it forwarded. Without it, multicast traffic would be treated as a broadcast and
sent to all ports in the VLAN.
• Open the “send” application from the client's desktop 6. And fill up as below the tool window.
This tool generates multicast IP packets, with Destination IP address (multicast group) 233.1.1.5.
- Enable Multicast Switching:
sw5 (6360-A) -> ip multicast admin-state enable

sw7 (6860-A) -> ip multicast admin-state enable
sw8 (6860-B) -> ip multicast admin-state enable
- Reset all Layer 2 statistics counters
sw5 (6360-A) -> clear interfaces 2/1/1-2 l2-statistics

sw8 (6860-B) -> clear interfaces 1/1/1 l2-statistics

6
Multicast switching
- Check the configuration on the three switches:

Profile = default,
Status = enabled,

Profile = default,
Status = enabled,
sw8 (6860-B) -> show ip multicast

Profile = default,
Status = enabled,
sw5 (6360-A) -> clear interfaces 2/1/1-2 l2-statistics

- On 6860--B enable Multicast Querying (the switch where the multicast server is connected to):
6860-B -> ip multicast querying enable
- On 6360-A and both 6860, enable Querier Forwarding:
6360-A -> ip multicast querier-forwarding enable

6860-B -> ip multicast querier-forwarding enable
- From client 8, restart the application “send” to send multicast traffic.

7
Multicast switching
- Open the “receive” application from the client's desktop 9 to subscribe to multicast traffic.( IP address
(multicast group) 233.1.1.5)
- Check multicast forward and group on 6360-A switch
sw5 (6360-A) -> show ip multicast forward

Total 0 Forwards
Ingress Egress
Group Address Host Address Tunnel Address Vlan/Service Vlan/Service Interface
---------------+---------------+---------------+--------------+--------------+----------------------
sw5 (6360-A) -> show ip multicast group

Total 4 Groups
Group Address Source Address Vlan/Service Interface Mode Static Count Life
---------------+---------------+--------------+----------------------+--------+-------+------+-----
231.1.1.5 0.0.0.0 vlan 30 1/1/2 exclude no 3 254
239.255.255.250 0.0.0.0 vlan 30 1/1/2 exclude no 3 227
239.255.255.250 0.0.0.0 vlan 30 2/1/1 exclude no 3 226
239.255.255.250 0.0.0.0 vlan 30 2/1/2 exclude no 4 231
- This shows all IGMP requests seen by the switch

Notes
239.255.255.250 is the multicast address of SSDP (Simple Service Discovery Protocol), basis of the discovery
protocol of universal Plug& Play (UPnP)
8
Multicast switching
- Check also multicast forward and group on 6860-B :
sw8 (6860-B) -> show ip multicast forward

Total 1 Forwards
Ingress Egress
---------------+---------------+---------------+--------------+--------------+----------------------
231.1.1.5 0.0.0.0 0.0.0.0 vlan 30 vlan 30 0/8
sw8 (6860-B) -> show ip multicast group
Total 4 Groups
---------------+---------------+--------------+----------------------+--------+-------+------+-----
239.255.255.250 0.0.0.0 vlan 20 0/78 exclude no 7 239
239.255.255.250 0.0.0.0 vlan 30 1/1/1 exclude no 7 245
231.1.1.5 0.0.0.0 vlan 30 0/8 exclude no 5 245
239.255.255.250 0.0.0.0 vlan 30 0/8 exclude no 14 245
- Check also multicast forward and group on 6860-A :
sw7 (6860-A) -> show ip multicast forward

Total 0 Forwards
Ingress Egress
---------------+---------------+---------------+--------------+--------------+----------------------
sw7 (6860-A) -> show ip multicast group

Total 1 Groups
---------------+---------------+--------------+----------------------+--------+-------+------+-----
239.255.255.250 0.0.0.0 vlan 20 0/7 exclude no 6 196
OMNISWITCH R8
D I S TA N C E V E C T O R M U LT I C A S T R O U T I N G P R O T O C O L
OBJECTIVES
• Describe the Distance Vector Multicast Routing

Protocol (DVMRP)
AOS SPECIFICATIONS
• Distance Vector Multicast Routing Protocol • DVMRP Attributes
• Similar to RIP • Reverse Path Multicasting
• Infinity = 32 hops • Neighbor Discovery
• Subnet masks in route advertisements • Multicast Source Location
• 1 Multicast Protocol per Interface (PIM or DVMRP) • Route Report Messages
• 128 interfaces • Distance Metrics
• 256 neighbors • Dependent Downstream Routers
• Poison Reverse
• RFCs Supported • Pruning
• 2667 – IP Tunnel MIB • Grafting
• DVMRP Tunnels
OVERVIEW
• DVMRP Version 3.255 supported
• V3 backward compatible with V1
• Supports IP Tunneling
• Unicast connection between two IP Multicast routers for traversing non-multicast devices
• Reverse Path Multicasting
• If a packet arrived on an upstream interface that would be used to transmit packets back to the
source, it is forwarded to the appropriate list of downstream interfaces.
• Otherwise, it is not on the optimal delivery tree and is discarded. In this way, duplicate packets
can be filtered when loops exist in the network topology.
• Source location
• Look up route to source to determine which interface to accept traffic on
• The Unicast routing table is propagated
• Split horizon is used (don’t propagate routes on the interface that you learned them from)
SPECIFICATIONS
NEIGHBOR DISCOVERY
• DVMRP Probe packet
• Periodic multicast group address packet
• Multicast address packets via 224.0.0.4 (All-DVMRP Routers)
R2
Server
R1 Probe for neighbor

discovery
Client
-> show ip dvmrp neighbor R3

Neighbor Address Vlan Uptime Expires GenID Version State
---------------+-----+-----------+-----------+---------+---------+-------
143.209.92.214 2 00h:09m:12s 00h:00m:06s 546947509 3.255 active
FLOOD AND PRUNE
• Flood and Prune Protocol
• Multicast traffic is flooded to all downstream routers
• This can be efficient if there are a large number of recipients.
• Routers that do not have clients registered to receive traffic will send a DVMRP prune message
Flood
Flood Prune
Prune
Traffic
GRAFT
• Grafting:
• Adding a branch to multicast traffic delivery
• If new IGMP membership requests are received, the router sends a “graft” message
• Graft is only used after a prune
• Waits for “graft ack”
If no ack, re-send
• When prune times out, upstream router starts flooding traffic again (7200 sec.)
• Router receives message, duplicates and sends it to local subscribers, and sends it on (if necessary)
New Tree
Graf
t
Graft
New Client New Client

ROUTING TABLE
Server R1 Route Exchange R2
Route Exchange
Client
R3
-> show ip dvmrp route

Address/Mask Gateway Metric Age Expires Flags
--------------+---------+------+------------+---------+-----
11.0.0.0/ 55.0.0.5 2 00h:13m:14s 02m:07s R
22.0.0.0/8 44.0.0.4 2 10h:33m:14s 02m:15s R
44.0.0.0/8 - 10 5h:24m:59s - L
CLI CONFIGURATION
• Minimum configuration
-> ip load dvmrp
-> ip dvmrp interface <interface_name>
-> ip dvmrp admin-state enable
-> write memory
• Summary of the show commands used for verifying the DVMRP configuration
THANK YOU
OMNISWITCH R8
P R O T O C O L I N D E P E N D E N T M U LT I C A S T ( P I M )
OBJECTIVES
• Describe the PIM Dense Mode protocol

• Describe the PIM Sparse Mode protocol
• Learn how to configure and monitor them
PIM - SPARSE MODE (PIM-SM)
AOS SPECIFICATIONS
• Protocol Independent Multicast – Sparse Mode version 2
• RFCs Supported
• 2362 - Protocol Independent Multicast-Sparse Mode (PIM-SM) Protocol Specification
• 2934 - Protocol Independent Multicast MIB for Ipv4
• 2932 - Ipv4 Multicast Routing MIB
• 3973 - Protocol Independent Multicast-Dense Mode (PIM-DM)
• 3376 - Internet Group Management Protocol
• 4601 - Protocol Independent
• 128 interfaces
• Maximum RPs allowed in a PIM-SM domain
• 100 (default value is 32)
• 1 multicast protocol per interface (PIM or DVMRP)
AOS SPECIFICATIONS
Specifications
PIM-SM - PROTOCOL OVERVIEW
Source 1
• PIM-SM is not a flood and prune mechanism.
It requires explicit joins. A1
• PIM-SM relies on the underlying IGP protocols

to make its routing decisions. B 1000
• It uses a Rendezvous Point (RP) as a shared
100
tree where sources send data to the RP who
A
distributes the data to receivers using a shared
100 D
tree.
• PIM-SM, like all multicast protocols, uses 100
Reverse Path Forwarding (RPF). C
• RPF = Forward a multicast packet only if it is

received on an interface that is used by the
D1
router to route to the source.
C1
NEIGHBOR DISCOVERY & DESIGNATED ROUTER
• Neighbor Discovery
• PIM Hello
PIM
• Periodic multicast group address packet router
(224.0.0.13= ALL-PIM-ROUTERS group)
PIM Hello
• TTL= 1
• Default = 30 seconds
PIM Hello
• Designated Router (DR) PIM Hello
• One per subnet, sends join messages to RP PIM PIM

router router
• Election based on:
• Highest Priority
• Highest IP address
• If the “DR” times-out, a new “DR” is elected
• Interface is added to egress interface list for all groups when first neighbor is heard
PIM-SM - RENDEZ-VOUS POINT TREE RPT
224.2.190.33 R1 R2
• Rendezvous Point (RP)
Server RP
• Common forwarding router for a shared distribution
tree 1/2/5
172.39.2.2 PIM Join
• Each group has a RP
• Receivers send explicit join message to RP R3
• Each source sends multicast data packets
1/1/15
encapsulated in unicast packets to RP (Register PIM Join
message). Register message Client
• RP can be configured statically Multicast Traffic
• Or dynamically through a Bootstrap router PIM Join IGMP R4

• Robustness: When the primary RP goes down,
bootstrap protocol can select an alternate RP -> show ip multicast forward
• A Candidate Rendezvous Point (C-RP) sends periodic

C-RP advertisements to the BSR
• Shared Distribution Tree/ Rendezvous Point Tree
(RPT)
• The distribution tree for multicast traffic
PIM-SM - SHORTEST PATH TREE (SPT)
• Once the last-hop router receives traffic form the RP along the RPT, it sends a PIM join
message towards the source of traffic.
• This forms the shortest path tree (SPT), which is rooted at the first-hop router closest to
the source.
(S,G) join
Server R1 R2
RP
172.39.2.2
PIM Join R3
Multicast Traffic
Client
R4
PIM-SM - SPT SWITCHOVER
• Once the multicast traffic goes along the SPT, Server
the last-hop router generates a PIM prune R1 Register-Stop R2
message towards the RP. RP
172.39.2.2
Prune
• The RP stops sending multicast traffic along the
RPT and generates a Register-Stop message that PIM Prune
R3
is sent to the first-hop router Multicast Traffic
Prune
Client
• The first-hop router stops the encapsulation of
the multicast traffic that was sent to the RP and R4
forwards the traffic along the SPT.
The switchover is initiated automatically by the last DR

SPT status is enabled by default
1
BOOTSTRAP ROUTER
• BootStrap Router (BSR)
• Keeps routers in network up to date on reachable C-
RPs Bootstrap (I want to be BSR)
• Candidate Bootstrap Router (C-BSR)

• Eligible to become a BSR 2
• Bootstrap election mechanism
• Multiple routers configured with a priority
• While only a single BSR can be operational at one
time, other routers are available to take over in the
Bootstrap (I am the new BSR )
event of a failure
• C-RP periodically sends out C-RP advertisements
• When a BSR receives one of these advertisements, 3
the associated C-RP is considered reachable (if it has
a valid route)
• BSR then periodically sends its RP set to neighboring
routers in the form of a Bootstrap message C-RP (I want to be RP for this group)
BOOTSTRAP ROUTER
• Calculation steps for selecting the RP
• RP set = list of reachable C-RPs
• Locate all RPs in RP-Set associated with the most specific advertised group range for the specific
group in the PIM Join message
• All devices with the best priority (lowest value)
• Highest Hash value using the group address, the RP address, and the advertised then elect the RP with the
highest hash value
• RP with the highest IP address
RP-SET 5
4
RP Group
RP-Set (list of CRP/Group)

PIM
DENSE MODE (PIM –DM)
PIM-DM - OVERVIEW
• Protocol Independent Multicast – Dense Mode
• Designed for networks with many receivers
• Flood and Prune operation similar to DVMRP

• Does flood all multicast traffic initially
• Performs reverse path forwarding (RPF)
• Fully integrated with the existing PIM Sparse Mode

• Still relies on unicast routing protocols such as RIP and OSPF
• Same packet formats as PIM-SM
• Re-using “pim” configuration
• No periodic joins transmitted, only explicitly triggered prunes and grafts
• No Rendezvous Point (RP)
PIM-DM - FLOOD AND PRUNE
• Traffic is flooded throughout the entire network
• Routers receive multicast traffic on RPF interfaces
Server • Routers forward to their neighbors
• Packets received on non RPF interfaces are dropped
Client
Client Server
Client
Client
• PIM Prunes are sent to stop unwanted traffic

• Multicast Traffic flows through network Client Client
• The tree is pruned
• Prunes timeout in 3 minutes
Flood & Prune process
• Traffic is flooded throughout the entire network
repeats every 3 minutes
• Prune process takes place
OPERATION AND CONFIGURATION
PIM - CLI
Minimum configuration
PIM-SM & SSM
-> ip load pim
-> ip pim interface <interface_name >
-> ip pim ssm group group_address/prefix_length [[no] override] [priority priority]
-> ip pim candidate-rp rp_address group-address/prefix_length [priority priority] [interval seconds]
-> ip pim cbsr <interface_address >
-> ip pim sparse admin-state enable
PIM-DM
-> ip load pim
-> ip pim interface <interface_name >
-> ip pim dense group group_address/prefix_length [[no] override] [priority priority]
-> ip pim dense admin-state enable
PIM-SM - ADVANCED CONFIGURATION
• Candidate Bootstrap Routers (C-BSRs)
-> ip pim cbsr 192.168.3.1 priority 0
• Highest Priority value (0 to 255, default=64) –> Highest IP address
• Static RP
-> ip pim static-rp group_address/prefix_length rp_address [[no] override] [priority priority]
• Interface
• Designated Router (DR)
• Highest Priority value (default=1) –> Highest IP address
-> ip pimsm interface int_name dr-priority priority
• Stub
• Specifies to not send any PIM packets via this interface, and to ignore received PIM packets
-> ip pimsm interface int_name stub

• SPT Switchover
• Last hop DR switching to the SPT begins once the first data packet is received
-> ip pim spt admin-state enable
• Source-specific (S, G) Join message
-> ip pim rp-threshold value (default=1)
• Specifies the data rate, in bits per second (bps), at which the RP will attempt to switch to native forwarding by issuing a source-specific (S, G) Join message toward the
source
-> show ip pim sparse
PIM - MONITORING Status
Keepalive Period
=
=
enabled,
210,
Max RPs = 32,
-> show ip pim? Probe Time = 5,
Register Checksum = header,
BSR
Register Suppress Timeout = 60,
CANDIDATE-RP RP Threshold = 1000,
CBSR SPT Status = enabled
DENSE
GROUP-MAP -> show ip pim dense
GROUTE Status = enabled,
Source Lifetime = 210,
INTERFACE
State Refresh Interval = 60,
NEIGHBOR State Refresh Limit Interval = 0,
NOTIFICATIONS State Refresh TTL = 16
SGROUTE
SPARSE -> show ip pim cbsr
SSM CBSR Address = 192.168.70.7,
STATIC-RP Status = enabled,
CBSR Priority = 64,
Hash Mask Length = 30,
Elected BSR = False,
Timer = 00h:00m:00s,
sw7 (6860-A) -> show ip pim candidate-rp

RP Address Group Address Priority Interval Mode Status
----------------+-------------------+---------+---------+-----+---------
192.168.70.7 231.5.5.0/24 192 60 asm enabled
192.168.70.7 231.7.7.0/24 192 60 asm enabled
PIM - MONITORING
-> show ip pim? -> show ip pim neighbor
BSR Total 1 Neighbors
CANDIDATE-RP Neighbor Address Interface Name Uptime Expires DR Priority
CBSR -----------------+--------------------+-----------+-----------+-----------
DENSE 192.168.3.2 vlan3 22h:52m:32s 00h:01m:44s 1
GROUP-MAP
GROUTE -> show ip pim group-map
INTERFACE Origin Group Address/Prefix RP Address Mode Precedence
NEIGHBOR -----------+---------------------+---------------+-----+-----------
NOTIFICATIONS Static RP 228.0.0.0/8 192.168.3.2 asm none
SGROUTE Static SSM 226.0.0.0/8 dm none
SPARSE Static SSM 231.0.0.0/8 ssm none RP-set
SSM BSR 225.0.0.0/8 192.168.3.1 asm 20
STATIC-RP BSR 225.0.0.0/8 192.168.3.2 asm 30
-> show ip pim ssm group

Group Address/Prefix RP Address Mode Override Precedence Status
--------------------+-----------+-----+--------+----------------------
231.0.0.0/8 0.0.0.0 ssm false none enabled
PIM - MONITORING
-> show ip pim? -> show ip pim groute
BSR Total 1 (*,G)
CANDIDATE-RP Group Address RP Address RPF Interface Upstream Neighbor UpTime
---------------+--------------+-------------------+-------------------+---------
CBSR
225.0.0.101 192.168.3.1 00h:12m:09s
DENSE
GROUP-MAP
-> show ip pim sgroute
GROUTE
Legend: Flags: D = Dense, S = Sparse, s = SSM Group,
INTERFACE L = Local, R = RPT, T = SPT, F = Register,
NEIGHBOR P = Pruned, O = Originator
NOTIFICATIONS Total 2 (S,G)
SGROUTE Source Address Group Address RPF Interface Upstream Neighbor UpTime Flags
---------------+---------------+----------------+-------------------+--------+------
SPARSE
192.168.100.100 225.0.0.101 vlan100 00h:52m:21s STL
SSM 192.168.100.100 226.0.0.102 vlan100 00h:52m:21s DOL
STATIC-RP
-> show ip mroute
Total 2 Mroutes
Group Address Src Address Upstream Nbr Route Address Proto
---------------+------------------+---------------+-------------------+------
225.0.0.101 192.168.100.100/32 0.0.0.0 192.168.100.1/24 PIM-SM
226.0.0.102 192.168.100.100/32 0.0.0.0 192.168.100.0/24 PIM-DM
PIM - MONITORING
-> show ip pim sgroute 192.168.100.100
225.0.0.101
(192.168.100.100,225.0.0.101)
UpTime = 01h:15m:49s
PIM Mode = ASM,
-> show ip pim groute 225.0.0.101 Upstream Join State = Not Joined,
(*,225.0.0.101) Upstream RPT State = Not Joined,
UpTime = 00h:32m:53s Upstream Join Timer = 00h:00m:00s,
RP Address = 192.168.3.1, Upstream Neighbor = none,
PIM Mode = ASM, SPT Bit = True,
PIM Mode Origin = Static RP, DR Register State = Pruned,
Upstream Join State = Not Joined, DR Register Stop Timer = 00h:00m:00s,
Upstream Join Timer = 00h:00m:00s, Interface Specific State:
Upstream Neighbor = none, vlan3
Interface Specific State: UpTime = 01h:15m:49s,
vlan3 Local Membership = False,
UpTime = 00h:32m:53s, Join/Prune State = Joined,
Local Membership = False, RPT State = No Info,
Join/Prune State = Joined, Prune Pending Timer = 00h:00m:00s,
Prune Pending Timer = 00h:00m:00s, Join Expiry Timer = 00h:02m:49s,
Join Expiry Timer = 00h:02m:37s, Assert State = No Info,
Assert State = No Info, Assert Timer = 00h:00m:00s,
Assert Timer = 00h:00m:00s, vlan100
vlan100 UpTime = 00h:00m:00s,
UpTime = 00h:00m:00s, Local Membership = False,
Local Membership = False, Join/Prune State = No Info,
Join/Prune State = No Info, RPT State = No Info,
Prune Pending Timer = 00h:00m:00s, Prune Pending Timer = 00h:00m:00s,
Join Expiry Timer = 00h:00m:00s, Join Expiry Timer = 00h:00m:00s,
Assert State = No Info, Assert State = No Info,
Assert Timer = 00h:00m:00s, Assert Timer = 00h:00m:00s,
THANK YOU
OmniSwitch R8
PIM-SM
How to
✓ This lab is designed to familiarize you with the PIM-SM capability on an
OmniSwitch.
Contents
1 Topology ........................................................................................ 2
2 PIM-SM Configuration ......................................................................... 5
2
PIM-SM
1 Topology
Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information
provided by unicast routing protocols such as RIP and OSPF. PIM is “protocol-independent” because it does
not rely on any particular unicast routing protocol.
3
PIM-SM
- In the multicast switching lab, all requesting devices in the same VLAN received the multicast stream.
Now let’s move the receivers into different VLANs. This will require the multicast traffic to be routed in
order to reach each receiver. PIM-SM gives us the capability to route multicast traffic.
- A multicast router is by default an IGMP querier, we can disable the querier forwarding on both 6860
6860-A -> ip multicast querier-forwarding disable
6860-B -> ip multicast querier-forwarding disable
- Move back client 8 to vlan 80
- Configure an IP DHCP relay on each switch 6900-A and 6900-B:

o On the 6900-A:
sw1 (6900-A) -> ip dhcp relay destination 192.168.100.102
sw1 (6900-A) -> ip dhcp relay admin-state enable
sw1 (6900-A) -> show ip dhcp relay
IP DHCP Relay :
- Configure an IP DHCP relay on each switch 6900-A and 6900-B:

o On the 6900-B:
sw2 (6900-B) -> ip dhcp relay destination 192.168.100.102
sw2 (6900-B) -> ip dhcp relay admin-state enable
IP DHCP Relay :
4
PIM-SM
- On the 6900, check that OSPF still runs properly and that all client vlans are reachable:

Total 25 routes

------------------+-------------------+----------+-----------
0.0.0.0/0 192.168.100.108 3d 4h STATIC
10.0.0.51/32 192.168.100.108 3d 4h STATIC
127.0.0.1/32 127.0.0.1 4d 4h LOCAL
172.16.12.0/24 172.16.12.1 3d 6h LOCAL
172.16.17.0/24 172.16.17.1 3d 1h LOCAL
172.16.28.0/24 172.16.12.2 3d 6h OSPF
172.16.78.0/24 172.16.17.7 3d 1h OSPF
172.16.137.0/24 172.16.17.7 3d 1h OSPF
192.168.20.0/24 172.16.17.7 3d 1h OSPF
192.168.30.0/24 172.16.17.7 3d 1h OSPF
192.168.57.0/24 172.16.17.7 3d 1h OSPF
192.168.60.0/24 172.16.17.7 3d 1h OSPF
192.168.70.0/24 172.16.17.7 3d 1h OSPF
192.168.80.0/24 +172.16.12.2 3d 4h OSPF
+172.16.17.7 3d 1h OSPF
192.168.100.0/24 192.168.100.1 3d 4h LOCAL
192.168.110.0/24 192.168.110.1 00:00:11 LOCAL
192.168.120.0/24 172.16.12.2 3d 5h OSPF
192.168.254.1/32 192.168.254.1 3d 6h LOCAL
192.168.254.2/32 172.16.12.2 3d 6h OSPF
192.168.254.3/32 172.16.17.7 3d 1h OSPF
192.168.254.5/32 172.16.17.7 3d 0h OSPF
192.168.254.7/32 172.16.17.7 3d 1h OSPF
192.168.254.8/32 +172.16.12.2 3d 6h OSPF
+172.16.17.7 3d 1h OSPF
5
PIM-SM
2 PIM-SM Configuration
- Enable PIM-SM in the core routers:
6900-A -> ip load pim

6900-A -> ip pim sparse admin-state enable
6900-B -> ip load pim

6900-B -> ip pim sparse admin-state enable


- Now, we must enable PIM-SM on the necessary interfaces.
6900-A -> ip pim interface int_217

6900-A -> ip pim cbsr 192.168.110.1
6900-B -> ip pim interface int_228

6900-B -> ip pim cbsr 192.168.120.2

6860-A -> ip pim cbsr 192.168.70.7

6860-B -> ip pim cbsr 192.168.80.8
- Now, we must define a CRP for a multicast group.
6900-A-> ip pim candidate-rp 192.168.110.1 231.1.1.0/24
6900-B-> ip pim candidate-rp 192.168.120.2 231.1.1.0/24
6860-A -> ip pim candidate-rp 192.168.70.7 231.5.5.0/24

6860-A -> ip pim candidate-rp 192.168.70.7 231.7.7.0/24
6860-B -> ip pim candidate-rp 192.168.80.8 231.10.10.0/24

6860-B -> ip pim candidate-rp 192.168.80.8 231.8.8.0/24
6
PIM-SM
- Check connectivity status on all 3 switches:
sw1 (6900-A) -> show ip pim interface
Total 3 Interfaces
Interface Name IP Address Designated Hello J/P Oper BFD

Router Interval Interval Status Status
--------------------------------+---------------+---------------+--------+--------+--------+--------
int_217 172.16.17.1 172.16.17.7 30 60 enabled disabled
int_110 192.168.110.1 192.168.110.1 30 60
sw2 (6900-B) -> show ip pim interface
Total 3 Interfaces

--------------------------------+---------------+---------------+--------+--------+--------+--------
sw7 (6860-A) -> show ip pim interface
Total 5 Interfaces

--------------------------------+---------------+---------------+--------+--------+--------+--------
sw8 (6860-B) -> show ip pim interface
Total 5 Interfaces

--------------------------------+---------------+---------------+--------+--------+--------+--------
- Check the Pim neighbor and group-map
sw1 (6900-A) -> show ip pim neighbor
Total 2 Neighbors
Neighbor Address Interface Name Uptime Expires DR Priority

-----------------+--------------------------------+--------------+--------------+-----------
172.16.17.7 int_217 00h:07m:01s 00h:01m:43s 1
172.16.12.2 int_212 00h:07m:22s 00h:01m:22s 1
7
PIM-SM
sw2 (6900-B) -> show ip pim neighbor
Total 2 Neighbors

-----------------+--------------------------------+--------------+--------------+-----------
172.16.28.8 int_228 00h:08m:09s 00h:01m:37s 1
172.16.12.1 int_212 00h:08m:02s 00h:01m:44s 1
sw7 (6860-A) -> show ip pim neighbor
Total 3 Neighbors

-----------------+--------------------------------+--------------+--------------+-----------
172.16.78.8 int_278 00h:07m:59s 00h:01m:16s 1
172.16.17.1 int_217 00h:08m:38s 00h:01m:39s 1
192.168.30.8 int_30 00h:07m:42s 00h:01m:33s 1
sw8 (6860-B) -> show ip pim neighbor
Total 3 Neighbors

-----------------+--------------------------------+--------------+--------------+-----------
172.16.78.7 int_278 00h:08m:29s 00h:01m:37s 1
192.168.30.7 int_30 00h:08m:12s 00h:01m:23s 1
172.16.28.2 int_228 00h:09m:41s 00h:01m:34s 1
sw1 (6900-A) -> show ip pim group-map
Origin Group Address/Prefix RP Address Mode Precedence

-----------+---------------------+---------------+-----+-----------
BSR 231.1.1.0/24 192.168.110.1 asm 192
BSR 231.1.1.0/24 192.168.120.2 asm 192
BSR 231.5.5.0/24 192.168.70.7 asm 192
BSR 231.7.7.0/24 192.168.70.7 asm 192
BSR 231.8.8.0/24 192.168.80.8 asm 192
BSR 231.10.10.0/24 192.168.80.8 asm 192
- Manage the client 1, client 6 and 9 to send and receive multicast traffic as indicated in the tables below.
- Use the application multicast tool from the desktop to do it.
PC Client Send Receive
Client 1 grps: 231.1.1.1 grps: 231.10.10.10

Client 6 grps: 231.10.10.10 grps: 231.5.5.5
Client 9 grps: 231.5.5.5 grps: 231.1.1.1
Example:
PC Client Send PC Client Receive

Client 6 (Vlan 20) grps: 231.10.10.10 Client 1 (vlan 110) grps: 231.10.10.10
8
PIM-SM
- Check the multicast routing table:
sw1 (6900-A) -> show ip pim sgroute

L = Local, R = RPT, T = SPT, F = Register,
P = Pruned, O = Originator
Total 1 (S,G)
Source Address Group Address RPF Interface Upstream Neighbor UpTime Flags
---------------+---------------+--------------------------------+-----------------+--------------+--------
192.168.20.70 231.10.10.10 int_217 172.16.17.7 00h:00m:48s ST
sw7 (6860-A) -> show ip pim sgroute

Total 1 (S,G)
---------------+---------------+--------------------------------+-----------------+--------------+--------
192.168.20.70 231.10.10.10 int_20 192.168.20.8 00h:02m:18s ST
sw8 (6860-B) -> show ip pim sgroute

Total 1 (S,G)
---------------+---------------+--------------------------------+-----------------+--------------+--------
192.168.20.70 231.10.10.10 int_20 00h:00m:15s STL
- Do the same with client 6 and 9

Client 1 grps: 231.1.1.1 grps: 231.10.10.10
Client 6 grps: 231.10.10.10 grps: 231.5.5.5
Client 9 grps: 231.5.5.5 grps: 231.1.1.1
OMNISWITCH R8
V I R T U A L R O U T I N G A N D F O RWA R D I N G
OBJECTIVES
• Understand the concept of VRF

• Configure VRF in an OmniSwitch
• Learn the VRF route Leak feature
VRF - VIRTUAL ROUTING AND FORWARDING
• Multiple routing instances within the same physical switch
• Multiple instances of IP routing protocols, such as static, RIP, IPv4, BGPv4, and OSPFv2 on
the same physical switch
• Ability to use duplicate IP addresses across VRF instances
• Separate IP routing domains for customer networks
OR
VRF 1
VRF 2
VRF 3
• VRF Interaction With Other Features
VRF Aware. Switch applications that are configurable independently and separately within one or more VRF instances. All VRF aware
applications can be enabled or disabled on each VRF instance
Default VRF. Switch applications that are VRF aware but only use the default VRF instance when IP connectivity is needed; these applications
are not supported across multiple VRF instances.
Non-VRF Aware. Switch applications that have no association with any VRF instance, even the default instance. Note that configuration of this
type of application is only allowed when the default instance is the active CLI context
• Provides the ability to configure separate • When an IP packet for customer A is
routing instances on the same switch. received on a PE; the VRF A determines how
• Segments layer 3 traffic. to route the packet trough the provider
• Each Provider Edge (PE) maintains more backbone so that it reaches the intended
than one routing table, in addition to the customer A destination
default routing instance. Customer A
Site 2
• One VRF instance is configured on the PE for

each customer network to which the PE is
VRF A Customer B
connected. Provider Site 2
Customer A Edge 2
Site 1
VRF A VRF B
Customer B
VRF B
Service Provider
Site 1
IP Network
Customer A
Provider Site 3
Customer C Edge 1
Site 1 VRF C VRF B
Provider
Edge 3
VRF C Customer B
Site 2
VRF
OR Customer
Per VRF QoS
VRF Edge
VRF 1
VRF 2
VRF 3
VRRP
DHCP Server 1
VRRP
DHCP Server 2
Enterprise class MPLS
VRRP
DHCP Server 3
Provider
Edge
VRF - CLI COMMANDS
• Creating a VRF Instance • Assigning IP Interfaces to a VRF Instance
-> vrf create vrpIpOne -> vrf IpOne
IpOne: -> IpOne: -> ip interface intf100 address 100.1.1.1/24 vlan 100
IpOne: ->
• Selecting a VRF Instance
IpOne: -> vrf IpTwo • Removing a VRF Instance
IpTwo: -> -> no vrf IpTwo
• View a list of the Configured VRF’s *removes associated ip interfaces as well

-> show vrf
Virtual Routers Protocols
--------------------------------------- • Returning to the default VRF instance
default
IpOne RIP IpOne: -> vrf default
IpTwo BGP ->
Total Number of Virtual Routers: 3 Note: VRF names are case sensitive
▪ A default VRF instance is automatically configured and available on system startup

▪ VRF names to be 32 characters long and contain letters, minus signs and numbers
VRF - CLI COMMANDS
• View a list of the Configured VRF interfaces
-> vrf create IpOne
IpOne: -> show ip interface
Total 1 interfaces
-------------+---------------+---------------+----------+----------+----------
intfone 200.1.1.1 255.255.255.0 DOWN NO vlan 200
IpOne: -> vrf default

Total 6 interfaces
------------+----------------+------------------+---------+-------+----------
EMP 192.168.10.1 255.255.255.0 DOWN NO EMP
vlan 130 192.168.130.161 255.255.255.0 DOWN NO vlan 130
vlan 2 10.255.11.161 255.255.255.0 UP YES vlan 2
vlan-2000 172.20.0.1 255.255.0.0 UP YES vlan 2000
vlan-2100 172.21.0.1 255.255.0.0 UP YES vlan 2100
Number of Virtual Routers: 3
VRF - GUIDELINES
• A single IP interface, as well as the VLAN associated with the interface, can only belong to
one VRF instance at a time
• Once a VLAN is associated with a specific VRF instance, configuring an interface for that
VLAN within the context of any other instance, is not allowed
• For example, if the first IP interface configured for VLAN 100 was associated with the VRF IpOne
instance, then any subsequent IP interface configuration for VLAN 100 is only allowed within the
context of the IpOne instance
• Use of Duplicate VLAN numbers is not supported
• A VRF instance can have multiple VLAN associations

• even though a VLAN can only have one VRF association
• VRF CLI context is used to determine the association between a specific routing
configuration and a VRF instance
VRF ROUTE LEAK
• VRF Route Leak forwards routes from one VRF routing table to another VRF routing table,
allowing routing from one VRF to a gateway in another VRF.
• Route maps are used to import and export routes from the VRFs to the GRT.
200.1.1.0
GRT
200.1.1.0
VRF 192.168.130.160
VRF 1
10.255.11.160
192.168.130.0 172.20.0.0
10.255.11.0 172.21.0.0
VRF 2 172.20.0.0 192.168.140.0
172.21.0.0 10.255.12.0
VRF 3 192.168.1.0 192.168.1.0
6860E/N, 6900, 9900

192.168.140.0
10.255.12.0
192.168.1.0
CONFIGURING VRF ROUTE LEAK
• Create a route-map to use as a filter for exporting or importing routes
-> ip route-map R1 action permit
• Define protocol preference for export policy route map. This route map controls the export of
routes from the VRF FDB (Forwarding Routing Database) to the GRT (Global Routing Table)
-> ip route-map R1 match protocol static
• Export routes from the source VRF to the GRT
-> ip export route-map R1
• Define protocol preference for import policy route map. This route map controls the import of
routes from the GRT.
-> ip route-map R2 match protocol static
• Import the leaked routes from the GRT
-> ip import vrf V1 route-map R2
• Configure route preference for imported routes
-> ip route-pref import 100
THANK YOU
OmniSwitch R8
Multiple VRF
How to
✓ Configure the Multiple VRF feature in Release 8
Contents
1 Topology ........................................................................................ 2
2 Configuring the Multiple VRF ................................................................ 2
2.1. Configure two VRF on 6900: ...................................................................... 2
2.2. VRF route leaking between two different networks ........................................... 5
2.3. VRF route-leak to leak the routes between 'default' VRF and a another VRF .............. 7
2
Multiple VRF
1 Topology
Multiple Virtual Routing and Forwarding (VRF) provides a mechanism for segmenting Layer 3 traffic into
virtual routing domains (instances) on the same switch. Each routing instance independently maintains its
own routing and forwarding table, peer, and interface information.
2 Configuring the Multiple VRF
2.1. Configure two VRF on 6900:
- Create two vlan and untagged them on port 1/1/ and 1/1/12
sw1 (6900-A) -> vlan 190
sw1 (6900-A) -> vlan 200

port type status
----------+-----------+---------------

port type status
----------+-----------+---------------
3
Multiple VRF
- Check the ip route on default vfr

Total 24 routes
------------------+-------------------+----------+-----------
0.0.0.0/0 192.168.100.108 3d 3h STATIC
10.0.0.51/32 192.168.100.108 3d 3h STATIC
127.0.0.1/32 127.0.0.1 4d 3h LOCAL
172.16.12.0/24 172.16.12.1 3d 4h LOCAL
172.16.17.0/24 172.16.17.1 3d 0h LOCAL
172.16.28.0/24 172.16.12.2 3d 4h OSPF
172.16.78.0/24 172.16.17.7 3d 0h OSPF
172.16.137.0/24 172.16.17.7 3d 0h OSPF
192.168.20.0/24 172.16.17.7 3d 0h OSPF
192.168.30.0/24 172.16.17.7 3d 0h OSPF
192.168.57.0/24 172.16.17.7 3d 0h OSPF
192.168.60.0/24 172.16.17.7 3d 0h OSPF
192.168.70.0/24 172.16.17.7 3d 0h OSPF
192.168.80.0/24 +172.16.12.2 3d 3h OSPF
+172.16.17.7 3d 0h OSPF
192.168.100.0/24 192.168.100.1 3d 3h LOCAL
192.168.120.0/24 172.16.12.2 3d 3h OSPF
192.168.254.1/32 192.168.254.1 3d 5h LOCAL
192.168.254.2/32 172.16.12.2 3d 4h OSPF
192.168.254.3/32 172.16.17.7 3d 0h OSPF
192.168.254.5/32 172.16.17.7 2d23h OSPF
192.168.254.7/32 172.16.17.7 3d 0h OSPF
192.168.254.8/32 +172.16.12.2 3d 4h OSPF
+172.16.17.7 3d 0h OSPF
sw1 (6900-A) -> sh ip global-route-table

Type Source Destination Gateway Metric Tag
------+--------------------+------------------+---------------+----------+----------
sw1 (6900-A) ->
- Create a “ipone” VRF and manage an ip interface on it
sw1 (6900-A) -> vrf create ipone

Wed Feb 23 14:48:06 : ChassisSupervisor MipMgr INFO message:
+++ VRF:ipone created
ipone::sw1 (6900-A) -> ip interface int_190 address 192.168.190.1/24 vlan 190
ipone::sw1 (6900-A) -> show ip interface

Total 1 interfaces
--------------------------------+---------------+---------------+------+-------+---------+------
int_190 192.168.190.1 255.255.255.0 UP YES vlan 190
ipone::sw1 (6900-A) -> show ip routes

Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:00:30 LOCAL
192.168.190.0/24 192.168.190.1 00:00:16 LOCAL
ipone::sw1 (6900-A) -> exit

4
Multiple VRF
- Check the ip route list on default VRF

sw1 (6900-A) -> show ip routes |grep 190
sw1 (6900-A) ->
- Create a second VRF as “iptwo”

sw1 (6900-A) -> vrf create iptwo
Wed Feb 23 14:49:11 : ChassisSupervisor MipMgr INFO message:

+++ VRF:iptwo created
iptwo::sw1 (6900-A) -> ip interface int_200 address 192.168.200.1/24 vlan 200
iptwo::sw1 (6900-A) -> show ip interface

Total 1 interfaces

--------------------------------+---------------+---------------+------+-------+---------+------
int_200 192.168.200.1 255.255.255.0 UP YES vlan 200
iptwo::sw1 (6900-A) -> show ip routes

Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:03:59 LOCAL
192.168.200.0/24 192.168.200.1 00:00:36 LOCAL
iptwo::sw1 (6900-A) -> exit
- Check the ip route list on default VRF

sw1 (6900-A) -> show ip routes |grep 200
sw1 (6900-A) ->
- Manage Client 1 and Client2 Ip addresses as below:

o Client 1:
Assign IP address : 192.168.190.50/24

Subnet :255.255.255.0
Gateway : 192.168.190.1
o Client 4:
Assign IP address : 192.168.200.50/24

Subnet :255.255.255.0
Gateway : 192.168.200.1
- Ping each other to test connection between them. What happens and why?
----------------------------------------------------------------------------------------------------------------------------- -
----------------------------------------------------------------------------------------------------------------------------- -
5
Multiple VRF
- Check the ip route list on VRF
sw1 (6900-A) -> vrf ipone


Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:03:37 LOCAL
192.168.190.0/24 192.168.190.1 00:03:23 LOCAL
sw1 (6900-A) -> vrf iptwo

Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:01:57 LOCAL
192.168.200.0/24 192.168.200.1 00:01:49 LOCAL
2.2. VRF route leaking between two different networks
Manage VRF route leaking between two different networks which are present in different VRF's
We will not be able to ping an IP interface of another VRF instance from one VRF instance within the same switch even
the leaked routes are existed. This is due to security reason
However, clients in two different VRF's can ping each other using the route-map filtering option
- Manage Route filtering in VRF1
In this ipone, using rout-map ("vlan190") local route (192.168.190.0/24) is exported to GRT. Only those FDB
(Forwarding Routing Database) routes that match the conditions of the route map are exported to GRT.
And allowing leaked route 192.168.200.0/24 to ingress in the VRF1 using the route-map " vlan200".
ipone::sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 action permit
ipone::sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 match ip-address 192.168.190.0/24 redist-
control all-subnets permit
ipone::sw1 (6900-A) -> ip route-map "vlan200" sequence-number 50 action permit
ipone::sw1 (6900-A) -> ip route-map "vlan200" sequence-number 50 match ip-address 192.168.200.0/24 redist-
ipone::sw1 (6900-A) -> ip export route-map vlan190
ipone::sw1 (6900-A) -> ip import vrf iptwo route-map vlan200

6
Multiple VRF
ipone::sw1 (6900-A) -> show ip route-map
Route Maps: configured: 2 max: 30

Route Map: vlan170 Sequence Number: 50 Action permit
match ip-address 192.168.190.0/24 redist-control all-subnets permit
Route Map: vlan180 Sequence Number: 50 Action permit
match ip-address 192.168.200.0/24 redist-control all-subnets permit

Total 2 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:05:30 LOCAL
192.168.190.0/24 192.168.190.1 00:05:16 LOCAL
- Check the route map are exported to GRT
sw1 (6900-A) -> show ip global-route-table

------+--------------------+------------------+---------------+----------+----------
vrf ipone 192.168.190.0/24 192.168.170.1 1 0
- Manage Route filtering in VRF2
In this vrf “ iptwo “, using rout-map (vlan200) local route (192.168.200.0/24) is exported to GRT. Only those FDB
(Forwarding Routing Database) routes that match the conditions of the route map are exported to GRT.
And allowing leaked route 192.168.190.0/24 to ingress in the VRF” iptwo” using the route-map " vlan190".
sw1 (6900-A) -> vrf iptwo
iptwo::sw1 (6900-A) -> ip route-map "vlan200" sequence-number 50 action permit

iptwo::sw1 (6900-A) -> ip route-map "vlan200" sequence-number 50 match ip-address 192.168.200.0/24 redist-
iptwo::sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 action permit
iptwo::sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 match ip-address 192.168.190.0/24 redist-
iptwo::sw1 (6900-A) -> ip export route-map vlan200
iptwo::sw1 (6900-A) -> ip import vrf ipone route-map vlan190

Total 3 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:04:42 LOCAL
192.168.190.0/24 192.168.190.1 00:00:04 IMPORT
192.168.200.0/24 192.168.200.1 00:04:34 LOCAL

7
Multiple VRF

------+--------------------+------------------+---------------+----------+----------
vrf ipone 192.168.190.0/24 192.168.190.1 1 0
vrf iptwo 192.168.200.0/24 192.168.200.1 1 0

Total 3 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:07:42 LOCAL
192.168.190.0/24 192.168.190.1 00:07:28 LOCAL
192.168.200.0/24 192.168.200.1 00:00:57 IMPORT
- Ping client 1 from client 4 to test connection between them.

- With this above configuration the clients in two different VRF can ping each other.
2.3. VRF route-leak to leak the routes between 'default' VRF and a another VRF
sw1 (6900-A) -> ip route-map "vlan100" sequence-number 50 action permit

sw1 (6900-A) -> ip route-map "vlan100" sequence-number 50 match ip-address 192.168.100.0/24 redist-control
all-subnets permit
sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 action permit

sw1 (6900-A) -> ip route-map "vlan190" sequence-number 50 match ip-address 192.168.190.0/24 redist-control
all-subnets permit
sw1 (6900-A) -> ip export route-map vlan100

sw1 (6900-A) -> ip import vrf ipone route-map vlan190

------+--------------------+------------------+---------------+----------+----------
vrf default 192.168.100.0/24 192.168.100.1 1 0
vrf ipone 192.168.190.0/24 192.168.190.1 1 0
vrf iptwo 192.168.200.0/24 192.168.200.1 1 0

ipone::sw1 (6900-A) -> ip route-map " vlan100" sequence-number 50 action permit
ipone::sw1 (6900-A) -> ip route-map " vlan100" sequence-number 50 match ip-address 192.168.100.0/24
redist-control all-subnets permit
ipone::sw1 (6900-A) -> ip import vrf default all-routes

Total 4 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:10:34 LOCAL
192.168.100.0/24 192.168.100.1 00:00:57 IMPORT
192.168.190.0/24 192.168.190.1 00:10:26 LOCAL
192.168.200.0/24 192.168.200.1 00:05:29 IMPORT
- Ping from client 1 ping 192.168.100.102 and do the same from client 4.
- With this above configuration only the client1 should be able to ping the 192.168.100.102.
OMNISWITCH R8
MACSEC
OBJECTIVES
• Understand MACsec standard

• List AOS switches which Support MACsec
• Configure and monitor MACsec on
OmniSwitch
- Static Mode
- Dynamic mode
• Know software limitations
MACSEC - OVERVIEW
MACSEC OVERVIEW
MACsec enable MACsec enable
Switch A Switch B
• Goal
• Prevents DoS/ M-in-M/playback attacks, intrusion,
wire-tapping, masquerading, etc Static or Dynamic SA Mode
• Secure most of the traffic on Ethernet links – LLDP
frames, LACP frames, DHCP/ARP packets, etc
MACsecDynamic
Host (MACsec) Mode Using EAP
• Functionalities • Available Modes

• IEEE 802.1AE standard that provides encryption and • Static SA Mode – Switch-to-Switch links
packet Authentication to IEEE 802.1 frames • Dynamic SA Mode
• Point-to-point security on Ethernet links between • Switch-to-Switch links
directly connected nodes • Switch-to-Host links (Using EAP)
(Data integrity and confidentiality)
• MACSec-enabled links are secured by matching
security keys
MACSEC OVERVIEW
• Packet structure
• MACSec packet Specific EtherType (0x88E5)
• 8-byte or 16-byte SecTag header containing

information about the decryption key, a packet
number and Secure Channel Identifier
• Payload (which may be optionally encrypted)
• Integrity Check Value (ICV) generated by GCM-AES of

size 16 bytes
• Packets are numbered to avoid replay

MACSEC OVERVIEW
• How it works MACsec enable MACsec enable
Switch A Switch B
• Each node has at least one transmit, and one
receive secure channel
1/1/25 1/1/26
• Each associated with a Secure Channel Identifier sci-tx key-chain 1
(SCI) sci-tx key-chain 2
• Need to Match receive secure channel, with an SA
SCI corresponding to the SCI of the transmit SA
secure channel of the peer sci-rx key-chain 1
sci-rx key-chain 2
• Within each secure channel,
secure associations (SA) are defined
• The SAs hold the encryption keys (SAK – Secure
Key-Chain 1 key1
Association Key) identified by their association
number (AN), along with a packet number (PN). key2
Key- Chain 2 Key3
Key 4
AOS SWITCHES – MACSEC SUPPORT
(MACsec site license required):
MACsec feature requires a site license, this license can be generated free of cost.
MACSEC OVERVIEW
AOS Switches – MACsec Platform Support
OmniSwitch 9900 OmniSwitch 6860(E)

OS9900-CMM 4X10G (Static mode only) OS6860(E) All models support MACsec on 10G ports.
OS9900-GNI-48/P48 10M/100M/1G ports OS6860E-P24 1G/10G ports.
OS9900-XNI-48/P48 10G ports (Static mode only)
OS9900-XNI-U48 10G ports (Static mode only) OmniSwitch 6860N Dynamic mode only.
OS9900-XNI-P48Z16 1G/2.5G/5G/10G (16x) OS6860N-U28 SFP (1-24), SFP+ (25-28) and SFP28 (31-34) ports
1G/10G (32x)
OS6860N-P48Z SFP28 (51-54) ports
OS99-GNI-U48 1G ports
OS6860N-P48M • Expansion modules (Not supported on any 4X10G
OS99-XNI-U24 10G ports (Static mode only) splitter transceivers).
OS99-XNI-P24Z8 1G/2.5G/5G/10G (8x) • Multi-rate Gigabit Ports (37-48)
1G/10G (16x) OS6860N-P24Z SFP28 (27-30) ports
OS99-XNI-U12Q 10G / 4x10G Uplink (Static mode only) OS6860N-P24M • Expansion modules (Not supported on any 4X10G
10G(Fiber)/4x10G Uplink (Static mode only) splitter transceivers)
OS99-XNI-UP24Q2 • Multi-rate Gigabit Ports (1-24)
10G (Copper) (Static mode only)
* Only 6860N and OS6900-X48E can do 256-bit MACsec at this time.
All other switches support 128-bit
OmniSwitch 6900
Dynamic mode only on all ports. Supports 256-bit
OS6900-X48C4E
key length.
MACSEC OVERVIEW
AOS Switches - MACsec Platform Support
OmniSwitch 6560
OS6560-P24X4/24X4 Ports 1-24 (Static and Dynamic modes)
OS6560-P48X4/48X4 Ports 1-48 (Static and Dynamic modes)

Ports 49-52 (Dynamic mode only)
OS6560-P48Z16 Ports 1-32 (Static and Dynamic Modes)
(904044-90 only) Ports 33-48 (Static and Dynamic modes)
Ports 49-52 (Dynamic mode only)
OS6560-X10 Ports 1-8 (10G ports only. Dynamic mode only)
OmniSwitch 6465
OS6465-P28 Supported on all ports except ports 27 and 28.
OS6465T-12 and
Not supported on ports 11 and 12.
OS6465T-P12
All other models Support MACsec on all ports.
Note: 128-bit platforms (e.g. 6465 or 6860E) in the access-layer can work
with the 6900-X48E supporting both 128 and 256-bit in the distribution/core.
MACSEC OVERVIEW
• MACsec Licensing Requirement
• MACsec feature requires a site license, this license can be generated free of cost
• There is no reboot required after applying the license.
How to generate a license or retrieve a license?

MACSEC – CONFIGURATION
MACSEC CONFIGURATION
MACsec Mode Static SAK –Management step
G e t o r g e n e r a t e R a n d o m Ke y s Switch A Switch B
C r e a t e s e c u r i ty k e y s Static SA Mode
( b o t h s w i t c h e s)
C r e a t e k e y - c h a in
Up to 4 manually configured SA
A s s o c i a te s e c u r i ty k e y t o k e y - c h a i n keys are used to secure traffic
on the point-to-point link
( b o t h s w i t c h e s) between two nodes
C o n f ig u r e s c i - tx / sc i - r x f o r a p o r t w i t h
k e y - c h a in E n a b l i n g o p t i o n “ e n c r y pt io n ” * MACsec - Static mode is not supported on OS6860N.
if any and enable MACSEC for the port
MACSEC CONFIGURATION Switch A Switch B
• MACsec Mode Dynamic (Using PSK)

• Secure-Channel (SCI-TX/SCI-RX) and
Secure-Association-Key (SAK) are exchanged
between
MACSec connected links dynamically using MKA
(MacSec Key Agreement Protocol)
• The MKA (IEEE 802.1X-2010) provides the required
session keys and manages the required encryption
keys
used by the underlying MACsec protocol
• The MKA protocol selects one of the nodes as
the key server, which creates a dynamic SAK and • Two Keys are used to secure the point-to-point
shares it with the node at the other end over Ethernet link
the secure channel • A connectivity association key (CAK) that secures
• Once the other end also creates this dynamic control plane traffic
SA key, subsequent traffic is secured using • A randomly-generated secure association key (SAK)
the new SA. that secures data plane traffic
Switch A Switch B
• MKA Protocol Key Exchange based on time or
data amount
• MACSec supports protocol key-rotation based on:

• Session time (in min) for SAK regeneration
(5 minutes – 120 minutes)
• Exchange data (received or transmitted)
between the MACSEC endpoints. (5GB –1000GB)
• Both values can be configurable in the same
command, and whichever happens first will trigger
the key exchange.
-> interfaces 1/1/27 macsec key-rotation max-session-time

-> interfaces 1/1/27 macsec key-rotation max-exchange-data
-> show interfaces macsec dynamic key-rotation
• MACsec Mode Dynamic (Using PSK)- Management steps
• A matching pre-shared key is configured on both switches which triggers MKA protocol to negotiate
the cipher suite and generate necessary key (SAK) for authentication and encryption
G e t R a n d o m Ke y s p r e - s h a r e d k e y
C r e a t e s e c u r i ty k e y s
C r e a t e k e y - c h a in
A s s o c i a te s e c u r i ty k e y t o k e y - c h a i n
C o n f ig u r e d y n a m ic m o d e / p o r t w i t h
k e y - c h a in E n a b l i n g o p t i o n “ e n c r y pt io n ”
if any and enable MACSEC for the port
• MACsec Mode Dynamic (Using EAP) – how it works
• IEEE 802.1X authenticates the endpoint and transmits the necessary cryptographic keying material
to both sides
• Endpoint undergoes authentication and the he switch relays the RADIUS server response and sniffs
the Master key to program it on the connected port.
CAK: The CAK is delivered in the RADIUS vendor-

specific attributes (VSAs) MS-MPPE-Send-Key and MS-
MPPE-Recv-Key.
The host must support MACSec and must run a

software that allows to enable MACSec-secured
connection with Switch.
• MACsec Mode Dynamic (Using EAP) - Management steps
Enable MACSEC for the port to use EAP
Enabled UNP on the port
C r e a t e n e c e ss a r y U N P Pr o f i l e
f o r l e a r n i n g s u p p l ic a n t
C o n f ig u r e R a d i u s S e r v e r u s e d
f o r 8 0 2 . 1 x - a u th e n ti c a ti o n
If Successful Radius
Auth returns UNP-
Profile “employee“
which ap the vlan
MONITORING COMMANDS
• Show command
show interfaces capability
show configuration snapshot macsec
show interfaces macsec [<chassis>/<slot>/<port1>[-<port2>]]
show interfaces macsec static [<chassis>/<slot>/<port>[-<port2>]]
show interfaces macsec dynamic [<chassis>/<slot>/<port>[-<port2>]]
show interfaces macsec dynamic details [<chassis>/<slot>/<port>[-<port2>]]
show interfaces macsec statistics [ <chassis>/<slot>/<port>]
MACSEC SECURITY ADMIN USER ACCOUNT
• How It Works
• MACSec feature is now part of the security domain when creating a new user account to configure
the switch
user securityadmin password Switch@123 read-write macsec OR

user securityadmin password Switch@123 read-write domain-security
• This allows the user to issue a MACSec security command compared to basic admin
THANK YOU
OmniSwitch R8
Macsec
How to
✓ This lab is designed to familiarize you with the MACsec feature
Contents
1 Overview ....................................................................................... 3
2 Topology ........................................................................................ 4
3 Prerequisite For switch 8 type 6860N ...................................................... 5
3.1. Initialize both switches ............................................................................ 5
3.2. Check available port for MACsec capability .................................................... 5
3.3. Check available licence MACsec capability on 6860 -A ....................................... 6
3.4. Check available licence MACsec capability on 6860 -B........................................ 6
3.5. Implement a link between switches ............................................................. 7
4 Dynamic SA Mode – Switch-to-Switch links for swith 6860N............................. 8
4.1. Configure keychain 1 with pre-shared Master key ............................................. 8
4.2. Configure keys and keychain and associate them in both switches ......................... 8
4.3. Monitor Macsec implementation ................................................................. 9
5 Prequisites - Configure For 6860 Swith 8 type 6860 or a 6860e ...................... 10
5.1. Initialize both switches ........................................................................... 10
5.2. Check available port for MACsec capability ................................................... 10
5.3. Check available licence MACsec capability .................................................... 11
5.4. Implement a link between switches ............................................................ 11
6 Dynamic SA Mode – Switch-to-Switch links .............................................. 12
6.1. Configure keychain 1 with pre-shared Master key ............................................ 12
6.2. Configure keys and keychain and associate them in both switches ........................ 12
6.3. Monitor Macsec implementation ................................................................ 13
2
Macsec
7 Appendix. .................................................................................... 14
7.1. Static SA Mode – Switch-to-Switch links ...................................................... 14
7.1.1. Configure the keys and keychains ............................................................... 14
7.1.2. Configure keys and keychain and associate them in both switches ........................ 14
7.1.3. Configure sci-tx/sci-rx for a port ............................................................... 15
7.1.4. Monitor Macsec implementation ................................................................ 15
7.1.5. Remove MACsec configuration ................................................................... 16
7.2. MACsec Mode Dynamic (Using EAP) - Management steps .................................. 17
3
Macsec
Implementation
1 Overview
MACSec provides point-to-point security on Ethernet links between directly connected nodes.
- IEEE standard (802.1AE-2006) for encryption over Ethernet. Encrypt and authenticate all traffic in a LAN
with GCM-AES-128.
Using MACSec prevents DoS attacks, intrusion, wire-tapping, masquerading, etc. MACSec can be used to secure
most of the traffic on Ethernet links – LLDP frames, LACP frames, DHCP/ARP packets, etc
MACSec-enabled links are secured by matching security keys. Data integrity checks are done. Optionally, traffic
can also be encrypted, if enabled by user configuration
Three modes are In AOS OmniSwitch :
- Static SA Mode – Switch-to-Switch links
- Dynamic SA Mode – Switch-to-Switch links
- Dynamic SA Mode – Host-to-Switch links
We are going to cover the second mode in this lab.
- Only dynamic mode is available on 6860N.
- Host-to-Switch links is not covered as Native Window supplicant doesn’t seem to support MACSec.
- Nevertheless two examples of configuration step are given at the end of the lab in appendix.
4
Macsec
2 Topology
Depending on the POD LAN you use, we have two types of switches.On most PODs, we have a 6860N for
switch 8.
On PODs also used for stellar courses, we have a 6860 model instead of a 6860N.
We can't use port 25 on the 6860N as we can on the 6860 for MACsec. In 6860N model we need to use port 27.
We, therefore, ask you to check the type of 6860 switch you have available before configuring the
appropriate ports.
Example with 6860N
sw8 (6860-B) -> sh chassis
Local Chassis ID 1 (Master)
Model Name: OS6860N-P24Z,
Module Type: 0x60e220b,
Description: 12G 12 MG POE 4 25G,
Part Number: 904300-90,
Hardware Revision: 02,
Serial Number: JSZ223501680,
Manufacture Date: Aug 30 2022,
Admin Status: POWER ON,
Operational Status: UP,
Number Of Resets: 77,
MAC Address: 94:24:e1:e8:b4:13
IF it is 6860N, port will be 1/1/27, do the part 3 and Part 4
IF it is not 6860N, port will be 1/1/25 – example 6860 or 6860e

Do the part 5 and Part 6
Notes
We are going to Create a "User-defined directories" call “labmacsec” and boot both switches on it for this lab.
At the end of the lab, we are going to restart to working directory to retrieve initial configuration.
5
Macsec
3 Prerequisite For switch 8 type 6860N
3.1. Initialize both switches
- Create a User-defined directories “labmacsec” and boot the switches from the new user-defined
directory (labmacsec):
- Type the following to create a user defined directory, copy the contents of the labinit directory to it and
once the switch boots, verify that it booted from the “labmacsec” directory:
sw7 (6860-A) ->

mkdir labmacsec
sw7 (6860-A) ->
cp labinit/*.* labmacsec
sw7 (6860-A) ->
ls labmacsec
sw7 (6860-A) ->
reload from labmacsec no rollback-timeout
sw8 (6860-B)
-> mkdir labmacsec
sw8 (6860-B)
-> cp labinit/*.* labmacsec
sw8 (6860-B)
-> ls labmacsec
sw8 (6860-B)
->reload from labmacsec no rollback-timeout
sw8 (6860-B) ->show running-directory
3.2. Check available port for MACsec capability
sw7 (6860-A) -> show interfaces 1/1/27 capability

Macsec Macsec
Ch/Slot/Port AutoNeg Pause Crossover Speed Duplex Supported 256-bit
--------------+--------+----------------+-----------+------------------+----------+-----------+-----------
---
1/1/27 CAP EN Tx/Rx/Tx&Rx/DIS - 1G/10G Full YES NO
1/1/27 DEF DIS DIS - 10G Full - -
sw8 (6860-B) -> show interfaces 1/1/27 capability

Macsec Macsec
Ch/Slot/Port AutoNeg Pause Crossover Speed Duplex Supported 256-bit
--------------+--------+----------------+-----------+------------------+----------+-----------+-----------
---
1/1/27 CAP EN Tx/Rx/Tx&Rx/DIS - 1G/10G/25G Full YES YES
1/1/27 DEF DIS DIS - 10G Full - -
6
Macsec
3.3. Check available licence MACsec capability on 6860 -A
Sw7 (6860-A) -> show license-info

Time (Days) Upgrade Expiration
VC device License Type Remaining Status Date
----+------+---------------+---------------+---------------+--------------+----------------
1 0 Advanced PERM NA NA NA
- Create the license.dat file and copy the License to it, then apply.
Sw7 (6860-A) -> cat > licence.dat

1ES2-4{v!-[AQy-hRrK-B$qF-5EGE-}oHt-NJ5K (Then enter and CTRL + D)
Sw7 (6860-A) -> license apply file licence.dat order-id "05200622"
sw8 (6860-A) -> show license-info

----+------+---------------+---------------+---------------+--------------+----------------
1 0 MACSEC PERM NA NA NA
3.4. Check available licence MACsec capability on 6860 -B
sw8 (6860-B) -> show license-info

----+------+---------------+---------------+---------------+--------------+----------------
- Create the license.dat file and copy the License to it, then apply.
sw8 (6860-B) -> cat > licence.dat

sw8 (6860-B) ->
sw8 (6860-B) -> license apply file licence.dat order-id "05200622"

----+------+---------------+---------------+---------------+--------------+----------------
7
Macsec
3.5. Implement a link between switches
- Log in to switches and activate the interface

- To begin, let’s create a new VLAN and assign an IP address to that VLAN as done previously
sw7 (6860-A) -> vlan 90

sw8 (6860-B) -> vlan 90

- Assign port to VLAN 90


sw8 (6860-B) -> show vlan 90 member
- Test connectivity between the two switches
sw8 (6860-B) -> ping 192.168.90.7

8
Macsec
4 Dynamic SA Mode – Switch-to-Switch links for swith 6860N
4.1. Configure keychain 1 with pre-shared Master key

- Pre-shared Master key have been already generated by the administrator. the step to generate them on a
switch can be skipped.
- Pre-shared Master key provided by the administrator are:
hex-key 0x000102030405060708090a0b0c0d0e0f
keyed-name 0x000102030405060708090a0b0c0d0eff
4.2. Configure keys and keychain and associate them in both switches
- Configure keys
sw7 (6860-A) -> security key 1 algorithm aes-cmac-128 hex-key 0x000102030405060708090a0b0c0d0e0f keyed-
name 0x000102030405060708090a0b0c0d0eff
sw8 (6860-B) -> security key 1 algorithm aes-cmac-128 hex-key 0x000102030405060708090a0b0c0d0e0f keyed-
name 0x000102030405060708090a0b0c0d0eff
- Create key-chain
sw7 (6860-A) -> security key-chain 1
sw8 (6860-B) -> security key-chain 1
- Associate security key to key-chain

Sw7 (6860-A) -> security key-chain 1 key 1
sw8 (6860-B) -> security key-chain 1 key 1
- Configure dynamic mode on port with the above key-chain with Session time (10 min) and Exchange data
(received or transmitted) between the MACSEC endpoints to 20G.
sw7 (6860-A) -> interfaces port 1/1/27 macsec mode dynamic key-chain 1 encryption
sw7 (6860-A) -> interfaces 1/1/27 macsec key-rotation max-session-time 10
sw7 (6860-A) -> interfaces 1/1/27 macsec key-rotation max-exchange-data 20
sw7 (6860-A) -> interfaces port 1/1/27 macsec admin-state enable
sw8 (6860-B) -> interfaces port 1/1/27 macsec mode dynamic key-chain 1 encryption
sw8 (6860-B) -> interfaces 1/1/27 macsec key-rotation max-session-time 10
sw8 (6860-B) -> interfaces 1/1/27 macsec key-rotation max-exchange-data 20
sw8 (6860-B) -> interfaces port 1/1/27 macsec admin-state enable
-
sw8 (6860-B) -> show interfaces macsec dynamic key-rotation
Chas/Slot/Port Time to Rekey (Sec) Data to Rekey (Byte)

----------------+---------------------+------------------------
1/1/27 556 19998014
9
Macsec
4.3. Monitor Macsec implementation
- Show configuration snapshot macsec in both switches

sw7 (6860-A) -> show configuration snapshot macsec
! MAC Security:
interfaces port 1/1/27 macsec mode dynamic key-chain 1 encryption key-rotation max-session-time 10 key-
rotation max-exchange-data 20M
interfaces port 1/1/27 macsec admin-state enable
sw8 (6860-B) -> show configuration snapshot macsec

! MAC Security:
interfaces port 1/1/27 macsec mode dynamic key-chain 1 encryption key-rotation max-session-time 10 key-
rotation max-exchange-data 20M

sw8 (6860-B) -> ping 192.168.90.7

---
sw7 (6860-A) -> ping 192.168.90.8
- Check MACsec interfaces

sw7 (6860-A) -> show interfaces macsec
Chas/Slot/Port Admin-State Mode Encryption Exchange Data Session Time (Min)
---------------+-------------+----------+--------------+---------------------+---------------------
1/1/27 Enabled Dynamic Enabled 20M 10
sw8 (6860-B) -> show interfaces macsec

Chas/Slot/Port Admin-State Mode Encryption Exchange Data Session Time (Min)
---------------+-------------+----------+--------------+---------------------+---------------------
1/1/27 Enabled Dynamic Enabled 20M 10
sw7 (6860-A) -> show interfaces macsec dynamic

Server Transmit Key Operation
Chas/Slot/Port Admin-State Mode Keychain Encryption Priority Interval(Sec) Server Status
----------------+-------------+----------+----------+------------+----------+---------------+--------+--------------
1/1/27 Enabled keychain 1 Enabled 10 2 NO UP
sw8 (6860-B) -> show interfaces macsec dynamic

Server Transmit Key
Server Transmit Key Operation
Chas/Slot/Port Admin-State Mode Keychain Encryption Priority Interval(Sec) Server Status
----------------+-------------+----------+----------+------------+----------+---------------+--------+--------------
1/1/27 Enabled keychain 1 Enabled 10 2 YES UP
10
Macsec
- At the end of this lab, restore both switches to initial configuration by restarting them from "working
directory".
sw7 (6860-A) -> rm -r labmacsec

sw8 (6860-B) -> rm -r labmacsec

5 Prequisites - Configure For 6860 Swith 8 type 6860 or a 6860e
5.1. Initialize both switches
- Create a User-defined directories “labmacsec” and boot the switches from the new user-defined
directory (labmacsec):
- Type the following to create a user defined directory, copy the contents of the WORKING directory to it
and once the switch boots, verify that it booted from the “labmacsec” directory:
sw7 (6860-A) ->

mkdir labmacsec
sw7 (6860-A) ->
cp labinit/*.* labmacsec
sw7 (6860-A) ->
ls labmacsec
sw7 (6860-A) ->
reload from labmacsec no rollback-timeout
sw8 (6860-B)
->mkdir labmacsec
sw8 (6860-B)
->cp labinit/*.* labmacsec
sw8 (6860-B)
->ls labmacsec
sw8 (6860-B)
->reload from labmacsec no rollback-timeout
5.2. Check available port for MACsec capability

sw7 (6860-A) -> show interfaces 1/1/25 capability
Macsec
Ch/Slot/Port AutoNeg Pause Crossover Speed Duplex Supported
--------------+--------+----------------+-----------+------------------+----------+-----------
1/1/25 CAP DIS Tx/Rx/Tx&Rx/DIS - 10G Full YES
1/1/25 DEF DIS DIS - 10G Full -
sw8 (6860-B) -> show interfaces 1/1/25 capability

Macsec
Ch/Slot/Port AutoNeg Pause Crossover Speed Duplex Supported
--------------+--------+----------------+-----------+------------------+----------+-----------
1/1/25 CAP DIS Tx/Rx/Tx&Rx/DIS - 10G Full YES
1/1/25 DEF DIS DIS - 10G Full -
11
Macsec
5.3. Check available licence MACsec capability
Sw7 (6860-A) -> show license-info

----+------+---------------+---------------+---------------+--------------+----------------
Sw7 (6860-A) -> cat > licence.dat

Sw7 (6860-A) -> license apply file licence.dat order-id "05200622"
sw8 (6860-A) -> show license-info

----+------+---------------+---------------+---------------+--------------+----------------

----+------+---------------+---------------+---------------+--------------+----------------
sw8 (6860-B) -> cat > licence.dat

sw8 (6860-B) ->
sw8 (6860-B) -> license apply file licence.dat order-id "05200622"

----+------+---------------+---------------+---------------+--------------+----------------
5.4. Implement a link between switches
- Log in to switches and activate the interface

- To begin, let’s create a new VLAN and assign an IP address to that VLAN as done previously
sw7 (6860-A) -> vlan 90

sw8 (6860-B) -> vlan 90

- Assign port to VLAN 90


sw8 (6860-B) -> show vlan 90 member
12
Macsec
sw8 (6860-B) -> ping 192.168.90.7

6 Dynamic SA Mode – Switch-to-Switch links
6.1. Configure keychain 1 with pre-shared Master key

- Pre-shared Master key have been already generated by the administrator. the step to generate them on a
switch can be skipped.
- Pre-shared Master key provided by the administrator are:
hex-key 0x000102030405060708090a0b0c0d0e0f
keyed-name 0x000102030405060708090a0b0c0d0eff
6.2. Configure keys and keychain and associate them in both switches
- Configure keys
sw7 (6860-A) ->
security key 1 algorithm aes-cmac-128 hex-key 0x000102030405060708090a0b0c0d0e0f keyed-name
0x000102030405060708090a0b0c0d0eff
sw8 (6860-B) -> security key 1 algorithm aes-cmac-128 hex-key 0x000102030405060708090a0b0c0d0e0f keyed-
name 0x000102030405060708090a0b0c0d0eff
- Create key-chain

sw8 (6860-A) -> security key-chain 1 key 1
sw8 (6860-B) -> security key-chain 1 key 1
- Configure dynamic mode on port with the above key-chain

sw7 (6860-A) -> interfaces port 1/1/25 macsec mode dynamic key-chain 1
sw7 (6860-A) -> interfaces port 1/1/25 macsec admin-state enable
sw8 (6860-B) -> interfaces port 1/1/25 macsec mode dynamic key-chain 1
sw8 (6860-B) -> interfaces port 1/1/25 macsec admin-state enable

13
Macsec
6.3. Monitor Macsec implementation

! MAC Security:
interfaces port 1/1/25 macsec mode dynamic key-chain 1

! MAC Security:
interfaces port 1/1/25 macsec mode dynamic key-chain 1

sw8 (6860-B) -> ping 192.168.90.7

---
sw7 (6860-A) -> ping 192.168.90.8

Chas/Slot/Port Admin-State Mode Encryption
---------------+-------------+------------+-----------------
1/1/25 Enabled Dynamic Disabled

---------------+-------------+------------+-----------------
1/1/25 Enabled Dynamic Disabled
sw7 (6860-A) -> show interfaces macsec dynamic

Server Transmit Key
Operation
Chas/Slot/Port Admin-State Mode Keychain Encryption Priority Interval(Sec) Server
Status
----------------+-------------+----------+----------+------------+----------+---------------+--------+----
----------
1/1/25 Enabled keychain 1 Disabled 10 2 NO UP
sw8 (6860-B) -> show interfaces macsec dynamic

Server Transmit Key
Operation
Chas/Slot/Port Admin-State Mode Keychain Encryption Priority Interval(Sec) Server
Status
----------------+-------------+----------+----------+------------+----------+---------------+--------+----
1/1/25 Enabled keychain 1 Disabled 10 2 YES UP
14
Macsec
- At the end of this lab, restore both switches to initial configuration by restarting them from "working
directory".
sw7 (6860-A) -> rm -r labmacsec

rm: remove 'labmacsec/pkg/.pkgDB_Commit'? y
rm: remove 'labmacsec/pkg/.appDB_Commit'? y
rm: remove 'labmacsec/boot.md5'? y
Sw8 (6860-B) -> rm -r labmacsec

rm: remove 'labmacsec/pkg/.pkgDB_Commit'? y
rm: remove 'labmacsec/pkg/.appDB_Commit'? y
rm: remove 'labmacsec/boot.md5'? y
Sw8 (6860-B) -> reload from working no rollback-timeout
7 Appendix.
7.1. Static SA Mode – Switch-to-Switch links

- This part is not working on remote lab. This is an example with 6860E connect to 6860
7.1.1. Configure the keys and keychains

- Random keys have been already generated by the administrator. The step to generate them on a switch
can be skipped.
- Random keys provided by the administrator are:
Key 1 : f514ab78a8f923225626dd6064d6d67a
Key 2 : 1937463f587115258ea8f0ed62f308e7
Key 3 : 0ad08a30ebdb532d4cb151dc1c0dafd9
Key 4 : b10f0a502c19f0c84acf798322f7efb8
Tips
If you do not have key, use the following command on a switch to generate it.
sw7 (6860-A) -> security key-chain gen-random-key
7.1.2. Configure keys and keychain and associate them in both switches
- Create security keys
o In this example, we used key generated above. If you generate new keys, do not forget to
replace it below in command line
sw7 (6860-A) -> security key 1 algorithm aes-gcm-128 encrypt-key ef68850d93b82fb494843f66f5864cc5
sw7 (6860-A) -> security key 2 algorithm aes-gcm-128 encrypt-key 0641ef514da5c09feee8bf9a96fb22e1
sw7 (6860-A) -> security key 3 algorithm aes-gcm-128 encrypt-key 58b554b11033d1d865ef35ba707e4767
sw7 (6860-A) -> security key 4 algorithm aes-gcm-128 encrypt-key f167cc24fc78950f265a74edcf5cb344
sw8 (6860-B) -> security key 1 algorithm aes-gcm-128 encrypt-key ef68850d93b82fb494843f66f5864cc5

15
Macsec
sw8 (6860-B) -> security key 2 algorithm aes-gcm-128 encrypt-key 0641ef514da5c09feee8bf9a96fb22e1
sw8 (6860-B) -> security key 3 algorithm aes-gcm-128 encrypt-key 58b554b11033d1d865ef35ba707e4767
sw8 (6860-B) -> security key 4 algorithm aes-gcm-128 encrypt-key f167cc24fc78950f265a74edcf5cb344
Tips
Up to 4 manually configured SA keys are used to secure traffic on the point-to-point link between two nodes)
- Create key-chain


sw7 (6860-A) -> security key-chain 1 key 1-2
sw7 (6860-A) -> security key-chain 2 key 3-4
sw8 (6860-B) -> security key-chain 1 key 1-2

sw8 (6860-B) -> security key-chain 2 key 3-4
7.1.3. Configure sci-tx/sci-rx for a port
- Configure sci-tx/sci-rx for a port with the above key-chain. Enabling option “encryption” if any and
enable MACSEC for the port
sw7 (6860-A)-> interface 1/1/25 macsec admin-state enable sci-tx key-chain 1 encryption sci-rx key-chain 2 encryption
sw8 (6860-B)-> interface 1/1/25 macsec admin-state enable sci-tx key-chain 2 encryption sci-rx key-chain 1 encryption
7.1.4. Monitor Macsec implementation

! MAC Security:
interfaces port 1/1/25 macsec mode static
interfaces port 1/1/25 macsec sci-tx key-chain 1 encryption
interfaces port 1/1/25 macsec sci-rx key-chain 2 encryption

! MAC Security:
interfaces port 1/1/25 macsec mode static
interfaces port 1/1/25 macsec sci-tx key-chain 2 encryption
interfaces port 1/1/25 macsec sci-rx key-chain 1 encryption

sw8 (6860-B) -> ping 192.168.90.7
16
Macsec
sw7 (6860-A) -> ping 192.168.90.8


---------------+-------------+------------+-----------------
1/1/25 Enabled Static Enabled

---------------+-------------+------------+-----------------
1/1/25 Enabled Static Enabled
sw7 (6860-A) -> show interfaces macsec static

Chas/Slot/Port Admin-State SCI Type Keychain Encryption
---------------+-------------+--------------------+------+-----------+--------------
1/1/25 Enabled - TX 1 Enabled
1/1/25 Enabled - RX 2 Enabled
sw8 (6860-B) -> show interfaces macsec static

Chas/Slot/Port Admin-State SCI Type Keychain Encryption
---------------+-------------+--------------------+------+-----------+--------------
1/1/25 Enabled - TX 2 Enabled
1/1/25 Enabled - RX 1 Enable
7.1.5. Remove MACsec configuration

sw7 (6860-A) -> interface port 1/1/25 macsec admin-state disable
sw7 (6860-A) -> no interfaces port 1/1/25 macsec
sw7 (6860-A) -> no security key-chain 1
sw7 (6860-A) -> no security key-chain 2
sw8 (6860-B) -> interface port 1/1/25 macsec admin-state disable

sw8 (6860-B) -> no interfaces port 1/1/25 macsec
sw8 (6860-B) -> no security key-chain 1
sw8 (6860-B) -> no security key-chain 2
Tips
//Example for “no” format:
// Un-configure macsec sci-tx params
-> no interface 1/1/25 macsec sci-tx key-chain
-> no interface 1/1/25 macsec sci-tx encryption
-> no interface 1/1/25 macsec sci-tx
// Un-configure macsec sci-rx params

-> no interface 1/1/25 macsec sci-rx 0x2 key-chain
-> no interface 1/1/25 macsec sci-tx 0x2 encryption
-> no interface 1/1/25 sci-tx 0x02
17
Macsec
7.2. MACsec Mode Dynamic (Using EAP) - Management steps
- This part is not working on remote lab as MACsec are not available on Window XP/7 client host. This is a n
example of management step.
- Enable MACSEC for the port to use EAP

interfaces port 1/1/1 macsec mode dynamic radius
- Enabled UNP on the port

unp port 1/1/1 port-type bridge
unp port 1/1/1 802.1x-authentication
- Create necessary UNP Profile for learning supplicant. If Successful Radius Auth returns UNP-Profile
“employee" which ap the vlan 30
vlan 30
unp profile “employee“
unp profile “employee” map vlan 30
- Configure Radius Server used for 802.1x-authentication

aaa radius-server radius host 192.168.100.102 key Alcatel
aaa device-authentication 802.1x radius
OMNISWITCH R8
E T H E R N E T R I N G P R O TO C O L ( E R P )
OBJECTIVES
• List & Identify the ERP concepts

• Summarize the ERP principle
• Identify a failure in the ERP Ring
• Explain the recovery process
ETHERNET RING PROTOCOL (ERP) - OVERVIEW
• Protection switching mechanism
• Maintains a loop-free topology in a ring Ring 2

Ring 1
Ring 1
• Fast recovery times (~50 ms)
• Dedicated Protocol
• APS (Automatic Protection Switching)
• AOS OmniSwitch supports ERPv2

Main
Ring
• Works on single and multiple independent and laddered rings
Sub - Ring
CONCEPTS
• Ring Protection Link (RPL) • Service VLAN
• Link between 2 ring switches that is blocked to • Ring-wide VLAN used for transmission of R-APS
prevent a loop in the ring messages
• RPL Owner • Protected VLAN

• Switch hosting the RPL Port • VLAN(s) that is/are added to the ERP ring
• Blocks traffic on the RPL Port during normal ring • ERP determines the forwarding state of protected
operations VLAN(s)
• R-APS (Ring-Automatic Protection Switching)

Messages
• Signal Fail (SF)
• Declared when a failed link or node is detected
• No Request (NR)
• Declared when there are no outstanding conditions
(ex. SF) on the node
CONCEPTS
• 2 ring ports are identified in each switch
• 1 link in the ring is identified as the Ring Protection Link (RPL)
• One of the switches terminating the RPL is identified as RPL Owner
RPL Owner
RPL Protection Link
RPL port
Normal ring port

RPL port on RPL Owner
STEADY STATE (NO FAILURE)
R-APS MESSAGE
NR (No Request)
RB (RPL blocked)
RPL Owner
RPL Protection Link
Blocked RPL port
RING FAILURE
• Failure! (Ring Mode: Protection) 1
• Adjacent ports are blocked 2
• Signal Failure (SF) R-APS message is sent 3
• RPL Owner unblocks RPL port 4
• Ring is protection mode
4
RPL Owner
RPL Protection Link
Unblocked RPL port
2 2
SF (Signal Fail) SF (Signal Fail)
3 3
R-APS MESSAGE R-APS MESSAGE
RECOVERY
• Recovered Link 1
• Adjacent nodes remove SF (Signal Failure) and send NR (No Request) 2
• RPL Owner starts a Wait To Restore (WTR) timer (default: 5 minutes) 3
• When WTR timer expires, RPL port is blocked 4
• RPL Owner sends NR/RB (No Request/RPL Blocked) 5
• Other nodes unblock their ring ports (Ring Mode: Idle) 6 NR/RB (No Request)
5
RPL Owner
6 6
NR (No Request) NR (No Request)
2 2
LADDERED RINGS (ERPV2)
A B
• Laddered rings are composed of:
• A Main ring Main
• One or more Subtending ring(s) Ring
• The Main ring is a fully closed ring (A-B-D-C-A) C D
• The Subtended ring does not include any shared

links with the main ring Subtended
Ring
• The Main ring acts as a virtual channel to close
the Subtended ring E F
• R-APS messages are sent over the virtual channel

using the S-tag (Service VLAN) of the subtended ring
A B C D
Main Subtended
Ring Ring
C D E F
ETHERNET RING PROTOCOL (ERP)
Specifications
ERP CONFIGURATION
ERP CONFIGURATION
Step by Step
Create ERP Ring, Service VLAN & MEG Level
Configure the RPL Port
Add Protected VLAN(s)
Enable the ERP Ring

ERP CONFIGURATION
Step by Step
Create ERP Ring, Service VLAN & MEG Level

Create an ERP Ring
Declare a Service VLAN
For transmission of R-APS messages
Define a MEG Level (Management Entity Group)

Value from 0 to 7
Must be identical on all the switches belonging to the ERP Ring
Ring 1 1/1
1/2
SVLAN 1001 1 2
MEG Level 1 1/3 1/4
ERP Ring
1/1 1/2
3 4
1/4 1/3
ERP CONFIGURATION
Step by Step
Configure the RPL Port

The RPL port is unique in an ERP Ring
Declared on one switch (= RPL Owner)
Ring 1 RPL Owner

1/2 1/1
SVLAN 1001 1 2
MEG Level 1 1/3 1/4
ERP Ring
1/1 1/2
3 4
1/4 1/3
RPL Port
ERP CONFIGURATION
Step by Step
Add Protected VLAN(s)

VLAN that is added to the ERP ring
RPL Owner
ERP determines the forwarding Ring 1
1/2 1/1
SVLAN 1001 1 2
state of protected VLANs MEG Level 1 1/3 1/4
Prot. VLAN(s) ERP Ring

• 2 1/1 1/2
• 3 4
3
1/4 1/3
RPL Port
Enable the ERP Ring

Administratively activate the ERP Ring
(admin-state enable)
THANK YOU
OmniSwitch R8
Ethernet Ring Protection
How to
✓ Create an ERP Ring and check its behavior
Contents
1 Topology ........................................................................................ 2
2 Configure ERPv2 ring ......................................................................... 3
2.1. Initialize switches .................................................................................. 3
2.2. Configure VLANs on the switches ................................................................ 3
2.3. Configure the ERP on all switches................................................................ 4
2.4. Make the physical connections according to the lab diagram ................................ 5
2.5. Check the ERP Ring 1 setup by performing some show commands. ......................... 5
3 Lab Check ...................................................................................... 7
3.1. Connect clients to switches ....................................................................... 7
3.2. Test the feature .................................................................................... 8
4 ERP Sub ring 2 configuration ................................................................ 8
4.1. Connect clients to switches ...................................................................... 10
4.2. Test the feature ................................................................................... 11
5 Access - Core resiliency .................................................................... 11
5.1. VRRP Verification .................................................................................. 12
6 Restore ....................................................................................... 13
6.1. Switch At the end of this lab, restore the four switches
to initial configuration by restarting them from "working directory". ..................... 13
2
1 Topology
Ethernet Ring Protection (ERP) is a protection switching mechanism for Ethernet ring topologies, such as
multi-ring and ladder networks. This implementation of ERP uses the Automatic Protection Switching (APS)
protocol to coordinate the prevention of network loops within a bridged Ethernet ring.
ERP is used to prevent formation of loops which would fatally affect the network operation and service
availability.
Configuring ERP requires several steps. These steps are outlined here and more described in relevant
OmniSwitch AOS Release Network Configuration Guides.
- For this lab, you will learn how to configure the ring network (including a major ring and a sub ring)
parameters through the Command Line Interface (CLI).
3
2 Configure ERPv2 ring
2.1. Initialize switches
- Create a User-defined directories “labERP” and boot the switches from the new user-defined directory
labERP):
once the switch boots, verify that it booted from the “labERP” directory:
sw7 (6860-A) ->

mkdir labERP
sw7 (6860-A) ->
cp labinit/*.* labERP
sw7 (6860-A) ->
ls labERP
sw7 (6860-A) ->
reload from labERP no rollback-timeout
sw8 (6860-B)
-> mkdir labERP
sw8 (6860-B)
-> cp labinit/*.* labERP
sw8 (6860-B)
-> ls labERP
sw8 (6860-B)
->reload from labERP no rollback-timeout
sw5 (6360-A) ->

mkdir labERP
sw5 (6360-A) ->
sw5 (6360-A) ->
ls labERP
sw5 (6360-A) ->
sw6 (6360-B) ->

mkdir labERP
sw6 (6360-B) ->
sw6 (6360-B) ->
ls labERP
sw6 (6360-B) ->
sw6 (6360-B) -> show running-directory
sw3 (6560-A) ->

mkdir labERP
sw3 (6560-A) ->
sw3 (6560-A) ->
ls labERP
sw3 (6560-A) ->
2.2. Configure VLANs on the switches

- On each node belonging to ERP ring, configure VLAN 30 and VLAN 20:
sw7 (6860-A) -> vlan 1001 name “Ring1”

sw7 (6860-A) -> vlan 20 name “subnet20”
sw8 (6860-B) -> vlan 1001 name "Ring1"

sw8 (6860-B) -> vlan 20 name "subnet20"
sw8 (6860-B) -> vlan 30 name "subnet30"
sw5 (6360-A) -> vlan 1001 name “Ring1”

sw6 (6360-B) -> vlan 1001 name “Ring1”

4
sw6 (6360-B) -> vlan 20 name “subnet20”

sw6 (6360-B) -> vlan 30 name “subnet30”
Notes: VLAN 1001 is the Service VLAN for ERP Ring 1, VLAN 20 and 30 are Protected VLAN.
Service VLAN is used for the transmission and reception of R-APS Channel (tagged R-APS
messages) and the ETH CCM (tagged CCM) for a given ring.
- On 6860-A, tag Vlan 1001, VLAN 20 and 30 to the assigned ring ports 1/1/3 and 1/1/27:
- On 6860-B, tag Vlan 1001, VLAN 20 and 30 to the assigned ring ports 1/1/3 and 1/1/27:
- On 6360-A, tag Vlan 1001, tag VLAN 20 and 30 to the assigned ring ports 1/1/3 and 1/1/27:
- On 6360-B , tag Vlan 1001, VLAN 20 and 30 to the assigned ring ports 1/1/3 and 1/1/27:

2.3. Configure the ERP on all switches.

The RPL owner will be switch 6 in this ring.
Notes
One of the nodes in the ERP ring must be configured as RPL, and this node is responsible for blocking and
unblocking the ring on link failure. The RPL port can be a physical or logical port, but only one of the ring ports
can be configured as RPL port. The RPL node can be configured only on a preexisting disabled ring.
The non-existence of a RPL node or the existence of multiple RPL nodes is considered as incorrect
configuration.
When a ring port is configured as RPL port, the node to which the port belongs becomes the RPL owner.
- On 6860-A, configure the ERP as follows:

sw7 (6860-A) -> erp-ring 1 port1 1/1/3 port2 1/1/27 service-vlan 1001 level 2
sw7 (6860-A) -> erp-ring 1 enable
- On 6360-A, configure the ERP as follows:

5
- On 6360-B, configure the ERP as follows:

sw6 (6360-B) -> erp-ring 1 port1 1/1/27 port2 1/1/3 service-vlan 1001 level 2
sw6 (6360-B) -> erp-ring 1 rpl-node port 1/1/27
sw6 (6360-B) -> erp-ring 1 wait-to-restore-timer 1
sw6 (6360-B) -> erp-ring 1 enable
- On 6860-B, configure the ERP as follows:

sw8 (6860-B) -> erp-ring 1 port1 1/1/3 port2 1/1/27 service-vlan 1001 level 2
Notes
- For ERP Ring 1, the RPL owner is switch 6360-B. Each ring must have its own RPL
- Mandatory parameters for ring creation are a unique ring ID, two physical or logical ports, Service
VLAN and MEG level.
- The maximum number of rings per node that can be created depends on switch model (refer to the
latest AOS Network Configuration guide)
- A maximum number of 16 nodes per ring is recommended.
- Physical switch ports and logical link aggregate ports can be configured as ERP ring ports.
2.4. Make the physical connections according to the lab diagram
- On 6860-A, activate interfaces:

- On 6860-B, activate interfaces:

- On 6360-A, activate interfaces:

- On 6360-B, activate interfaces:

2.5. Check the ERP Ring 1 setup by performing some show commands.
- On all nodes, check the ERP setup:
-> show erp

-> show erp {<chassis/slot/portSubport> <chassis/slot/port> > |linkagg <aggId>}
-> show erp statistics
-> show erp statistics ring <ringId>
-> show erp statistics ring <ringId> {<chassis/slot/portSubport> <chassis/slot/port> > |linkagg <aggId>}
-> clear erp statistics
-> clear erp statistics ring <ringId>
-> clear erp statistics ring <ringId> {<chassis/slot/portSubport> <chassis/slot/port> > |linkagg <ag
6
- Example:
sw7 (6860-A) -> show erp

Legends: WTR - Wait To Restore
MEG - Maintenance Entity Group
Ring Ring Ring Ring

Serv WTR Guard MEG Ring Ring Ring Remote
ID Port1 Port2 Status
VLAN Timer Timer Level State Node Profile System ID
(min) (csec)
----------+--------+--------+---------+-----+-----+------+-----+-----------+--------+--------+------------
---
1 1/1/3 1/1/27 enabled 1001 5 50 2 idle non-rpl N/A
N/A
Total number of rings configured = 1
sw6 (6360-B) -> sh erp

Ring Ring Ring Ring

Serv WTR Guard MEG Ring Ring Ring Remote
ID Port1 Port2 Status
VLAN Timer Timer Level State Node Profile System ID
(min) (csec)
----------+--------+--------+---------+-----+-----+------+-----+-----------+--------+--------+------------
---
1 1/1/27 1/1/3 enabled 1001 1 50 2 idle rpl N/A
N/A
Notes
ERP Ring States:
- idle: the RPL port is blocking, indicating that the topology is stable. the node is performing normally.
- Protection: on link failure, NI down, or node down of erp nodes. The RPL node is now forwarding and
the ring is said to be protected.
- Pending: The node is recovering from failure. When a node is in pending state, the WTR timer will be
running. All nodes are in pending state till WTR timer expiry.
7
3 Lab Check
3.1. Connect clients to switches
- Client 7:
Assign IP address 192.168.20.107/24
- On 6860-A:

- Client 6:
- Ping each other to test connection between them.
- On 6360-B:

- Client 8:
- On 6860-B:

- Client 9:
- On 6360-A:

- Ping each other to test connection between them.

8
3.2. Test the feature
- Launch a continuous ping running between client 7 and 6.
- Then disconnect (disable) a link in ERP Ring 1.
Sw7 (6860-A) -> interfaces 1/1/3 admin-state disable
- Check the status of the ERP ring.

What happens?
.................................................................................................................
.................................................................................................................
.................................................................................................................
- Re-connect (enable) the link in ERP Ring 1. Check status of ERP ring. What happens?
Sw7 (6860-A) -> interfaces 1/1/3 admin-state enable
.................................................................................................................
.................................................................................................................
4 ERP Sub ring 2 configuration

9
- Create the ERP-Service VLAN for Ring 2
sw3 (6560-A) -> vlan 1002

sw3 (6560-A) -> vlan 1002 members port 1/1/5-6 tagged
sw3 (6560-A) -> interface 1/1/5-6 admin-state enable
sw5 (6360-A) -> vlan 1002

sw6 (6360-B) -> vlan 1002

sw5 (6360-A) -> erp-ring 2 sub-ring-port 1/1/5 service-vlan 1002 level 2

sw5 (6360-A) -> erp-ring 2 rpl-node port 1/1/5
sw5 (6360-A) -> erp-ring 2 wait-to-restore-timer 1
sw6 (6360-B) -> erp-ring 2 sub-ring-port 1/1/6 service-vlan 1002 level 2

sw5 (6360-A) -> vlan 40

sw6 (6360-B) -> vlan 40

sw3 (6560-A) -> vlan 40

Sw7 (6860-A) -> vlan 40

Sw7 (6860-A) -> vlan 40 members port 1/1/3 tagged
Sw7 (6860-A) -> vlan 40 members port 1/1/27 tagged
Sw7 (6860-A) -> write memory
sw8 (6860-B) -> vlan 40

10
sw3 (6560-A) -> sh erp

Ring Ring Ring Ring Serv WTR Guard MEG Ring Ring Ring Remote
ID Port1 Port2 Status VLAN Timer Timer Level State Node Profile System ID
(min) (csec)
----------+--------+--------+---------+-----+-----+------+-----+-----------+--------+--------+------------
---
N/A
sw5 (6360-A) -> sh erp

(min) (csec)
----------+--------+--------+---------+-----+-----+------+-----+-----------+--------+--------+------------
---
N/A
2 1/1/5 - enabled 1002 1 50 2 idle rpl N/A
N/A
sw6 (6360-B) -> sh erp

(min) (csec)
----------+--------+--------+---------+-----+-----+------+-----+-----------+--------+--------+------------
---
1 1/1/27 1/1/3 enabled 1001 1 50 2 idle rpl N/A
N/A
2 1/1/6 - enabled 1002 5 50 2 idle non-rpl N/A
N/A
4.1. Connect clients to switches
- Client 3:
- On 6560-A:

11
- Client 5:
- On 6360-A:

- Ping each other to test connection between them
4.2. Test the feature
- Launch a continuous ping running between client 3 and 5.
- Then disconnect (disable) a link in ERP Ring 2.
Sw3 (6560-A) -> interfaces 1/1/6 admin-state disable
- Check the status of the ERP ring.

What happens?
.................................................................................................................
.................................................................................................................
.................................................................................................................
- Re-connect (enable) the link in ERP Ring 1. Check status of ERP ring. What happens?
Sw3 (6360-A) -> interfaces 1/1/6 admin-state enable
.................................................................................................................
.................................................................................................................
5 Access - Core resiliency

In order to provide resilient dual path to core, we will provide VRRP redundancy by eliminating the single
point of failure inherent to the two routers which will be connected to the OSPF network.

12

sw7 (6860-A) -> ip vrrp 1 interface int_20 priority 150






5.1. VRRP Verification

- Let’s check VRRP operation and switchover in case the Master switch fails.
- The DHCP server has not been configured with these gateway addresses, so to perform this test we need
to switch back to static addresses by setting the gateway for clients
- From any client 3, begin a continuous ping on to client 5 or client 10 which do not belong to same vlan.
- Then, reload the master switch (be care of the switch/vlan to determine the master to be rebooted).
- Notice the pings are redirected to the backup routing instance and continue to be successful; the
associated arp entry should remain the same.
13
6 Restore
6.1. Switch At the end of this lab, restore the four switches to initial configuration by restarting
them from "working directory".
sw7 (6860-A) -> rm -r labERP

rm: remove 'labERP/pkg/.pkgDB_Commit'? y
rm: remove 'labERP/pkg/.appDB_Commit'? y
rm: remove 'labERP/.boot.pkg.md5'? y
rm: remove 'labERP/boot.md5'? y
sw8 (6860-B) -> rm -r labERP


sw6 (6360-B) -> rm -r labERP


OMNISWITCH R8
P R I VAT E V L A N
OBJECTIVES
• Understand the Private VLAN implementation

on the OmniSwitches
• Learn the Different VLAN Port types
• Understand how the traffic flows between
different VLAN’s
• Configure Private VLAN
PRIVATE VLAN - OVERVIEW
• Physical isolation extension across the network per VLAN basis
• Partitions single broadcast domain into Primary Layer 2

several broadcast sub-domains • Provides scalable VLAN distribution
Secondary Network and IP address management
• Provides network-wide isolation per VLAN Isolation
primary VLAN PVLAN • Common IP address space
• Primary VLAN can have multiple
secondary VLANs Inter−switch • Works over VLANs, services (SPBM) and
Scalability behaviour Ethernet-services (QinQ)
• Isolation by IP Source filtering
This type of data isolation improves security and simplifies system configuration
PRIVATE VLAN - VLAN TYPES
• PVlan divides the broadcast domain into sub-domains
Secondary VLAN
Primary VLAN • VLAN associated with the Primary
VLAN
• VLAN referred as Private VLAN − Same primary vlan IP space
− Same primary vlan SPT state
• 2 Vlan types
PVLAN
Isolated Vlan
Community Vlan
Community Vlan Isolated Vlan

• Can communicate each other at L2 • Cannot communicate with each
but not with other communities other at L2
PRIVATE VLAN - PORT TYPES
PVLAN
Promiscuous ports PVLAN ISL Ports
• Part of the primary VLAN • Extend a PVLAN domain across different
• Can communicate to all ports in all Vlans switches
• Carries both primary and secondary traffic
PVLAN
Community Vlan Isolated Vlan
Community ports Isolated ports

• Part of the community VLAN • Part of the isolated VLANs
• Can communicate to ports in the same • Can only communicate to promiscuous ports
community or promiscuous ports
PRIVATE VLAN – USE CASE
◼ Ports C1,C2,C3 are UNP ports whose client is assigned to Community vlan 103
◼ Ports C4,C5 are UNP ports whose client is assigned to Community vlan 102
◼ ISL ports connecting switches to extend ALL Private Vlans
◼ Promiscuous port to whom everyone can communicate bi-directionally
Phone community
Private VLAN 100 VLAN 103
ISL
All private VLANs tagged
Community
100,101,102,103
VLAN 102 Community
C4 C5 VLAN 103
C3
I1 I2
Isolated
VLAN 101 Switch 1 Switch 2
Switch 3
Promiscuous
C1 C2 port
Community
VLAN 103 OV 2500
IP services and
internet
Phone community
VLAN 103
PRIVATE VLAN – SPECIFICATIONS
PRIVATE VLAN – CONFIGURATION EXAMPLE
pvlan 100 admin-state enable
pvlan 100 secondary 101 type community
pvlan 100 secondary 103 type isolated
pvlan
pvlan
100
101
members port 1/1/20 untagged
members port 1/1/1 untagged
PVLAN 100
1/1/20
pvlan 101 members port 1/1/15 untagged
pvlan 103 members port 1/1/16-17 untagged
1/1/17
-> show pvlan mapping 1/1/1 1/1/16

Primary Secondary 1/1/15
VLAN VLAN Type
----------+----------+------------ Isolated Vlan 103
100 101 Community Community Vlan 101
100 103 Isolated
sw2> show pvlan members

pvlan port type status port-type
-------+---------+------------------+------------+------------
-------+---------+------------------+------------+------------
100 1/1/20 default forwarding promiscuous
101 1/1/1 default forwarding community
103 1/1/16 default forwarding isolated
-> show mac-learning

VLAN 100 00:50:56:9e:2f:37 dynamic bridging 1/1/1
VLAN 100 00:50:56:9e:a4:03 dynamic bridging 1/1/15
VLAN 100 00:50:56:9e:85:68 dynamic bridging 1/1/16
VLAN 100 00:50:56:9e:1f:9f dynamic bridging 1/1/17
VLAN 100 00:50:56:9e:05:2b dynamic bridging 1/1/20
VLAN 100 00:50:56:9e:73:25 dynamic bridging 1/1/20
PRIVATE VLAN
Vlan Traffic Primary Vlan
Isolated Vlan 103

Community Vlan 101
Traffic not authorized

Traffic authorized
Primary
Vlan
Isolated Vlan 103

Community Vlan 101
PRIVATE VLAN – CONFIGURATION PVLAN 100 1/3/20
Example 1/3/1 1/3/14

1/3/15
1/3/12
Isolated Vlan 103
Community Vlan 101
linkagg lacp agg 1 size 2 admin-state enable

linkagg lacp agg 1 actor admin-key 1
linkagg lacp port 1/4/1 actor admin-key 1 1/4/1-2
linkagg lacp port 1/4/2 actor admin-key 1 Linkagg 1
2/1-2
pvlan 100 admin-state enable
pvlan 100 secondary 101 type community
pvlan 100 secondary 103 type isolated
pvlan 100 members linkagg 1 isl PVLAN 100 1/1/20
pvlan 101 members port 1/3/12 untagged 1/1/17
1/1/15
pvlan 103 members port 1/3/14-15 untagged 1/1/1
1/1/16
Community Vlan 101 Isolated Vlan 103

PRIVATE VLAN – UNP PORTS
• Can also be assigned to Secondary VLANs (isolated or community ports)
• The UNP ports are designated as isolated or community ports during IEEE 802.1x, MAC Auth or
runtime based on the first MAC address learned on the port. UNP Classification Rules
• If the first MAC address is learned on a UNP port is classified into an

Isolated VLAN, the port is designated as an isolated port.
• If the first MAC address is learned on a UNP port is classified into a UNP
Community VLAN, the port is designated as a community port. PVLAN
• If the first MAC address learned on the a UNP port is classified into
any standard VLAN (non-PVLAN), then the UNP port cannot be
Isolated Vlan
designated as an isolated or community port. Community Vlan
UNP
IEEE 802.1x, MAC Auth or

UNP Classification Rules
THANK YOU
OmniSwitch R8
Private VLAN
How to
✓ Setup the Private VLAN feature on the OmniSwitch
Contents
1 Objective ....................................................................................... 2
2 Private VLAN Overview ....................................................................... 2
3 Lab Diagram .................................................................................... 2
4 Create a User-defined directories labPVLAN .............................................. 3
5 Configuring Link aggregation between 6860’s ............................................ 3
6 Configuring the Private VLAN................................................................ 4
6.1. Configuring the Private VLAN ..................................................................... 4
6.2. Configuring the PC Clients ........................................................................ 4
7 Testing the Configuration .................................................................... 4
7.1. Testing the Community VLAN ..................................................................... 4
7.2. Testing the Isolated VLAN ......................................................................... 5
8 Deleting the Configuration ................................................................... 5
2
Private VLAN
Implementation
1 Objective
This lab is designed to familiarize you with the concept of Private VLAN (PVLAN). This feature provides the
ability to isolate Layer 2 data between devices that are on the same VLAN. This type of data isolation
improves security and simplifies system configuration.
2 Private VLAN Overview

Private VLAN divides a single broadcast domain into smaller broadcast sub-domains while keeping the existing
Layer 3 configuration. When a VLAN is configured as a PVLAN, this is referred to as the Primary VLAN, and any
subsequent VLANs that are associated with the Primary VLAN are referred to as Secondary VLANs.
There are two types of Secondary VLANs:

- Isolated VLAN: In an Isolated VLAN, all hosts connected to a member port are Isolated at Layer 2. They
can communicate only with the promiscuous port of the Primary VLAN. There can be only one Isolated
VLAN within one Primary VLAN.
- Community VLAN: A Community VLAN is associated to a group of ports that connect to a certain
“community” of end devices with mutual trust relationships. Any switch port associated with a common
Community VLAN can communicate with each other and with the promiscuous ports of the Primary VLAN
but not with any other Secondary VLAN. There can be multiple distinct Community VLANs within one
Primary VLAN.
3 Lab Diagram
3
Private VLAN
4 Create a User-defined directories labPVLAN
- Create a User-defined directories “labPVLAN” and boot the switches from the new user-defined directory
(labPVLAN):
once the switch boots, verify that it booted from the “labPVLAN” directory:
sw7 (6860-A) ->

mkdir labPVLAN
sw7 (6860-A) ->
cp labinit/*.* labPVLAN
sw7 (6860-A) ->
ls labPVLAN
sw7 (6860-A) ->
reload from labPVLAN no rollback-timeout
sw8 (6860-B) ->

mkdir labPVLAN
sw8 (6860-B) ->
cp labinit/*.* labPVLAN
sw8 (6860-B) ->
ls labPVLAN
sw8 (6860-B) ->
reload from labPVLAN no rollback-timeout
5 Configuring Link aggregation between 6860’s
- Type on both 6860:


- Check the result


4
Private VLAN
6 Configuring the Private VLAN
6.1. Configuring the Private VLAN
- Configure a Primary VLAN 250 on both switches and assign the link aggregation group 78 as an Inter-
Switch-Link for this VLAN:
sw7 (6860-A) -> pvlan 250 admin-state enable
sw7 (6860-A) -> pvlan 250 members linkagg 78 isl
sw8 (6860-B) -> pvlan 250 admin-state enable

ERROR: pvlan config is not allowed as capability shared-vlan-learning is disabled
sw8 (6860-B) -> capability shared-vlan-learning enable
sw8 (6860-B) -> pvlan 250 admin-state enable
- Two Secondary VLAN’s are going to be created:

o VLAN 251 as a Community VLAN
o VLAN 252 as an Isolated VLAN
- Configure both VLAN’s on the 6860’s:

6860 -> pvlan 250 secondary 251 type community
6860 -> pvlan 250 secondary 252 type isolated
- Check that the Secondary VLAN’s are associated to the Primary VLAN:
6860 -> show pvlan mapping
Primary Secondary
VLAN VLAN Type
----------+----------+------------
250 251 Community
250 252 Isolated
6.2. Configuring the PC Clients

- Configure the following IP addresses on the PC Clients:
Client 7: 192.168.250.7/24 >> def. GW: 192.168.250.1
Client 8: 192.168.250.8/24 >> def. GW: 192.168.250.2
7 Testing the Configuration
7.1. Testing the Community VLAN
- Move ports 1/1/1 on both switches to VLAN 251 which is the Community VLAN:
6860 -> pvlan 251 members port 1/1/1 untagged
- Enable the 1/1/1 interface on both 6860:

6860 -> interface 1/1/1 admin-state enable
5
Private VLAN
- Verify the configuration:

6860 -> show pvlan members
-------+---------+------------------+------------+------------
250 0/78 qtagged forwarding isl
- Ping from Client 7 to Client 8:

Client 7> ping 192.168.250.8
This command should be successful as both PC’s now belong to the same community VLAN. Remember
that all the ports that are part of the same community VLAN can communicate between each other.
7.2. Testing the Isolated VLAN
- Now, let’s check the Isolated VLAN by moving both ports to VLAN 252:
6860 -> no pvlan 251 members port 1/1/1
6860 -> pvlan 252 members port 1/1/1 untagged
- Verify the configuration:

6860 -> show pvlan members
-------+---------+------------------+------------+------------
250 0/5 qtagged forwarding isl
- Ping from Client 7 to Client 8:

Client 7> ping 192.168.250.8
This command should not work because both PC’s now belong to the same Isolated VLAN. Remember that
in an Isolated VLAN hosts cannot communicate between each other.
8 Deleting the Configuration
- When the tests are completed, delete the PVLAN configuration with the following commands:
6860 -> no pvlan 252 members port 1/1/1
6860 -> no pvlan 250 members linkagg 78
6860 -> no pvlan 250


6
Private VLAN
sw7 (6860-A) -> rm -r labPVLAN

rm: remove 'labPVLAN/pkg/.pkgDB_Commit'? y
rm: remove 'labPVLAN/pkg/.appDB_Commit'? y
rm: remove 'labPVLAN/.boot.pkg.md5'? y
rm: remove 'labPVLAN/boot.md5'? y
sw8 (6860-B) -> rm -r labPVLAN

rm: remove 'labPVLAN/pkg/.pkgDB_Commit'? y
rm: remove 'labPVLAN/pkg/.appDB_Commit'? y
rm: remove 'labPVLAN/.boot.pkg.md5'? y
rm: remove 'labPVLAN/boot.md5'? y
OMNISWITCH R8
B O R D E R G AT E WAY P R O T O C O L ( B G P )
OBJECTIVES
• Describe the basic BGP concepts

• Perform a basic BGP implementation on an AOS
switch-based network
• BGP Synchronization
• BGP Policy routing
BGP CONCEPTS AND BASIC SETUP - AOS SPECIFICATIONS
BGP CONCEPTS
IGP VS EGP
• Two different classes of routing protocols • IGP do not scale well

• IGP – Internal Gateway Protocol • SPF algorithm runs slow on big routing table
• EGP – External Gateway Protocol • Not sized for internet routing table
• No policy routing mechanisms
AS AS
ISP
IGP EGP
BGP4
• Border Gateway Protocol • Used to:
• Current version: 4 • See the Internet Network (received IP routes)
• Exterior routing protocol used to make policy • Advertise our own network (announce IP routes)
routing decisions between autonomous systems • Influence the inbound traffic flow
(AS) • Influence the outbound traffic flow
• Standardized: RFC 4271
• Listens on port 179 / TCP
• Optional authentication IGP
• MD5: adds an option to TCP AS 100
(digest based on pseudo Header + header + data + AS 999
shared password)
BGP IGP
• Point-to-point over directly connected
interfaces or Multi-hop between non-adjacent
routers BGP
BGP
• Routing information is exchanged in BGP Update
messages AS 1
IGP
AS DEFINITION
• Autonomous Systems OSPF
OSPF
• An autonomous system (AS) is a set of routers
that are under a single technical administration OSPF
OSPF
• Normally, use a single interior gateway protocol OSPF
and a common set of metrics to propagate
routing information within the set of routers
• To other ASs, an AS appears to have a single,
coherent interior routing plan and presents a
consistent picture of what destinations are Destination reachable
reachable through it
194.10.10.0 /24
• Identified by AS number (1-65535) Private ASNs 194.12.10.0 /23
194.13.10.0 /24
from 64512-65535 Etc….
BGP PEERING AND BGP NEIGHBORS
• Internal BGP Neighbor • External BGP Neighbor
• A router that falls under the administrative control • A router whose administrative and policy control is
of a single AS and is assumed to follow a consistent outside of your AS
policy with other BGP speakers of that AS • Send and receive BGP information to or from
• Internal BGP neighbors are reachable by static other AS
routes, internal routing protocol, or directly
connected
BGP
BGP
OSPF RIP
BGP
IBGP peering
• Peering
• Two routers with a BGP connection are neighbors or EBGP peering
peers
• Peers can be external (EBGP) or internal (IBGP)
• No need of direct connection between IBGP peers
• EBGP peers are usually directly connected
BGP PEER/NEIGHBOR
• No dynamic discovery • Connection State
• (Selective) Route exchange • Idle – waiting for incoming connection TCP port 179
• Connect – setting up a TCP session
• Keepalive mechanism
• Active – unable to create a TCP session
• 4 four message types • OpenSent - sending out its OPEN message
• Open • OpenConfirm – waiting for the KEEPALIVE message
• Keepalive • Established – BGP session is up
• Update
• Notification
AS 54
AS 4
BGP ROUTE INFORMATION
• Path Vector Protocol
• BGP advertisement is made of:
• Prefix
• Attribute
AS 25
R2
192.168.1.0
R1
AS 54
R3
AS 4
BGP UPDATE
• Between BGP neighbors
• To advertise new route/prefix
• To withdraw previously advertised route/prefix
AS 25
AS 54 192.168.1.0
R1 R3
BGP UPDATE
BGP ATTRIBUTE (1)
• Part of the update message
• Variable length
• Can be:
• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Optional nontransitive
AS 25
AS 54 192.168.1.0
R1 R3
BGP ATTRIBUTES OVERVIEW
AS-PATH ATTRIBUTE
• Well-known mandatory attribute
AS 25
• List of traversed ASes R1 192.168.1.0
R2
AS 54 R3
AS 401
R4
AS 23 R5
AS 4
192.168.1.0 AS ( 23,401,54,25)
NEXT-HOP ATTRIBUTE (1)
• IP address of the next node towards destination
192.168.1.0 AS (25) 10.1.1.3
R1
R3
10.1.1.2
R2
10.1.1.3
AS 25
192.168.1.0
NEXT-HOP ATTRIBUTE (2)
• IBGP conserves the next hop attribute learned over EBGP
• When BGP Synchronization if off, “next-hop-self” can act as a workaround to validate the BGP path
192.168.1.0 AS (25) 31.0.0.3/8

31.0.0.1/8
31.0.0.3/8
R3 R1
10.1.1.2/24
R2
AS 25
10.1.1.3/24 192.168.1.0
ORIGIN ATTRIBUTE
• Defines the origin of the path information :

• IGP - the prefix was learned from an IGP
• EGP - the prefix was learned via EGP
• Incomplete - the prefix was learned through redistribution or static routing or unknown
LOCAL PREFERENCE ATTRIBUTE
• Well-known discretionary attribute
• Specify a most preferred path to exit an AS
AS 54 AS 250
172.18.0.0
R1 172.18.0.0 /8
Local pref = 200
AS 3400
AS 100
R2
172.18.0.0 /8
Local pref = 100
BGP LOCAL PREFERENCE METRIC
New York Local AS 200 AS 400

Preference = 300
AS 600
198.100.28.1
Chicago
198.101.24.0
Atlanta
200.100.50.1
AS 300 AS 500
Local
Preference = 200
ATOMIC AGGREGATE ATTRIBUTE
• Well-known discretionary attribute
• CIDR support (Only BGP 4)
• Informs that routes are aggregated
AS 54 AS 650 AS 20
150.215.30.8 /30 150.215.30.4 /30

150.215.30.12 /30
AS 10 150.215.30.0 /28
MULTI EXIT DISCRIMINATOR (MED)ATTRIBUTE
• Optional non-transitive attribute
• Specify a most preferred path to an AS
AS 54 172.18.0.0/16
R1 MED = 100
R4
R2
172.18.0.0/16
172.18.0.0/16
MED = 200 R3 AS 250
BGP MULTI-EXIT DISCRIMINATOR
• Inbound Metric
• Meaning: “How I prefer receiving the traffic from you”
• When two autonomous systems have multiple links with each other, the MED (Multi-Exit
Discriminator) informs the other AS of recommended entrance points
• Lower MED value is preferred
• Default setting for MED = 0
• Metric is non-transitive
• Only shared between two autonomous systems
• Passed from one AS to a second AS
• When the second AS advertises the networks from the first AS, MED value is set back to 0 before
leaving second AS
BGP MULTI-EXIT DISCRIMINATOR
AS 100
MED for
198.100.28.1
198.101.24.0 = 300
AS 200
MED for
198.101.24.0
198.101.24.0 = 100
200.100.50.1
I’ll go through 200.100.50.1 to get to

network 198.101.24.0 because it has a
lower MED, but I’ll remember the other
route in case the pathway though
200.100.50.1 becomes unavailable
BGP COMMUNITIES
• Provides a way of grouping destinations (called communities) to which routing decisions (such as
acceptance, preference, and redistribution) can be applied
• Can be passed through and to other AS
• Allows tagging various networks and grouping them into communities
• A few predefined communities are listed:

• No-export (networks are not announced to outside AS)
• No-Export-subconed (sub-confederations)
• No advertise (networks are not announced to any BGP speakers)
BGP COMMUNITY EXAMPLE
200.100.50.1
AS 300 AS 100
Router B
AS 200
198.101.24.0 198.101.24.0 /21 ISP A
198.101.25.0
198.101.26.0
198.101.27.0
198.101.28.0
198.101.29.0
198.101.30.0
198.101.31.0 Router A
198.101.24.0 /21 Internet
COMMUNITY ATTRIBUTE
• Optional transitive attribute
• Permits to tag routes with an indicator
• Filtering can be implemented based on tags
Community Action
NO-EXPORT No adv. to EBGP peers
NO-ADVERTISE No adv. to Any peers
<AS:Community#> User defined policy

BGP ROUTE SELECTION
• Recursive lookup validates the route
• Route selection process

• Highest Local preference
• Shortest AS-Path
• lowest origin (IGP>EGP>Incomplete)
• Lowest MED
• Closer Next-Hop
• EBGP > IBGP > IGP
• Lowest RID
BGP AOS CONFIGURATION
CLI - IBGP/EBGP BASIC SETUP
• Define Router ID
-> ip router router-id
• Load and activate BGP
-> ip load BGP
-> ip bgp admin-state enable
• Define AS
-> ip bgp autonomous-system 100
• Create a BGP peer entry
-> ip bgp neighbor 100.10.1.1
• Create Peer relationship with authentication
-> ip bgp neighbor 100.10.1.1 > remote-as
-> ip bgp neighbor < 100.10.1.1 > md5 key
-> ip bgp neighbor < 100.10.1.1 > status enable
-> show ip bgp neighbors
Nbr address As Admin state Oper state BgpId
--------------+----+-----------+------------+-------------
192.40.4.29 3 enabled estab 192.40.4.29
192.40.4.121 5 disabled idle 0.0.0.0
BGP PEER SESSION WITH LOOPBACK0
• BGP peering is based on the Loopback0 IP interface address of the peering router
• binding the source (i.e., outgoing IP interface for the TCP connection) to its own configured Loopback0
interface
• Loopback0 IP interface address can be used for both Internal and External BGP peer sessions
-> ip bgp neighbor 100.10.1.1 update-source Loopback0
• ebgp-multihop parameter
• For EBGP sessions, if the External peer router is multiple hops away
-> ip bgp neighbor 100.10.1.1 ebgp-multihop
BGP SPLIT HORIZON
Routes learned via IBGP should never be
Propagated to other IBGP peers
R1 AS 4
R5
R3
R2
AS 4
R4
BGP SYNCHRONIZATION
A BGP router should not advertise, a route learned by IBGP, to an EBGP

peer unless the route is local or is learned from an IGP
R4
R1 EBGP peers
AS 54
172.31.0.0
IBGP
R5 peers
EBGP peers R3
10.3.0.0 AS 4
R2 23.0.0.0/8
-> ip bgp synchronization

ROUTING TABLE
• AOS Protocol preference for choosing which routes go into the routing table
• Local =1
• Static =2
• OSPF = 10
• RIP = 100
• BGP = 200 BGP Path table Local/Static Routes
-> show ip route-pref

Protocol Route
Preference Value
------------+------------------
Local 1
Static 2 OSPF Routes
OSPF 10
RIP 100
BGP 200
Routing table
-> ip route-pref BGP 8

BGP POLICY ROUTING
BGP POLICY ROUTING
• AS Path, Community and Prefix lists
• Route map
-> ip bgp policy aspath-list “100 300 150” permit/deny
-> ip bgp policy community-list 600:1 permit/deny
-> ip bgp policy prefix-list 172.31.0.0 /16 permit/deny
Route-map example
If BGP update matches aspath-list
If prefix-list = <value>
Set network local_preference = <value>
BGP POLICY MATCHING FLOWCHART
Match ?
ip bgp policy aspath-list 1
Yes
policy ip bgp policy prefix-list 2
Denied->
Action?
ip bgp policy community-list 3 Evaluation
stopped
Route-map aspath-list 4 Permitted ->

Route-maps
evaluation
Route-map prefix-list 5
NO->
Route-maps ?
Route-map community-list 6 Evaluation
Route-map stopped
Yes
Route-map regexp match 7
NO->
Match?
Route-map prefix match 8 Routes
dropped +
Route-map community match 9 Yes

Evaluation
stopped
BGP POLICIES
-> ip bgp policy aspath-list aspathfilter “^100 200$” action permit
• looks for routes with an AS path with the next hop AS 100, and originating from AS 200
• permits routes that match the regular expression ^100 200$
-> ip bgp policy community-list commfilter 600:1 < action permit / match-type exact /priority 3
• looks for routes in the community 600:1

• permits routes in community 600:1 to be advertised
• looks for routes that only belong to the community 600:1
• Routes with a high priority number are applied first
-> ip bgp policy prefix-list prefixfilter 12.0.0.0 255.0.0.0 action deny
• denies routes that match the network address 12.0.0.0/8

ROUTE-MAP POLICY
• Create a route map policy
-> ip bgp policy route-map mapfilter1
• Set the policy action
-> ip bgp policy route-map mapfilter1 action deny
• mapfilter now denies routes that are filtered
• Add conditions to the route map policy

-> ip bgp policy route-map mapfilter1 aspath-list aspathfilter
-> ip bgp policy route-map mapfilter1 community-list commfilter
• Assigning a Policy to a Peer

-> ip bgp neighbor 172.22.2.0 route-map mapfilter1 out
• To assign the same policy to route advertisements to the peer
-> ip bgp neighbor 172.22.2.0 route-map mapfilter1 in

• To filter routes learned from a peer by the route map
THANK YOU
OmniSwitch R8
BGP
How to
✓ Configure a BGP connection
Contents
1 Topology ........................................................................................ 2
2 Create a User-defined directory ............................................................ 3
3 Lab Prerequisites .............................................................................. 3
3.1. Configure VLANs on all switches ................................................................. 3
3.2. Configure ospf on all switches .................................................................... 4
3.3. “WAN” Configuration .............................................................................. 6
3.4. WAN Connectivity .................................................................................. 6
3.5. BGP Connectivity ................................................................................... 6
3.6. Redistributing Routes .............................................................................. 7
3.7. Gathering Routing Information ................................................................... 8
2
BGP
1 Topology
3
BGP
2 Create a User-defined directory

- Create a User-defined directories “labbgp” and boot the switches from the new user-defined directory
(labbgp):
once the switch boots, verify that it booted from the “labbgp” directory:
sw1 (6900-A) ->

mkdir labbgp
sw1 (6900-A) ->
cp labinit/*.* labbgp
sw1 (6900-A) ->
ls labbgp
sw1 (6900-A) ->
reload from labbgp no rollback-timeout
sw2 (6900-B) ->

mkdir labbgp
sw2 (6900-B) ->
sw2 (6900-B) ->
ls labbgp
sw2 (6900-B) ->
sw7 (6860-A) ->

mkdir labbgp
sw7 (6860-A) ->
sw7 (6860-A) ->
ls labbgp
sw7 (6860-A) ->
sw8 (6860-B) ->

mkdir labbgp
sw8 (6860-B) ->
sw8 (6860-B) ->
ls labbgp
sw8 (6860-B) ->
3 Lab Prerequisites
3.1. Configure VLANs on all switches
- On Switch 6900-A:
sw1 (6900-A) -> vlan 10

sw1 (6900-A) -> vlan 12
sw1 (6900-A) -> vlan 13
sw1 (6900-A) -> interfaces 1/2/25 admin-state enable or interfaces 1/2/1 admin-state enable
sw1 (6900-A) -> ip interface vl10 address 192.168.10.254/24 vlan 10
4
BGP
- On Switch 6900-B:
sw2 (6900-B) -> vlan 20

sw2 (6900-B) -> vlan 12
sw2 (6900-B) -> vlan 24
sw2 (6900-B) -> ip interface vl20 address 192.168.20.254/24 vlan 20
- On Switch 6860-A:
sw7 (6860-A) -> vlan 30

sw7 (6860-A) -> vlan 13
sw7 (6860-A) -> vlan 34
- On Switch 6860-B:
sw8 (6860-B) -> vlan 40

sw8 (6860-B) -> vlan 24
sw8 (6860-B) -> vlan 34
3.2. Configure ospf on all switches
- On Switch 6900-A:

sw1 (6900-A) -> ip ospf area 0.0.0.0
sw1 (6900-A) -> ip ospf area 1.1.1.1
sw1 (6900-A) -> ip ospf interface vl10
sw1 (6900-A) -> ip ospf interface vl10 area 1.1.1.1
sw1 (6900-A) -> ip ospf interface vl10 admin-state enable
5
BGP
- On Switch 6860-A:

sw7 (6860-A) -> ip ospf area 0.0.0.0
sw7 (6860-A) -> ip ospf area 3.3.3.3
- On Switch 6900-B:

sw2 (6900-B) -> ip ospf area 0.0.0.0
sw2 (6900-B) -> ip ospf area 2.2.2.2
sw2 (6900-B) -> ip ospf interface vl20
sw2 (6900-B) -> ip ospf interface vl20 area 2.2.2.2
sw2 (6900-B) -> ip ospf interface vl20 admin-state enable
- On Switch 6860-B:

sw8 (6860-B) -> ip ospf area 0.0.0.0
sw8 (6860-B) -> ip ospf area 4.4.4.4
With the commands above, we have now two independent networks (two AS), each network runs an
separate IGP protocol (here we use ospf) within its AS.
Next, configure BGP to advertise routes between each of two Autonomous Systems.
6
BGP
3.3. “WAN” Configuration
We are using the network 192.168.12.0/24 between the switches 1 and 2, and network
192.168.34.0/24 between the switches 3 and 4. The network should be complete and up now.
3.4. WAN Connectivity

Ensure you can ping your neighbor switch from each of the “WAN” connections.
3.5. BGP Connectivity

Two Autonomous Systems have now been connected using the “WAN” connection. Now BGP can be
configured to advertise routes between them.
- On Switch 6900-A:
sw1 (6900-A) -> ip load bgp

sw1 (6900-A) -> ip bgp autonomous-system 100
sw1 (6900-A) -> ip bgp neighbor 192.168.12.2
sw1 (6900-A) -> ip bgp neighbor 192.168.12.2 remote-as 200
sw1 (6900-A) -> ip bgp neighbor 192.168.12.2 admin-state enable
sw1 (6900-A) -> ip bgp admin-state enable
sw1 (6900-A) -> show ip bgp
sw1 (6900-A) -> show ip bgp neighbors
- On Switch 6900-B:
sw2 (6900-B) -> ip load bgp

sw2 (6900-B) -> ip bgp autonomous-system 200
sw2 (6900-B) -> ip bgp neighbor 192.168.12.1
sw2 (6900-B) -> ip bgp neighbor 192.168.12.1 remote-as 100
sw2 (6900-B) -> ip bgp neighbor 192.168.12.1 admin-state enable
sw2 (6900-B) -> ip bgp admin-state enable
sw2 (6900-B) -> show ip bgp
sw2 (6900-B) -> show ip bgp neighbors
- On Switch 6860-A:
sw7 (6860-A) -> ip load bgp

sw7 (6860-A) -> ip bgp autonomous-system 100
sw7 (6860-A) -> ip bgp neighbor 192.168.34.8
sw7 (6860-A) -> ip bgp neighbor 192.168.34.8 remote-as 200
sw7 (6860-A) -> ip bgp neighbor 192.168.34.8 admin-state enable
sw7 (6860-A) -> ip bgp admin-state enable
sw7 (6860-A) -> show ip bgp
sw7 (6860-A) -> show ip bgp neighbors
- On Switch 6860-B:
sw8 (6860-B) -> ip load bgp

sw8 (6860-B) -> ip bgp autonomous-system 200
sw8 (6860-B) -> ip bgp neighbor 192.168.34.7
sw8 (6860-B) -> ip bgp neighbor 192.168.34.7 remote-as 100
sw8 (6860-B) -> ip bgp neighbor 192.168.34.7 admin-state enable
sw8 (6860-B) -> ip bgp admin-state enable
sw8 (6860-B) -> show ip bgp
sw8 (6860-B) -> show ip bgp neighbors
7
BGP
The commands above created an AS identifier for each switch. Additionally, the switch’s BGP neighbor
was configured using its neighbor’s IP address as well as its neighbor’s AS identifier.
By now ‘show ip bgp neighbors’ should display all your neighbors in an established operational state. You
will talk iBGP with neighbours in your AS and eBGP with neighbors outside your AS.
At this point you have only the routes from your AS network, type the following on all switches to check
the routing table:
all-> show ip ospf routes
all-> show ip bgp routes
all-> show ip routes

Total 5 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:33:30 LOCAL
192.168.10.0/24 192.168.10.254 00:11:17 LOCAL
192.168.12.0/24 192.168.12.1 00:10:44 LOCAL
192.168.13.0/24 192.168.13.1 00:08:53 LOCAL
192.168.30.0/24 192.168.13.3 00:08:08 OSPF
Please notice that, at this step, there are no routes from the AS100 advertised to the AS200.
3.6. Redistributing Routes

Now that the network configuration is complete, configure BGP to distribute the routes to the other
Autonomous Systems. Create the following filter.
Type the following on switches 1, 2, 7 and 8:
ip route-map switch1bgp sequence-number 10 action permit

ip redist ospf into bgp route-map switch1bgp
ip redist local into bgp route-map switch1bgp



8
BGP
3.7. Gathering Routing Information

You should now begin to see routes from the other Autonomous Systems.
Do another ping to your neighbor AS switch 4 (or other bgp peers) and check the routing table again, you
will see that the BGP advertises the routes from AS100.
-> show ip routes
Total 8 routes
------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 00:35:16 LOCAL
192.168.10.0/24 192.168.10.254 00:13:03 LOCAL
192.168.12.0/24 192.168.12.1 00:12:30 LOCAL
192.168.13.0/24 192.168.13.1 00:10:39 LOCAL
192.168.20.0/24 192.168.12.2 00:00:26 EBGP
192.168.24.0/24 192.168.12.2 00:00:26 EBGP
192.168.30.0/24 192.168.13.3 00:09:54 OSPF
192.168.40.0/24 192.168.12.2 00:00:26 EBGP
- At the end of this lab, restore the four switches to initial configuration by restarting them from "working
directory".
sw1 (6900-A) -> rm -r labbgp

rm: remove 'labbgp/pkg/.pkgDB_Commit'? y
rm: remove 'labbgp/pkg/.appDB_Commit'? y
rm: remove 'labbgp/.boot.pkg.md5'? y
rm: remove 'labbgp/boot.md5'? y
sw2 (6900-B) -> rm -r labbgp

sw7 (6860-A) -> rm -r labbgp

sw8 (6860-B) -> rm -r labbgp

OMNISWITCH R8
S H O R T E S T PAT H B R I D G I N G ( S P B )
OBJECTIVES
• Learn about the Shortest Path Bridging (SPB)

feature
• Identify the control and data planes in SPB
• Learn about IP Routing over SPB
STP VS. SPB-M IEEE 802.1ad (Provider Bridging, or Q-in-Q)
maximum of 4096 service instances.
• Unused links:
• loop-free topology by disabling network links
• inefficient bandwidth use
• low Return on Investment (ROI)
• Sub-optimal paths:
• A single tree, the traffic always must pass through the ‘Root’ bridge bridges
• May need to traverse a sub-optimal route transiting the root-bridge
• Lack of a coordinated control plane
• Flooding: Ethernet’s “flood and learn” address learning floods unknown-unicast traffic until the destination
address is learned from return traffic
• MAC Learning: All nodes in the LAN learn all end-device MAC addresses thus posing a scalability challenge
• Slow convergence:
• Typical convergence times are in the order of seconds.
• Transient loops may form, resulting in packet drops, link saturation, and session timeouts
SPB-M VS STP
Data path with Spanning Tree +
-
Link redundancy
Centralized Root Bridge
- Convergence time
- High @MAC tables
- Scalability
- High number of unused links
Inefficient routes 1
MACs
Source 1
….
Source100
Destination-2
Root Bridge
Source
All the nodes on the 2

route need to learn
MAC’s Source1- Cannot use these
Source100 links
3
Destination-1
OS6860E/N
SHORTEST PATH BRIDGING (SPB-M) OS6865

OS6900
OS9900
• Network requirements
• Fast reconvergence IEEE standard (802.1aq)
• Increase bandwidth utilization
• Reduce latency SPB-M provides following advantages
• High availability • All network links are use with no loops
• Security • Spanning Tree Protocol replacement
• Uses the shortest path end to end
• 100’s ms convergence times
• Applications requirements • Natively protect failures and reroute
• Fast network reconvergence • End-point provisioning
• High bandwidth • Mesh topologies
• Low latency • Deterministic traffic flows
• Symmetrical and congruent paths
• Address isolation through mac-in-mac
• OAM capabilities
• Flexible and scalable service separation
• Traffic separation
SPB-M VS STP +
+
Link redundancy
No Centralized Root Bridge
Data path with SPB-M

+ Convergence time
+ No High @MAC tables in core
+ Scalability
+ All links usable
+ No need IGP in the core for routing
Multiple shortest 1
paths
MACs
Source 1
PBB encapsulation ….
at the edges Source100
Destination-2
PBB
encapsulation
at the edges
2
MAC’s Source1-
Source100 learning
All the links are
restricted to the edges
usable
3 PBB encapsulation
at the edges Destination-1
SHORTEST PATH BRIDGING
Control and Data Planes IEEE 802.1aq
Control Plane Data Plane

Distributes « reachability » information
Populates SPB-M bridging/forwarding tables
between SPB-M switches
ISIS–L1
ISIS–L1 SPB-M
Constructs Shortest Path Trees (SPT)
ISIS-SPB control packets
Access
Bridge
Access
Bridge
No learning of Access LAN @MAC and Edge network @MACs dynamically learnt
paths accross core SPB-M switches and propagated accross SPB-M core
SPB - DATA FORWARDING
Payload SA = Source MAC address
DA = Destination MAC address
Ethertype (IP) C-VID = Customer VlanID
C-VID I-SID = Service ID
B-VID = Backbone VID
Ethertype 802.1q
B-DA = Backbone DA
00:01 B-SA = Backbone SA
00:02
I-SID
Ethertype 802.1ah
B-VID
Ethertype 802.1 ad
00:03
Payload Payload
00:04
Ethertype (IP) Ethertype (IP)
C-VID Service Service C-VID

Ethertype 802.1q
Identifiers Identifiers Ethertype 802.1q
00:01 00:01
00:02 Tunnel 00:02
MAC :00:03 Identifiers MAC :00:04
SPB Network MAC :00:02

MAC :00:01
Customer Network Customer Network

Backbone Bridge Network
SPB COMPONENTS Backbone Core Bridge
Backbone Vlan (BVLAN)
Special VLAN provides the physical path and
BCB is unaware of services propagation of network control
Backbone Edge Bridge Performs forwarding only by Expansion of Layer 2 Ethernet domains
looking at BMAC header No source @mac learning of Customer data traffic
Edge nodes of the SPBM network Each B-VLAN calculates its own Shortest Path Tree
Service termination
BCB BCB
BCB
Customer VLAN (CVLAN)
A traditional VLAN with MAC learning C-VID
& flooding where users connect to BVLAN
802.1Q 1001
ISID
SAP 1001 BEB BVLAN ISID
Access
ISID 1001
SAP Node
SAP
1002
Access 1002
ISID SAP
Node
BEB 1002
BCB
SPB Access Port
BCB
Where the customer traffic
ingresses or egresses Service
A flooding domain
for customer traffic
Service Access Point (SAP)
Used to specify what type of CVLAN traffic is
allowed to enter/exit from/to the SPB network BCB Service Instance Identifier
BCB BCB ISID
Associate a traffic to a SPB service based on Vlan-TAG 1001
Backbone services instance identifier
BCB SAP
Identifies a MAC-in-MAC service instance

BEB Used to identify and transmit any virtualized
BEB = Backbone Edge Bridge traffic in an encapsulated SPB-M frame
BCB = Backbone Core Bridge Delivers service abstraction
C-VID = Customer VlanID
BVLAN=Backbone VLAN
I-SID = Service ID
SAP=Service Access Point
B-VID = Backbone VID
BMAC= Backbone switch MAC address
SPB – SERVICE FRAMEWORK
Service Distribution Point (SDP)

Far-End Node (Unicast SDP) or group of far-end nodes (Multicast SDP)
SDP ID SDP ID
Service I-SID 66 I-SID 66 Service
SAP SAP
I-SID 66 I-SID 66
I-SID 77 I-SID 77
SPB-M
DEMUX BACKBONE DEMUX
Service I-SID 66 I-SID 66 Service
SAP SAP
I-SID 77 I-SID 77
I-SID 77 I-SID 77
SPB – VIRTUAL PRIVATE NETWORK
Building 1
BEB
DC
Building 2
CMAC :00:01 / IP.1 BEB BEB
I-SID1 – Video CMAC :00:02/ IP.2
CMAC :00:10 / IP.10 I-SID2 – Data
BCB BCB
CMAC :00:20 / IP.20
BEB
Building 3
AUTOMATED PROVISIONING
INTO SPB VIRTUAL CONTAINERS
Separate Departments
Administration
Communication
Facilities
Security
A Virtual Department
Department
Private Network for
PrivateDepartment
Network
Private
Private
every Network
Network
department
Private Network
Separate Storage
Separate Computing
SPB – IP ROUTING
Routing L3 traffic over a L2 SPBM backbone network
Run routing protocols

No need IGP in the on L3 VPN IP interfaces
Core/Aggregation
for routing
Subnet 1
Access
Bridge
Access
Subnet 2
Bridge
Routing to CVLANs
IP interfaces
attached to an end
of the SPB-M tunnel Subnet 3
Layer 3 routing advertisements sent

through SPB BVLAN “Default Gateway” Point To Point routing
-> Multi-point routing ative to IPv4/IPv6 formats
SPB-M network acts as a physical network
IP ROUTING OVER SPB-M CONCEPT
AOS supported two mechanisms: IP-VPN Lite / L3/IP-VPN
AOS supported mechanisms

L3/IP-VPN routing over SPB-M
IP-VPN Lite over SPB-M
I-SID Mapping to IP Interface
ISID
VRF
VRF
BVLAN
Operates on BEB Bridges VRF

in a SPB-M backbone
VRFs on different BEBs are tied together by

ISIDs across SPB-M backbone
IP-VPN LITE
• Routing L3 traffic over a L2 SPBM backbone network
• Run routing protocols on L3VPN IP interfaces

SPB IP ROUTING – IP-VPN LITE
VPN-Lite
No need IGP in the
Core/Aggregation for routing DC
Building 1
IP
IP
IP
IP L3 routing advertisements
sent through SPB BVLAN Run routing protocols
Routing to CVLANs IP on L3 VPN IP interfaces
interfaces attached to an Building 2
end of the SPB-M tunnel
IP
IP
“Default Gateway”
Point To Point routing
SPB-M network acts as a physical network Multi-point routing
native to IPv4/IPv6 formats
L3/IP-VPN
• Routing L3 traffic over a L2 SPBM backbone network
• VRF L3 routes exchanged via dedicated ISIS/SPB TLV

SPB IP ROUTING – L3/IP-VPN
No need IGP in the

Core/Aggregation for routing
L3/IP-VPN
DC
Building 1
IP
IP
IP
IP
L3 routes exchanged via ISIS/SPB TLV
No need to run routing protocols
on L3 VPN IP interfaces
Building 2
IP
IP
ISIS-SPB protocol acts as an IP-IGP protocol
Routes can be selectively imported into ISIS- SPB
and advertised across the SPB-M domain
SPB DEPLOYMENT IN LAN NETWORK
DC
Core
Backbone Core Bridge (BCB) role ALE Switch
Learns BEB addresses proposal
BCB BCB
IS-IS SPB for paths OS9900
PBB for data plane OS6900
L3 routing
Aggregation
Backbone edge bridge (BEB) role
VLAN to I-SID ALE Switch
proposal
IS-IS for MAC learning BEB BEB BEB BEB OS9900
IS-IS for SPB paths OS6900
PBB for data plane OS6860E/N
Loopback Detection Feature
ALE Switch
Access proposal
IEEE 802.1Q VLAN on uplinks (port or LAG) OS6360
STP towards BEB OS6450
OS6465
OS6560
BUM TRAFFIC FORWARDING METHODS
• Head-End (default mode)
• Customer BUM traffic is encapsulated in the corresponding destination unicast B-MAC address and
send to ALL destinations
VM VM VM
OS6900 OS6900
VM
• Tandem
• Customer BUM traffic is a special B-MAC Destination Address that encodes the source of the traffic
and send out
VM VM VM
OS6900 OS6900
VM
MC mode can be specified on a per I-SID basis or globally

IP MULTICAST OPTIMIZATION
• IP multicast snooping at service level
Without Optimization
Tandem
Head-End
10005
SAP
SAP 1/1/1:1000 ISID 1000
10006
MCAST
SAP ISID 1000 SDP
SAP 1/1/2:1000 SAP
Dynamic
Querier
Q • Prevents flooding SAPs and SDPs 10007
SAP 1/1/3:1000
• IPv4 and IPv6(MLD)
• IGMP/MLD snooping and proxy per service
• Spoofing, zapping, robustness controls
• Querier forwarding
• Zero based queries
• Flood unknown controls
SPB BENEFITS IN THE CAMPUS
Manageability
• Management
• Out of Band (EMP or port)
• In Band Map VLAN to ISID
• Standard VLAN
• Inline
• Spanning Tree Replacement
Advantages • SPB iFab Technology
• Automated SPB-M (L2) domains creation
• SPB-M auto-discovery of I-SID, BEB services
• UNP based auto-provisioning at BEB of VLAN-ISID
• Simpler than MPLS
Security Resiliency / Scalability

• L2/L3 Virtual Private Networks • Fast reconvergence (~300ms)
• SPB IOT containment • Path diversity / Increase bandwidth utilization
• Automated access profile provisioning • Low latency
with UNP • High availability
• Scalability (up to 1000 nodes)
• Multi-tenancy
https://www.al-enterprise.com/en/solutions/shortest-path-bridging
SPB - SPECIFICATIONS
SPB – VCLASS
THANK YOU
Shortest Path Bridging
Architecture guide
Tech Brief
Shortest Path Bridging Architecture guide
Table of Contents
1. About this architecture guide........................................................................................4

1.1 Purpose..........................................................................................................................4
1.2 Audience........................................................................................................................4
1.3 Glossary.........................................................................................................................4
1.4 References.....................................................................................................................5
2. The network needs to evolve........................................................................................5
3. Introducing SPB...................................................................................................................6
3.1 Scalable, fast-converging, multi-path fabric....................................................7
3.2 Multi-tenancy...............................................................................................................7
3.3 Dynamic service instantiation..............................................................................8
3.4 Edge-only service provisioning............................................................................8
3.5 Micro-segmentation..................................................................................................8
3.6 Non-IP core...................................................................................................................9
4. The Data Plane: IEEE 802.1ah Provider backbone bridging..............................9
5. The Control Plane: RFC 6329 IS-IS Equal-cost trees.......................................... 11
6. The service framework.................................................................................................. 13
7. BUM traffic.......................................................................................................................... 15
8. Creating an SPB backbone........................................................................................... 16
9. L2 services......................................................................................................................... 20
10. Routing concepts........................................................................................................... 26
11. L3 services....................................................................................................................... 29
11.1 VPN Lite................................................................................................................... 29
11.2 L3 VPN...................................................................................................................... 30
11.3 VPN Lite versus L3 VPN.................................................................................... 34
12. Shared Services VPN and Route Leaking............................................................. 34
13. Automation...................................................................................................................... 36
13.1 Auto-Fabric............................................................................................................. 36
13.2 Dynamic SAPs........................................................................................................ 38
13.3 Dynamic Services................................................................................................. 42
Tech Brief
Shortest Path Bridging Architecture guide 2
14. Management................................................................................................................... 43
15. Operation and Maintenance...................................................................................... 45
15.1 Connectivity Fault Management: 802.1ag.................................................. 45
15.2 Network performance: Service Assurance Agent ................................... 47
15.3 Network maintenance......................................................................................... 48
16. Service attachment redundancy............................................................................. 48
17. Loop avoidance and suppression........................................................................... 51
18. General design guidelines.......................................................................................... 52
18.1 BVLANs..................................................................................................................... 52
18.2 VLAN-to-Service mapping................................................................................. 52
18.3 Virtual Chassis....................................................................................................... 53
18.4 Link Aggregation................................................................................................... 53
18.5 Link Metric.............................................................................................................. 54
18.6 QoS............................................................................................................................. 54
19. Security guidelines....................................................................................................... 54
19.1 Management VRF.................................................................................................. 55
19.2 MACSec..................................................................................................................... 55
19.3 NAC............................................................................................................................ 55
19.4 Router authentication......................................................................................... 55
20. Conclusion........................................................................................................................ 56
Tech Brief
1. About this architecture guide
1.1 Purpose
The purpose of this architecture guide is to present SPB (802.1aq) networking concepts along
with design and deployment guidelines. It does not attempt to cover every aspect, nor every
possible architecture option, only the most common, validated and recommended architectures.
You are encouraged to refer to the Alcatel-Lucent Operating Software (AOS) documentation for
additional details, options and guidelines.
1.2 Audience
The intended audience for this document includes customer and business partner networking
professionals involved in the design and deployment of enterprise networks.
1.3 Glossary
AG Access Guardian
BCB Backbone Core Bridge
B-DA Backbone Destination Address
BEB Backbone Edge Bridge
BGP Border Gateway Protocol
BMAC Backbone MAC
B-SA Backbone Source Address
BSN Base Service Number
B-VID Backbone VLAN ID
BVLAN Backbone VLAN
CMAC Customer MAC
CP Control Plane
DoS Denial of Service
DP Data Plane
ECT Equal-Cost Tree
FDB Forwarding Data Base
IETF Internet Engineering Task Force
iFab Intelligent Fabric
IGP Interior Gateway Protocol
ISID Instance Service Identifier
IS-IS Intermediate System to Intermediate System
LDP Label Distribution Protocol
MAC Media Access Control
MACs Moves Adds and Changes
MP-BGP Multi-Protocol BGP
Tech Brief
MSTP IEEE 802.1s Multiple Spanning Tree Protocol
NAC Network Admission Control
OSPF Open Shortest Path First
PBB IEEE 802.1ah Provider Backbone Bridging
Q-in-Q IEEE 802.1ad Provider Bridging
RADIUS Remote Access Dial-In User Service
ROI Return on Investment
RSTP IEEE 802.1w Rapid Spanning Tree Protocol
SAP Service Access Point
SDP Service Distribution Point
SPB IEEE 802.1aq Shortest Path Bridging
SPB-M SPB MAC-in-MAC
SPB-V SPB Q-in-Q
SPF Shortest Path First
STP IEEE 802.1D Spanning Tree Protocol
TLV Type, Length, Value
UNP User Network Profile
1.4 References
[1] IP/IPVPN services with IEEE 802.1aq SPB networks - draft-unbehagen-spb-ip-ipvpn-00.txt
[2] Alcatel-Lucent OmniSwitch® Template Based Provisioning with Alcatel-Lucent OmniVista®
2500 Network Management System (NMS)
[3] Network infrastructure security best practices
2. The network needs to evolve

Local Area Networks (LAN) have traditionally relied on Spanning Tree Protocol (STP), and its
variants (RSTP, MSTP), collectively referred to as “STP” for simplicity, for loop prevention. STP
achieves a loop-free topology by electing a “root bridge” and building a least-cost tree linking
the root bridge with other non-root nodes. This least-cost tree is created by pruning (disabling)
all branches (links) which are not in the least-cost path towards the root. STP’s design principle
presents several drawbacks for modern Enterprise networks:
• Unused links: Creating a loop-free topology by disabling network links results in inefficient
bandwidth use and low Return on Investment (ROI)
• Sub-optimal paths: While communication to-and-from the root bridge follows the least-
cost path, communication between non-root bridges may need to traverse a sub-optimal
route transiting the root-bridge instead of alternative better routes over links that have
been disabled
• Slow convergence: STP is a decades-old protocol designed when network devices were far less
powerful than they are today. Even with the “rapid” version of STP, typical convergence times
are in the order of seconds. While STP re-converges to a new topology, transient loops may
form, resulting in packet drops, link saturation, and session timeouts.
Tech Brief
Figure 1. The problems with STP
Inefficient
routes
Destination 2 MACs
M1 ... M100
Source
Root bridge
All the nodes on Cannot use

the route need to these links
learn MAC’s M1-M100
Destination 1
In addition to STP’s weaknesses, Ethernet’s scalability beyond the LAN is limited by its lack of
a coordinated control plane and use of a flat (as opposed to hierarchical) address space. Legacy
Ethernet networks present the following challenges:
• Flooding: Ethernet’s “flood and learn” address learning floods unknown-unicast traffic until
the destination address is learned from return traffic
• MAC Learning: All nodes in the LAN learn all end-device MAC addresses thus posing a
scalability challenge
Lastly, IEEE 802.1ad (Provider Bridging, or Q-in-Q) is limited to a maximum of 4096

service instances.
3. Introducing SPB
802.1aq Shortest Path Bridging (SPB) is an IEEE networking standard whose primary focus was
addressing the challenges in STP. But SPB is much more than STP’s evolution: SPB provides
MPLS-like VPN services but is significantly simpler to deploy and maintain. And unlike MPLS,
which requires a “stack” of protocols (for example: LDP, OSPF, MP-BGP, among others), SPB relies
on a single protocol to provide this functionality: IS-IS (Intermediate System to Intermediate
System). IS-IS is the only control plane protocol required to build a multi-path topology, perform
address learning, and carry VPN routes across the backbone. Alcatel-Lucent Enterprise’s
Intelligent Fabric (iFab) brings further simplification by automating network node provisioning,
client device attachment, and dynamic service instantiation. Because of this simplicity and
automation, an ALE-powered SPB solution offers high-end services for a lower total cost of
ownership (TCO). Let’s analyse SPB’s benefits in further detail.
Tech Brief
3.1 Scalable, fast-converging, multi-path fabric
Figure 2. Addressing STP’s challenges
Multiple
shortest
paths
Destination 2 MACs
PBB M1 ... M100
encapsulation
at the edges
PBB
encapsulation
at the edges 2
MACs M1-M100 All the links

3 learning restricted are usable
to the edges
PBB
encapsulation
at the edges Destination 1
SPB’s loop-free topology is built by a link-state routing protocol running Dijkstra’s Shortest
Path First (SPF) algorithm: IS-IS. With IS-IS, no network link is disabled, all paths are available
and traffic between any pair of nodes follows the shortest path. In addition, with MAC-in-MAC
encapsulation, backbone nodes do not learn any end-device MAC addresses, thus increasing
the network scalability and stability. With IS-IS and MAC-in-MAC encapsulation, SPB creates an,
any-to-any, scalable and fast-converging “fabric” supporting multiple active optimal paths for
both bridged and routed traffic.
3.2 Multi-tenancy
SPB natively supports multi-tenancy: The physical network is partitioned into multiple virtual
“slices” referred to as VPNs, “containers” or “communities”. Customers, or IoT device groups,
segregated into different VPNs are isolated and do not interfere with one another. In fact, they
can use overlapping address space without conflict. Inter-VPN communication, if needed, is
tightly controlled by firewall policies. This multi-tenancy capability makes SPB suitable for use
cases such as smart cities, transportation, higher education, video surveillance or data centres,
to name a few. SPB’s scalability is not limited to 4096 tenants because its service identifier, the
ISID, is a 24-bit field which can differentiate up to 16M services.
Figure 3. Multi-tenancy
Tech Brief
3.3 Dynamic service instantiation
SPB services do not need to be statically bound to a switch port. SPB is tightly integrated with
Alcatel-Lucent Enterprise’s classification and Network Admission Control (NAC) framework
known as Access Guardian (AG). Upon connection, end devices can be classified (for example;
based on the MAC OUI or IoT “fingerprint” rules) or authenticated (for example; through 802.1x
or MAC) against a RADIUS server. The appropriate service is dynamically instantiated according
to the device or user classification, or role attribute returned by the RADIUS server. In the same
manner, this user-to-service binding is removed when the user/device disconnects. This dynamic
service instantiation has the following advantages:
• User/Device mobility: The network configuration dynamically adapts to mobile users and
devices or Virtual Machines (VMs) migrations without need for Move, Add or Change requests
• Increased security: Services are instantiated on an as-needed basis only, and for authenticated
devices/users only, if applicable. This association is maintained for as long as the user/device
remains connected and/or authenticated, and is brought down on disconnection/log-off. These
ephemeral services are inherently more secure: they cannot be scanned, DoSd, or otherwise
hacked, while they’re not active.
• Device templates: This dynamic instantiation of network services easily lends itself into
template-based configuration of network nodes. Edge nodes can all share the same base
configuration template and dynamically adjust the service configurations on the fly.
3.4 Edge-only service provisioning

Whether statically or dynamically instantiated, SPB services need only be provisioned on edge
nodes, not on core nodes. Core nodes are effectively isolated from service Moves, Adds and
Changes and require no touch while these activities are performed. In fact, service MACs can
be conducted during business hours and do not require a maintenance window to be scheduled,
reducing time-to-service.
3.5 Micro-segmentation
Firewalls filter and control communication between different VPN “tenants” or “containers”.
But, how do you secure communication within the same VPN? For instance, if one device were
compromised, how do you prevent lateral movement to other resources within the same VPN?
When users/devices are dynamically bound to a service, they are also mapped to a User Network
Profile (UNP). The UNP is a set of Access Control Lists (ACLs) and Quality of Service (QoS) policies
which are applied to the device/user according to the device category or user role. Let’s take
CCTV cameras as an example: ACLs contained in the UNP can allow communication between
the camera and surveillance servers but at the same time block camera-to-camera communication,
preventing the spread of malware, “pivoting” and other hacking techniques which rely on
lateral movement.
Tech Brief
Figure 4. Micro-segmentation
Audio/visual profile
Authenticate ✓ Container
Classify ✓ Quality
Auto provision ✓ Security
Campus operation profile
Security profile
3.6 Non-IP core

Even when providing L3 services to IP packets, SPB core nodes do not route traffic, they bridge
it. In fact, SPB core nodes do not have IP addresses and the IS-IS control protocol, unlike OSPF
and BGP, does not run on top of IP. This makes the network core inherently more secure and
protects it from IP-based attacks such as scanning, spoofing, DoS and others. Of course, SPB
nodes still need an IP address for management purposes, but the management IP interface is
isolated in its own service and VRF, not in-line with user traffic.
4. The Data Plane: IEEE 802.1ah Provider backbone bridging

The Data Plane’s (DP) mission is to forward user traffic between different ports. The DP makes
no decisions as to what port a frame should be forwarded to. It simply performs lookups on
the Forwarding Data Base (FDB). FDB entries indicate what port, or group of ports, each frame
should be forwarded to and what encapsulation to use. Building, or populating entries in the
FDB, is a function of the Control Plane (CP), which is discussed in the next section.
The SPB data plane utilizes IEEE 802.1ah Provider Backbone Bridging (PBB), aka MAC-in-MAC,
encapsulation. The PBB header includes de following fields:
B-VID: Or Backbone VLAN (BVLAN) ID. A VLAN that serves as a transport VLAN for the SPB
service instances and to connect SPB bridges together through SPT sets. Unlike the standard
VLAN domain which uses “flood and learn” or source learning in the DP to populate the FDB,
the BVLAN domain’s FDB is pre-populated by the CP.
ISID: Service Instance Identifier. The ISID is a 24-bit number that designates the service instance,
tenant, container or VPN. Different SPB services are assigned different ISIDs and isolated from
one another. Each SPB service or ISID is bound to a BVLAN.
B-SA and B-DA: Or Backbone source and destination MAC addresses. The MAC addresses associated
with SPB nodes (BMACs). Within the SPB backbone, traffic is forwarded based on the destination
BMAC (B-DA). Inner customer MACs are not learnt or used for forwarding within the backbone.
Tech Brief
Ethertype: 0x88E7
Upon entering the SPB domain, the PBB header is wrapped around the incoming frame which
can be un-tagged, single-tagged (IEEE 802.1q) or double-tagged (IEEE 802.1ad). Figure 5
illustrates the case of a double-tagged (Q-in-Q) frame. Note that MAC and BMAC addresses
are shortened to 2 bytes for simplicity in this diagram.
Figure 5. PBB Data Plane
Payload
Ethertype (IP)
C-VID
Ethertype 802.1q
S-VID
Ethertype 802.1ad
Payload 00:01 Payload
Ethertype (IP) 00:02 Ethertype (IP)

Payload Payload
C-VID I-SID C-VID
Ethertype (IP) Ethertype 802.1q Ethertype 802.1ah Ethertype 802.1q Ethertype (IP)
C-VID S-VID B-VID S-VID C-VID
Ethertype 802.1q Ethertype 802.1ad Ethertype 802.1ad Ethertype 802.1ad Ethertype 802.1q
00:01 00:01 00:0A 00:01 00:01
00:02 00:02 00:0B 00:02 00:02
MAC :00:01 MAC :00:0A MAC :00:0B MAC :00:02
Customer Provider bridge Provider backbone Provider bridge Customer

network network bridge network network network
Let’s define a few key terms.
BEB: An SPB switch positioned at the edge of the PBB network that learns and encapsulates
(adds an 802.1ah backbone header to) “customer” frames for transport across the backbone
network. The BEB interconnects the customer network space with PBB network space.
BCB: An SPB node that resides inside the PBB network core. The BCB employs the same BVLAN
on two or more network ports. This BVLAN does not terminate on the switch itself; traffic
received on an SPB network port is switched to other SPB network ports. As a result, the BCB
does not have to learn any of the customer MAC addresses. It mainly serves as a transit bridge
for the PBB network.
Within the SPB domain, that is, between BEB and BCB nodes, frame forwarding depends entirely
on the outer PBB 802.1ah header (BMAC and BVLAN) and not on the inner header or “customer”
MAC addresses (CMAC). In fact, the SPB backbone nodes do not learn CMACs and this makes
SPB networks more scalable and stable (CMACs are not learnt and therefore do not need to be
flushed and re-learnt when they change or move).
The DP implements an additional loop mitigation mechanism by which a node will not accept
unexpected frames from their neighbours. This additional loop mitigation mechanism is faster
during topology changes. In summary, SPB implements two loop avoidance mechanisms: loop
prevention and loop mitigation.
Tech Brief
5. The Control Plane: RFC 6329 IS-IS Equal-cost trees
As stated earlier, the role of the CP is to populate the FDB tables used by the DP. SPB uses IS-IS,
or Intermediate System to Intermediate System (ISO/IEC 10589:2002); a well-known, proven
and widely-deployed protocol, particularly in service-provider backbones. IS-IS is responsible
for topology and service discovery. IS-IS is an extensible link-state protocol which implements
Dijkstra’s Shortest Path algorithm for path computation. IS-IS extensions for SPB are described
in RFC 6329 and include a new Network Layer Protocol Identifier (NLPID), as well as a set of
Type-Length-Values (TLVs). In a nutshell, these extensions add support for multiple topologies,
allowing load sharing over multiple equal-cost paths, and service-membership discovery, or in
other words: Communicating what services are enabled on each SPB node.
Figure 6. RFC 6329 IS-IS extensions
New! SPB extensions NLPI, TLVs, PDUs

SPB-ISIS
Existing! Discovery and computation Discovery – Hello and LSP packets, Computation – SPF and SPT
Unlike STP which creates a single tree rooted at the root bridge, in SPB networks, every node
builds a topology tree rooted on itself. This is the key reason why, in an SPB network, traffic
between any pair of nodes always travels along the shortest path. When using STP, traffic
between two nodes does not necessarily travel over the shortest path unless one of the two
nodes involved is the root bridge. This is illustrated in figure 7 in which B1 is the root bridge.
Traffic between nodes B5 and B2 for instance, none of which is the root bridge, cannot use the
direct single-hop path because that link is disabled by STP. Traffic between these two nodes
must take a 3-hop detour traversing the root bridge.
Figure 7. Multiple trees
Spanning Tree SPB

Single root bridge Every bridge is the root
B2 B2
B1 B5 B1 B5
B3 B3
B4 B4
Path B5 to B2 = B5 – B3 – B1 – B2 Path B5 to B2 = B5 – B2
In contrast, when using SPB, no link is disabled: each node is the root of its own tree. Nodes B2
and B5 can simply communicate over the direct single-hop path while at the same time they can
communicate with other nodes over different paths (for example; between B4 and B5). SPB’s
support for multiple trees and multiple active paths unlocks utilization of bandwidth in optimal
paths that would otherwise be wasted, increasing throughput and reducing latency.
An SPB network supports up to 16 BVLANs and each node builds a SPF tree for each BVLAN.
Load balancing is accomplished by mapping different tenant services (ISIDs) to different BVLANs.
Service traffic between any node pair uses a single path and this path only changes if the
topology changes, for instance, on node or link failure and subsequent path re-computation. In
other words: SPB networks do not balance loads on a packet-by-packet basis like IP networks
do. Provided the physical topology supports multiple shortest paths (same cost and same hop
Tech Brief
count) between two nodes, different BVLANs can build different trees and services mapped to
those BVLANs can use different paths. And, those paths will remain the same for as long as the
topology remains the same. An important property of SPB networks is that network paths are
deterministic and frames are delivered in the order they were sent. This property is important
for certain applications such as storage and real-time application traffic.
Figure 8. One tree per node and per BVLAN
B1’s tree on BVLAN A B1’s tree on BVLAN B B1’s tree on BVLAN C

B2 B2 B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
B5’s tree on BVLAN A B5’s tree on BVLAN B B5’s tree on BVLAN C

B2 B2 B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
The trees shown in figure 8 are SPB’s equal-cost trees (ECTs). Each node builds a tree per
BVLAN and the cost to reach other nodes is the same across all BVLANs. The ECT-ID is a number
assigned to each BVLAN at the time of BVLAN creation and is used for tie breaking during path
computation. Assigning different ECT-IDs to different BVLANs helps those BVLANs build different
trees, provided the underlying topology supports multiple equal-cost, or shortest paths.
Another important property of SPB networks is path symmetry. If you closely examine the
picture above, you will notice that the path from node X to node Y is identical to the path from
node Y to node X. Path symmetry is key to Operations and Maintenance (OAM). For instance,
one-way delay calculations can be easily derived from roundtrip delay measurements. Note
that this is not the case for other IP-based technologies such as MPLS in which the reverse
path may differ.
Tech Brief
Figure 9. Symmetric paths, per-BVLAN load balancing
B1 <–> B5 path BVLAN A B1 <–> B5 path BVLAN B B1 <–> B5 path BVLAN C
B2 B2 B2
B1 B3 B5 B1 B3 B5 B1 B3 B5
B4 B4 B4
The result of IS-IS path computation for each BVLAN and node is the FDB which is used by the
data plane for frame forwarding. Figure 10 shows BEB5’s unicast FDB. The multicast FDB will
be discussed in Section 7.
Figure 10. B5’s Unicast FDB
BVID Node Outbound port
B2 BVID A B1 Port 1
BVID B B1 Port 2
BVID C B1 Port 3
BVID A B2 Port 1
B1 B3 B5
BVID B B2 Port 1
BVID C B2 Port 1
BVID A B3 Port 2
BVID B B3 Port 2
BVID C B3 Port 2
BVID A B4 Port 3
B4
BVID B B4 Port 3
BVID C B4 Port 3
6. The service framework

An SPB service represents a VPN, or tenant, and is uniquely identified by its service identifier,
the ISID. An SPB service needs only be created, or instantiated, on BEB nodes, not on BCB
nodes, and only on those BEB nodes servicing locations associated to the service. SPB service
membership information is shared across the SPB backbone by way of IS-IS TLVs such that all
SPB nodes have a consistent view of the services which are active on each BEB. Each node
then builds a service database.
Figure 11. The service database
ISID 66
B2
ISID BVID Node

66 BVID A B1
B1 B5
B3 66 BVID A B2
66 BVID A B4
66 BVID A B5
ISID 66 ISID 66
77 BVID B B1
ISID 77 ISID 77
77 BVID B B5
B4
ISID 66
Tech Brief
In each BEB node there are two kinds of virtual ports:
Service Access Point: The SAP is a UNI-side logical port which binds a physical port and specific
customer traffic types (untagged, single-tagged, double-tagged or all) to an SPB service. Multiple
SAPs can be associated to the same physical port thus multiplexing and mapping different
customer traffic encapsulations to different SPB services.
Service Distribution Point: The SDP is an NNI-side logical port which binds an SPB service to
a far-end BEB on which the service is instantiated. SDPs are dynamically created in the CP and
only for those far-end BEBs with SAPs for the specific service.
Let’s look at figure 12. In this diagram, B5 terminates 2 SPB services: One is associated to
ISID 66 and the other to ISID 77. There are two SAP ports, one for each service. SAP 1:1 is
defined on port 1, matches traffic tagged with VLAN 1, and binds it to service 66. SAP 2:2
is defined on port 2, matches traffic tagged with VLAN 2, and binds it to ISID 77.
ISID 66 is also enabled on nodes B1, B2 and B4 while ISID 77 is also enabled on node B1.
Figure 12. The service framework
ISID 66 Identifier BVID Node

B2 SAP 1:1 — —
SAP 2:2 — —
SD
P SDP 32769: 66 BVID A B1
Y:
66
B1 B5 SDP 32768: 66 BVID A B2
SDP X:66 SAP 1:1
SDP 32767: 66 BVID A B4
SDP X:77 SAP 2:2
SDP 32766: 77 BVID B B1
66
Z:
ISID 66 ISID 66
P
SD
ISID 77 ISID 77
B4
ISID 66
It should be noted that while BMAC address learning is performed in the CP (for example; not
through “flood and learn”) CMAC address learning is performed in the BEB’s DP through flood
and learn. Near-end CMACs are bound to SAP ports and far-end CMACs are bound to SDP ports.
BCB nodes have neither SAP nor SDP ports and therefore do not learn any CMACs.
Let’s expand this example by adding some end customer sites and CMACs associated to those
customers. We will keep using 2-byte MAC addresses for simplicity. In figure 13, near-end CMAC
addresses are bound to SAP ports while far-end CMAC addresses are bound to SDP ports. Within
the service domain, a BEB performs CMAC source address learning like a standard Ethernet
switch, except there is no “flooding” of BUM traffic. BUM traffic is discussed in the next section.
Figure 13. Customer MAC address learning
ISID 66
B2
MAC B:B Identifier ISID CMAC

MAC C:C SD MAC A:A
P SAP 1:1 66 A:A
Y:
66
B1 B5 SAP 2:2 77 E:E
SDP X:66 SDP 1:1
SDP 32769: 66 66 C:C
SDP X:77 SDP 2:2
SDP 32768: 66 66 B:B
66
SDP 32767: 66 66 D:D

Z:
ISID 66 ISID 66 MAC E:E

P
MAC G:G
SD
SDP 32766: 77 77 G:G

ISID 77 ISID 77
B4
ISID 66
MAC D:D
Tech Brief
7. BUM traffic
SPB supports 3 BUM (broadcast, unknown unicast, and multicast) traffic replication and
forwarding methods:
Head-end: In this mode, BUM traffic received on a SAP port is replicated at the ingress BEB and
converted to multiple unicast frames: A replica is created for every other BEB in the same ISID
and these replicas have the BEB BMACs as the B-DA and are forwarded using the unicast FDB.
For this reason, Head-End replication can be inefficient in terms of bandwidth consumption but
is efficient in terms of resource usage because it does not require a separate tree. However,
Head-end replication can be optimal in some circumstances, particularly when combined with
IGMP Snooping. Head-end replicated BUM traffic simply uses the unicast FDB and therefore
travels along the same path. This property is known as congruency.
Figure 14. Head-end BUM replication
BCB2 BEB3
ISID 77 Type B-MAC Port BVID

U 00:02 Port 2 BVID B
BEB1 BCB7 BEB4 U 00:03 Port 7 BVID B
ISID 77 ISID 77 U 00:04 Port 7 BVID B

ISID 77
BCB6 BCB5
Tandem (S,G): In this mode, a separate multicast SPT and FDB are created. The multicast SPT is also
congruent with the unicast SPT however the B-DAs in the multicast FDB are multicast addresses
constructed as a combination of ISID and source BEB BMAC. When a BUM frame is received on a
BEB, it is MAC-in-MAC encapsulated with this special BMAC as the B-DA and forwarded according
to the multicast FDB. A B node can use the unicast FDB to check if it is in the SPT between a source
BEB and other BEBs in the same ISID. If the B node happens to be in the SPT, it will populate the
multicast FDB such that the frame is replicated and forwarded as needed, to other BEBs connecting
the same service (ISID). Tandem Replication is very efficient in terms of bandwidth use because it
will only send a single replica on any given link; however, it is less efficient in terms of resource
use because it requires an additional SPT and multicast FDB per ISID.
Figure 15. Tandem (S,G) BUM replication
Type B-MAC Port BVID Out Intf

BCB2 BEB3
ISID 77 U 00:02 Port 2 BVID B
BEB1 BCB7 BEB4 U 00:04 Port 4 BVID B
ISID 77 ISID 77 U 00:05 Port 5 BVID B

M 00:0W Port 1 BVID B Port 3/4/5
M 00:0X Port 3 BVID B Port 1/5
ISID 77
M 00:0Y Port 4 BVID B Port 1
BCB6 BCB5 M 00:0Z Port 5 BVID B Port 1/3
Tech Brief
Tandem (*,G): In this mode, a separate multicast tree is created. This tree is not a Shortest Path
tree and is not congruent with the unicast SPT. A multicast (*,G) is created for every BVLAN using
Tandem (*,G) multicast replication. This (*,G) tree is similar to a Spanning Tree and is rooted at one
B node according to the bridge priority. In this mode, there is a single tree for the BVLAN and not
one tree for every node. Therefore, traffic will not generally follow the shortest path. This mode
is a compromise between bandwidth and resource usage, however, it can be a good option when
all traffic is sourced or destined towards the root bridge.
Refer to Table 1 to compare these three modes.
Table 1. Multicast replication modes and suggested uses
Head-end Tandem (S,G) Tandem (*,G)

Operation BUM traffic replicated at BUM traffic forwarded per the BUM traffic forwarded using
ingress BEB and forwarded multicast FDB and replicated a shared, non-SP tree and
using the unicast FDB. as needed at the SPT’s fork-out replicated at fork-out points.
points.
Bandwidth efficiency Low High High
Resource efficiency High Low Medium
Congruency Yes Yes No
Suggested use • Low multicast bandwidth • High multicast bandwidth • When root bridge is
• Many sources and few • Few sources and many receivers source or receiver of
receivers* most multicast traffic
and congruency is not
required
• When required to inter-
operate with third-party
equipment
* When combined with IGMP Snooping.
8. Creating an SPB backbone

In this section, we provide a sample SPB Backbone configuration and refer to figure 16 as
a sample topology. We will continue using this sample topology throughout the rest of this
document. Nodes BEB-1 through BEB-4 are called “BEB” nodes because we will add services
to these nodes later. Node BCB will remain a pure transit node and not terminate any service.
If you observe this topology, you will notice that it provides up to 3 shortest paths, for example,
between nodes BEB-1 and BEB-3, or between nodes BEB-2 and BEB-4. To take advantage of
those 3 diverse paths for traffic load balancing, we need to create a minimum of 3 BVLANs. In
this example, we will however, dedicate one BVLAN purely for control traffic and therefore we
will create a total of 4 BVLANs. However, it should be noted that this is not strictly necessary,
the control BVLAN can also be used for services.
Backbone configuration entails the following tasks:

• Creating one or more BVLANs with their associated ECT-IDs. ECT-IDs need not be explicitly
defined, default ECT-IDs are applied
• Defining the control BVLAN
• Defining one or more SPB IS-IS interfaces
• Enabling the SPB IS-IS protocol
Tech Brief
Figure 16. Sample backbone topology
BEB2
1/
A 1/
49 50
1/ A
1/
1/1/54A
A 1/
BEB1 49 1/1/50A 1/
49 BEB3
1/
1/ A
1/1/54A 1/1/49A 1/1/52A 1/1/54A
1/
BCB
1/ A
50 1/1/53A 49
1/
A 1/
1/1/54A
1/ A
1/ 49
50 1/
A 1/
BEB4
Following are the configuration snippets for all nodes.
Snippet 1. BEB-1’s backbone configuration
Tech Brief
Snippet 5. BCB backbone configuration
Through this configuration, VLANs 4000 through 4003 are defined as SPB backbone VLANs and
will therefore not use any form of spanning tree protocol. AOS automatically assigns a different
ECT-ID to each BVLAN and this maximises the chance that different BVLANs will create different
SPTs, up to the maximum number of shortest paths supported by the physical topology. Nodes
will exchange IS-IS “Hello” messages over the control BVLAN (such as, 4000 in this example) and
form point-to-point adjacencies. LSPs are exchanged, a topology database is created and one SPT
is built for each BVLAN.
Let’s review this configuration with some show commands.
Snippet 6. “show SPB isis interface”
In the “show spb isis interface” command output we can observe three interfaces are SPB-IS-
IS enabled for L1 adjacencies. All three interfaces are both administratively and operationally
up. By default, the link metric is 10 regardless of link speed. “Hello” messages are sent at nine
second intervals and adjacencies are declared lost if no “Hello” message is received for three
consecutive intervals (for example; 27 seconds).
Snippet 7. “show SPB isis nodes”
In the “show spb isis nodes” command output we can observe all discovered SPB IS-IS nodes
including the local node. For each node, we can see the system or host name, the system ID
(the BMAC), as well as the source ID and the bridge priority. The source ID is a 20-bit identifier
which designates the node as the origin of BUM traffic and is derived from the system ID’s least
significant bytes. The source ID is relevant when using tandem BUM replication. The bridge
priority is 16-bit identifier and is used as a tie breaker during path computation.
Tech Brief
Snippet 8. “show SPB isis adjacency”
In the “show spb isis adjacency” command output we can observe all SPB IS-IS adjacencies
established by the local node. For each adjacency, we can see the system or host name,
the system ID (the BMAC), as well as type (always L1 for SPB IS-IS), the state, the hold timer
(number of seconds until the adjacency is declared lost if no “Hello” messages are received)
and the interface over which the adjacency is formed.
Snippet 9. “show SPB isis bvlans”
In the “show spb isis bvlans” command output we can observe, for each configured BVLAN, the
ECT algorithm in use and whether the BVLAN is in use and has services mapped to it. So far, we
have not configured any service, therefore the only BVLAN in use is the control BVLAN, which is
used for IS-IS CP messaging. We can also observe the number of ISIDs mapped to the BVLAN. For
services using tandem BUM replication, we can observe whether this is (S,G), which is the default,
or (*,G). Note that while the choice of head-end versus tandem replication is done on a per-service
basis, the choice between (S,G) and (*,G) tandem replication is done on a per-BVLAN basis. Lastly,
the root bridge BMAC is shown only for those BVLANs using (*,G) tandem replication.
Snippet 10. “show SPB isis unicast-table”
Tech Brief
In the “show spb isis unicast-table” command output we can observe, for each node, the
outbound interface used when sending unicast traffic to that node. Note that the outbound
interface can be different for different BVLANs because different BVLANs can build different
SPTs. For example, the path to BEB-3 goes through interface 1/1/49A in the case of BVLAN
4000, interface 1/1/54A in the case of BVLANs 40001 and 4002, and interface 1/1/50A in the
case of BVLAN 4003.
Snippet 11. “show SPB isis spf bvlan”
In the “show spb isis spb bvlan” command output we can observe, for a given BVLAN, the
outbound interface, the next hop node, as well as the SPB metric and total number of hops
required to reach a destination node. We can observe in this output that traffic destined towards
BEB-3 will transit BEB-2 in the case of BVLAN 4000, BCB in the case of BVLANs 4001 and 4002,
and BEB-4 in the case of BVLAN 4003.
9. L2 services
A L2 service refers to a type of VPN service connecting multiple sites in a single any-to-any
bridging domain. In this section, we continue building upon the previous example and create a
L2 service on top of the previously created backbone configuration.
Services need only be created on BEBs, not on BCBs, and only on those BEBs where the service
needs to be delivered. Creating an SPB service entails the following tasks:
• Creating a service and associating the service to an IS-IS and BVLAN – the specified BVLAN’s
SPF will be used for the service traffic
• Defining a Service Access Port (SAP)
• Defining SAPs matching specific customer traffic
Tech Brief
Figure 17. L2 service
Site 2
1/1/48
BEB2
BEB1 BEB3
1/1/48 1/1/54A 1/1/48
ISID 1001
BVLAN 4001
Site 1 Site 3
BEB4
1/1/48
Site 4
With regard to figure 17, we provide BEB configurations in the snippets that follow.
As well, please note:
• The service number is only locally significant and can differ across different BEBs
• The ISID number is globally significant and must match across all BEBs connecting
a given service
• The BVLAN that the service is mapped must also match across all BEBs connecting
a given service
• Different services can be mapped to different BVLANs to achieve traffic load balancing
Snippet 12. BEB-1’s service configuration
Tech Brief
In the four configuration snippets above we can observe the following:
• Service 1 is associated to ISID 1001 and mapped to BVLAN 4001’s SPF tree
• Port 1/1/48 is defined as a SAP
• A SAP is defined on port 1/1/48 mapping untagged traffic (:0) to service 1
Let’s now proceed to verify the service status.
Snippet 16. “show service spb” – BEB view
In the “show service spb” command output we can observe, for a given BEB, the locally defined
SPB services, their administrative and operational status, the number of (local) SAPs and (remote)
SDPs along with the ISID and BVLAN number that the service is mapped to. We can also observe
the multicast replication mode, which is head-end by default. The multicast replication mode can
be changed to tandem on a per-service basis.
Snippet 17. “show service spb” – BCB view
In the “show service spb” command output we can observe that, by definition, a BCB does not
have locally defined services.
Snippet 18. “show spb isis services” – BEB view
In the “show spb isis services” command output we can observe SPB services known to the node
along with their ISID and BVLAN number and the node name, and BMACs that the service is
enabled on. We should note that these services are learnt thanks to the IS-IS CP. A “*” denotes
that the service also matches a service locally created on the BEB.
Tech Brief
Snippet 19. “show spb isis services” – BCB view
In the “show spb isis services” command output we can observe the same output now from the
perspective of a BCB. We should note that a BCB is still aware of all existing services with the
IS-IS CP.
Snippet 20. “show service spb”
The “show service spb” command output provides some additional details about a given SPB
service. We can highlight the following:
• RemoveIngressTag: As explained in section 3, by default, a PBB frame includes all the frame’s
original tags. However, we can choose to remove those tags with the “service service_id
remove-ingress-tag enable” command.
• VLAN Translation: A given service may require different encapsulations on different SAPs.
For instance, a server may tag traffic with a specific VLAN while client devices may require
untagged SAPs. In such situation, VLAN translation can be enabled to allow both devices
to communicate. We should note that VLAN translation must be enabled both at service
level with the command “service service_id vlan-translation enable” and on the SAP with
the command “service access port vlan-xlation enable”.
• Allocation Type: Services can be either statically or dynamically created. We will cover
dynamic service creation in section 13.3.
Snippet 21. “show service access”
Tech Brief
In the “show service access” command output we can observe, for a given BEB, the list of SAPs
along with their type (manual or dynamic), the number of defined SAPs and whether VLAN
translation is enabled or not. We will cover dynamic SAP creation in section 12.2. We can also
observe the L2Profile assigned to the SAP. The L2Profile defines how L2 control protocol frames
received on a SAP will be handled. Traffic can be peered, dropped, or tunnelled. Default L2
profile settings are shown in Table 2. Additional L2 profiles can be created with the command
“service l2profile name stp action 802.1x action 802.3ad action mvrp action gvrp action amap
action 802.1ab action” and assigned to the SAP with the command “service access l2profile
name”. We will cover unp SAPs and profiles in section 12.2.
Table 2. Default L2 profiles
Protocol def-access-profile unp-def-access-profile

STP tunnel drop
802.1x drop peer
802.3ad peer peer
MVRP tunnel tunnel
GVRP tunnel tunnel
AMAP drop drop
802.1ab drop drop
Snippet 22. “show service spb ports”
In the “show service spb ports” command output, we can observe local (SAP) as well remote
(SDP) ports for a given service. For each port, we can see administrative and operational status,
the system ID (BMAC) and BVLAN, as well as the system name and associated local interface. SDP
ports will always display a “*” next to them because SDP ports are always dynamically created
by the IS-IS CP. The name of an SDP is a combination of a dynamically generated number,
followed by a colon and the service number.
Tech Brief
Snippet 23. “show service mesh-sdp spb”
In the “show service mesh-sdp spb” command output we can observe far-end SDPs for each
service along with the ISID number and the far-end system ID (BMAC), BVLAN, system name
and associated interface.
Snippet 24. “show mac-learning domain spb” – BEB view
In the “show mac-learning domain spb” command output we can observe the list of CMAC
addresses learnt in the SPB domain along with the service number and ISID, as well as the
interface (SAP or SDP) port that the CMAC address is bound to.
Snippet 25. “show mac-learning domain spb” – BCB view
In the “show mac-learning domain spb” command output we can observe the same output now
from the point of view of a BCB node. As expected, BCB nodes do not learn any CMACs.
Tech Brief
10. Routing concepts
Before delving into L3 services, which are covered in the next section, we need to discuss certain
routing concepts in relation to SPB. The Alcatel-Lucent OmniSwitch® product line has supported
SPB since AOS 7.3.1, released in 2012. Since then, multiple SPB-enabled platforms have been
launched and each new platform incorporated new advancements in ASICs.
First generation ASICs were not capable of routing and performing MAC-in-MAC encapsulation in
a single-pass operation. Consequently, routing between IP interfaces associated to two different
SPB services, or to a VLAN and an SPB service, had to traverse the switch fabric twice. This
required an external physical loopback connecting two different switch ports: one port in the
VLAN domain and another SAP in the SPB domain. IP interfaces could only be associated to a
VLAN, not directly to an SPB service. It should be noted that these physical loopbacks can be
either physical ports or linkaggs. When using VC, linkagg member ports can span different units
in the VC for redundancy. We refer to this as two-pass routing with external physical loopback.
Newer generation ASICs support a concept similar to an external physical loopback without
requiring a cable connection. One or more physical ports’ bandwidth is dedicated to the
loopback function without requiring a cable to be attached. Multiple ports can be dedicated to
this function for additional bandwidth and redundancy. When using multiple ports, ports are
configured as a linkagg and, when using VC, linkagg member ports can span different units in
the VC. We refer to this as two-pass routing with internal front-panel loopback. One additional
difference between the internal front-panel loopback and the external physical loopback
described in the previous paragraph is that the internal front-panel loopback is a single logical
port, not two ports (a VLAN port and a SAP) as in the case of the external physical loopback.
However, even in the single logical port, there is a “VLAN” function and a “SAP” function. This
will become clearer when looking at the configuration snippets later in this section.
Latest generation ASICs support integrated routing and bridging in the SPB domain in the exact
same manner as in the VLAN domain. This means that IP interfaces can be associated to an
SPB service directly and traffic can be routed between two SPB services or between a VLAN
and an SPB service in a single-pass operation without loopbacks. We refer to this as single-pass
inline routing.
Figure 18. Routing options – Physical view
Single-pass Two-pass with external Two-pass with internal

or inline physical loopback physical loopback
VLAN 11
VLAN 11
ISID 1 VLAN + SAP

VLAN port SAP port all in one
1/1/1 1/1/2 port or LAG
ISID 2 ISID 1 ISID 1

VLAN 1 VLAN 1
VLAN 1
Figure 18 provides a physical view of these routing options. The leftmost diagram represents a
switch supporting single-pass inline routing. This example shows a bridge with 2 SPB services,
designated by their ISIDs, and one VLAN. IP interfaces are represented by dots. As we can see,
the IP interfaces are bound to either VLANs or services and the switch performs inter-VLAN,
inter-Service or inter-VLAN-Service routing directly in a single operation.
Tech Brief
The diagram in the middle illustrates the case of two-pass routing with a physical hairpin. In this
diagram, you can observe that IP interfaces are bound to VLAN 1 and VLAN 11, but not directly
to the service. The external physical loopback cable creates the link between the service and the
“dummy” VLAN, VLAN 11 in this example, where the IP interface resides. This external physical
loopback is configured with a SAP-side, where SAPs are defined for each service requiring
routing, and a VLAN-side, where dummy VLANs mapping to those services are tagged.
The right diagram illustrates the case of two-pass routing with internal front-panel loopback.
In this diagram, the dotted line represents an imaginary physical external loopback, which is
not required. In addition to not requiring an external physical loopback cable, the front-panel
loopback requires a minimum of one port only. CLI configuration is different between physical
external loopback and front-panel internal loopback. However, the concepts are very similar.
You should still think about the front-panel internal loopback port or ports as having a SAP
function and a VLAN function all in one port or linkagg.
Figure 19. Routing Options - Logical view
Single-pass Two-pass with external Two-pass with internal

or inline physical loopback physical loopback
VLAN 11
11
VLAN 1
VLAN 1
VLAN
ISID 1 VLAN + SAP
VLAN port SAP port all in one port
ISID 2 ISID 1 ISID 1

VLAN 1 VLAN 1
VLAN 1
Figure 19 provides a logical representation of these options. The left diagram represents the
case of single-pass or inline routing. In these products, routing and bridging functions are fully
integrated in the service domain in the exact same manner as they are integrated in the VLAN
domain. For this reason, these products are represented with a router icon.
The diagram in the middle represents the case of two-pass routing with an external physical
loopback. In these products, routing and bridging functions are separate and represented by
router and bridge icons. You can observe that the router function, where dots representing IP
interfaces exist, connects to the bridge function using a VLAN port and a SAP.
The right diagram illustrates the case of two-pass routing with internal front-panel loopback.
As you can see, this case is almost the same to the case of two-pass routing with an external
physical loopback from a logical standpoint. However, the routing function attaches to the
bridging function using a single port or group of ports. This front-panel loopback port or group
of ports still performs a SAP function and a VLAN function. In addition, this connection between
routing and bridging functions is created internally in the switch ASIC and does not require an
external cable.
Let’s review some configuration examples to commit these concepts.
Snippet 26. Single-pass or inline routing example
Tech Brief
The configuration snippet 26 shows that, in products supporting single-pass or inline routing,
IP interfaces can be bound to services just like they can be bound to VLANs. The switch simply
performs routing in the same domain (VLAN or Service) or between different domains (VLAN
and Service). Note that the backbone and service configuration is not shown in this example.
Snippet 27. Two-pass routing with external physical loopback example
The configuration snippet 27 shows the equivalent configuration for products supporting two-
pass routing with external physical loopback. Since IP interfaces cannot be bound to a service
directly, we create 2 additional “dummy” VLANs to bind these interfaces to. VLAN 11 will be
associated to service 1 and VLAN 12 will be associated to service 2. The external physical
loopback uses port 1/1/1 as VLAN port and port 1/1/2 as SAP. When creating the IP interfaces
bound to those dummy VLANs, we use the rtr-port option. This prevents those VLANs from
being bound to other ports and disables STP on those VLANs. Note that as explained previously,
linkaggs can be used instead of single ports and linkagg member ports can span diverse units in
a VC for redundancy.
Snippet 28. Two-pass routing with internal front-panel loopback example
The configuration snippet 28 shows the equivalent configuration for products supporting two-
pass routing with internal front-panel loopback. Firstly, port 1/1/51A is designated as the front-
panel loopback port. Dummy VLANs are created and SAPs linking those dummy VLANs to their
associated services are defined on the loopback port. When creating the IP interfaces bound
to the dummy VLANs, we use the rtr-port option and reference the loopback port. Once again,
the example shows the case of single front-panel loopback port but linkaggs can be used for
additional bandwidth and resiliency in the case of VC.
Tech Brief
11. L3 services
A L3 service refers to a type of VPN service connecting multiple sites in a single any-to-any
routing domain. Different sites utilize different subnets and require routing to communicate.
For multi-tenancy, and to keep different customers isolated at L3, each customer service is
associated to its own VRF instance.
Figure 20. Customer A’s L3 service
BEB1 BEB2
10.0.1.0/24 10.0.2.0/24
.254 .254
.1 .2
Site 1 Site 2
10.0.0.0/24
SPB Service A
VRF A
10.0.3.0/24 10.0.4.0/24
.254 .254
.3 .4
Site 3 Site 4
BEB3 BEB4
Figure 20 illustrates an example of a L3 Service connecting four of customer A’s sites: Sites 1 through
4. You will notice that each site uses a different subnet and therefore, inter-site routing is required.
BEB nodes connecting customer sites are represented with router icons for simplicity. These BEBs
have a “LAN”-facing interface which acts as the local site default gateway, as well as a “WAN”-facing
interface to reach remote sites. All “WAN” interfaces are bound to a single SPB service and are on the
same “WAN” subnet. Lastly, all the LAN and WAN IP interfaces associated to customer A are bound
to the same customer A VRF to provide L3 isolation between different customers.
SPB-based L3 VPN services rely on edge routing: Routing is only performed at ingress and egress
BEBs and bridged between these. At L3, the WAN represents a single L3 hop regardless of the
number of intermediate L2 hops (BCBs) in between. SPB simply bridges traffic from ingress BEB
to egress BEB along the shortest path.
Up to this point, we have only described the DP. What about the CP? At the CP level, L3 VPN
services come in two variants: VPN Lite and L3 VPN. Let’s elaborate on these two variants.
11.1 VPN Lite

A VPN Lite L3 Service is created by overlaying a L3 routing protocol on top of the L2 WAN SPB
service. This routing protocol can be OSPF, BGP, or even static routing. The routing protocol runs
inside the customer’s VRF and a separate instance and associated configuration is created for
each customer. Figure 21 shows an example of how customer A’s L3 service can be created
as a VPN Lite service by running OSPF on BEB nodes.
Figure 21. Customer A’s VPN Lite service
BEB1 BEB2
10.0.1.0/24 10.0.2.0/24
.254 .254
.1 .2
Site 1 Site 2
SPB Service A
VRF A
OSPF area 0
10.0.0.0/24
10.0.3.0/24 10.0.4.0/24
.254 .254
.3 .4
Site 3 Site 4
BEB3 BEB4
Tech Brief
We should highlight that, in a VPN Lite type of L3 service, the L2 SPB service simply provides
L2 connectivity to the “WAN” IP interfaces. Continuing with OSPF as an example, this means that
OSPF is configured as usual. Also, since all WAN IP interfaces are connected to a single L2 SPB
service, in the case of OSPF, a DR/BDR election will take place as usual.
11.2 L3 VPN
SPB L3 VPN leverages the existing SPB IS-IS instance to carry customer VPN routes without
requiring an additional routing protocol such as OSPF. This is accomplished with additional
IS-IS TLVs extensions. We should note that each customer or tenant is still associated to its
own VRF and IS-IS TLVs reference the customer’s ISID to preserve L3 isolation between different
customers or tenants. This mechanism is described in an IETF draft [1]. Refer to figure 22.
For those familiar with MPLS or EVPN, those technologies rely on an IGP (for example; OSPF or
IS-IS) for backbone node reachability, and MP-BGP (RFC 4760) for customer VPN route transport.
In SPB L3 VPN, IS-IS can play both of those roles; backbone node reachability and customer VPN
route transport. Using a single protocol instead of two, results in a network that is simpler to
deploy and operate.
In addition, when comparing SPB and MPLS, SPB BEB nodes play a role similar to MPLS PE nodes
while SPB BCB nodes are similar to MPLS P nodes. In particular, SPB BCB nodes do not learn any
customer VPN routes and require no VRFs to be created on them. VRFs need only be created on
BEB nodes and customer VPN routes are only learnt on the BEBs that those customers connect to.
Figure 22. Customer A’s L3 VPN service
BEB1 BEB2
10.0.1.0/24 10.0.2.0/24
.254 .254
.1 .2
Site 1 Site 2
SPB Service A
VRF A
SPB IS-IS
10.0.0.0/24
10.0.3.0/24 10.0.4.0/24
.254 .254
.3 .4
Site 3 Site 4
BEB3 BEB4
Unlike the case of a VPN Lite, an SPB L3 VPN does not require the addition of any routing
protocol. Customer’s VRF routes are exported to the SPB IS-IS instance, associated to the
customer’s ISID, and bound to the WAN IP as a gateway address. Far-end BEBs will import those
routes into their local VRF routing table. Therefore, those routes will point to the WAN IP address
as next-hop. We should note that this mechanism is applicable and identical for both IPv4 and
IPv6. This is illustrated in figure 23 from the perspective of BEB-1. We should note that route-
maps can be used for fine-grained route filtering.
Figure 23. Route Import/Export
Export local customer VRF routes to SPB IS-IS,

associate to customer’s ISID and bind to WAN address
BEB1
10.0.1.0/24
.254
.1 SPB Service A
VRF A
Site 1 SPB IS-IS
10.0.0.0/24
Import far-end SPB IS-IS routes associated with the customer’s ISID
into the customer’s VRF and set the far-end WAN IP address as next hop
Tech Brief
A L3 VPN service builds upon a L2 service and involves the following steps:
• Creating an L2 SPB service
• Creating a tenant VRF
• Creating LAN-side and WAN-side IP interfaces on the tenant VRF. LAN-side IP interfaces
normally reside on a VLAN. WAN-side IP interfaces can reside directly on the SPB services
itself on products supporting single-pass inline routing, or on a “dummy” VLAN on products
requiring external physical or internal front-panel loopback.
• Binding the WAN IP interface to the L2 SPB service’s ISID
• Route import/export between local VRF routing table and SPB IS-IS ISID instance
Let’s go back to the sample topology used for L2 services in section 9 and configure a L3 VPN
service so we can have a look at the configuration. We will look at devices supporting internal
front-panel loopback.
Figure 24. L3 VPN service example
Site 2
192.168.22.0/24
1/1/48
.254
BEB2
.2
BEB1 ISID 1002 BEB3

10.0.2.0/24
VRF A
1/1/48 BVLAN 4002 1/1/48
.1 .3
.254 192.168.30.0/24 .254
Site 1 Site 3
192.168.21.0/24 192.168.23.0/24
.4
BEB4
.254
1/1/48
Site 4
192.168.24.0/24
We will now provide configuration snippets for all BEBs. Like their L2 counterpart, L3 VPN
services require no configuration on BCBs. Let’s provide some details about this example:
• Customer sites connect to their local BEB though interface 1/1/48
• LAN-side, or site default-gateway IP interfaces are bound to VLAN 3001, which is the default
VLAN on port 1/1/48
• Port 1/1/54A is designated as a loopback port
• WAN-side IP interfaces are bound to dummy VLAN 3100
Tech Brief
Snippet 29. L3 VPN example – BEB-1
Tech Brief
Having created the L3 VPN service on all nodes, we can now proceed to verify it with show
commands. Let’s start by verifying correct route import and export. Snippet 33 shows routes in
BEB-1’s VRF “Customer_A”. Both local LAN and WAN subnets are LOCAL routes while far-end LAN
subnets are IMPORT routes whose next hop gateway address is the WAN address of the remote BEB.
Snippet 33. L3 VPN example – Verifying route import/export
Snippet 34 shows arp entries in BEB-1’s VRF “Customer_A”. Far-end WAN gateway addresses are
dynamically learnt.
Snippet 34. L3 VPN example – Verifying gateway L2 reachability
In addition to these L3-related verification steps, all steps covered in section 9 can be used to
verify the underlying L2 service.
Tech Brief
11.3 VPN Lite versus L3 VPN
Having presented VPN Lite and L3 VPN, we can now discuss the pros and cons and provide
guidelines to help you choose one versus the other.
Let’s start with the advantages of L3 VPN:

• Simplicity: L3 VPN does not require routing protocol configuration as it simply leverages the
existing SPB IS-IS instance. VPN Lite on the other hand requires one routing protocol instance
per tenant/VRF and BEB. For example, if using OSPF, 4 customer services spanning 8 BEB
nodes require 4 x OSPF instances per node: A total of 32 x OSPF configurations across all
nodes. In case dual stack IPv4 and IPv6 support is required, this translates to an OSPFv2 and
an OSPFv3 instance per BEB and VRF: A total of 64 x OSPF configurations all nodes included.
More routing protocol configurations result in longer service provisioning times and increased
chances of making mistakes.
• Scalability: L3 VPN is significantly more efficient than VPN Lite from a CP point of view as it
uses a single routing instance. This results in lighter CP load and allows for greater scalability
than VPN Lite.
• Convergence: L3 VPN convergence can be faster than VPN Lite because it relies on a single
protocol. VPN Lite convergence can be slower because the stacking of routing protocols has
a compounding effect over convergence time: IS-IS must converge before OSPF can converge.
With such compelling arguments in favour of L3 VPN, you may wonder why anyone would
choose to use VPN Lite instead. The reason is that, while L3 VPN is the recommended option
within the SPB domain, L3 VPN relies on SPB IS-IS and cannot directly interoperate with external
networks. This is where VPN Lite comes in. VPN Lite can be configured on border BEB nodes
linking the SPB domain to external, non-SPB capable networks. These border BEB nodes use L3
VPN to communicate with other BEB nodes and VPN Lite to interoperate with external non-SPB
nodes through common routing protocols such as OSPF or BGPv4.
In short, L3 VPN is recommended within the SPB domain and VPN Lite is needed only on border
nodes connecting to the outside world.
12. Shared Services VPN and Route Leaking

In L3 VPN designs in which each VPN maps to its own VRF, it is common for certain services
such as DHCP, DNS and Internet access to be shared across two or more of those VPNs. This
can be implemented through VRF leaking.
Figure 25 shows the same familiar diagram that we have been using so far, but now with two
customers, A and B. Each customer is associated to its own ISID (1002 for Customer A and
1003 for Customer B) and VRF (Customer_A and Customer_B) on BEBs 1 through 4. Routes
are propagated across the backbone as explained in section 11.2.
Let’s now imagine that these customers need to also access some shared services and Internet
access. An additional L3_VPN is created on BEB1 and BEB2, the “border” BEBs. These are
the nodes that those shared services are accessed through. The “shared_services” L3VPN is
associated to its own ISID (1004) and VRF (shared_services). Note that this L3VPN need not
be stretched to BEBs 2 and 4.
BEB1 and BEB2 can exchange routes with external entities, such as the firewalls, using a
standard protocol, such as BGP4. Those routes can be leaked to customer A’s and B’s VRFs. In
turn, customer A’s and B’s VRF routes can be leaked to the “shared_services” VRF. As a pre-
requisite, customer A’s and B’s address space must not overlap with each other nor with the
shared services.
Tech Brief
Snippet 35. Route leaking
Snippet 35 provides the commands required to accomplish this on the border BEBs, BEB1
and BEB2.
We can summarize the process as below:

• Shared routes are exported from the shared_services VRF and into the global IP routing table.
When doing so, a route-map filters routes such that only external routes are exported. This is
to prevent re-export of routes imported from the other border BEB.
• Shared routes are imported from the global IP routing table and into the customer VRFs. Note
that this step is only necessary if customer sites are connected to the border BEBs.
• Customer routes are imported from the global IP routing table and into the shared_services
VRF. Note that this step is only necessary if customer sites are connected to the border BEBs.
• Remote customer routes are imported from the SPB IS-IS instance and ISID associated to those
customers and into the shared_services VRF.
• Shared routes are redistributed from the shared_services VRF to the SPB IS-IS instance and
ISIDs associated to customers. These routes will then be propagated across the backbone and
imported into customer VRFs at remote BEBs.
Figure 25. Shared services
Customer B Customer B
Site 1 Site 2
Customer A BEB1 BEB2 Customer A

Site 1 Site 2
SPB
IS-IS
Customer B Customer B
Site 3 Site 4
Customer A Customer A
BEB3 BEB4
Site 3 Site 4
Tech Brief
13. Automation
Up to this point, we have explained SPB concepts and configured the SPB backbone and
services manually. However, AOS incorporates features that can build both the SPB backbone
and services automatically. In this section, we will explain the various mechanisms that make a
near zero-touch SPB network possible. A factory-default Alcatel-Lucent OmniSwitch has these
mechanisms enabled by default and will automatically attempt to create an SPB backbone
and services as explained in the subsequent subsections, unless these automation features are
explicitly disabled. This set of features is sometimes referred to as “Intelligent Fabric” or “iFab”
for short. In this section, we provide a simplified, high-level overview of these features. For a
detailed description, please refer to the Alcatel-Lucent OmniSwitch Switch Management Guide.
13.1 Auto-Fabric
Figure 26 is a simplified view of a factory-default OmniSwitch bootup process. For a more
detailed flow chart, please refer to the Alcatel-Lucent OmniSwitch Switch Management Guide.
This process involves the following stages:

• Auto Virtual Chassis (VC)
• Auto Remote Configuration Download (RCD)
• Auto LACP
• Auto SPB
• Auto MVRP
• Auto IP
Auto-Fabric features are enabled by default on a factory-default OmniSwitch. These features

can however be disabled in their entirety, or, on a per-protocol or per-port basis. By default,
automatically learnt and created configuration is not saved to the vcboot.cfg file but this option
can be enabled.
Figure 26. Bootup state diagram
Auto-VC
Succeeds
with AF Auto-IP
Fails or disabled
succeeds with Auto-RCD STOP As soon as IP
AF enabled interface is up
if AF is enabled
Auto-LACP Auto-SPB Auto-MVRP
Link flap
Let’s describe these stages one-by-one.
13.1.2 Auto-VC
On bootup, and in absence of the vcsetup.cfg file, an OmniSwitch uses LLDP to detect other
VC-compatible nodes connected to the default auto-VFL ports. Default auto-VFL ports depend
on the product family. Some families such as the Alcatel-Lucent OmniSwitch® 6860 Stackable
LAN Switch have 2 designated VFL ports which default to this role. In other families such as
the Alcatel-Lucent OmniSwitch® 6900 Stackable LAN Switch, which support VC of up to 6 units,
the last 5 VFL-eligible ports default to auto-VFL ports. If other products in the same family are
detected at the other end, they will attempt to automatically create a VC. A Master node will
be chosen through an election mechanism and non-Master nodes will reboot. Since this process
creates a vcsetup.cfg file on all involved nodes, auto-VC will not kick-in in subsequent node
reboot events.
Tech Brief
13.1.3 Auto-RCD
Next, and in absence of a vcboot.cfg file, an OmniSwitch attempts to obtain an IP address
through DHCP on any of its operational non-VFL ports. It will try this using the untagged default
VLAN and tagged VLAN 127 and it will retry three times. If the switch succeeds in obtaining
an IP address, and depending on the DHCP options in the lease, the switch will subsequently
attempt to fetch an instruction file from a TFTP server or it will contact the Alcatel-Lucent
OmniVista® 2500 Network Management System. Next, the switch will attempt to download
firmware and vcboot.cfg from either an FTP/SFTP server or OmniVista. If the switch succeeds
at obtaining its firmware and configuration, it will reboot and load its configuration. Depending
on the configured options, the switch may or may not continue with the subsequent stages.
Please refer to the AOS Switch Management Guide and to [2] for further details.
13.1.4 Auto-LACP
All non-VFL ports are auto-LACP enabled by default. Auto-LACP kicks in on a factory-default
switch or a non-factory-default switch, unless explicitly disabled. Auto-LACP can be disabled
globally or only on specific ports.
During the auto-LACP stage, a switch uses LLDP to identify switches connected to auto-
LACP-enabled ports. Any LACP-compatible ports linking the same pair of switches will be
automatically added to a linkagg. Even if there is only a single link connecting two nodes, it
will still be configured as a linkagg because this allows additional links to be added later on
without requiring configuration changes. For instance, by creating a linkagg of 1 member port
and by referencing the (logical) linkagg as opposed to the (physical) port in other configuration
commands, those configuration commands do not need to change when additional member
ports are added to the linkagg. This is a best practice.
Note that, even if the remote switch is not an OmniSwitch, but is (manually) configured for LACP,
the OmniSwitch detects LACP PDUs and automatically configures its side of the linkagg. This
simplifies deployment even when 3rd party switches are used.
13.1.5 Auto-SPB
All non-VFL ports and linkaggs are auto-SPB enabled by default. Auto-SPB kicks in on a factory-
default switch or a non-factory-default switch, unless explicitly disabled. Auto-SPB can be
disabled globally or only on specific ports or linkaggs.
Auto-SPB also uses LLDP to detect presence of SPB-capable switches. When an SPB-capable
switch is detected, the switch will attempt to configure the port or linkagg as an SPB backbone
interface. When doing so it will use certain defaults.
On switches running AOS release 8.7R1 and later these defaults are:
• BVLANs 4000 through 4003 are created and mapped to ECT IDs 1 through 4 respectively
• BVLAN 4000 is designated as the control BVLAN
If the switch succeeds in establishing at least one SPB adjacency, all remaining non-VFL and
non-SPB backbone ports are automatically configured as auto UNP access ports, unless explicitly
disabled. Please refer to section 13.3 for details on auto UNP access ports.
13.1.6 Auto-MVRP
Auto-MVRP is enabled on factory-default switches. On switches booting from a vcboot.cfg
file however, this feature needs to be explicitly enabled. When auto-MVRP is enabled, and
if the switch fails to establish any SPB adjacency, MVRP will be enabled on all remaining
and operational non-VFL ports. This enables the dynamic instantiation of VLANs learnt from
neighbouring switches.
Tech Brief
13.1.7 Auto-IP
The Auto-IP features runs in parallel with other features described in this section and, when
enabled, it kicks-in as soon as an IP interface is created. Auto-IP listens for routing protocol
(OSPFv2, OSPFv3 or IS-IS) “Hello” packets from neighbour devices and automatically creates local
routing configuration matching parameters in the received “Hello” packets such that an adjacency
can be formed. For example, reception of an OSPF “Hello” packet with area 1, Hello timer of
5 and Dead timer of 20 will result in matching configuration on the local device such that the
two devices become neighbours and an adjacency is established.
13.2 Dynamic SAPs

Up to this point, we have shown how to configure SAPs statically and manually. However, SAPs
can be automatically and dynamically configured using the User Network Profile (UNP) feature
in conjunction with authentication (802.1x, MAC) or classification rules (for example VLAN tag).
Dynamically-created SAPs can map traffic to a manually created service. Dynamically-created

SAPs can also map traffic to a dynamically-created service for a fully dynamic configuration,
which is covered in the next section.
Let’s analyse the sample configuration in snippet 36 . This example refers to the case of L2
Services in which any required routing, such as default gateway, DHCP relay, is performed on a
central node, which can be a switch or a Firewall. Either way, service and SAP configuration on
the central L3 device is static. Dynamic configuration is useful at the edge nodes where client
devices are added, moved, and changed on a regular basis.
Six UNP profiles named “EMPLOYEE”, “IoT”, “GUEST”, “WLAN”, “CCTV”, and “RESTRICTED” are
created, each mapping to a different ISID. There are a total of four BVLANs, 4000 through 4003.
BVLAN 4000 is reserved as control BVLAN and therefore services can be mapped to BVLANs
4001 through 4003. As a result, each BVLAN carries traffic for two different services. These
UNP profiles use head-end replication and have VLAN translation enabled; these are default
behaviours which are explained elsewhere in this document.
So far, this describes the services but does not describe how ports or client devices will be
mapped to those services. This mapping can be either static or dynamic. Let’s start by analysing
the dynamic case. Ports 1/1/10 through 1/1/16 are defined as UNP “access” ports. This means
that they map traffic to an SPB service, as opposed to a UNP “bridge” port which maps traffic to
a VLAN. These ports utilise the “SAMPLE_FLOW” port template. This template is defined such that:
• 802.1x supplicants are authenticated against the “UPAM” radius server. If successful, the
radius server returns a “filter-id” attribute which matches one of the locally defined UNPs
(for example; EMPLOYEE, IoT, among others).
• As a fall-back mechanism for non-802.1x capable devices, such devices can use MAC
authentication. If successful, the radius server also returns a “filter-id” attribute which
matches one of the locally defined UNPs (for example; EMPLOYEE, IoT, among others).
• In both 802.1x or MAC authentication cases, it may happen that the radius server does not
return a “filter-id” or that the returned “filter-id” value does not match any of the locally
defined UNPs. In such case, those devices are bound to a “RESTRICTED” UNP.
• The RESTRICTED UNP is also defined as the default UNP which is used in case of
authentication failure. When bound to this RESTRICTED UNP, devices will receive an IP address
through DHCP but will be very limited in their access to network resources. This is controlled
at the central L3 node or firewall. This allows for these devices to have minimal network
connectivity such that they can be onboarded (for example a digital certificate can be applied)
and they can successfully authenticate next time they connect.
With this configuration in place, devices connected to ports 1/1/10 through 1/1/16 will be
authenticated and dynamically bound to an SPB service according to their type or user identity.
This means that the SPB service will automatically adapt and change as devices connect,
disconnect, move, or otherwise change without manual intervention.
Tech Brief
In some cases, it may be necessary to statically bind these UNP services to a port. This is
particularly useful if authentication is not used or when the device is a “silent” device. A “silent”
device is a device that does not transmit traffic for extended periods of time because it goes into
power-save mode for instance. These periods of inactivity can result in a loss of service binding,
thus making the device effectively unreachable (for example for a WAKE-ON-LAN packet). This
problem can be avoided by statically binding the UNP profile to the port. We have applied static
UNP binding to ports 1/1/5 through 1/1/9 such that the service is statically bound to those ports
even if the device disconnects or stops communicating for extended periods of time.
It should be noted that statically binding a SAP, as opposed to a UNP, also offers a solution to
the silent device problem. However, by statically binding a UNP instead of a SAP, the exact
same UNP constructs can be used for both silent and non-silent devices. This results in a more
standardized configuration which is easier to create and maintain with fewer mistakes when
configurations need to change. This is considered a best practice.
Snippet 36. Dynamic SAPs – L2 services
Tech Brief
Let’s analyse the L3 Service case for this example. What this means is that, rather than routing
at a centralized switch or firewall, edge routing is performed. Furthermore, let’s consider the case
of devices which attach to a standard VLAN port (for example not a SAP) and BEBs supporting
front-end-panel loopback routing. Since VLAN-to-Service mapping happens at the loopback
port, in this case we need to create bridge-type (VLAN) UNPs instead of access-type UNPs.
The SPB configuration will be statically defined. Configuration snippets are split in three parts
for convenience. Snippet 37 contains the VLAN-domain part of the configuration, snippet 38
contains the IP-domain part of the configuration, and snippet 39 contains the Service-domain
part of the configuration.
We should note that devices placed in the “RESTRICTED” role do not normally need to
communicate with other such devices. However, the configuration snippet allows for all routes
in the RESTRICTED VRF to be imported. This can be modified with the addition of a route-map
permitting routes to a central BEB or firewall only. Furthermore, a policy list can be attached t
o the RESTRICTED UNP definition such that those devices can only communicate with certain
head-end resources and can only use certain ports or applications. We will leave this exercise
for you to complete.
Snippet 37. Dynamic SAPs – L3 services – VLAN Domain
Tech Brief
Snippet 38. Dynamic SAPs – L3 services – IP Domain
Snippet 39. Dynamic SAPs – L3 services – Service Domain
Tech Brief
13.3 Dynamic Services
In the preceding section, we explained how SAPs can be dynamically configured to accommodate
mobile users and devices, and highly dynamic environments. This same mechanism is applicable
to VMs in a data centre. As VMs are created, turned-on or off, or migrated from one hypervisor
to another, SAPs can be automatically and dynamically created to adapt to those events on the
fly without network manager intervention.
For instance, classification rules can match VM traffic based on the VLAN tag (configured in the
hypervisor) and create the required SAPs dynamically and automatically. This is a best practice
compared to statically enabling all possible SAPs on all access ports because it reduces the
broadcast domain footprint to only the required ports, thus eliminating unnecessary broadcast
traffic and MAC learning.
However, with the features that we have described so far, even if the SAPs can dynamically
adapt, this would require that the service UNP be manually created. In certain scenarios, the
network administrator does not know the required parameters beforehand. For instance, the
server manager may create, change, and delete VLANs on the hypervisor’s vswitch on a regular
basis. It may be tempting to pre-provision services for all 4096 VLANs. But this is a poor practice
as it creates an unnecessary load on the control plane.
The best practice for that type of environment is to use AOS’ Dynamic Services feature. With
Dynamic Services, UNPs can be dynamically created, on the fly, based on the VLAN tag seen on
UNP ports. This feature is enabled by default on factory-default switches.
Upon receiving a frame on a UNP access port, the OmniSwitch automatically creates a dynamic
SAP and a dynamic UNP profile defining the SPB service that traffic will be mapped to. Snippet
40 provides an example of such a dynamically created UNP profile. The profile in the snippet is
created upon reception of traffic tagged with VLAN 101. How does the AOS select the ISID and
BVLAN to be used in the newly created service? It uses the formulas below where ‘%’ denotes
the “modulo” division: the reminder of the integer division.
• ISID Number = Base Service Number + Domain ID + (VLAN Number % Service Modulo)
• BVLAN Index = ISID Number % (Total number of BVLANs)
By default:
• Base Service Number = 10,000,000
• Domain ID = 0
• Service Modulo = 512
Let’s also assume that BVLANs 4000-4003 are created and calculate the ISID and BVLAN
number manually.
ISID Number = 10,000,000 + 0 + (101 % 512) = 10,000,000 + 101 = 10,000,101
BVLAN Index = 10,000,101 % 4 = 1
The formula does not provide the BVLAN number directly but the BVLAN index: the position
in a BVLAN array sorted in ascending order where the lowest numbered BVLAN is in position 0
and the highest numbered BVLAN is in position N-1. Therefore, in our example, with BVLANs
4000-4003, BVLAN index 1 maps to BVLAN 4001.
Snippet 40. Dynamic services – Dynamic UNP
Tech Brief
It is important to understand that with 4096 possible VLAN tags, using the default Service
Modulo of 512 can result in up to 8 different VLAN tags being mapped to the same service. This
is not the desired outcome most of the time because it will result in different VLAN traffic being
bridged in the same L2 domain. To ensure L2 isolation, we can change the Service Modulo to
4096 as shown in Snippet 41.
Snippet 41. Dynamic services – Dynamic UNP – Service Modulo
Let’s now focus on another parameter used in the ISID calculation formula: Domain ID. The
Domain ID is useful in a multi-tenanted environment. For example, let’s consider a network
providing services to three different customers: A, B, and C. These customers can use multiple
VLANs and some of those VLANs may overlap. How do you ensure customer traffic isolation
in the SPB domain? Isolation is achieved by creating a Domain ID for each customer and by
the mapping customer’s UNI ports to the Domain. The example in Snippet 42 illustrates this
configuration. Domains 1 through 3 are created for customers A through C. Ports 1/1/1-10
connecting customer A’s devices are mapped to domain 1, ports 1/1/11-21 connecting customer
B’s devices are mapped to domain 2, and so on. This configuration preserves customer isolation
even when services and SAPs are dynamically and automatically configured on the fly in
response to VLAN tags in incoming traffic.
Snippet 42. Dynamic services – Dynamic UNP – Multi-tenancy
Lastly, the Base Service Number (BSN) enables manual and dynamic service coexistence without
conflict. Dynamically created services map to ISIDs greater than or equal to the BSN. Manually
created services should use ISID numbers lower than the BSN.
14. Management
As explained in section 3.6, SPB IS-IS is not an IP protocol. BCB nodes do not require IP
interfaces. BEB nodes supporting L2 services only do not require IP interfaces either. BEB nodes
require IP interfaces only when supporting an L3 service (for example, L3 VPN or VPN Lite).
However, all SPB nodes whether BCB or BEB, require IP interfaces for management purposes.
There are different ways of managing SPB nodes:

• Out of Band Management (OOBM): OOBM is applicable to any network architecture and will
not be discussed further
• Dedicated Management Service: An SPB service and VRF are dedicated to management. This
is a good option if all nodes support single-pass inline routing. However, nodes that do not
support single-pass inline routing will require an external physical or internal front-panel
loopback for this purpose even if they would not require it otherwise (for example, because
they are BCBs).
• In-band Management: In-band management is applicable to all SPB nodes regardless of their
routing capabilities (such as, single-pass inline, external physical, or internal front-panel
loopback). Management IP interfaces can be created directly on the control BVLAN, therefore,
Tech Brief
no loopback of any kind is required. The management network or stations attach to one or
more gateway nodes through VLAN-domain interfaces. We should note that IP interfaces
created on the control BVLAN do not support configuration of any routing protocol or function
(for example, OSPF or VRRP) and do not rely on ARP for IP-to-MAC resolution because there
are no broadcasts on the SPB domain. IP-to-MAC mapping is resolved through IS-IS TLVs. IS-IS
TLVs also carry management routes through the SPB backbone. VLAN-domain and SPB-domain
management routes can be cross-redistributed at gateways nodes. The “spb-mgmt” protocol is
associated to SPB-domain management routes.
Figure 27. In-band management
BEB1 BEB3
1/1/1 BCB
172.16.0.0/24 BVLAN 4000

OSPF area 0 172.16.1.0/24
SPB IS-IS
Management VRF
1/1/1
BEB2 BEB4
Let’s examine the in-band management example in figure 27. In this example, nodes BEB-1 and
BEB-2 are gateways nodes linking the SPB-management domain and the VLAN-management
domain. The VLAN-management subnet is 172.16.0.0/24 and the SPB-management subnet is
172.16.1.0/24. OSPF is used in the Management network. Nodes BEB-1 and BEB-2 redistribute
routes between OSPF and SPB-MGMT protocols. Route maps prevent circular route redistribution
between these two protocols.
Snippet 43. In-band management – BEB-1
Tech Brief
Snippet 47. In-band management – BCB
In-band management configuration examples are provided in snippets Snippet 43 through

Snippet 47. OSPF and route-map configuration in BEBs 1 and 2 is excluded from these snippets.
15. Operation and Maintenance

15.1 Connectivity Fault Management: 802.1ag
CFM in an SPB network is most useful to perform L2 trace and L2 ping for analysis and
troubleshooting. Other aspects of CFM such as fault detection, which are important in PBB,
are less important in SPB because SPB has an IS-IS control plane. These functions (CCM) are
not currently supported in conjunction with SPB.
OAM is supported at the BVLAN level, refer to figure 28. Virtual MEPs must be configured for
all BVLANs and BEBs and, optionally, also for BCBs (such that a L2 PING or L2 trace test can be
initiated from any node to any other node). MIPs are automatically created and do not need to
be explicitly configured.
Since there is no CCM function to map system names, link trace commands and output will
reference the BMACs.
Figure 28. OAM in BVLAN and VLAN Domains
VLAN maintenance domain
BVLAN maintenance domain
MIP
MIP
(V) SPBM (V)
V V
MEP MEP
MEP MEP
MIP
Tech Brief
OAM is also supported at the VLAN level or between L2 access switches connected to BEBs over
SAP UNIs. This is useful in a L2 deployment for testing end-to-end service connectivity between
sites. OAM at the VLAN level must be set at a higher maintenance domain level than BVLAN OAM.
Figure 29 shows a practical example of how OAM can be used to verify connectivity between
BEBs by means of Loopback message (LBM) and loopback reply (LBR) and checking the route
with link trace message (LTM) and link trace reply (LTR).
Figure 29. L2 ping and L2 trace
LBM
(V) (V)
MEP MEP
BEB BCB BCB BEB
LBR
LTM
(V) MIP MIP (V)

MEP MEP
BEB BCB BCB BEB
LTR
LTR
LTR
Configuration Snippet 48 provides a sample OAM configuration for service BVLANs 4001-4003.
Snippet 48. OAM
Tech Brief
Snippet 49 provides sample configuration and output for an L2 trace test. As shown in the
snippet, the trace provides, among other elements, BMACs for all transit nodes as well as
ingress and egress interfaces used.
Snippet 49. L2 trace
15.2 Network performance: Service Assurance Agent

Latency, jitter and packet loss SAA tests are automatically set-up between all BEBs and BCBs
and across all BVLANs with the “saa auto-create” command. Refer to Snippet 50 showing the
configuration and Snippet 51 showing sample statistics.
Snippet 50. Service Assurance Agent configuration
Tech Brief
Snippet 51. Service Assurance Agent stats
15.3 Network maintenance

Two features in SPB can assist in network maintenance tasks: Overload state and graceful restart.
15.3.1 Overload state

SPB provides a graceful way to remove a node from service for maintenance and transition
traffic to an alternate path (if there is one) with minimal disruption. This is the “overload state.”
Setting the overload state on the node will signal other nodes not to use it as a transit node and
use alternate paths instead. This is similar to increasing the metric on all the links but is a much
quicker way of achieving this outcome. Note, however, once the overload state is enabled on a
node no traffic will transit through the node even if there are no alternative paths.
The overload state can be set indefinitely (until removed) or it can revert after a timer expires.
15.3.2 Graceful restart

SPB IS-IS supports graceful restart in a virtual chassis or physical chassis with redundant
control modules.
Without graceful restart, a VC master or CMM takeover event would require neighbour nodes
to tear down and re-establish adjacencies with the restarting node and re-build the topology
database, resulting in some disruption to traffic flows.
When graceful restart is enabled, and with the help of a neighbour node, the node undergoing
a takeover will announce this condition to its neighbours by setting the RR (restart request) in
a TLV message and continue using its existing FDB while restarting. The neighbour nodes will
maintain their adjacencies with the restarting node during this process and send their complete
LSP database information to the restarting node once the process is complete.
This makes the transition a much smoother process because disruption to traffic forwarding is
minimized and the topology database is re-built in a much shorter time.
16. Service attachment redundancy

When redundant links and nodes exist in the SPB domain, path computation in the event of a
failure or restoration event is handled by the IS-IS protocol. But, access or Customer Edge (CE)
devices connected to BEB nodes do not run SPB IS-IS and therefore other solutions are required
when redundancy is needed. In this section we will present the different options for the different
service types.
We start by highlighting that the simplest way of achieving redundant CE to BEB attachment
is to use VC at the BEB and to attach the CE device to the BEB through a LAG. This redundancy
option is applicable to any service type (L2 or L3).
Tech Brief
We will now present alternate redundancy options other than VC+LAG.
Let’s start with L2 Services in figure 30 below. We can consider the following options:
• Non-redundant: The CE is attached to a single BEB through a single link. Link, BEB or CE
failure will result in loss of service to the site
• Redundant links: The CE is attached to a single BEB through a link aggregate (LAG). This adds
protection from single-link failure. Note that fibre runs should use diverse physical paths to
protect against fibre cuts which would typically interrupt both links otherwise.
• Redundant links and nodes: The CE is attached to two different BEBs through two different
links. This adds protection from BEB failure. When possible, both links should use physically
diverse paths such that link failure events are not correlated. Dual-Home Link (DHL) is a high
availability feature that provides fast failover without implementing Spanning Tree or Link
Aggregation. Please refer to the “AOS 8 Network Configuration Guide” for further details.
• Fully redundant: This option adds CE device redundancy. MSTP (Multiple Spanning Tree
Protocol) can be used to avoid loops in this redundant connection. By default, SPB floods STP
BPDUs messaging over SPB services. When using MSTP, different sites must use different
MSTP regions to avoid creating a large MSTP region spanning all sites.
Note that Virtual Chassis (VC) can be combined with all the options above to increase resiliency.
Figure 30. L2 Service attachment
1. Non-redundant 2. Redundant links
SPB SPB
BEB
3. Redundant links and nodes 4. Fully redundant CE
SPB SPB
DHL MSTP
Let’s now continue with L3 services. We can distinguish two sub-variants: L3 CE and L2 CE. A L3
CE can exchange routes with the BEBs by using any supported routing protocol as well as static
or default routes. A L2 CE on the other hand will completely delegate routing to the BEB, which
will act as a default gateway for local devices. These two sub-variants are illustrated in figure 31
and figure 32. Note that hairpins, when required, are not shown for simplicity.
L3 Service attachment with L3 CE options:

• Non-redundant: The site is attached to a single BEB through a single link. Link, BEB or CE
failure will result in loss of service to the site.
• Redundant links: The site is attached to a single BEB through a link aggregate (LAG). This adds
protection from single-link failure. Note that fibre runs should use diverse physical paths to
protect against fibre cuts which would typically interrupt both links otherwise.
• Redundant links and nodes: The site is attached to two different BEBs through two different
links. This adds protection from BEB failure. When possible, both links should use physically
diverse paths such that link failure events are not correlated. A dynamic routing protocol such
as OSPF is used between BEBs and CEs to exchange routing information. Import/Export and
re-distribution of routes must be carefully planned to avoid circular re-distribution of routes.
This is accomplished with route maps.
• Fully redundant: This option adds CE device redundancy
Tech Brief
Figure 31. L3 Service attachment - L3 CE
SPB SPB
BEB
Routing
protocol
SPB SPB
Routing
protocol Routing
protocol
You may notice that the case of L3 Service attachment with a L2 CE is almost identical to the
case of L2 Service attachment. However, since the routing function is delegated to the BEB,
VRRP is required when CEs attach to redundant BEBs. This requires access VLANs to be extended
across both BEBs. If BEBs are directly connected, the access VLANs can be simply tagged on the
link interconnecting both BEBs. However, if there is no direct connection between the BEB pair,
a dedicated SPB service can be created to this effect.
In addition, note that when using a L2 CE in a L3 Service, there is no routing protocol between CE
and BEB. In such a case, the associated VRF can be configured as a “low profile” VRF. Low profile
VRFs have routing capabilities restricted to static and/or imported routes, which is sufficient for
such a situation. Low profile VRFs take up less BEB resources than “max profile” VRFs allowing
for creation of more VRFs on the BEB.
As in the case of L2 Service attachment, all options can be combined with VC and LAG.
Figure 32. L3 service attachment - L2 CE
SPB SPB
BEB
SPB SPB
VRRP VRRP
DHL
MSTP
Tech Brief
17. Loop avoidance and suppression
In the CP, loops are avoided with IS-IS, a link-state routing protocol. In the DP, a node will not
accept unexpected frames from its neighbours.
However, short-lived transient loops may form in the event of a topology change and until
network convergence is attained. Loops pose a serious threat to the network stability.
In the DP, SPB incorporates an additional loop mitigation technique to detect and break these
transient loops:
• Reverse-path Forwarding Check (RPFC): RPFC exploits SPB’s symmetry and congruence
properties. RPFC verifies that incoming traffic’s source BMAC is indeed reachable over the
ingress interface according to the local FDB and discards non-conforming frames.
In addition, the SPB backbone must be protected from loops that may be created due to failures
and misconfiguration at the VLAN-domain access layer. By default, SAPs forward STP BPDUs
allowing redundantly-attached VLAN-domain access layer to use STP for loop prevention.
There is always a chance however that STP may be misconfigured, fail, or not be enabled at all.
Configuration faults in customer networks can result in loops spanning both the SPB backbone
and customer access network. This can result in broadcast storms. To protect the SPB backbone
from broadcast storms, loops involving SAPs must be detected and broken.
AOS supports an additional loop mitigation mechanism to detect and break access layer loops:
Loopback Detection (LBD). LBD can detect and protect the backbone network from forwarding
loops created at the VLAN-domain customer-access layer. LBD operates in addition to other
mechanisms such as DHL or STP. When a loop is detected, the port is disabled and goes into a
shutdown state. A trap is sent and the event is logged.
The switch periodically sends out LBD frames from LBD-enabled ports and concludes that the
port is looped back if it receives the frame on any of the LBD-enabled ports.
LBD can be used on both VLAN UNI and SAP UNI ports. In the case of SAP UNI ports, LBD frames
will be sent on all SAPs because different access VLANs may have different logical topologies.
However, if a loop is detected on a SAP, the entire physical port will be shut down.
LBD should be enabled on all UNI ports.
Figure 33 illustrates situations in which LBD can detect and break loops.
Figure 33. Loopback detection
SPB SPB SPB

BEB-A BEB-B BEB-A BEB-B BEB-A BEB-B
Port in switch with highest Port in switch with highest Port in switch with highest
BridgeID is shut down BridgeID is shut down PortID is shut down
By default, LBD is disabled for the switch and on all service-access ports. Enable LBD globally
on the switch and in specific service-access ports or linkaggs as shown in Snippet 52.
Tech Brief
Snippet 52. Loopback detection
AOS incorporates storm control through flood rate limiting of broadcast, multicast and unknown
unicast traffic. A high threshold rate is configured in megabits-per-second (mbps), packets-per-
second (pps), or as a percentage of the port speed. When the threshold value is reached, packets
are dropped or, the port is shutdown. Storm control is enabled by default with pre-defined rates.
Please refer to the AOS Network Configuration Guide for further details.
18. General design guidelines

Design guidelines have been provided throughout this document. In this section, we provide
additional design guidelines to assist the network architect in designing SPB networks.
18.1 BVLANs
As described in section 5, SPB networks load balance traffic on a per-service basis. This load
balancing is achieved by mapping different services to different BVLANs. An SPB network
supports up to 16 BVLANs, however, most real-world physical topologies do not support 16
equal-cost-paths. There is no advantage in creating more BVLANs than the number of equal-cost-
paths in the physical topology. Moreover, since a SPT must be computed for each BVLAN, having
more BVLANs than equal-cost-paths in the physical topology creates an additional unnecessary
load in the CP which results in increased resource utilization and convergence times.
In short: Only create as many BVLANs as there are equal-cost-paths in the physical topology. As
of AOS 8.7R1 and later releases, only four BVLANs are created by default when using auto-SPB.
18.2 VLAN-to-Service mapping

When creating a SAP, AOS allows mapping multiple or all VLAN tags to the same SPB service.
We want to stress that, as a general guideline, to preserve L2 isolation between VLANs, different
VLANs should be mapped to different services (for example, through different SAPs).
Mapping different VLANs to the same SPB service makes inter-VLAN bridging possible, thus
defeating the purpose of having different VLANs in the first place.
In addition, there is a risk of having duplicate MAC addresses. In theory, there should be no
duplicate MAC addresses; in reality, it can happen, particularly in virtualized environments.
Duplicate MAC addresses in different VLANs do not collide, however, if these VLANs are mapped
to the same SPB service and the client devices are connected to different SAPs, those MACs will
be constantly learned, re-learned and flushed. This is known as a “mac-move” and should be
avoided to maintain stability. To avoid mac-move, we strongly recommend mapping different
VLANs to different SPB services (ISIDs). This will require one SAP and ISID per access VLAN.
There are some situations in which mapping different VLANs to the same SPB service (ISID) is
acceptable, but we will not elaborate on those situations.
In short: As a general guideline, map different VLANs to different SPB services by using specific
SAPs for each VLAN.
Tech Brief
18.3 Virtual Chassis
Virtual chassis (VC) is a feature that combines multiple “stackable” switches into a single logical
“virtual chassis” such that each physical switch becomes a virtual “slot” in the virtually modular
chassis. A virtual chassis is a single logical entity managed as one device and with single control
and management planes.
Virtual chassis provides many benefits such as network architecture and management
simplification. VC greatly simplifies redundant service attachment. Customer CE access devices
can be dual-homed to diverse slots in a BEB through a link aggregate. This eliminates the need
to configure other L2 or L3 redundancy mechanisms such as DHL or VRRP.
When using virtual chassis in the SPB backbone, logical link aggregates (LAGs) are recommended
to interconnect the VC to all its SPB neighbours such that one member (physical) port connects
to every slot in the VC as seen in figure 34. This is not mandatory but is recommended and will
improve the network convergence time in the event of slot failure because the need to update
tables during the control plane takeover is greatly reduced. In addition, dual homing nodes to
a VC reduces the need to forward traffic across the VFL because traffic forwarding in a LAG
prioritizes the use of local linkagg member ports over remote (across the VFL) member ports.
Figure 34. VC and SPB
BxB BxB BxB BxB BxB BxB
BxB
BxB BxB
BxB
BxB BxB
18.4 Link Aggregation

Combining multiple physical links into a LAG improves resiliency and increases total available
bandwidth on the logical link.
In a LAG, traffic is load balanced across member ports in one of two ways:
• MAC hash (brief mode)
• IP + TCP/UDP port hash (extended mode)
However, SPB backbone ports use MAC-in-MAC encapsulation which means MAC addresses are
the BMACs of BEB and BCB nodes while IP addresses and port numbers are not visible to the
hashing logic. In most cases this does not create enough entropy and the load will not be spread
evenly across all different physical links.
Since AOS 8.3.1R01, a “tunnel-protocol” option can be selected such that the hashing can use
CMACs or IP addresses + TCP/UDP ports.
It is recommended that this option be enabled on all SPB nodes using LAG. The choice of MAC
(brief) or IP+TCP/UDP ports (extended) is a global setting which will apply to all LAGs. Please
refer to the AOS Command Line Interface Guide for further details.
Tech Brief
18.5 Link Metric
SPB uses the link metric as a measure of a link’s cost to reach another node. By default, all link
metrics are set to 10 regardless of link speed. The link metric is an integer in the 1-16M range.
The link metric can be adjusted to influence the SPT calculations. For instance, the metric can be
changed to reflect the link speed. It should be noted that the metric must be adjusted on both
sides of a link. Nodes will become adjacent even when the metrics are different, but the highest
metric will be used in the SPT calculations.
Changing the link metric to reflect the link speed will help steer traffic towards links with
higher capacity and away from lower capacity ones, making the best use of the total available
bandwidth and improving performance. Table 3 shows a way in which the metric can be set to
be inversely proportional to the link speed.
Table 3. Recommended Link Metric
Speed Suggested Metric
100G 1000
50G 2000
40G 2500
25G 4000
10G 10000
1G 100000
100M 1000000
18.6 QoS
In an SPB network, traffic is classified at the SAP and the classification does not change as traffic
traverses the backbone and until it exits through another SAP at the destination BEB.
Trusted SAPs copy CoS markings from the incoming VLAN tag onto the BVLAN tag. If incoming
traffic is not tagged, then the port’s default priority is used. Un-trusted SAPs set the CoS
markings to a user-defined value.
No further classification based on inner L2-L4 conditions is possible within the SPB backbone
due to the MAC-in-MAC encapsulation.
When using an external or two-pass routing (external physical or internal front-panel loopback),
the standard VLAN port must best set to trust and use CoS and not DSCP to preserve CoS
markings end-to-end.
19. Security guidelines

In this section, we will provide some additional design guidelines specific to the security domain.
This is not an exhaustive list of recommendations, rather, we will focus on certain guidelines
specific to SPB deployments. We will go through different AOS features and how they can be
used to improve security in an SPB network. Other more general security guidelines can be
found in [3].
Tech Brief
19.1 Management VRF
As explained in section 3.6, SPB relies on a non-IP protocol for path computation. For this reason,
BCB nodes and BEB nodes supporting L2 services only do not require an IP address. The only
case in which an SPB node requires an IP address is the case of a BEB node supporting a L3
service or feature such as L3 VPN, VPN Lite, or VRRP, among others.
We have covered different SBP management options in section 14. Management IP addresses
can be bound to:
• The EMP port, in case of OOBM
• To a standard VLAN port, in the case of OOBM
• The control BVLAN, in the case of in-band management
• A Management SPB service, directly in the case of products supporting single-pass
inline routing
• A Management SPB service, indirectly in the case of products supporting external physical
or internal front-panel loopback
We want to point out that no matter what management option is chosen, management IP
addresses should use a different VRF from the VRF used for service or customer traffic. This
is already the case when using the EMP port for OOBM. One possibility is creating a dedicated
management VRF and enabling the required management protocols on this VRF as shown in
Snippet 43 through Snippet 47.
Another possibility is using the default VRF for management, under the condition of not using
it for anything other than management.
19.2 MACSec
Data integrity and confidentiality must be protected while in transit through the network.
MACSec is an IEEE standard (802.1AE) which provides point-to-point authentication and optional
encryption between MACSec-capable devices such as switches. MACSec can prevent various
threats such as man-in-the-middle, sniffing, spoofing, and playback attacks.
Because MACSec operates at the MAC layer, it transparently secures all upper layer traffic
transiting through MACSec-enabled links. This includes both application-layer data, as well
as control-plane and management-plane communication. In addition, unlike IPSec, MACSec is
implemented in hardware at wire-speed and does not introduce additional latency or bandwidth
limitations.
19.3 NAC
In section 13.2, we explained how users and devices can be dynamically mapped to their
services based on their identity. Enabling authentication on every front-panel port ensures only
authorized users and devices can access network services. One additional benefit of creating
dynamic SAPs through NAC is that no service is instantiated on a BEB until an authorized user
successfully authenticates and is mapped to the service: The service is instantiated on demand.
This is an additional layer of security compared to static SAPs because no service is connected
if no authorized user is connected. It is clearly more difficult to hack, attack, or otherwise disrupt
a service when it is not even connected.
19.4 Router authentication

As explained in section 11.1, an SPB network can exchange routes with external non-SPB entities
by using the VPN Lite feature. This means that one or more SPB BEB nodes will run a routing
protocol such as OSPF or BGP with external entities. Any learnt route may be imported into the
SPB backbone and propagated to other BEB nodes by way of IS-IS TLVs.
Tech Brief
This creates an opportunity for a bad actor to inject malicious routes and poison the routing
table to carry out DoS, MITM, or other attacks.
This risk can be mitigated by enabling routing protocol authentication (e.g. MD5 for OSPF or BGP).
20. Conclusion
Shortest Path Bridging is a powerful technology yet simple when compared to others such as
MPLS or EVPN. SPB is broadly supported across the Alcatel-Lucent OmniSwitch portfolio with
products in multiple formats, from stackable to modular chassis and even industrial-grade
ruggedized variants. This product breadth, coupled with SPB’s service-oriented framework,
results in a network architecture that can deliver the required service to the right location
with minimal network configuration changes, or even in a fully automated manner.
www.al-enterprise.com The Alcatel-Lucent name and logo are trademarks of Nokia used under license
by ALE. To view other trademarks used by affiliated companies of ALE Holding, visit: www.al-enterprise.
com/en/legal/trademarks-copyright. All other trademarks are the property of their respective owners.
The information presented is subject to change without notice. Neither ALE Holding nor any of
its affiliates assumes any responsibility for inaccuracies contained herein. © Copyright 2021 ALE
International, ALE USA Inc. All rights reserved in all countries. DID21040501EN (April 2021)
CONSOLE CONNECTIONS
ALE NETWORK PRODUCTS
OS6900 CONSOLE
Console Server
Serial to USB
USB A RJ45 to DB9 Female
console
Straight UTP cable
OS6900 T20/T40/X20/X40
@ 9600 Baud Rate OS6900-USB-RJ45
Comes in the box

Comes in the box
Console Server
Serial to USB
OS6900 X72/Q32 OS6900-USB-RJ45RJ45 to DB9 Female

RJ45 Straight UTP cable
@ 9600 Baud Rate console
Comes in the box
Serial to USB
Console Server
RJ45 to DB9 Female
OS6900 RJ45
console RJ45 to DB9 Female
Straight UTP cable
V72/C32/X48C6/T48C6/V48C8
@ 115200 Baud Rate
Comes in the box
Male-Male DB9 Adapter
* Connections to Console servers may need Straight or Roll-over UTP cable depending on Console Server model
OS6900 CONSOLE
USB A
console
Console Roll-over Adapter
OS6900 T20/T40/X20/X40
@ 9600 Baud Rate OS6900-USB-RJ45
Comes in the box Console Roll-over cable with USB Type A
RJ45
OS6900 X72/Q32 console
OR
@ 9600 Baud Rate
Console Roll-over cable with USB Type C
OS6900 RJ45
console
V72/C32/X48C6/T48C6/V48C8
@ 115200 Baud Rate
OS6860 CONSOLE
Console Server
Serial to USB
Micro USB RJ45 to DB9 Female
console
Straight UTP cable
OS6860/OS6860E
@ 9600 Baud Rate OS6860-RS232CBL
Needs to be
ordered separately
Micro USB Serial to USB

console
Micro USB to DB9
Console Server
OS6860N
@ 115200 Baud Rate RJ45 to DB9 Female
Straight UTP cable
Male-Male DB9 Adapter
OS6860 CONSOLE Comes in the box Requires installation of a driver on PC
https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
Micro USB Console Roll-over cable with USB Type A

console
OS6860/OS6860E OR Console Roll-over Adapter
@ 9600 Baud Rate
OS6860-RS232CBL
Needs to be
ordered OR
separately
Console Roll-over cable with USB Type C
OS6860N Micro USB OS6860-RS232CBL
@ 115200 Baud Rate console Needs to be

ordered
separately
OTHER SWITCHES Console Server
Serial to USB
OS6900-USB-RJ45RJ45 to DB9 Female
Legacy/New Switches Straight UTP cable
@ 9600 Baud Rate

6350 Comes in the box
6360
6450 RJ45
console
6465
6560 Console Roll-over cable with USB Type A
6850
6855
6865 Console Roll-over Adapter
9900
10K Console Roll-over cable with USB Type C
THANK YOU
OmniSwitch AOS R6
Link Aggregation
How to
✓ This lab is designed to familiarize you with Static link aggregation.
Contents
1 Topology ........................................................................................ 2
2 Link Aggregation – Static option ............................................................ 2
2.1. Create a Static Link Aggregation ................................................................. 2
3 Lab Check ...................................................................................... 4
2
Link Aggregation
1 Topology
throughput and redundancy; this can be done statically using OmniChannel or dynamically using the IEEE
802.3ad (LACP) protocol.
2 Link Aggregation – Static option
2.1. Create a Static Link Aggregation

- Define a static link aggregate and set its size on both 6450 by typing :
6450 -> static linkagg 5 size 2
Notes
In this example, 5 represents the aggregate identifier and 2 is the maximum number of ports in the aggregate
- Check to see what you have done; notice the operational status is DOWN.
- Type:
-> show linkagg
-------+----------+---------+----+------------+--------------+-------------
5 Static 40000005 2 ENABLED DOWN 0 0
6450 -> show linkagg 5

Static Aggregate
SNMP Id : 40000005,
SNMP Descriptor : Omnichannel Aggregate Number 5 ref 40000005 size 2,
Name : ,
Operational State : DOWN,
Aggregate Size : 2,
Primary Port : NONE
- Add ports to your aggregate, type on both 6450 :
6450 -> static agg 1/11 agg num 5

6450 -> static agg 1/12 agg num 5
Notes
If the ports 1/11 and 1/12 of the 6450 are not available, it means that the 6450 has still its stack configuration.
Go to the “Stacking” lab and follow the commands from the part “Delete the Stack”.
- In this example ports 1/11 and 1/12 to aggregate 5 on 6450.

3
Link Aggregation
- Let’s see what we have accomplished. Type:

-> show linkagg
-------+----------+---------+----+------------+--------------+-------------
5 Static 40000005 2 ENABLED DOWN 0 2

Static Aggregate
SNMP Id : 40000005,
Name : ,
Operational State : DOWN,
Aggregate Size : 2,
Aggregate Min-Size : 1,
Primary Port : NONE
-> show linkagg port
- Now, connect the switches by activating linkagg interfaces :

6450 -> interfaces 1/11-12 admin up
Notes
Ports don't necessarily have to be the same on both ends of the link.
- Using the commands you learned earlier, compare the outputs:

-> show linkagg
-------+----------+---------+----+------------+--------------+-------------
5 Static 40000005 2 ENABLED UP 2 2

Static Aggregate
SNMP Id : 40000005,
Name : ,
Aggregate Size : 2,
-> show linkagg port

- By default, the linkagg is associated with vlan 1. In order to test connectivity, assign an IP address to this
VLAN :
Notes
6450-A already an IP address assigned to vlan 1 from previous lab
4
Link Aggregation
6450-A -> ip interface int_1 address 192.168.10.5/24 vlan 1

6450-B -> ip interface int_1 address 192.168.10.6/24 vlan 1
- Try to make a ping between both 6450 or both 6860

6450-A -> ping 192.168.10.6
PING 192.168.10.6: 56 data bytes
64 bytes from 192.168.10.6: icmp_seq=0. time=171. ms
----192.168.10.6 PING Statistics----
6 packets transmitted, 6 packets received, 0% packet loss
round-trip (ms) min/avg/max = 2/43/171
Notes
There’s no link between 6860 and 6450, so it’s not possible to make a ping between them.
- To demonstrate the redundancy capabilities, experiment with removing a link and monitor the results of
your pings tests
Tips
You can use the command ping <dest_ip_address> count <number> to send more than 6 pings.
To break a ping sequence, press the key CTRL+C
To simulate a link failure, you can bring down the corresponding interface :
interface slot/port admin down (6450)
- We will now perform a similar configuration exercise using the IEEE 802.3ad standard (LACP). Before
proceeding remove the static link aggregation group you created. You can either return your switch to
factory default or remove them manually. Note that you cannot delete a link aggregation group if there
are ports still associated with it:
6450 -> no static linkagg 5
ERROR: LAERR53 Static aggregate not empty deletion failed
6450 -> static agg no 1/11

6450 -> static agg no 1/12
6450 -> no static linkagg 5
- Ensure the link aggregation groups are removed on both switches as described above. There is no need to
disconnect the physical connections to continue to the next lab section.
3 Lab Check
What command is used to check the status of a particular link aggregate?

OmniSwitch R8
6560 Virtual Chassis
Objectif
✓ This lab is designed to familiarize you with the OmniSwitch 6560 Virtual
Chassis feature (VC) and its configuration.
Contents
1 Configuring a Virtual Chassis of 2 OmniSwitchs 6560 .................................... 2
2 Monitoring the Virtual Chassis ............................................................... 4
2
1 Configuring a Virtual Chassis of 2 OmniSwitchs 6560

In this part, we will configure the Virtual Chassis ID, and group them in a Virtual Chassis Group 1.
- Assign a globally unique chassis identifier to the switch and enable the switch to operate in virtual chassis
mode, on both 6560:
6560-A -> show virtual-chassis topology
6560-A -> virtual-chassis chassis-id 1 configured-chassis-id 1
6560-A -> virtual-chassis chassis-group 1
6560-B-> show virtual-chassis topology

6560-B-> virtual-chassis chassis-id 1 configured-chassis-id 2
6560-B-> virtual-chassis chassis-group 1
6560-B-> show virtual-chassis topology
- Manage the 6560-A to be the master chassis, assign a highest chassis priority to it:
6560-A -> virtual-chassis configured-chassis-priority 200
- Configure a virtual fabric link (VFL) and member ports for the VFL:
6560-A -> virtual-chassis auto-vf-link-port 1/1/25
6560-A -> virtual-chassis auto-vf-link-port 1/1/26
6560-B-> virtual-chassis auto-vf-link-port 1/1/25

6560-B-> virtual-chassis auto-vf-link-port 1/1/26
6560-B-> write memory
VFL is an aggregate of high-speed ports used, between the peers, for inter-chassis traffic and control data
through the IPC-VLAN
- Enable the corresponding interface

6560-A -> interfaces 1/1/25 admin-state enable
6560-A -> interfaces 1/1/26 admin-state enable
6560-B-> interfaces 1/1/25 admin-state enable

6560-B-> interfaces 1/1/26 admin-state enable
6560-B-> write memory
- Vérifier que les liens virtuel fabric link (vfl) ont bien été créés :
6560-A -> show virtual-chassis vf-link
6560-A -> show virtual-chassis vf-link member-port
6560-B -> show virtual-chassis vf-link

6560-B -> show virtual-chassis vf-link member-port
3
- Reload the switch after converting the configuration

6560-A -> reload from working no rollback-timeout
6560-B -> reload from working no rollback-timeout
Notes
At the end of Chassis role election process, the Slave chassis will reboot to initialize its parameters and chassis
status.
4
2 Monitoring the Virtual Chassis

Wait for a moment after reboot, then verify the Virtual-Chassis status settings and the chassis roles.
- Check the virtual-chassis topology:
Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
1 Master Running 1 200 1 2c:fa:a2:aa:32:a1
2 Slave Running 2 100 1 2c:fa:a2:a2:f1:9d
- If the status of the OS6560 is not “Running”, check that the System Ready is set to Yes with the command:
6560-A -> debug show virtual-chassis topology
Local Chassis: 1
Oper Config Oper System
Chas Role Status Chas ID Pri Group MAC-Address Ready
-----+------------+-------------------+--------+-----+------+------------------+-------
1 Master Running 1 200 1 2c:fa:a2:aa:32:a1 Yes
2 Slave Running 2 100 1 2c:fa:a2:a2:f1:9d Yes
Notes
The chassis role determines which switch is the master of the Virtual Chassis.
The Master and Slave roles are only active when the operational status of the virtual-chassis feature is up for
both chassis.
- Display the different ports belonging to the VFL link, type:

6560-A -> show virtual-chassis vf-link
VFLink mode: Auto

-------------------+----------+---------+-------+-------+---------+-----------
1/0 Up 1/1/25 2 2 1 10G
2/0 Up 2/1/25 2 2 1 10G
6560-A -> show virtual-chassis vf-link member-port

VFLink mode: Auto
Chassis/VFLink ID Chassis/Slot/Port Oper Is Primary

-------------------+------------------+----------+-------------
1/0 1/1/25 Up Yes
1/0 1/1/26 Up No
2/0 2/1/25 Up Yes
2/0 2/1/26 Up No
Notes
The “Is Primary” field defines the primary port of the virtual fabric link.
5
- Verify the consistency of system-level mandatory parameters between the two chassis:
6560-A -> show virtual-chassis consistency


------+------+---------+-------+------+-------+--------+--------+----------
1 1 OK OS6560 1 15 4094 4094 A
2 2 OK OS6560 1 15 4094 4094 A
Notes
The two chassis in the same Virtual-Chassis group must maintain identical configuration and operational
parameters.
- You can access to the secondary VC by typing the following:
6560-A -> ssh-chassis admin@2

([email protected])
***********************
* *
* Pod 20 Switch 4 *
* 6560-B *
* *
***********************
Password: switch
- Although the prompt is the same, you are now connected to the secondary VC. Type the following:

Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- Look at the Local Chassis parameter. Now it says 2, which means you are connected to the secondary VC.
log
- Type the following to return to the master VC:
6560-A -> logout

logout
Connection to 127.10.2.65 closed.
OMNISWITCH R8
I N T E L L I G E N T FA B R I C
OBJECTIVES
• Understand the auto fabric feature

• Mount automatically a Virtual Chassis
• Mount automatically a LACP
• Automate the Routing, SPB, MVRP
AUTO-FABRIC
AUTO-FABRIC - PLUG-N-PLAY ZERO TOUCH DEPLOYMENT
• First time bootup
1- Auto-VC
• Elements of same family discovered
• Virtual Chassis created
2- Automatic remote configuration
• Download remote configuration
• Discover LACP 3- Auto-LACP
• Discover OSPF & IS-IS

• IP interface must exist 4- Auto-Routing
• Neighbor relationship must establish
• Pre-defined defaults
• If not established configuration deleted & disabled
5- Auto-SPB Fabric
• Discover SPB neighbor
• Pre-defined defaults
• If not established configuration deleted & disabled
6- Auto-Network Profiling
• If fabric successful, user & network port profiles creation
• Enable VLAN propagation with MVRP 7- Auto-MVRP

AUTO-FABRIC - START UP
Switch Power on
Or reload without any config file
Starting 6900 Boot Process

Mount /dev/sda1
FS is EXT2
Do you want to disable auto-configurations on this switch [Y/N]?
10s N
Auto-Configurations enabled
Preparing Flash..
If no response or input is [N], then it is assumed to be false.

N
Meaning to use auto-VC, RCL and auto-fabric
Y If input is [Y] then auto-VC, RCL and auto-fabric are disabled

AUTO-VC
1- Auto-VC
• Auto VFL
• Auto VFL Default ports
• Auto Chassis ID
• Auto vs Static
• Demo License enabled by default
Valid Advanced or vcsetup.cfg VC Mode

Demo license exists • VFL: Auto or Static
Y Y
N N
boot.cfg VC Mode
Standalone Mode exists? • Auto VFL
Y N • Auto Chassis ID
AUTO VFL FEATURE – AUTO VFL PORTS
Auto VFL process runs only on port explicitly configured
as auto VFL port in vcsetup.cfg or runtime configuration
1 Auto VFL Detection Process
Y
Auto VFL Ports Automatically detect whether an
10G and 40G auto VFL port can become VFL
No copper
vcsetup.cfg
exists
2 OS6900-X / T
Assign VFL ID automatically • Last 5 ports of each chassis
Assign VFL ID OS6900: id= 0, 1, 2, 3, 4, 5 • Including ports in expansion slots
• Regardless of SFP+/QSFP presence on those ports
OS6900-Q32
3 • Last 5 ports of each chassis
Aggregate Auto VFL ports in aggregate • In case of 4x10G splitter cables is used
Aggregate
• Ports with 4x10G splitter is counted as 4 ports
multiple auto
• Ports with 40G QSFP are counted as 1 port
VFL ports
• Ports with no SFP+/QSFP are counted as 1 port
AUTO-VC - AUTO-CHASSIS ID
• Auto Chassis ID selection only occurs when there is no vcsetup.cfg
• Master selection is then run based on lowest MAC address
• Upon receiving their new chassis ID, non master units reboot and apply their new ID
• In case of a new chassis insertion, Master Chassis assigns the chassis id of the new member
vcsetup.cfg
virtual-chassis auto-vf-link-port 1/1/31A
virtual-chassis auto-vf-link-port 1/1/32A
virtual-chassis auto-vf-link-port 1/1/32B
virtual-chassis auto-vf-link-port 1/1/32C
virtual-chassis auto-vf-link-port 1/1/32D
INTELLIGENT FABRIC
AUTOMATIC REMOTE CONFIGURATION
2-Auto-Predefined config template
• RCL is run after Auto VC, and before the rest of Auto Fabric
• May result in no Auto Fabric being run depending on the RCL result
• May be used to enhance Auto Fabric
• The linkagg created by the RCL will be retained for use later and not modified by regular Auto
Linkagg
• RCL tries 6 times, 3 each on VLAN 1 and 127 to get DHCP and download instruction file
• To cancel RCL, run command “auto-config-abort”
• At the end of RCL, if a vcboot.cfg is downloaded, the box will be reset
• Auto Fabric will only run if the config file has the commands to do so
INTELLIGENT FABRIC - AUTOMATIC FABRIC PROTOCOLS
3- Auto-LACP
4- Auto-Routing
5- Auto-SPB Fabric
7- Auto-MVRP
AUTO-DISCOVERY - AUTO-LACP
3- Auto-LACP
• LLDP enhancement
• Propriatery TLV used to detect the peer and, in return, receive peer’s system ID
• If LACP negotiation succeeds, form a link aggregation on a detected set of ports
vcboot.cfg
! Link Aggregate: -> show linkagg port

linkagg lacp agg 127 size 16 admin-state enable
linkagg lacp agg 127 actor admin-key 65535 Chassis/Slot/Port Aggregate SNMP Id Status Agg Oper Link Prim
linkagg lacp port 1/1/1c actor admin-key 65535 -----------------+----------+--------+----------+----+-----+-----+-----
linkagg lacp port 2/1/15 actor admin-key 65535 1/1/1C Dynamic 1003 ATTACHED 127 UP UP NO
linkagg lacp port 3/1/14 actor admin-key 65535 2/1/15 Dynamic 101015 ATTACHED 127 UP UP NO
AUTO-DISCOVERY - IP AUTO PROTOCOL CONFIGURATION
4- Auto-Routing
• Supports IP protocols (OSPFv2, OSPFv3, IS-IS) • Protocol network configuration is learned

• IP Interface or VRF configuration is not through Hello packets
concerned • Determine area, area type, and timers
• DHCP, RCL or user configuration CLI • Protocols are loaded when the first valid hello is
received
• Active during and after the normal auto fabric • Configure the critical parts in order to form
discovery time adjacencies and share routes
• Runs in parallel with no interdependency • Will automatically create route-maps to redistribute
• Can be started by the following local subnet routes into OSPF/ISIS as internal routes
• No boot.cfg (out of box)
• Auto fabric discovery started by CLI or boot.cfg
• IP auto protocol started by CLI or boot.cfg
vcboot.cfg
! IP Route Manager:
ip static-route 135.118.225.0/24 gateway 172.25.167.193 metric 1
ip route-map "auto-configure" sequence-number 50 action permit
ip route-map "auto-configure" sequence-number 50 set metric-type internal
ip redist local into ospf route-map "auto-configure" admin-state enable
AUTO-DISCOVERY - AUTO SPB FABRIC vcboot.cfg
! VLAN:
spb bvlan 4000-4015 admin-state enable
5- Auto-SPB Fabric spb bvlan 4000-4015 name "AutoFabric BVLAN"
mac-learning vlan 4000-4015 disable
! SPB-ISIS:
• SPB configuration !spb isis bvlan 4000 ect-id 1
spb isis bvlan 4001 ect-id 2
• To apply a set of default SPB Backbone port spb isis bvlan 4002 ect-id 3
configuration on a port or aggregate (configured spb isis bvlan 4004 ect-id 5
during LACP phase) spb isis bvlan 4005 ect-id 6
• Network port configuration spb isis bvlan 4007 ect-id 8
• If adjacencies not formed during 4 Hello intervals spb isis bvlan 4009 ect-id 10
(4x9 sec) – NOT a part of SPB spb isis bvlan 4011 ect-id 12
• Default SPB configuration spb isis bvlan 4015 ect-id 16
spb isis control-bvlan 4000
• BVLANs 4000-4015 mapped to ECT-IDs 1-16 spb isis interface linkagg 127
spb isis admin-state enable
respectively -> show vlan
• Control BVLAN: 4000 vlan type admin oper ip mtu name

------+-------+-------+------+------+------+------------------
• Bridge priority: 0x8000

. . . .
4000 spb Ena Ena Dis 1524 AutoFabric BVLAN
. . .
AUTO-DISCOVERY - AUTO-NETWORK PROFILING
• Access port configuration
• User profiles creation
• Single service
• Defines a single service SAP binding that will accept
untagged frames
• Auto VLAN service
• Automatically generate SAP bindings for the VLANs
concerned by the traffic coming on port as well as a
default untagged service by default
AUTO-NETWORK PROFILING - LOOPBACK DETECTION
• Eliminate the formation of data loops that are created by people attaching networks or
devices to multiple access ports that offer an open path for data to flow between the
access ports
• Edge loop detection available on service access interfaces and LACP links
• Even in case of the absence of other loop-detection mechanisms like STP/RSTP/MSTP
• LBD transmits periodic proprietary Multicast MAC frames on the LBD enabled ports
• Loop detected when receive the frame back on any of the Loop-back detection enabled port
• Port is disabled (forced down)
• Error Log is issued
• SNMP trap
• Can be re-enabled by user
AUTO-NETWORK PROFILING - LOOPBACK DETECTION
• Loop Back Detection for SPB-M access ports
• LBD frames extended for Service Access ports
• ISID
• Detect loops on a per ISID basis
• Topology of services and VLANs vary from access port to access port
• More LBD frames may be sent per port depending on SAP binding
• Port Path Cost

• Ability to block the slower port
vcboot.cfg
! Loopback Detection:
loopback-detection enable
loopback-detection service-access port 2/1/1 enable
loopback-detection service-access port 3/1/1 enable
LOOPBACK DETECTION- SERVICE ACCESS PORT
SPB Network SPB Network
1/1 2/1
1/1 2/1
AOS Switch with OS6900 OS6900
AOS Switch with OS6900 OS6900
Loopback-detection Loopback-detection enable
enable 1/2 1/3
1/2 2/2
Legacy or non AOS L2 switch

Legacy or non AOS L2 switch switch
switch
• 1/2 and 1/3 are SAP ports having same ISID and path cost
• 1/2 and 2/2 are SAP ports having same ISID and path cost • Loopback-detection is enabled with option ‘service-access’ on ports 1/2
• Loopback-detection is enabled with option ‘service-access’ on ports and 1/3
1/2 and 2/2 • Traffic loops through 1/2 and 1/3
• Traffic loops through 1/2 and 2/2 • Port 1/3 is shutdown as this interface has higher port identifier, since
• Port 2/2 is shutdown in case B has higher bridge identifier, since 1/2 1/2 and 1/3 has equal path costs
and 2/2 has equal path costs
AUTO-DISCOVERY - AUTO MVRP
7- Auto-MVRP
• MVRP enabled globally after LACP and SPB discovery process

• Spanning Tree mode switch to flat
-> show vlan
------+-------+-------+------+------+------+------------------
. . . .
12 dyn Ena Ena Dis 1500 VLAN 12 MVRP VLANs
. . .
AUTO FABRIC- ADMINISTRATION
vcboot.cfg
! Dynamic auto-fabric:
auto-fabric protocols lacp admin-state disable
auto-fabric protocols spb admin-state disable
auto-fabric protocols mvrp admin-state disable
auto-fabric protocols loopback-detection admin-state disable
auto-fabric protocols ip ospfv2 admin-state disable
auto-fabric protocols ip ospfv3 admin-state disable
auto-fabric protocols ip isis admin-state disable
-> show auto-fabric config

Auto-fabric Status : Disable, -> auto-fabric admin-state enable
Config Save Timer Status : Disabled,
Config Save Timer Interval : 300 seconds, -> auto-fabric config-save admin-state enable
Default UNP SAP Profile : Auto-vlan,
Discovery Interval : 0 minute(s),
Discovery Status : Idle, -> auto-fabric discovery start
LACP Discovery Status : Enabled,
LBD Discovery Status : Enabled,
MVRP Discovery Status : Enabled,
OSPFv2 Discovery Status : Enabled,
OSPFv3 Discovery Status : Enabled,
ISIS Discovery Status : Enabled,
SPB Discovery Status : Enabled
THANK YOU
OmniSwitch R8
Intelligent Fabric
How to
✓ Configure the Intelligent Fabric on the 6900 and 6860
Contents
1 Basic Network Diagram ....................................................................... 2
2 Lab Preparation ............................................................................... 3
2.1. OmniSwitches not used in the configuration ................................................... 3
2.2. OmniSwitches 6900 and 6860-A Configuration ................................................. 3
3 Auto-VC ......................................................................................... 4
4 Auto-LACP ...................................................................................... 9
2
Intelligent Fabric
1 Basic Network Diagram
The objective of this lab is to achieve automatically the following topology with the Intelligent Fabric.
The Auto-VC feature will automatically create the virtual chassis between the two OmniSwitches 6900 and
the Auto-LACP feature will create the aggregation “127” from the OmniSwitch 6860 to the virtual chassis.
3
Intelligent Fabric
2 Lab Preparation
2.1. OmniSwitches not used in the configuration
The OmniSwitches not used in the configuration are the Switches 3, 4, 5, 6 and 8.
These Switches should not interact with the three OmniSwitches used in the topology.
To do so, launch the script “reset SW#” (replace # by the Switch number) for each Switch not used in the
topology: 3, 4, 5, 6 and 8.
Shutdown all the user ports of the Switches 3, 4, 5, 6 and 8 with the command :
Sw# -> interfaces 1/1/1-24 admin-state disable
2.2. OmniSwitches 6900 and 6860-A Configuration
The auto-VC (auto-Virtual Chassis) process will be triggered when the Switch is powered on (or reloaded) and
no config file is located in on the switch.
In order to match these requirements, all the configuration files (*.cfg) will be deleted from the flash
memory of these three Switches. The three Switches will then be restarted.
Open a terminal for each Switch (6900-A,6900-B and 6860-A). Log in with the default login and password
(admin / switch).
Enter the commands:

Sw1 (6900-A) -> rm /flash/working/*.cfg
Sw1 (6900-A) -> rm /flash/certified/*.cfg
Sw1 (6900-A) -> reload from working no rollback-timeout
Sw2 (6900-B) -> rm /flash/working/*.cfg

Sw2 (6900-B) -> rm /flash/certified/*.cfg
Sw2 (6900-B) -> reload from working no rollback-timeout
sw7 (6860-A) -> rm /flash/working/*.cfg

sw7 (6860-A) -> rm /flash/certified/*.cfg
Sw7 (6860-A) -> reload from working no rollback-timeout
Notes:
The command “-> rm /flash/…/*.cfg” will delete all configuration files for a stand-alone switch
(boot.cfg) or an already configured virtual chassis (vcboot.cfg and vcsetup.cfg).
4
Intelligent Fabric
3 Auto-VC
One of the Auto-fabric feature is the Auto-VC (Automatic Virtual Chassis). The Auto-Fabric is enabled by
default on the 6900 and 6860(E).
Auto-VC allows device that have no existing Virtual Chassis (VC) configuration (no config file) to form a VC
with compatible devices without user configuration.
In our case, a Virtual Chassis will be configured automatically between the two OS6900.
The following actions are performed by the Auto-VC feature:
- Auto VFL Ports: Virtual Fabric Link (VFL) Detection Process – Automatically detect whether an auto VFL
port can become VFL. Without a config file (no vcsetup.cfg and no boot.cfg) the last 5 ports of each
chassis are designed as auto VFL port.
- Assign VFL ID: A VFL ID is assigned automatically.
- Auto Chassis ID: Both chassis start with a chassis ID 1 and then begins negotiation. The chassis with the
lowest MAC address is elected Master (Chassis ID 1) and the other chassis will get the chassis ID 2.
During the reload of the Switches, take a look at the terminal of your two OS6900. You will notice these
lines:
Starting 6900 Boot Process
Mount /dev/sda1
FS is EXT2
Do you want to disable auto-configurations on this switch [Y/N]?
Preparing Flash...
Without an input from the user, the Switch will use the default value “Yes” and will activate the auto-Fabric.
If you don’t want to use the auto-fabric feature, enter “N” when this message is displayed.
- Wait for the switch to reboot. You will then see auto-fabric messages displayed in the terminal.
***********************
* *
* Pod 20 Switch 1 *
* 6900-A *
* *
***********************
(none) login:
Thu Feb 9 10:36:19 : capManCmm Chass info message:
+++ CMM: INFO: early NI discover slot 1 waiting module type
Thu Feb 9 10:36:20 : vc_licManager licMgr warning message:

+++ License Manager Notification: You have 45 days left on your demo period.
Alcatel-Lucent Enterprise OS6900-T20 8.3.1.314.R01 GA, September 07, 2016.
Copyright(c), 1994-2014 Alcatel-Lucent. All Rights reserved.
Copyright(c), 2014-2016 Alcatel-Lucent Enterprise. All Rights reserved.
Thu Feb 9 10:36:26 : isisVc init info message:

+++ isisVcEnable@549: Using temporary chassisId 1 (mac 2c:fa:a2:05:cd:a9)
- Here, the chassis gets the default chassis ID 1.

5
Intelligent Fabric
Thu Feb 9 10:36:31 : ipsec key info message:

+++ IPsec master security key not set
chassis mode is
2
[ 73.835476] linux-kernel-bde : Broadcom memory allocated at c4000000/04000000
Thu Feb 9 10:37:38 : vcmNi thread info message:

+++ NI:thread_main@3092: Connecting to VC-ISIS (0/65)
Thu Feb 9 10:38:41 : isisVc vcprot info message:

+++ isisVcUpdateVcNodes@7075: Adding peer chassisId 1* (mac 2c:fa:a2:05:cd:71)

+++ isisVcUpdateVcNodes@7417: New Master: chassisId 1 chassisMac 2c:fa:a2:05:cd:71
+++ isisVcUpdateVcNodes@6720: My new chassisId 2
- The MAC address of the remote 6900 is discovered. The negotiation process starts and elects the remote
6900 as the new Master, because the remote 6900 has the lowest MAC address.
Thu Feb 9 10:38:46 : isisVc library(vcmLib) info message:

+++ vcmlib_overwrite_vcsetup_config@8365: Overwriting chassis ID
- As the local chassis has not been elected as the Master and act as the Slave, it’s chassis ID is changed
(Chassis ID 2).

+++ vcxScheduleChassisReboot@5651: Rebooting chassis in 10 seconds

+++ vcxRebootChassis@5670: Rebooting chassis now
...
Thu Feb 9 10:39:23 : ChassisSupervisor bootMgr alert message:

+++ _bootMgrRebootCMM: rebooting system
- As the local chassis is not the Master, its chassis ID changed and so, the chassis must restart in order to
apply its new chassis ID.
- This whole process, between the manual reboot and the automatic reboot should last for about 5
minutes.
- On the other 6900, you will get the following logs:

***********************
* *
* Pod 20 Switch 2 *
* 6900-B *
* *
***********************
(none) login:
Thu Feb 9 10:36:16 : capManCmm Chass info message:
+++ CMM: INFO: early NI discover slot 1 waiting module type
Thu Feb 9 10:36:24 : isisVc init info message:

+++ isisVcEnable@549: Using temporary chassisId 1 (mac 2c:fa:a2:05:cd:71)
6
Intelligent Fabric
- Here, the chassis gets the default chassis ID 1.
Thu Feb 9 10:36:28 : ipsec key info message:

+++ IPsec master security key not set
chassis mode is
2
[ 74.355450] linux-kernel-bde : Broadcom memory allocated at c4000000/04000000


+++ isisVcUpdateVcNodes@7075: Adding peer chassisId 1* (mac 2c:fa:a2:05:cd:a9)

+++ vcxElectionTimerExpiration@1345: I am the Master: chassisId 1 chassisMac 2c:fa:a2:05:cd:71
+++ vcxSetChassisIdAssignment_algo2@6022: Assign myself chassisId 1
- The MAC address of the remote 6900 is discovered. The negotiation process starts and elects the local
6900 as the new Master, because the local 6900 has the lowest MAC address.
Thu Feb 9 10:38:46 : isisVc library(vcmLib) info message:

+++ vcmlib_overwrite_vcsetup_config@8365: Overwriting chassis ID
- The local chassis has been elected as the Master, it’s chassis ID is set to 1.
Thu Feb 9 10:38:51 : vc_licManager licMgr error message:
+++ alaAfnInstallLicenseFromMaster: Unable to open afnId.txt.
Thu Feb 9 10:38:51 : qosNi Info info message:

- The remote 6900 is rebooting.

Thu Feb 9 10:38:52 : AAA Switch-Access info message:
+++ AAA aaaCsSystemReadyCB: Reveived system ready event
Thu Feb 9 10:38:54 : ChassisSupervisor reloadMgr info message:

+++ Redundancy time expired - updating next running to working
Thu Feb 9 10:39:37 : vcmCmm port_mgr info message:

+++ CMM:vcmCMM_client_rx_pm@2054: VFL link 1/0 down (last 1/2/1) [L2]

+++ isisVcProcessNodeDown@4249: List of Nodes down: 1
+++ isisVcProcessNodeDown@4290: Deleting peer chassisId 1* (mac 2c:fa:a2:05:cd:a9)
- The remote 6900 is unreachable through the VFL link 1/0, so the local 6900 considers the Virtual Chassis
“Down” for the moment.
- Please wait around 3 minutes after the automatic reboot of the Slave 6900.
7
Intelligent Fabric
- You can check the terminal of the Slave 6900 after its automatic reboot:
Sw1 (6900-A) -> show virtual-chassis topology

Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
2 Unassigned Init 2 100 113 2c:fa:a2:05:cd:a9


+++ isisVcUpdateVcNodes@7059: Adding peer chassisId 1 (mac 2c:fa:a2:05:cd:71)
+++ isisVcUpdateVcNodes@7417: New Master: chassisId 1 chassisMac 2c:fa:a2:05:cd:71
Thu Feb 9 10:42:51 : vcmCmm ipc info message:


Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- Check then the terminal of the Master 6900:
Sw2 (6900-B) -> show virtual-chassis topology

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------

+++ isisVcUpdateVcNodes@7059: Adding peer chassisId 2 (mac 2c:fa:a2:05:cd:a9)
Thu Feb 9 10:42:50 : vcmCmm ipc info message:

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
- When the Slave 6900 has completed its reboot, it will go into a Virtual Chassis “Init” state. It will then
contact the Master and act as the Slave running in the Virtual Chassis.
- Let’s then have a look to the Virtual-Chassis configuration.
- On the Master 6900 enter the following:

Local Chassis: 1
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
8
Intelligent Fabric
Sw2 (6900-B) -> show virtual-chassis consistency


------+------+---------+-------+------+-------+--------+--------+----------
1 1 OK OS6900 113 10 4094 4094 AB
2 2 OK OS6900 113 10 4094 4094 AB
Sw2 (6900-B) -> show virtual-chassis auto-vf-link-port

Chassis/Slot/Port Chassis/VFLink ID VFLink member status
-------------------+------------------+--------------------
1/2/1 1/0 Up
1/2/2 1/0 Up
1/2/3 Unassigned Unassigned
2/2/1 2/0 Up
2/2/2 2/0 Up
Sw2 (6900-B) -> show virtual-chassis vf-link

VFLink mode: Auto
-------------------+----------+---------+-------+-------+---------+-----------
1/0 Up 1/2/2 2 2 1 10G
2/0 Up 2/2/2 2 2 1 10G
- On the Slave 6900 enter the following:

Local Chassis: 2
Oper Config Oper
-----+------------+-------------------+--------+-----+------+------------------
Sw1 (6900-A) -> show virtual-chassis consistency


------+------+---------+-------+------+-------+--------+--------+----------
1 1 OK OS6900 113 10 4094 4094 AB
2 2 OK OS6900 113 10 4094 4094 AB
Sw1 (6900-A) -> show virtual-chassis auto-vf-link-port

Chassis/Slot/Port Chassis/VFLink ID VFLink member status
-------------------+------------------+--------------------
1/2/1 1/0 Up
1/2/2 1/0 Up
2/2/1 2/0 Up
2/2/2 2/0 Up
9
Intelligent Fabric
Sw1 (6900-A) -> show virtual-chassis vf-link

VFLink mode: Auto

-------------------+----------+---------+-------+-------+---------+-----------
1/0 Up 1/2/2 2 2 1 10G
2/0 Up 2/2/2 2 2 1 10G
- The Virtual Chassis configuration is correct due to the following points:

Each chassis has its own chassis ID and a Virtual Chassis status “Master” and “Slave”
Both chassis belong to the same Virtual Chassis Group 113.
The two 10G ports of each chassis (2/1 and 2/2) have been elected as VFL ports and are contained in the
same VFL Group.
4 Auto-LACP
- One other Auto-fabric feature is the Auto-LACP (Automatic Link Aggregation Protocol).
- Auto-LACP uses enhanced LLDP packets in order to detect the peer and in return, receive peer’s system
ID.
- If two ports at least are detected, the LACP negotiation will start and the aggregation link is formed.
- If the Switch 7 has been rebooted at the same time than the two Switches 6900, it will reach a ready
state long before the 6900 Virtual Chassis is established.
- The auto-LACP will be configured automatically around 5 minutes after the establishment of the auto-
VC. If you want to speed up the discovery process, you could use the following command to force the
auto-LACP to be discovered :
sw7 (6860-A) -> auto-fabric discovery start
- Compared to the Auto-VC, the Auto-LACP does not generate logs in the console.
- You can still get some logs from the swlog file.
- Enter the following command and check the time and date of the switch
sw7 (6860-A) -> show system
- Display the swlog file with a timestamp. Replace mm/dd/yyyy and hh:mm:ss by the start time and date of
the 6860-A (its last reboot).
sw7 (6860-A) -> show log swlog timestamp mm/dd/yyyy hh:mm:ss

2014 Feb 19 06:00:21 0S6860 swlogd: dafcCmm cmm info(5) AUTO-FABRIC-EVENT: LINKAGG_AGG_CONFIG: Aggregate
127 created. Key 65535, partner 2c:fa:a2:05:cd:71
2014 Feb 19 06:00:21 0S6860 swlogd: MIP_GATEWAY mipgwd info(5) ---- Logging MIP_SET type, command to be
sent:
2014 Feb 19 06:00:21 0S6860 swlogd: MIP_GATEWAY mipgwd info(5) MIP_SET(4) msg_id(14680090)
(APPID_DAFC_CMM(165/0) -> APPID_LINKAGGREGATION(12)) values:
2014 Feb 19 06:00:21 0S6860 swlogd: MIP_GATEWAY mipgwd info(5) Table(12301/0): alclnkaggAggTable
2014 Feb 19 06:00:21 0S6860 swlogd: dafcCmm cmm info(5) AUTO-FABRIC-EVENT: LINKAGG_AGG_CONFIG: Hash 7 on
aggregate 127 created.
10
Intelligent Fabric
- Enter the following commands on the 6860 and the Master 6900:
SW2 (6900-B) -> show linkagg
-------+-------------+---------+----+------------+--------------+-------------
SW2 (6900-B) -> show linkagg port

-------------------+----------+--------+----------+----+-----+-----+----
SW7 (6860-A) -> show linkagg
-------+-------------+---------+----+------------+--------------+-------------
SW7 (6860-A) -> show linkagg port

-------------------+----------+--------+----------+----+-----+-----+----
-
- As you can see, the Aggregation Link has been automatically created. The aggregation ID has the same
value on both switch (6860-A and the VC of 6900). The ports that belong to the aggregation are also the
same.
OMNISWITCH R8
ANYCAST RP
OBJECTIVES
• Describe Anycast RP functionality

• Summarize PIM Anycast-RP configuration step
ANYCAST RP Source
Register
RP2
• Goal RP1 OSPF
• Provide fast convergence when a PIM rendezvous

point (RP) router fails and RP load-sharing Register Register
• Anycast addressing is a generic concept and

is used in PIM sparse mode to add load balancing Client Client
and service reliability to RPs Receiver 1 Receiver 2
Server
• RFC Register
RP2
• RFC 4610 Anycast-RP Using Protocol Independent

Multicast (PIM)
RP1 OSPF
• RFC 7761 Protocol Independent Multicast –

Sparse Mode (PIM-SM) Register Register
• RFC 5060 Protocol Independent Multicast MIB

Client Client
Receiver 1 Receiver 2
ANYCAST RP
How it works Source
ip pim static-rp 231.0.0.0/8 10.10.10.1
“Loopback1” 10.10.10.1
RP2
• Uses a single statically defined RP address
(set on a Loopback interface) Register
• The RP routers share this Loopback unicast IP

OSPF
address announced as a host address (IGP)
RP1
• Senders and Receivers exchange messages “Loopback1”
10.10.10.1
with the nearest RP
• Determined by the Unicast routing table (IGP).) Register Register
• In case of a failure, the convergence is the same as the IGP

• Sources from one RP are known to other
Client Client
Receiver 1 Receiver 2
ANYCAST RP
• Hardware Requirements
• Software Requirements as specified in RFC 4610

• This feature will only be supported with PIM-SM
• not supported with PIM-DM, PIM-BIDIR or PIM-SSM
• Maximum of 8 Anycast RP routers to be configured statically
• SPT must be enabled when supporting Anycast-RP
ANYCAST RP CONFIGURATION
Step by Step
• Here, we define the specific configuration need to manage Anycast-RP
• The rest of the network configuration including additional IP interfaces, PIM Interfaces and
OSPF configuration to complete the network setup is outside the scope of this example
Configure a dedicated Loopback interface
Configure a static RP for a range of multicast groups
Set of router that will act as RPs for the Anycast -RP address
Configure Non -RP Router

Step by Step
ip interface “Loopback1” address 10.10.10.1 ip interface “Loopback1” address 10.10.10.1
Configure a dedicated Loopback interface
Configure a static RP RP1 RP2
Statically configure the RP address used with Anycast-RP Unique ID

• RP address is 10.10.10.1, which is configured on a Loopback1 interface on both routers
Non-RP
• OSPF has been configured on both routers, so this Loopback1 address is then be
advertised in OSPF to all routers in the network
Configure a static RP for a range of multicast groups
The group address range that the Anycast-RPs will be ip pim static-rp 231.0.0.0/8 10.10.10.1 ip pim static-rp 231.0.0.0/8 10.10.10.1
responsible for
Sw1 RP1 Sw7 RP2
The Anycast-RP address

Sw8 Non-RP
Note: This static configuration should exist on all PIM routers in the
PIM domain, not just those routers that are participating in the Anycast-RP set. ip pim static-rp 231.0.0.0/8 10.10.10.1
Step by Step
Set of router that will act as RPs for the Anycast -RP address
Switch Loopback0 manged previously on each switch
Configure the RP set

• This is the set of all routers which would act as the RP ip pim anycast-rp 10.10.10.1 192.168.254.1
ip pim anycast-rp 10.10.10.1 192.168.254.7
ip pim anycast-rp 10.10.10.1 192.168.254.1
ip pim anycast-rp 10.10.10.1 192.168.254.7
• Need a LoopbackX interface on each prospective RP router,
which is different than the LoopbackX that is being used as
the RP address Sw1 RP1 Sw7 RP2
Eg; Loopback0 : 192.168.354.x (x identified the router)
Loopback0 : 192.168.254.1 Loopback0 : 192.168.254.7
Sw8 Non-RP
Loopback0 : 192.168.254.8
Configure Non -RP Router
All other PIM routers that are NOT participating in the Anycast-RP set will still have the
PIM configuration defining the RP, but will not have the anycast-rp specific configuration
Sw1 RP1 Sw7 RP2

Loopback0 : 192.168.254.7
Loopback0 : 192.168.254.1
Sw8 Non-RP
ip pim static-rp 231.0.0.0/8 10.10.10.1
Loopback0 : 192.168.254.7
THANK YOU
OmniSwitch R8
Anycast RP
How to
✓ This lab is designed to familiarize you with the Anycast capability on an
OmniSwitch.
Contents
1 Topology ........................................................................................ 2
2 PIM-SM Configuration ......................................................................... 4
3 Lab Check ...................................................................................... 8
2
Anycast RP
1 Topology
Protocol-Independent Multicast (PIM) is an IP multicast routing protocol that uses routing information
provided by unicast routing protocols such as RIP and OSPF. PIM is “protocol-independent” because it does
not rely on any particular unicast routing protocol.
3
Anycast RP
- In the multicast switching lab, all requesting devices in the same VLAN received the multicast stream.
Now let’s move the receivers into different VLANs. This will require the multicast traffic to be routed in
order to reach each receiver. PIM-SM gives us the capability to route multicast traffic.
- Move Clients 9 and 10 into vlan 30 :
6450-A -> vlan 30 port default 1/2
6450-B -> vlan 30 port default 1/2
- As we will route the traffic, we don’t need the querier configured on 6450-A (but we still need to
forward querying) :
6450-A -> ip multicast querying disable
-
- Also, a multicast router is by default an IGMP querier, we can disable the querier forwarding on both
6860
6860-A -> ip multicast querier-forwarding disable
6860-B -> ip multicast querier-forwarding disable
- On the 6900, check that OSPF still runs properly and that all client vlans are reachable :
6900-A -> show ip routes

Total 25 routes

------------------+-------------------+----------+-----------
127.0.0.1/32 127.0.0.1 1d 7h LOCAL
172.16.17.0/24 172.16.17.1 1d 6h LOCAL
172.16.18.0/24 172.16.18.1 1d 6h LOCAL
172.16.78.0/24 +172.16.17.7 05:36:45 OSPF
+172.16.18.8 07:06:25 OSPF
172.16.137.0/24 172.16.17.7 05:06:42 OSPF
172.16.148.0/24 172.16.18.8 04:36:05 OSPF
192.168.20.0/24 +172.16.17.7 05:36:45 OSPF
+172.16.18.8 06:11:44 OSPF
192.168.30.0/24 +172.16.17.7 05:36:45 OSPF
+172.16.18.8 06:11:44 OSPF
192.168.100.0/24 192.168.100.1 1d 5h LOCAL
192.168.110.0/24 192.168.110.1 1d 6h LOCAL
192.168.120.0/24 192.168.120.1 1d 6h LOCAL
192.168.130.0/24 172.16.17.7 04:31:38 OSPF
192.168.140.0/24 172.16.18.8 04:26:32 OSPF
192.168.170.0/24 172.16.17.7 05:36:45 OSPF
192.168.180.0/24 172.16.18.8 07:06:25 OSPF
192.168.254.1/32 192.168.254.1 1d 6h LOCAL
192.168.254.3/32 172.16.17.7 04:31:38 OSPF
192.168.254.4/32 172.16.18.8 04:30:33 OSPF
192.168.254.6/32 +172.16.17.7 05:36:45 OSPF
+172.16.18.8 05:47:38 OSPF
192.168.254.7/32 172.16.17.7 05:36:45 OSPF
192.168.254.8/32 172.16.18.8 07:06:25 OSPF
4
Anycast RP
2 PIM-SM Configuration
- Enable PIM-SM in the core routers :
6900 -> ip load pim

6900 -> ip pim sparse admin-state enable


- Now, we must enable PIM-SM on the necessary interfaces.
6900 -> ip pim interface int_217



- Configure Anycast-RP on three.These routers will be used as the RP. The RP address will be 10.10.10.1,
which will be configured on a Loopback1 interface on the three routers.
6900 -> ip interface “Loopback1” address 10.10.10.1
6860-A -> ip interface “Loopback1” address 10.10.10.1
6860-B -> ip interface “Loopback1” address 10.10.10.1
- OSPF is configured on these routers so this Loopback1 address is advertised in OSPF to all routers in the
network. Different PIM routers in the network will either reach one if these three routers for the RP
depending on the best path metric.
- On the three routers, configure the Anycast-RP address 10.10.10.1. The 231.0.0.0/8 specifies the group
address range that the Anycast-RPs will be responsible for.
-
6900 -> ip pim static-rp 231.0.0.0/8 10.10.10.1
6860-A -> ip pim static-rp 231.0.0.0/8 10.10.10.1
6860-B -> ip pim static-rp 231.0.0.0/8 10.10.10.1

5
Anycast RP
Note: This static configuration should exist on all PIM routers in the PIM domain, not just those routers
that are participating in the Anycast-RP set.
Next you need to define something called the RP set. This is the set of all routers which would act as
the RP. You need to have a LoopbackX interface on each prospective RP router, which is different than
the LoopbackX that is being used as the RP address.
In our previous configuration, we defined the Loopback0 is defined on all routers with IP address
192.168.254.X/32. This Loopback0 address is already used as the Router ID for OSPF.
This Loopback0 address is used to complete the configuration of the RP set.
Configuration defining the Anycast-RP set must be the same on all routers participating in Anycast-RP
6900-A -> ip pim anycast-rp 10.10.10.1 192.168.254.1


6860-B -> ip pim anycast-rp 10.10.10.1 192.168.254.1

- One thing to note here is that you need to define your own IP address as well as all remote IP addresses
in this RP set so the configuration for the Anycast-RP set will be the same on all RPs in the Anycast-RP
set.
- Check connectivity status on all 3 switches:
6900-A -> show ip pim interface

Total 3 Interfaces

--------------------------------+---------------+---------------+--------+--------+--------+--------
6860-A -> show ip pim interface
Total 5 Interfaces
--------------------------------+---------------+---------------+--------+--------+--------+--------
6
Anycast RP
6860-B -> show ip pim interface
Total 5 Interfaces
--------------------------------+---------------+---------------+--------+--------+--------+--------
- Check the Pim neighbor and group-map
6900-A -> show ip pim neighbor
Total 2 Neighbors

-----------------+--------------------------------+-----------+-----------+-----------
172.16.17.7 int_217 00h:04m:41s 00h:01m:34s 1
172.16.18.8 int_218 00h:03m:56s 00h:01m:19s 1
6900-A -> show ip pim group-map
Origin Group Address/Prefix RP Address Mode Precedence

-----------+---------------------+---------------+-----+-----------
BSR 231.1.1.0/24 192.168.110.1 asm 192
BSR 231.5.5.0/24 192.168.170.7 asm 192
BSR 231.7.7.0/24 192.168.170.7 asm 192
BSR 231.8.8.0/24 192.168.180.8 asm 192
BSR 231.10.10.0/24 192.168.180.8 asm 192
6900-A -> show ip pim static-rp

--------------------+---------------+-----+--------+----------+-------
231.0.0.0/8 10.10.10.1 asm false none enabled
6860-A -> show ip pim static-rp

--------------------+---------------+-----+--------+----------+-------
6860-B -> show ip pim static-rp

--------------------+---------------+-----+--------+----------+-------
7
Anycast RP
- Manage the client 1 , client 5 and 10 to send and receive multicast traffic as indicated in the tables
below.
Use the application multicast tool from the desktop to do it.

Client 1 grps: 231.1.1.1 grps: 231.10.10.10
Client 5 grps: 231.5.5.5 grps: 231.1.1.1
Client 10 grps: 231.10.10.10 grps: 231.5.5.5
Example given with Client 1

Client 1 grps: 231.1.1.1 grps: 231.10.10.10
Do the same with client 5 and 10

Client 5 grps: 231.5.5.5 grps: 231.1.1.1
Client 10 grps: 231.10.10.10 grps: 231.5.5.5
8
Anycast RP
- Check the multicast routing table :
6900-A -> show ip pim sgroute

Total 3 (S,G)
---------------+---------------+--------------------------------+-----------------+-----------+--------
192.168.110.50 231.1.1.1 int_110 00h:18m:46s STL
192.168.20.50 231.5.5.5 int_217 172.16.17.7 00h:00m:07s ST
192.168.30.50 231.10.10.10 int_217 172.16.17.7 00h:00m:31s ST
6860-A -> show ip pim sgroute

Total 3 (S,G)
---------------+---------------+--------------------------------+-----------------+-----------+--------
192.168.110.50 231.1.1.1 int_217 172.16.17.1 00h:00m:05s SR
192.168.20.50 231.5.5.5 int_20 192.168.20.8 00h:03m:04s ST
192.168.30.50 231.10.10.10 int_30 192.168.30.8 00h:03m:01s ST
6860-B -> show ip pim sgroute

Total 3 (S,G)
---------------+---------------+--------------------------------+-----------------+-----------+--------
192.168.110.50 231.1.1.1 int_218 172.16.18.1 00h:00m:19s ST
192.168.20.50 231.5.5.5 int_20 00h:03m:12s STL
192.168.30.50 231.10.10.10 int_30 00h:03m:15s STL
3 Lab Check
- What is the purpose of PIM-SM?

.................................................................................................................
- What happens to multicast traffic in different VLANs without PIM-SM enabled?

.................................................................................................................
- Is PIM-SM a replacement routing protocol for RIP or OSPF?

.................................................................................................................
- What is the difference between DVMRP and PIM-SM?

.................................................................................................................
OMNISWITCH R8
S E RV E R L O A D B A L A N C I N G ( S L B )
OBJECTIVES
• Sum up the concept & characteristics of SLB

• Configure the SLB feature
• Understand the Distribution algorithm
• Learn about the Server Cluster types
• Monitor the Health
• Configure a SLB Probe
CONCEPT
• Method to logically manage a group of physical servers as one large virtual server (SLB
cluster)
• Cluster is identified and accessed at layer 3 by using a Virtual IP (VIP) address or a QoS policy
condition
192.168.0.10
192.168.0.3 192.168.0.9
192.168.0.5
192.168.0.8
• Benefits:
• Cost savings: no costly hardware upgrade to servers
• Scalability: allows up to 16 clusters per switch
• Reliability: provides load-sharing and redundancy
• Flexibility: QoS may be applied to servers
CHARACTERISTICS
• Virtual IP address
• Must be an address in the same subnet as the servers
• SLB cluster automatically creates a proxy ARP for the VIP with the switch’s MAC address
• Designed to work at IP layer or bridge
• Capability to specify if SLB is enforced at L2 or L3
• Distribution based on wire-rate load balancing
• Load balancing is based on L3/L4 information
• Using IPSA and IPDA pairs (optionally UDP/TCP ports)
• Policies for server load balancing can be assigned for the purpose of applying ACLs
• Servers can belong to multiple clusters
• Servers can be distributed on several Nis
• All servers must be part of the same VLAN/subnet. Servers do not need to be physically
connected to the SLB switch/router, they can be connected through L2 switches for that
SLB VLAN.
CONFIGURATION
• Create a loopback adapter in the server
• Define the Virtual IP address to the loopback adapter
• Enable SLB globally
-> ip slb admin-state enable
• policy condition, action and rule are automatically created
• Configure the SLB cluster
-> ip slb cluster Web vip 128.241.130.204
• Assign physical servers to the SLB cluster
-> ip slb server ip 128.241.130.127 cluster Web
-> ip slb server ip 128.241.130.109 cluster Web
• Modify optional parameters, if necessary
• SLB traffic distribution algorithm
• Load balance hashing control algorithm
• Health monitoring
DISTRIBUTION ALGORITHM
• Default
• Round-robin based on IPSA, SLB-VIP and a random generated number of the SLB-MAC
• Alternative
• Weighted Round Robin (WRR)
• SLB cluster distributes traffic according to the relative “weight” a server has within an SLB cluster
• Aggregate weight of all servers should not exceed 32
-> ip slb server ip <ip-addr> cluster <clstr> admin-state <enable | disable> probe <probe> weight <weight>
Cluster
192.168.100.102
Weight = 3
192.168.100.109
Weight = 2
192.168.100.99
Weight = 1
192.168.100.200
192.168.100.103
Weight = 0
BACKUP SERVER SCENARIO
-> ip slb cluster cl1 vip 192.168.100.200
-> ip slb server ip 192.168.100.102 cluster cl1 weight 1
-> ip slb server ip 192.168.100.99 cluster cl1 weight
Cluster cl1
192.168.100.102
Weight = 1
192.168.100.200 192.168.100.99
Weight = 0
• If Server 192.168.100.102 goes down, Server 192.168.100.99 will start receiving all the
traffic
WEIGHTED ROUND ROBIN
-> ip slb cluster cl1 vip 192.168.100.200
-> ip slb server ip 192.168.100.103 cluster cl1 weight 0 => use for backup
Cluster cl1
Server A: 192.168.100.102
Weight = 3
Server B:192.168.100.109
Weight = 2
Server C: 192.168.100.99
Weight = 1
192.168.100.200
Server D: 192.168.100.103
Weight = 0
• Server A handles three times the traffic of Server C, and Server B twice the traffic of
Server C.
• Server D is a backup server
HASHING CONTROL ALGORITHM
• Hashing Control AA Source Destination AA
AA Address Address AA
• Control over the hashing mode
• Link Aggregation
• ECMP Server #
Brief Mode
• Two hashing algorithms available
• Brief Mode:
• UDP/TCP ports not included
• Only Source IP and destination IP addresses are
considered
-> hash-control brief Switch Default Hasing Mode
AA Source Destination UDP/TCP AA
9900 extended AA Address Address Port AA
• Extended 6900 brief
• UDP/TCP ports to be included 6860 extended
in the hashing algorithm
• Result in more efficient
6865 extended Server #
load balancing 6560 extended
Extended Mode
-> hash-control extended [udp-tcp-port | no] 6465 brief
6360 brief
CLUSTER MODES
• SLB Cluster VIP
• Traffic destined to the Virtual IP of the Server Farm
• Each server is also configured with a Loopback Interface for the Virtual IP
• A server can be configured with more than one VIP
• Therefore, a server can belong to more than one SLB cluster
• SLB Cluster QoS Condition

• Traffic not destined to the server
• i.e : firewall server simply inspects the packet and sends it back if accepted by the Firewall policies
VIP MODE (L3 ONLY)
• Configuring VIP SLB cluster in a routed network
-> ip slb cluster <cluster_name> vip <vip_address>
-> ip slb cluster WebServer vip 10.0.0.250

-> ip slb server ip 10.0.0.1 cluster WebServer
VIP 10.0.0.250 (WebServer)

Access the VIP
VLAN 10
IP@ 10.0.0.254 Server 10.0.0.1
VLAN Server 10.0.0.2

VLAN 11
10
L3 Network Server 10.0.0.3
Route to reach VIP Switch Router
SLB enabled L2 switch
Routing from VLAN 11 to Server VLAN 10

VIP MODE (L3 ONLY)
• Configuring VIP SLB cluster in a Bridged network
-> ip slb cluster <cluster_name> vip <vip_address>
-> ip slb cluster WebServer vip 10.0.0.250

VIP 10.0.0.250 (WebServer)
Access the VIP
VLAN 10
IP@ 10.0.0.254 Server 10.0.0.1
10
L3 Network
Route to reach VIP Server 10.0.0.3
Switch
SLB enabled L2 switch
Proxy ARP to 10.0.0.250 is used in a bridged network and will force the
bridged packet to be routed
Bridging in VLAN 10
QOS CONDITION MODE
• Configuring QoS Condition SLB cluster in a Routed network
-> ip slb cluster <cluster_name> condition <condition name> L3
-> policy condition cond1 source port 1/1 destination tcp port 80
-> ip slb cluster Firewall condition cond1 L3
Cluster « Firewall »
Access the VIP
VLAN 10
IP@ 10.0.0.254 Server 10.0.0.1

VLAN 11
1/1 10
L3 Network
Route to reach VIP Switch Router
SLB enabled
Routing from VLAN 11 to Server VLAN 10

The server must be configure to receive packet with a destination
IP address that may not match any addresses known to the server.
QOS CONDITION MODE
• Configuring QoS Condition SLB cluster in a Bridged network
-> ip slb cluster <cluster_name> condition <condition name> L2
-> policy condition cond1 source port 1/1 destination tcp port 80
-> ip slb cluster Firewall condition cond1 L2
Cluster « Firewall »
Access the VIP
VLAN 10
IP@ 10.0.0.254 Server 10.0.0.1
Server 10.0.0.2
VLAN
1/1 10
L3 Network
Switch
Route to reach VIP
SLB enabled
Bridged Network
The server must be configure to receive packet with a destination MAC address
that is different than the MAC address of the server (i.e. promiscuous mode)
HEALTH MONITORING
• Health Monitoring of the servers based on
• Ethernet link state detection
• IPv4 ICMP ping
• Content Verification Probe
• 20 probes per switch
• Basic Probe - PING
• Application probes: ftp, http, https, mail (imap, imaps, pop, pops, smtp), nntp)
• Custom probes - tcp, udp
• Can specify interval, time-out, and retries
• Server States
• Disabled server has been administratively disabled by the user
• No Answer server has not responded to ping requests from the switch
• Link Down bad connection to the server
• Discovery switch is pinging a physical server
• In Service server can be used for client connections
• Retrying switch is making another attempt to bring up the server
SERVER LOAD BALANCING - PROBE CONFIGURATION
• Creating SLB Probes
-> ip slb probe <probe_name> {ftp | http | https | imap | imaps | nntp | ping |
pop | pops | smtp | tcp | udp}
• Associating a Probe with a Cluster or Server

-> ip slb cluster <cluster_name> probe <probe_name>
• Options
• Probe timeout (ms) and Period (sec)
• TCP/UDP Port
• URL / User Name / Password
• sent to a server as credentials for an HTTP(S) GET operation
• Send
• An ASCII string sent to a server to invoke a response
• Expect
• An ASCII string used to compare a response from a server
-> ip slb probe http_test http
-> ip slb probe http http_test period 10
-> ip slb cluster C1 vip 192.168.160.201
-> ip slb server ip 192.160.160.4 cluster C1 weight 2 probe http_test
-> ip slb server ip 192.160.160.4 cluster C1 weight 4 probe http_test
PROBE CONFIGURATION • http / https
• USERNAME
• URL
• ping • TIMEOUT
• TIMEOUT • STATUS
• RETRIES • RETRIES
• PORT • PORT
• PERIOD • PERIOD
• PASSWORD
• EXPECT
• tcp / udp
• TIMEOUT
• SSL
• SEND
• RETRIES
• PORT
• ftp / imap / imaps / pop / pops / smtp / nntp
• PERIOD
• TIMEOUT
• NO
• RETRIES
• EXPECT
• PORT
• PERIOD
SPECIFICATIONS
AOS specification
APPENDIX
ADDING AND CONFIGURING LOOPBACK ADAPTER
Appendix
ON WINDOWS SERVER
• Device Manager > Add Legacy Hardware
• Install the hardware that I manually select from a list (Advanced)
• Network adapters
• Microsoft > Microsoft KM-Test Loopback Adapter (Win 2k12)
• Microsoft > Microsoft Loopback Adapter (Win 2k8 r2)
• Starting with Windows Server 2008, Microsoft has implemented a strong host model which
disallowed the host to receive packets on an interface not assigned as the destination IP
address. To configure weak host mode, enter the following commands:
netsh interface ipv4 set interface <LAN Interface Name> weakhostreceive=enabled
netsh interface ipv4 set interface <Loopback Interface Name> weakhostreceive=enabled
netsh interface ipv4 set interface <Loopback Interface Name> weakhostsend=enabled
• Assign VIP address to the Loopback adapter

ADDING AND CONFIGURING LOOPBACK ADAPTER
Appendix
ON LINUX SERVER
• Add Loopback adapter
ifconfig lo:1 <VIPAddress> broadcast <VIPAddress> netmask 255.255.255.255
• Disable ARP replies

• In /etc/sysctl.conf add the following lines:
net.ipv4.conf.eth0.arp_ignore=1
net.ipv4.conf.eth0.arp_announce=2
THANK YOU
OmniSwitch R8
Server Load Balancing
How to
✓ This lab is designed to familiarize you with the server load balancing
feature on OmniSwitches.
Contents
1 Topology ........................................................................................ 1
2 Server Load Balancing configuration ....................................................... 1
2.1. Client Configuration ................................................................................ 1
2.2. Client VLAN configuration ......................................................................... 1
2.3. Loopback interface creation on clients ......................................................... 1
2.4. SLB configuration ................................................................................... 2
2.5. Demonstrate SLB ................................................................................... 3
2.6. SLB Load Balancing – Self Guided Section ....................................................... 3
3 Summary ........................................................................................ 4
4 Lab Check ...................................................................................... 4
1
1 Topology
Virtual Chassis
192.168.110.0 192.168.110.0
1/2/1-2 2/2/1-2
1/1/1 2/1/1
OS6900-A 1 OS6900-B 2
1/1/5 1/1/6 2/1/6 2/1/5 Client 2 VLAN 110
Client 1 VLAN 110
2 Server Load Balancing configuration

Server Load Balancing allows multiple servers to act as one. By assigning a virtual IP address, all traffic
destined for that IP address could be balanced among multiple servers.
2.1. Client Configuration

Client 2 :
IP : 192.168.110.102
Mask : 255.255.255.0
Gateway : 192.168.110.1
2.2. Client VLAN configuration

On the OmniSwitch 6900 Virtual Chassis, type the following:
You can now check client 2 connectivity by pinging its gateway interface.
2.3. Loopback interface creation on clients

On both clients (1&2), to manually install the Microsoft Loopback adapter in Windows XP, follow these steps:
Click Start, and then click Control Panel.
If you are in Classic view, click Switch to Category View under Control Panel in the left pane.
Double-click Printers and Other Hardware, and then click Next.
Under See Also in the left pane, click Add Hardware, and then click Next.
Click Yes, I have already connected the hardware, and then click Next.
At the bottom of the list, click Add a new hardware device, and then click Next.
Click Install the hardware that I manually select from a list, and then click Next.
Click Network adapters, and then click Next.
In the Manufacturer box, click Microsoft.
In the Network Adapter box, click Microsoft Loopback Adapter, and then click Next.
Click Finish.
Assign the following network properties to the Loopback interface
IP: 192.168.110.100 Mask : 255.255.255.0 no Gateway
2
2.4. SLB configuration

On the Virtual Chassis, perform the following commands:
sw1 (6900-A) -> ip slb admin-state enable
(This enables the Server Load Balancing feature)

sw1 (6900-A) -> ip slb cluster WorldWideWeb vip 192.168.110.100
(This creates a Server Load Balancing cluster with the virtual IP address of 192.168.20.100). We will now
assign servers to the cluster.
sw1 (6900-A) -> ip slb server ip 192.168.110.101 cluster WorldWideWeb
(This add the server with IP address 192.168.110.101 to the cluster)

sw1 (6900-A) -> ip slb server ip 192.168.110.102 cluster WorldWideWeb
The previous commands added two servers to the cluster named WorldWideWeb. Let’s view some of the SLB
configuration parameters. Type the following:
sw1 (6900-A) -> show ip slb
Admin status : Enabled,
Operational status : In Service,
Number of clusters = 1
sw1 (6900-A) -> show ip slb servers

Admin Operational %
IP addr Cluster Name Status Status Avail
---------------+-----------------------+--------+--------------+-----
192.168.110.101 WorldWideWeb Enabled In Service 100
192.168.110.102 WorldWideWeb Enabled In Service 100
sw1 (6900-A) -> show ip slb clusters

Admin Operational # %
Cluster Name VIP/COND Status Status Srv Avail
-----------------------+---------------+--------+--------------+---+-----
WorldWideWeb 192.168.110.100 Enabled In Service 2 100
sw1 (6900-A) -> show ip slb cluster WorldWideWeb

Cluster WorldWideWeb
VIP : 192.168.110.100,
Type : L3
Ping period (seconds) : 60,
Ping timeout (milliseconds) : 3000,
Ping retries : 3,
Redirect algorithm : round robin,
Probe : None,
Number of packets : 0,
Number of servers : 2
Hash type = ECMP
Server 192.168.20.101
Admin status = Enabled, Operational status = In Service,
Weight = 1, Availability (%) = 100
Server 192.168.20.102
-> show ip slb cluster WorldWideWeb server 192.168.110.101

VIP 192.168.110.100
Server 192.168.110.101
Admin weight : 1,
MAC addr : 00:50:56:A1:0D:35,
Slot number : 1,
Port number : 1,
Oper status : In Service,
Probe : None,
3
Availability time (%) : 100,

Ping failures : 0,
Last ping round trip time (milliseconds) : 14,
Probe status : OK
2.5. Demonstrate SLB

Any requests to the 192.168.110.100 IP address will be load balanced to both servers.
From any client, bring up a WEB browser and enter the URL address http://192.168.110.100
You should see the home page of the Server. This is because the OmniSwitch is forwarding the http
request to the virtual IP address to one of the servers participating in SLB.
Type the following:
sw1 (6900-A) -> show ip slb cluster WorldWideWeb
VIP : 192.168.110.100,
Type : L3,
Ping period (seconds) = 60,
Ping timeout (milliseconds) = 3000,
Ping retries = 3,
Probe = None,
Number of packets = 2,
Number of servers = 2,
Hash type = ECMP
Server 192.168.110.101
Server 192.168.110.102
You will see that one of the servers has a flow associated with it. Change the ip address of the client 5 and
connect again to the vip web server, you should be associated with another one.
2.6. SLB Load Balancing – Self Guided Section

Use the knowledge gained from lecture and previous sections of this lab to configure WRR load balancing
and backup scenario, hashing modes (brief or extended).
4
3 Summary
This lab introduced the configuration of the Server Load Balancing feature of an OmniSwitch. Load
balancing can be used to distribute traffic over multiple servers. This is done using a virtual IP address for
all client requests;
4 Lab Check
- What is an advantage of configuring SLB?
.........................................................................................................................
.........................................................................................................................
- What is the purpose of the Virtual IP address?
.........................................................................................................................
.........................................................................................................................
- What is the purpose of the MS Loopback Adapter?
.........................................................................................................................
.........................................................................................................................
OMNISWITCH R8
A O S O M N I S W I T C H - U P G R A D E S O F T WA R E I M A G E
OBJECTIVES
• Describe how to upgrade a Software

image on a switch
UPGRADE SOFTWARE IMAGE
Step by step
Download the Upgrade Files
Analyse Requiremen ts on the release note
FTP the Upgrade Files to the Switch
Upgrade the image file
Verify the Software Upgrade
Upgrade uboot and/or FGPA if mandatory
Certify the Software Upgrade

Step by step
Download the Upgrade Files

Download and unzip the upgrade files for the appropriate model and release
OS6465 OS6860
OS6360 OS6860N 0S6900 0S9900
OS6560 OS6865
Configuration files vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg vcboot.cfg

vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg vcsetup.cfg
image files (AOS) Nosa.img Nos.img Uos.img Uosn.img Tos.img Mhost.img

Mos.img
Yos.img Meni.img
(V72/C32/X48C6/T48C6/X48C4E/V48C8)
From BPWS
Step by step
Analyse Requiremen ts on the release note

▪ Memory Requirements
▪ UBoot and FPGA Requirements
▪ Upgrade Instructions
▪ …
FTP the Upgrade Files to Running directory of the switch

▪ FTP/SFTP/SCP Client or Server
▪ TFTP client
▪ USB
▪ Webview
▪ OmniVista 2500
* Note Running directory ; working or user defined directory

Step by step
Upgrade the image file

▪ Reload the switch from the Running Directory
Verify the Software Upgrade

▪ Display version installed
▪ Display the version running in CMM
Note: If there are any issues after upgrading the switch can be rolled back to the previous certified version
Step by step
Upgrade uboot and/or FGPA if mandatory

▪ In addition to the AOS images, archive will also contain an uboot and FPGA upgrade kit.
▪ If require (Release note)
▪ FTP (Binary) the FPGA upgrade kit and /or Uboot upgrade tar.gz to the /flash directory (primary CMM)
▪ Reload from running directory
-> update uboot cmm all file u-boot.8.4.1.R03.141.tar.gz
-> update fpga-cpld cmm all file fpga_kit_3312
-> reload from working no rollback-timeout
Note: The command show hardware-info is used
Certify the Software Upgrade

▪ Verifying the software and that the network is stable
▪ Certify the new software
-> copy running certified
THANK YOU
OMNISWITCH R8
A C C E S S G U A R D I A N - C A P T I V E P O R TA L
OBJECTIVES
• Describe and Manage the Captive Portal
• Monitor the Captive Portal configuration

CAPTIVE PORTAL - OVERVIEW
CAPTIVE PORTAL - OVERVIEW
• Web Portal for getting user credential

• Could be applied to supplicants and non-supplicants
• When an authorized user launches a browser a web page is served to ask for credentials
• Still requires RADIUS for authentication
• Has its own fail/pass policies AAA Radius
http://www.alcatel-lucent.com
You have to log in fist!
• Useful for guest or contractor to temporarily gaining controlled network access to the
enterprise network
• Integrated with the rest of the policies
CAPTIVE PORTAL - ANOTHER ACCESS GUARDIAN POLICY
Supplicant?
Yes No
MAC No
802.1X authentication
auth
Pass Fail Pass Fail
Captive
RADIUS Profile RADIUS Profile Portal
Captive Portal Captive Portal Captive Portal Captive Portal Pass Fail
Group mobility Captive Portal Group mobility Group mobility Group mobility
Profile Profile Profile Profile Profile RADIUS Profile
Block Block Block Block Block Group mobility
Profile Profile
Block
Block
Policies can be interchanged
Some policies (Captive portal, Profile, Block) are terminal policies (cannot be followed by other policies)
Captive Portal policy will start a new authentication branch
“Fail” branches will only classify devices into non-authenticated Profiles
CAPTIVE PORTAL - EXAMPLE
Supplicant?
Yes No
Captive
MAC
802.1X Portal
auth
Pass Fail Pass Fail Pass Fail
Radius Profile
Captive Portal Group mobility Captive Portal

Profile
Enterprise users with Known devices (printers, Unknown users

802.1X capable devices IP phones, etc.) (guests, contractors)
Default VLAN Block Block

CAPTIVE PORTAL - CONCEPT
AAA Radius
Supplicants
or http://www.alcatel-lucent.com
non-supplicants user
DHCP
1 Offer
Switch DHCP and DNS Server
DHCP
Default DHCP scope
Request
10.123.0.0/16
Def GW: 10.123.0.1
DNS server: 10.123.0.1
1 DNS Request
Pre authentication phase Authentication phase

2
HTTP redirect to
captive portal login
CAPTIVE PORTAL - CUSTOMIZATION
• Logo
• Welcome text
• Background image
• Company policy file
• Customizable banner image
• Associated Help pages
R8
/flash/switch/captive_portal/custom_files
/assets My Company Welcome text message
/images/logo.jpg
/pages/cportal_policy.pdf
/scripts/cportal_scripts.js
/styles/cportal_style.css
/templates
cportal_login.html
cportal_redirect.html
cportal_status.html
error404.html
qmr_quarantined.html
unauth.html
CAPTIVE PORTAL - CUSTOMIZATION
• Configuring a different subnet for the Captive Portal IP address

-> captive-portal ip-address 10.124.0.1
• URL redirection
• capability of redirecting the user to a
• Redirection URL upon successful authentication
• Redirection URL upon failure/bypass authentication (not supported in R8)
-> captive-portal success-redirect-url http://test-cp.com/success.html
• Configuration
-> unp profile profile_name captive-portal-authentication
Used when successful CP auth does not return a VLAN ID,

returns a VLAN ID that does not exist, or when CP auth fails
ACCESS GUARDIAN – PORT-TEMPLATES
• AAA Profile
• Specifies the default AAA profile for the port Template
• Default Edge-Profile
• When template is attached to UNP port/linkagg any existing default profile is overridden
• Pass-alternate
• If classification does not return a valid UNP then the pass-alternate is assigned
ACCESS GUARDIAN - APPLICATION EXAMPLE
SUPPLICANT/NON-SUPPLICANT WITH CAPTIVE PORTAL
AUTHENTICATION
• Corporate supplicant device • Guest non-supplicant device
• Passes 802.1X authentication • Fails 802.1X authentication
• Assigned a UNP-corporate • Fails MAC authentication
• Corporate user with non-supplicant, • Get temporary UNP-captive_portal
non-corporate device • Captive Portal assign UNP-guest after successful
authentication
• Does not trigger 802.1X authentication
• Fails MAC authentication • Allowed devices
• Get temporary UNP-captive_portal • Passes MAC authentication
• Captive Portal assign UNP-corporate after • Assigned a UNP-allowed_devices
successful authentication
• Guest supplicant device
• Fails 802.1X authentication
• Get temporary UNP-captive_portal
• Captive Portal assign UNP-guest after successful
authentication
AUTHENTICATION
Yes No
Supplicant?
MAC
802.1X auth
Fail Pass
Pass Fail
UNP_Corporate
UNP_devices
Captive
Portal
Pass Fail
UNP_Guest
UNP_Corporate
Block
AUTHENTICATION
1. Configure a RADIUS Server
-> aaa radius-server radius_server host 10.2.3.4 hash-key secret
2. Configure authentication parameters

-> aaa device-authentication 802.1x radius_server
-> aaa device-authentication mac radius_server
-> aaa device-authentication captive-portal radius_server
3. Create the required VLANs

-> vlan 10 name "corporate"
-> vlan 20 name "guest"
-> vlan 30 name "devices"
-> vlan 40 name "captive_portal"
AUTHENTICATION
4. Create the required User Network Profiles and map then to the associated VLAN
-> unp profile "UNP-corporate"
-> unp profile "UNP-guest"
-> unp profile "UNP-devices"
-> unp profile "UNP-default"
-> unp profile "UNP-captive_portal"
-> unp profile "UNP-corporate" map vlan 10
-> unp profile "UNP-guest" map vlan 20
-> unp profile "UNP-devices" map vlan 30
-> unp profile "UNP-captive_portal" map vlan 40
-> unp profile "UNP-captive_portal" captive-portal-authentication
AUTHENTICATION
5. Configure authentication on bridge port
-> unp port 1/1/1 default-profile UNP-captive_portal
-> unp port 1/1/1 802.1x-authentication enable pass-alternate UNP-corporate
After successful 802.1x authentication, if the RADIUS server doesn't return a valid UNP, force UNP-corporate. If 802.1x fail, then
device is assigning the UNP-captive_portal for which captive portal configuration is set.
-> unp port 1/1/1 mac-authentication enable pass-alternate UNP-devices

After successful MAC authentication, if the RADIUS server doesn't return a valid UNP, force UNP-devices. If MAC fail, then device
is assigning the UNP-captive_portal for which captive portal configuration is set.
-> captive-portal authentication-pass profile UNP-guest

After successful Captive Portal authentication, if the RADIUS server doesn't return a valid UNP, force UNP-guest.
THANK YOU
OMNISWITCH R8
IS-IS
OBJECTIVES
• Describe the characteristics of the IS-IS Routing

protocol
IS-IS CONCEPTS AND BASIC SETUP - AOS SPECIFICATIONS
• Maximum number of (per router) • 3373-Three-Way Handshake for Intermediate

System to Intermediate System (IS-IS) Point-to-
• Areas - 3
Point Adjacencies
• Maximum number of L1 adjacencies 70
• 3567-Intermediate System to Intermediate
• Maximum number of L2 adjacencies 70
• System (IS-IS) Cryptographic Authentication
• Maximum number of IS-IS interfaces 70
• 2966-Prefix Distribution with two-level IS-IS (Route
• Maximum number of Link State Packet Entries 255 Leaking) support
• Maximum number of IS-IS routes 24000 • 2763-Dynamic Host name exchange support
• Maximum number of IS-IS L1 routes 12000 • 3719-Recommendations for Interoperable
• Maximum number of IS-IS L2 routes 12000 Networks using IS-IS
• 3787-Recommendations for Interoperable IP
• RFCs Supported • Networks using IS-IS draft-ietf-isis-igp-p2p-over-
lan-05.txt-Point-topoint operation over LAN in
• 1142-OSI IS-IS Intra-domain Routing Protocol
link-state routing protocols
• 1195-OSI IS-IS for Routing in TCP/IP and Dual
• 5308-IS-IS support for IPv6 (Routing IPv6 with IS-IS)
Environments
IS-IS BASICS IS-IS Routes
Router A
10.0.0.0: cost 30 via Router C
• IS-IS Overview *10.0.0.0: cost 20 via Router B
* = Best path
• OmniSwitch based on RFC 3787
• Link-state driven updates, periodic hellos A
Packet Flow
• Uses the SPF algorithm to determine routes
• Area hierarchy, ASs use a two-level hierarchy
• Support for authentication C Cost:10 Cost:10 B
<
• Support for VLSM and CIDR Cost:10
• Routing interface parameters
10.0.0.0
• Layer 2 multicast addressing
• IS-IS TE extensions • IS-IS uses SPF for path determination.
• SPF uses cost values to determine the best
path to a destination.
IS-IS - ISO NETWORK ADDRESSING
• Each IS-IS Router is known as an “Intermediate System”

• IS-IS uses unique addressing (OSI NSAP addresses)
• Each address identifies the area, system, and selector.
AFI IDI High Order-DSP System ID NSEL

49.0002 18B6.A345.0BF1 00
Area ID System Address NSEL
• Level 1 routing uses the system ID.

• Level 2 routing uses the area address.
• 2 nodes cannot have the same NSAP address.
• 2 nodes within an area cannot have the same system ID.
• The minimum NSAP using local authority is 8 bytes (1 for area, 6 for system, 1 for SEL).
• The area ID must be minimum 1 byte.
• The AFI should be set to 49 for locally administered IS-IS configurations.
NSAP ADDRESSING
• Red - the locally administered area ID of each router.

• Blue - the system ID of each router.
• Black - the NSEL default of “00”.
00:d0:95:f3:c8:ba
{Area-ID} {System-ID} {NSEL}

49.0002.00D0.9501.0101.00 49.0003.00D0.9501.0103.00
Area 49.0002
Area 49.0003
L1/L2
L1
L1 L1/L2
49.0002.00D0.9501.0102.00 49.0003.00D0.9501.0104.00
IS-IS — PACKET FORMAT
• IS-IS packets use layer 2 encapsulation of the media.

• IS-IS uses Ethernet 802.3/802.2 instead of the Ethernet II used for IP traffic.
• The TLV identifies the type of information in the IS-IS packet.
• IS-IS packets are called PDUs.
MAC LLC IS-IS

IS-IS TLV FCS
Header Header Header
• PDUs are encapsulated directly into the layer 2 frame.

• There are 4 types of PDUs:
• Hello (ESH, ISH, and IIH) — Maintain adjacencies
• LSP (link-state packet) — Information about neighbors and links, generated by all L1 and L2 routers
• PSNP (Partial Sequence Number PDU) — Specific requests and responses about links, generated by
all L1 and L2 routers
• CSNP — Complete list of LSPs exchanged to maintain database consistency
IS-IS - TERMS
• DIS
• The IS in a LAN that is designated to perform additional duties. In particular, the DIS generates
link-state PDUs on behalf of the LAN, and treats the LAN as a pseudo node.
• Pseudo node
• When a broadcast subnetwork has n connected ISs, the broadcast subnetwork itself is considered to
be a pseudo node. The pseudo node has links to each of the n ISs and each of the ISs has a single
link to the pseudo node (rather than n-1 links to each of the other ISs). Link-state PDUs are
generated on behalf of the pseudo node by the DIS.
IS-IS - HELLO PACKET FORMAT
• Used to discover neighbors and elect the DIS

• Sent every 9 seconds from L1 and L2 routers, if they are not the DIS
• Sent every 3 seconds from the DIS in broadcast multi-access networks
• 3 different formats:
• Level 1 and Level 2 in broadcast subnetworks
• Point-to-point in general topology subnetworks
• Highest priority elects the DIS for both L1 and L2 in broadcast networks
• Highest interface MAC address is the tiebreaker if priorities are equal
• DIS assigns the subnetwork ID (DIS NET + SEL)
LINK-STATE PDU (LSP) FORMAT
• Slightly different formats for L1 and L2 LSPs

• LSP Identifier indicates which router created the LSP
• Sequence number indicates relative age of the LSP
• When a router creates a new LSP, the sequence number is incremented.
• Reachability information is provided for all local networks from the router that created the
LSP:
• Network prefix
• Metrics
• IP mask
• An L1 LSP is flooded to all other L1 routers in the area.
• An L2 LSP is flooded to all other L2 routers in the network.
COMPLETE SEQUENCE NUMBER PDU FORMAT
• CSNPs used to maintain consistency of link-state database

• Contains list of router’s LSPs and their sequence numbers.
• A router that receives a CSNP that includes out-of-date LSPs will transmit up-to-date LSPs.
• CSNPs are exchanged at router initialization and periodically afterward to maintain
synchronization.
• Every 10 seconds on broadcast network
• Every 5 seconds on point-to-point link
• For each LSP in its database, the CSNP contains:
• Remaining life of the LSP, in seconds
• LSP ID
• LSP sequence number
• Checksum value
PARTIAL SEQUENCE NUMBER PDU FORMAT
• PSNPs are used by routers to request a specific LSP.

• PSNPs are also used on point-to-point links to acknowledge the receipt of an LSP (but not
on a broadcast link).
• A PSNP is similar to a CSNP except that it is a subset of the LSPs from the database.
• A PSNP describes one or more LSPs and contains the following information for each:
• Remaining life of the LSP, in seconds
• LSP ID
• LSP sequence number
• Checksum value
IS-IS – NETWORK TYPES
• IS-IS only supports:

• Broadcast for LAN and multipoint WAN topologies
• Point-to-point for all other topologies
• When IS-IS implemented in an NBMA network:
• Broadcast mode assumes fully meshed connectivity.
• Point-to-point assumes true point-to-point connectivity.
• LAN and multipoint WAN topologies require the election of a Designated Intermediate
System DIS.
• Hellos are used to create adjacencies and determine router priority.
• The DIS is elected based on the following criteria:
• Only routers with adjacencies are eligible.
• Highest interface priority
• Highest interface MAC address
IS-IS – DIS ELECTION FOR L1 AND L2 ROUTERS
• L1 and L2 routers can elect separate DIS routers.

• DIS election is based on priority and/or the highest MAC address and is preemptive.
• L1 and L2 can have separate priorities set.
• The DIS creates the pseudo node and floods updates over the LAN.
L1 L1/L2 L2
L1 L1 L2
IS-IS — PACKET EXCHANGE
• L1 and L2 adjacencies use the same procedure.

• Adjacency is established when a valid IIH is received:
• L1 adjacency if area IDs are the same and the circuit is L1
• L2 adjacency if the circuit is L2
• The initial exchange of IIHs establishes the type of adjacency.
• The 2-way handshake depends on a reliable circuit.
• A unique local circuit ID is determined by each IS configuration.
• The link’s circuit ID is set by the system with the higher source ID.
• Concatenation of system ID and local circuit ID
• Both sides exchange CSNPs.
• Update reliability is accomplished by:
• Sending PSNP for all new and duplicate LSPs
• Answering older LSPs with newer LSPs
CONFIGURING IS-IS
• Minimum configuration (single area)

-> ip load isis
-> ip isis admin-state enable
-> ip isis area-id 49.0001
-> ip isis activate-ipv4
-> ip isis vlan 5
-> ip isis vlan 5 address-family v4
-> ip isis vlan 5 admin-state enable
IS-IS - CLI COMMANDS
• Interface configuration
-> ip isis level-capability level-1
-> ip isis level-capability level-2
-> ip isis level-capability level-1/2
-> ip isis vlan 10 level-capability level-1/2
• Monitoring
-> show isis status
-> show ip isis vlan
-> show ip isis vlan detail
-> show ip isis route
-> show ip isis spf
-> show ip isis adjacency
IS-IS - AREA TYPES
Area 01 Area 02
L1 L1/L2 L1/L2
L1 L1
L1
Area 04
Area 03 L1/L2
L1/L2
L1 L1 L1
THANK YOU
OMNISWITCH R8
INTERNET OF THINGS (IOT)
OBJECTIVES
• Describe IoT Device Profiling feature

• Describe Device Profiling steps
IOT - DEVICE PROFILING OVERVIEW
OVERVIEW
• IoT Device Profiling monitors the devices connecting to the network, detects and profiles
the devices at the switch level
• Device Profiling consists of three main components:

• A local signature collector local
profiler
• A local profiler
• UNP profiling
OmniSwitch®
Signature
DB
DP enable UNP
OVERVIEW
• IoT (Internet of Things) device profiling allows network administrators to support and
manage smartphones, tablets and other devices connecting to the network.
• IoT device profiling uses DHCP FingerPrinting and MAC OUI to identify IoT devices.
AAA Radius
OmniSwitch®
Employee DB
IoT Device Profiling

MAC OUI
DHCP fingerprint
Contacts DB
Internet
OVERVIEW
• MAC OUI: allows devices to be recognized by identifying their MAC addresses.
• DHCP FingerPrinting: allows to track the devices on the network and block those are not
allowed access. It also helps in analyzing the future growth by accessing the trending
information.
OmniSwitch®
DP
interface
DP enable
Example:
Microsoft Windows XP option 55
DHCP client request 1,15,3,6,44,46,47,31,33,249,43
DHCP option 55 (the parameter request list) Apple iPhone
and option 60 (the vendor identifier) 1,3,6,15,119,78,79,95,252
Or
[Mac Vendors]
DEVICE PROFILING STEPS
Signature • Collect signature and various packet meta data
collector required for IoT device identification

MAC OUI
DHCP fingerprint
Local • Identify the IoT devices based on local device
profiler signature database
Signature • Use the meta data received from signature

DB collector for identifying the IoT device and its
category
DEVICE PROFILING STEPS
UNP • When a device gets identified and categorized,

the UNP profile can be automatically assigned to
the device.
UNPs for IoT device categories such as PoE
camera, Temperature sensor, heart-rate monitor,
MAC OUI
medical imaging etc for the identified device.
DHCP fingerprint
Device
• Maintain a database of identified IoT
devices and un-identified IoT devices Unknown
Known
Device DB
Device DB for qualitative and quantitative
analysis.
• Admin can classify the unidentified IoT devices

based on UNP of choice and update database.
THANK YOU
OMNISWITCH R8
SIP SNOOPING
OBJECTIVES
• Describe SIP Snooping feature

OVERVIEW
• Identify, Mark, Treat and Monitor

• Allow the configuration of SIP policy rules
• QOS treatments for the media streams / RTP flows being established between the SIP user
agent endpoints.
• Each media stream contains RTP and RTCP flows.
• Marking is done using the DSCP field in IP header.
• Provide user configured QOS treatment for SIP/RTP/RTCP traffic flows based on its marking.
• QOS treatment will be done by mapping DSCP to queue number and drop precedence
• Calculate QOS metric values of delay, jitter, round trip time, R factor and MOS values of
media streams from its corresponding RTCP.
• Raise trap when any of QOS metrics cross user defined threshold.
• By default, the SIP packets forwarded by hardware are not subject to any specific QOS
treatment.
• The packets are treated as normal packets and follow the same QOS treatment according
to qos port or policy rules configuration.
OVERVIEW
• SIP network Components

• Edge switches, aggregation switches and core switches SIP Proxy
(Call server)
• SIP Server (registrar, proxy, redirect, gateway)
• SIP Phones (User Agents) Core
SIP signaling
• SIP snooping operation
• A SIP ACL triggers the setup of HW with SIP keywords:
INVI, UPDA, BYE,…
• Match on keywords copies packet to CPU: “snooping” RTP/RTCP flows
• Once RTP and RTCP ports have been negotiated

• ACL is setup in HW for the 4 flows (2 x RTP, 2 x RTCP) Access
• RTCP flows are duplicated to CPU for analysis
Other
Video
• When call Ends, HW resources taken for RTP/RTCP are

Other
Voice
freed up Video
Voice
• On edge switch, QOS treatment is enforced for

both ingress and egress media streams
IDENTIFICATION OF SIP PACKETS
• SIP packets are identified based on string value at the beginning of UDP payload.
• SIP responses always have SIP/2.0 at the beginning.
• SIP requests have their name at the beginning.
• SIP packets are identified by doing lookup at starting of UDP payload.
• SIP/2.0
• INVITE
• ACK
• PRACK
• UPDATE
• BYE
• SIP Snooping supports a 4 byte lookup, only “INVI” lookup will be done instead of complete
INVITE.
OmniSwitch AOS Release 8 Network Configuration Guide ---> Chapter: Configuring SIP Snooping
THANK YOU
END OF TRAINING EVALUATIONS
C L A S S R O O M S E S S I O N O R V I RT U A L C L A S S S E S S I O N
YOUR FEEDBACKS ARE
IMPORTANT!
Thank you to complete the training

evaluation online survey before leaving
your session.
You must complete the end of training

evaluation to be able to download your
training certificate of attendance.
LOGIN TO ALE KNOWLEDGE HUB
• Connect to ALE Knowledge Hub (https://enterprise-education.csod.com ) with your usual

credentials
ACCESS TO THE ONLINE EVALUATION SURVEY (1/2)
• Click on My Training on the home page
• Search for the training course by the reference provided by your instructor
ACCESS TO THE ONLINE EVALUATION SURVEY (2/2)
• From the session, select Evaluate in the dropdown menu and follow the instructions
OR
• From the curriculum, select Open Curriculum
• Then select Evaluate in the dropdown menu associated to the session and follow the
instructions
THANK YOU
Find a Course
Browse our catalog available on https://enterprise-education.csod.com/ to find your training path
and course detail.
Feedback
In order to improve the quality of the documentation, please report any feedback and address to:
Alcatel-Lucent Enterprise
115-225 rue Antoine de Saint-Exupéry
ZAC Prat Pip – Guipavas
29806 BREST CEDEX 9 – France
FAX: (33) 2 98 28 50 03
or mail to: [email protected]

Dt00xte220en 17

Uploaded by

Copyright:

Available Formats

Dt00xte220en 17

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dt00xte220en 17

Uploaded by

Copyright:

Available Formats

OMNISWITCH LAN - R8

Your opinion counts!

Reach the session evaluation

Standard class hours Break Badges for participants Internet access

• OmniSwitch R8 - Portfolio Description • VLANs Management

• AOS OmniSwitch Management • Basic Switch Management & Diagnostic

• Multiple Spanning Tree Protocol (MSTP)

Day 3 • Open Shortest Path First (OSPF)

Day 4 • Security Network

Day 5 • Ethernet Ring Protection

• Training & Certification

• RFC Technical documents

Document showcasing the networking products designed by ALE.

• Describe Remote-Labs (R-Labs) topology

- Username: LanpodXa ou LanpodXb (X = R-Lab Number)

6900-A : Model 6900T24C2

Or 6900-A : Model 6900T20

Switch Interface IP address

6860-B EMP 10.4.100+Pod#.8

• AAA Training Server POD x

• The OmniVista 2500 is reachable

• DNS server on the client : 10.0.0.51

• If Internet access is required for VM clients,

• List the OmniSwitch models and their

WLAN OmniAccess Stellar Wi-Fi 6E OmniAccess

Management Location Based Asset Tracking SERVICES

MAIN CHARACTERISTICS 8 fixed 10/100/1000 Base-T ports

IEEE 1588v2 PTP support Model OS6465(T)-P12

MAIN CHARACTERISTICS 24 x 10/100/1G Base-T POE+ ports

A perpetual Metro license is required to enable this functionality.

CPE Test Head

Fibre aggregations • Separately orderable 19" rack

Application monitoring enforcement OS6860(E)-(P)48 (D)

Click for More details on datasheets

TYPICAL DEPLOYMENT Model OS6865-U28X

10800W of inline PoE power OS9907-Fan tray

TYPICAL DEPLOYMENT OS99-XNI-48

Converged campus networks OS99-XNI-U48

• Brand and campus workgroups Model OS2360-U24X

Uplinks 1 Gbps 1/10 Gbps

Software AOS 8 base AOS 8 base AOS 8 base AOS 8 base

• Network Protection • Secure Diversified Code

• Describe the different possibilities of connection

OXO R > 9.1

-> no aaa authentication http

-> show aaa authentication

-> no aaa authentication http

The Local userDB file is named userTable8

*User login information and user privileges

* Up to 64 users can be configured in the local switch database

Login to the Console Port

1 RJ45 – Port console 2 USB - RS232 3 Micro-USB - USB 4 Micro-USB - RS232

More information about

Note: the configuration for the 6900 V72 / C32,

Speed (baud) : 115200

USB Ethernet Dongle (8.9.R1)

• The EMP port IP address of the master chassis

Secure Shell public key authentication Password

-> show webview