Though router on a stick is not on current TSHOOT Topologies that I see, and will more likely be SVI’s that you are troubleshooting, I wanted to add some notes on here pertaining to that subject as well for possible dated real life scenarios of dated networks.
Quick review of Router on a Stick Troubleshooting
Router on a stick is used when the Cisco switches are running at Layer 2, and have to uplink to a Router to handle L3 routing between VLANs, so just a quick review of how to even configure ROAS since it is not a normal configuration in modern networks.
On the PC
- Make sure IP Address, Subnet mask, and Default Gateway are correct
- Default Gateway will be Routers sub-interface for ROAS
On the Switch
- Create Trunk Nonegotiate (not dynamic at all) use Dot1q encap
- Make sure no VLANs are being disallowed from traversing the Trunk
On the Router
- “int fa1/1.100” , “encap dot1q 100”, “ip add 192.168.100.1 255.255.255.0”
- Use the above config for each VLAN / Subinterface on the physical interface that is connecting to the Trunk Uplink to the Router
Dynamic Trunking will not work, ISL will not work, and you will want to confirm the Trunk allows traffic and IP addressing is correct / PC’s are connect to interfaces on the switch in the proper VLAN (“sh mac address-table dyn”), etc
Switched Virtual Interface (SVI) Troubleshooting
SVI’s are much more common and likely what will be found both on the TSHOOT exam and in real world networks, and are fairly straight forward, the following are some necessary configs for them to work / how to verify them / possible issues.
For an SVI to Up/Up and Functioning properly
- Must have one port (Access or Trunk) in an STP FWD state in the VLAN corresponding to the SVI configured
- Must not be administratively shutdown
- VLAN must exist locally on the switch the SVI is on
- “ip routing” must be configured globally for hosts to communicate between two or more VLANs on a single switch
Reasons for connectivity issues
- PC may have incorrect IP info, may be in wrong VLAN on switch
- SVI may have incorrect IP info, may be down due to one of the requirements not being met
- Trunks can cause the SVI to be down if there is a mismatch with encapsulaton / mode / native vlan / VLAN being pruned on Trunk manually or via VTP
Verification commands to troubleshoot
- “ipconfig /all” – On PC to verify IP information and MAC Address
- “sh mac address-table dyn” – To verify Host is being learned, in correct VLAN
- “sh int trunk” – To verify no trunking issues as described above
- “sh vlan brief” – To verify L2 VLAN exists locally on switch, and which ports are associated with the VLANs listed
- “sh ip int brief” and “sh int vlan #” to verify VLANs IP info and State
- “ip routing” – If the IP Route table is empty, “ip routing” needs to be enabled to allow for inter-VLAN routing to occur
Routed Port Troubleshooting
Switchports are Layer 2 by default even on L3 Switches, but certain ports can be made “Routed” to allow the switch to learn of networks via Dynamic Routing protocols, or to configure a Layer 3 link to a network segment that does not require Layer 2 protocols such as a Layer 3 EtherChannel that may be connected to a high utilization server.
To configure a working Routed Port on a switch:
- “ip routing” in global configuration
- “no switchport” on the interface
- “ip address x.x.x.x y.y.y.y.y” on interface
- “no shutdown” on interface
The main difference between a Routed Port and an SVI, is that a Routed Port is considered a network boundary for a single interface, whereas an SVI is a network boundary for all interfaces associated to its VLAN.
To verify a port is Switched or Routed, “sh int (int) switchport” output will have “Switchport: Disabled” if the port is Routed / Layer 3.
Some characteristics to note regarding an MLS Routed Port:
- No VLAN association
- Has full routing capapbilities
- Runs no Layer 2 protocols like STP or DTP
- Does not support sub-interfaces like a router interface
- Useful for uplinks to devices that do not need Layer 2 protocols or information
- Routing must be enabled, just like with SVI interfaces, or for ANY routing to occur
Routed ports must connect to other Routed Ports, router interfaces, or can connect to Host devices such as a Server. They can be confirmed by viewing the interface with “sh run int gi1/1” (or whichever port #), and see the output shows no switchport / an ip address / no shutdown. If “sh run” output is not available, use the “sh int (int) switchport” to confirm “Switchport: Disabled” shows in the output.
Layer 3 EtherChannel Troubleshooting
A collection of Routed Port links can be logically bundled together the same way a Layer 2 collection of links is bundled, to create a Layer 3 EtherChannel.
Before listing what CAN go wrong with Layer 3 EtherChannels, it is important to note that Layer 2 protocols do not run over these link types, so STP / DTP / Native VLAN mismatches / anything Layer 2 related will not cause an issue with L3 EtherChannel.
Now things that do need to match / can cause issues:
- All settings for bundled ports should be identical on both sides of the link such as speed, duplex, etc
- Layer 2 EtherChannels can be made be issuing “channel-group # mode (mode)” across a range of interfaces, for Layer 3 it is expected that you make the Port-Channel interface first THEN associate the range of bundled ports to that Port-Channel # (will post link to exact configuration below)
- Mismatched EtherChannel modes are the same matrix as Layer 2, PAgP must have one side “Desirable” and LACP must have one side “Active” or the EtherChannel will not form, for “On” mode both sides must be “On” to form, modes cannot be mixed and Auto-Auto or Passive-Passive will not form an EtherChannel
- Inappropriate EtherChannel load-distribution is still a consideration, as you don’t want load-distribution set to “dst-ip” when an entire VLAN is trying to access one server, or the algorithm will always result in one link out of the entire bundle being chosen for all traffic
Verification commands for L3 EtherChannel
SW1#sh ether summ
Flags: D – down P – bundled in port-channel
I – stand-alone s – suspended
H – Hot-standby (LACP only)
R – Layer3 S – Layer2
U – in use f – failed to allocate aggregator
M – not in use, minimum links not met
u – unsuitable for bundling
w – waiting to be aggregated
d – default port
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
——+————-+———–+———————————————–
12 Po12(RU) PAgP Fa1/0/13(P) Fa1/0/14(P) Fa1/0/15(P)
13 Po13(SU) LACP Fa1/0/1(P) Fa1/0/2(P) Fa1/0/3(P)
Fa1/0/4(P)
SW1#
This shows a Layer 2 and Layer 3 EtherChannel in the output, showing the ports as (P) which means its part of the bundle for that Port-Channel, this information can also be found when looking at “sh int po#” as it will show the bundled interfaces.
I highly advise checking out these two links to learn more about EtherChannel configuration / verification if you are not already VERY familiar:
In depth explanation of EtherChannel configuration and verification
Cisco’s Best Practice for Layer 3 EtherChannel Configuration – NEED TO KNOW!
That concludes the look at these few topics
I would highly encourage labbing these topics very heavily as seen in the links posted above, as I’ve found I needed to run into configuration issues and have links suspended and struggle to get it to work to fully understand it.
I would go beyond just using a Boson Exam simulator to confirm you understand the topics, I would make sure to lab this several times until you can configure and verify these topics without referring to any study material!
The DEVNET GRIND! 