If you use the same name for all of your (MQC) QoS elements (class-map, policy-map, service-policy, etc), then you can easily see all of these elements with the section filter:
r3(config-cmap)#do sh run | sec FROM_FTP
class-map match-all FROM_FTP_SERVER
match access-group name FROM_FTP_SERVER
policy-map FROM_FTP_SERVER
class FROM_FTP_SERVER
bandwidth 256
service-policy output FROM_FTP_SERVER
ip access-list extended FROM_FTP_SERVER
permit tcp host 132.1.33.33 132.1.6.0 0.0.0.255 eq ftp
BitBucket has posted on what he did to pass the CCIE lab. There is a ton of good information in that post so I strongly encourage you to surf over and read it. Below are some of his words of wisdom:
Here are some words of wisdom:
1) Read the entire lab –> For you first timers, as nervous as you are, read all of the questions. The 20 minutes it takes you to look it over isn’t going to doom you.
2) Redraw the diagram –> This is optional for some. Personally, it gives me a sanity check on the layout. My 4-color Bic pen came in handy. By the time I left the lab, my scrap sheet had colored arrows and marks all over the place.
3) Alternate methods –> If you happen to practice just one method of accomplishing a task, try and figure out if there is another way. For example, if you can do something with an access-list, then know how to do it with a prefix-list.
4) Eat, sleep, and drink the IOS –> I spent all of November walking around like a zombie. The only thing on my brain was IOS and learning to think like a router. I also had dreams of solutions for some of the problems in my practice labs. It’s weird, but by the time I sat my lab, I was breaking everything down like Neo in the Matrix. It all just made sense.
5) Keep your answers simple –> Yes, we are led to believe that the lab is designed to fail us. That part is true, if you don’t know what you are doing. As creative as you want to be with your methods, don’t bother. It doesn’t get you any extra points and could probably hurt you later. Just figure out the simplest way of doing it. Have you ever logged into a router or switch configured by someone else and didn’t understand why it was configured that way? Keep it simple, enough for someone to follow your method.
6) Cleanup –> If you decide to use a tclsh script, remember to just type tclquit to get out. Or if you happen to use a macro on the switches for a ping test, remember to remove the macro name and description. I kept notepad open on the desktop and wrote down, ‘remove macros from switches’. When it hit 5PM, since I was pretty much done verifying my configurations, I started cleaning off the devices.
7) Get some rest (if you can) or clear your mind –> Thanksgiving is one of my favorite holidays. I love stuffing my face with turkey, but this year I couldn’t do so. Wednesday to Saturday was spent studying all day and night. I managed to step away for some grub, but it wasn’t the same. By the time Sunday rolled around, Sally’s relatives were planning on coming over to hang out. I could either hang out with everyone or sit in the study room cramping up my fingers and melting my brain some more. If I didn’t know the material at that point, then I wasn’t ready. I felt ready and chose to hang out. Played some Nintendo Wii, watched TV, talked, and just relaxed. I arrived in San Jose at 10PM, drove to the hotel, and just read some of the QoS sections on the DocCD until midnight. You would think that would put anyone to sleep, but there was some anxiousness stirring about in my system. I forced myself into bed and set my alarm for 7AM. I only slept until 5AM because my sleep was restless. I had cranked up the heat before going to bed and it just blew through the night. My room was a freakin sauna by the time I got out of bed. Rather than force myself back to sleep, I just got up and read some of my notes. Jumped in the shower at 6:30AM. Checked out out of the hotel and headed up the road to a Starbuck’s near the testing facility. Bought a Venti bold which was extremely hot. Checked in at the testing center and sat down in the lobby by 8AM. Just sat and enjoyed my coffee until it was time to enter the lab. Want to know why everyone tells us to get some rest the night before? After eating lunch, I started to feel that warm and fuzzy feeling once the food hit my stomach. By the time I sat back down at my rack, I was mentally and physically exhausted. I had to get up, go to the bathroom, and drink some aspirin I had in my pocket. Lucky for me the aspirin had enough caffeine to keep my awake until the end of the day.
Good luck to everyone pursuing the R&S track.
There’s a lot more stuff in his original post. Congratulations once again to BitBucket on getting his number.
I have an access server (actually an access router) running on my home lab. I connect to the console port of this 2500 and then make reverse telnet connections out to the devices in the pod. To jump from one device to another, I will use “control+shift+6+x” to return to the access server and then jump from there to the next device. So to go from r1 to r2 I would use “control+shift+6+x” to get to the access server, then type “2” to connect to r2. That’s what I intended to do when I encountered this output:
r1#x2
*
*?ERR
*
Type “exit” to return
Somehow I had messed up my key strokes and ended up entering “x2” on r1. This transported me into the strange, confusing world of the x28 emulation:
r1#x?
x28 x3r1#x2?
x28r1#x28 ?
debug Turn on Debug Messages for X28 Mode
dns Enable DNS based mnemonic address resolution
escape Set the string to escape from X28 PAD mode
noescape Never exit x28 mode (use with caution)
nuicud All calls with NUI, are normal charge with the NUI placed in Call
User Data
profile Use a defined X.3 Profile
reverse All calls default to reverse charge
verbose Turn on Verbose Messages for X28 Mode
<cr>
If this happens to you, just use “Shift-Ctrl-^-x” to get back to exec mode.
While it’s rare that you would accidently put your self in x.28 emulation mode, it is nice to know why your command prompt just went goofy and how to fix it. You don’t want to waste time troubleshooting this in the CCIE lab.
Cisco Documentation
I came across an interesting Frame Relay inverse-ARP issue:
Here’s my intitial configuration (Frame Relay inverse-ARP disabled):
r4(config-if)#do sh run int s0/0
Building configuration…Current configuration : 136 bytes
!
interface Serial0/0
description ->r1 FR (spoke)
no ip address
encapsulation frame-relay
shutdown
no frame-relay inverse-arp
end
Let’s turn on Frame Relay inverse-ARP:
r4(config-if)#frame inv
r4(config-if)#do sh run int s0/0
Building configuration…Current configuration : 143 bytes
!
interface Serial0/0
description ->r1 FR (spoke)
no ip address
encapsulation frame-relay
shutdown
no frame-relay inverse-arp IP 405
end
WTF??? Where did that command come from? Here’s the IOS version that I’m running:
r4(config-if)#do sh ver | i IOS
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10),
RELEASE SOFTWARE (fc1)
This command was something that I had configured on an earlier lab. Even though I had turned off Frame Relay inverse-ARP (“no frame inverse”) for the ALL DLCIs, once I re-enabled it, it restored the old configuration that was disabling Frame Relay inverse-arp for DLCI 405 only. This is a good “feature” to be aware of so it does not bite you in the ass on the exam. [I should have just defaulted the interface instead of peeling off commands one at a time 🙂 ]
Let’s make sure that Frame Relay inverse-ARP is enabled for all DLCIs:
r4(config-if)#frame-relay inverse-arp IP 405
r4(config-if)#do sh run int s0/0
Building configuration…Current configuration : 108 bytes
!
interface Serial0/0
description ->r1 FR (spoke)
no ip address
encapsulation frame-relay
shutdown
end
I was very surprised to find out that Frame Relay subinterfaces do NOT inherit the Frame Relay inverse-ARP settings from the physical interface. For instance, in the configuration below, Serial0/0.1 will inherit the Frame Relay encapsulation setting, but it will NOT inherit the “no frame-relay inverse-arp” setting:
int s0/0
encap frame
no frame inv
int s0/0.1 multi
ip add 10.0.0.1 255.255.255.0
frame interface-dlci 102
We can prove this in a lab:
r1#sh run | sec Serial0/0
interface Serial0/0
description ->frame inverse-arp disabled at physical int
no ip address
encapsulation frame-relay
no frame-relay inverse-arp
!
interface Serial0/0.102 multipoint
description ->frame inverse-arp disabled at subint
ip address 10.0.0.12 255.0.0.0
frame-relay map ip 10.0.0.2 102 broadcast
no frame-relay inverse-arp
!
interface Serial0/0.103 multipoint
description ->frame inverse-arp NOT disabled at subint(assumes inheritance from physical int)
ip address 10.0.0.13 255.0.0.0
frame-relay interface-dlci 103
When we look at the Frame maps, we see that DLCI 103 is mapped via inverse-ARP(dynamic):
r1#sh frame map
Serial0/0.102 (up): ip 10.0.0.2 dlci 102(0x66,0x1860), static, broadcast,
CISCO, status defined, active
Serial0/0.103 (up): ip 10.0.0.3 dlci 103(0x67,0x1870), dynamic, broadcast,, status defined, activeLet’s shut down int s0/0(physical interface) and then debug:
r1#sh debug
Frame Relay:
Frame Relay events debugging is on
Frame Relay packet debugging is on
Now let’s bring s0/0 back up and view the debugging output:
*Mar 1 00:09:02: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:09:03: %LINK-3-UPDOWN: Interface Serial0/0, changed state to down
*Mar 1 00:09:08: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:09:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar 1 00:09:18: Serial0/0.103: preparing IP inarp on 103
*Mar 1 00:09:18: Serial0/0.103(o): dlci 103(0x1871), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
*Mar 1 00:09:18: FR: Sending INARP Request on interface Serial0/0.103 dlci 103 for link 7(IP) <-note
*Mar 1 00:09:18: broadcast dequeue
*Mar 1 00:09:18: Serial0/0.103(o):Pkt sent on dlci 103(0x1871), pkt encaps 0x300 0x8000 0x0 0x806 (ARP), datagramsize 34
*Mar 1 00:09:25: Serial0/0(i): dlci 103(0x1871), pkt encaps 0x0300 0x8000 0x0000 0x806 (ARP), datagramsize 34
*Mar 1 00:09:25: Serial0/0.103: FR ARP input
*Mar 1 00:09:25: datagramstart = 0x79E78AE, datagramsize = 34
*Mar 1 00:09:25: FR encap = 0x18710300
*Mar 1 00:09:25: 80 00 00 00 08 06 00 0F 08 00 02 04 00 08 00 00
*Mar 1 00:09:25: 0A 00 00 03 48 D1 00 00 00 00 01 02 00 00
*Mar 1 00:09:25:
*Mar 1 00:09:25: Serial0/0.103: frame relay INARP received
*Mar 1 00:09:25: Serial0/0.103: inarp received on 103
*Mar 1 00:09:25: FR: Sending INARP Reply on interface Serial0/0.103 dlci 103 for link 7(IP)
As we can see from this example, Frame Relay inverse-ARP is definitely active on the s0/0.103 subinterface even though we disabled it at the physical interface (s0/0) level. So unlike the encapsulation configuration, Frame Relay inverse-ARP settings are NOT inherited by the subinterface(s).
So…why do we care? In the real world, we really do not care. By default all DLCIs are assinged to the physical interface, so the only DLCIs that could get mapped via inverse-ARP on the subinterfaces are the DLCIs that you have assigned to the subinterface yourself (with “frame-relay interface-dlci [DLCI]”). In other words, the frame switch can advertise a ton of DLCIs to you (use “show frame pvc” to view them), but the subinterface is only going to look at the DLCIs that you have explicitly assign to it. If you turn off Frame Relay inverse-ARP at the physical interface, then you only need to worry about Frame Relay inverse-ARP mapping the DLCIs that you explicitly asssign to the subinterface(s).
Furthermore, it is nescessary to have an IP address configured on the interface for Frame Relay inverse-arp to work. If there is no IP address assigned to the physical interface then disabling Frame Relay inverse-ARP at the physical level while running subinterfaces is not nescessary.
BUT…we’re not concerned about good design or real world issues in the CCIE lab. We need to watch out for tasks like this:
Configure s0/0.103 as a multipoint Frame Relay subinterface. Ensure that layer 2 to layer 3 dynamic mapping is not possible on this subinterface.
We need to know that simply disabling Frame Relay inverse-ARP on the physical interface and using a static Frame Relay mapping on the subinterface will not meet the requirements of this task.
This is pretty basic, but you need to remember a couple of important things when tasked with tweaking spanning-tree timers:
1) Make the changes on the root bridge.
2) The root bridge settings are the timers that are used – not the local settings on the non-root bridge(s).
You can see the timers with the “show spanning-tree vlan x” command. The timers are set on the root. Non-root bridges will still show the local timer values, but will use the root values:
sw2#sh span v 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 0012.018f.d580
Cost 19
Port 15 (FastEthernet0/13)
Hello Time 2 sec Max Age 20 sec Forward Delay 4 sec <-noteBridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0012.009c.ca00 <-sw2 is not the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec <-note
Aging Time 300Interface Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
Fa0/1 Desg FWD 19 128.3 P2p
Fa0/13 Root FWD 19 128.15 P2p
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/15 Altn BLK 19 128.17 P2pBring up a port in VLAN 1:
sw2(config)#int fa0/1
sw2(config-if)#no sh
sw2(config-if)#^Z*Mar 1 22:33:42: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 22:33:43: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
*Mar 1 22:33:44: set portid: VLAN0001 Fa0/1: new port id 8003
*Mar 1 22:33:44: STP: VLAN0001 Fa0/1 -> listening
*Mar 1 22:33:46: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar 1 22:33:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
*Mar 1 22:33:48: STP: VLAN0001 Fa0/1 -> learning [listen to learn = 4 seconds]
*Mar 1 22:33:52: STP: VLAN0001 sent Topology Change Notice on Fa0/13
*Mar 1 22:33:52: STP: VLAN0001 Fa0/1 -> forwarding [learn to forward = 4 seconds]
The non-root bridge uses the root bridge’s Forward Delay timer of 4 seconds rather than its local timer of 15 seconds.
**************************
3 different ways to change the forward delay back to default (15 seconds)
We set the forward delay to 4 seconds (sw1 is on the root bridge):
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID Priority 24577
Hello Time 2 sec Max Age 20 sec Forward Delay 4 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Hello Time 2 sec Max Age 20 sec Forward Delay 4 sec
1) “no spanning-tree vlan 1 forward-time 4”
sw1(config)#no sp v 1 f 4
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID Priority 24577
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
2) “default spanning-tree vlan 1 forward-time”
sw1(config)#default sp v 1 f
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID Priority 24577
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
3) “spanning-tree vlan 1 forward-time 15”
sw1(config)#sp v 1 f 15
sw1(config)#do sh sp v 1 | i ID|Forward
Root ID Priority 24577
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24577 (priority 24576 sys-id-ext 1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
If your VTP domains do not match on each side of a trunk link, then DTP will NOT work. You need to watch out for this as the ports will be up/up, but trunking will not be negotiated. You’ll need to either make both VTP domains the same, or hard-set the trunks with “switchport nonegotiate”.
In this example, one side of the trunk is in VTP domain CCIE, and the other is in VTP domain FAILED:
sw1(config-if-range)#^Z
sw1#
*Mar 1 05:58:26: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 05:58:27: %LINK-3-UPDOWN: Interface FastEthernet0/13, changed state to up
*Mar 1 05:58:27: %LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
*Mar 1 05:58:27: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to down
*Mar 1 05:58:28: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/13 because of VTP domain mismatch.
*Mar 1 05:58:28: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/14 because of VTP domain mismatch.
*Mar 1 05:58:28: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/15 because of VTP domain mismatch.Hmmm…looks like it “righted itself”:
*Mar 1 05:58:29: %LINK-3-UPDOWN: Interface FastEthernet0/15, changed state to up
*Mar 1 05:58:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up
*Mar 1 05:58:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to up
*Mar 1 05:58:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to up
Looks good (actually we want to see “trunk” instead of “1”):
sw1#sh int status | b 0/13
Fa0/13 ->sw2 connected 1 a-full a-100 10/100BaseTX
Fa0/14 ->sw2 connected 1 a-full a-100 10/100BaseTX
Fa0/15 ->sw2 connected 1 a-full a-100 10/100BaseTXZoiks!!! No trunks!!!
sw1#sh int trunksw1#
sw1#sh int fa0/13 switch
Name: Fa0/13
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
sw1#sh int fa0/13 count trunkPort TrunkFramesTx TrunkFramesRx WrongEncap
Fa0/13 0 0 0 <-no frames
To fix this issue configure the following on the port-channel interface on each switch:
sw2(config)#int po1
sw2(config-if)# switchport trunk encapsulation isl
sw2(config-if)# switchport mode trunk
sw2(config-if)# switchport nonegotiate
Now we have trunking established (without DTP) even though our VTP domains are different:
sw1:
sw1#sh vtp stat | i Domain
VTP Domain Name : CCIEsw1#sh int trunk
Port Mode Encapsulation Status Native vlan
Po1 on isl trunking 1sw1#sh int po1 eth
Age of the Port-channel = 00d:00h:04m:09s
Logical slot/port = 2/1 Number of ports = 3
GC = 0x00000000 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = –Ports in the Port-channel:
Index Load Port EC state No of bits
——+——+——+——————+———–
0 00 Fa0/13 On/FEC 0
0 00 Fa0/14 On/FEC 0
0 00 Fa0/15 On/FEC 0Time since last port bundled: 00d:00h:03m:18s Fa0/15
sw1#sh int status | b 0/13
Fa0/13 ->sw2 connected trunk a-full a-100 10/100BaseTX
Fa0/14 ->sw2 connected trunk a-full a-100 10/100BaseTX
Fa0/15 ->sw2 connected trunk a-full a-100 10/100BaseTXsw2:
sw2#sh vtp statu | i Domain
VTP Domain Name : PASSEDsw2#sh int trunk | i trunking
Po1 on isl trunking 1sw2#sh int po1 eth
Age of the Port-channel = 00d:00h:08m:02s
Logical slot/port = 2/1 Number of ports = 3
GC = 0x00000000 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = –Ports in the Port-channel:
Index Load Port EC state No of bits
——+——+——+——————+———–
0 00 Fa0/13 On/FEC 0
0 00 Fa0/14 On/FEC 0
0 00 Fa0/15 On/FEC 0Time since last port bundled: 00d:00h:05m:06s Fa0/15
Time since last port Un-bundled: 00d:00h:07m:19s Fa0/15sw2#sh int status | b 0/13
Fa0/13 ->sw1 connected trunk a-full a-100 10/100BaseTX
Fa0/14 ->sw1 connected trunk a-full a-100 10/100BaseTX
Fa0/15 ->sw1 connected trunk a-full a-100 10/100BaseTX
I was mucking with etherchannel today and discovered a cool command that I was not aware of: show interface [interface] counters etherchannel.
You can run this command on your port-channel interface:
sw4#sh int po1 count ether
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 23863 15 229 0
Fa0/19 1899894 835 18864 0
Fa0/20 1903864 835 18862 5
Fa0/21 1945733 835 19307 5Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 3653 15 14 0
Fa0/19 181124 834 533 5
Fa0/20 171050 834 494 0
Fa0/21 169510 834 469 0
If you run it on one of the bundled links, you’ll get an error message:
sw4#sh int fa0/19 count ether
Etherchannel not enabled on this interface
Clearing the counters for this command takes a bit of work. If you clear the counters on the port-channel interface, it will not clear the counters on the individual bundled links:
sw4#clear count po1
Clear “show interface” counters on this interface [confirm]
sw4#
*Mar 1 02:20:57: %CLEAR-5-COUNTERS: Clear counter on interface Port-channel1 by console
sw4#sh int po1 count ethPort InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 1504 3 13 0 <-cleared
Fa0/19 1900270 838 18865 0
Fa0/20 1904240 838 18863 5
Fa0/21 1959175 838 19447 5Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 0 0 0 0 <-cleared
Fa0/19 181500 837 534 5
Fa0/20 171426 837 495 0
Fa0/21 169886 837 470 0
You can clear each bundled link on its own:
sw4#clear count fa0/19
*Mar 1 02:25:35: %CLEAR-5-COUNTERS: Clear counter on interface FastEthernet0/19 by console
sw4#sh int po1 count ethPort InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 136047 87 1311 0
Fa0/19 94 1 0 0 <-cleared
Fa0/20 1909733 866 18877 5
Fa0/21 2082732 866 20717 5Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 16479 84 42 0
Fa0/19 0 0 0 0 <-cleared
Fa0/20 176919 865 509 0
Fa0/21 175379 865 484 0
You can clear both the port-channel and the bundled links’ counters all at once with “clear counters”. Personally, I very rarely use that command. I feel that it’s like dropping a nuke on a mosquito. Sure you clear the counters that you want cleared, but you also destroy a ton of historical data by wiping out the all of the counters. I hate trying to troubleshoot an issue after another engineer has run this command. But if you must use it 🙂
sw4#clear count
Clear “show interface” counters on all interfaces [confirm]
*Mar 1 03:40:48: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
sw4#sh int po1 count ethPort InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 1222 0 13 0
Fa0/19 0 0 0 0
Fa0/20 0 0 0 0
Fa0/21 1222 0 13 0Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 0 0 0 0
Fa0/19 0 0 0 0
Fa0/20 94 1 0 0
Fa0/21 94 1 0 0
You can use this command to illustrate the method that the switch is using to “load balance” over the etherchannel links:
First, let’s create an SVI on each side of the Etherchannel
sw4(config)#vlan 100
sw4(config-vlan)#int vlan 100
sw4(config-if)#ip address 100.0.0.4 255.255.255.0sw3(config)#vlan 100
sw3(config-vlan)#int vlan 100
sw3(config-if)#ip address 100.0.0.3 255.255.255.0Let’s clear etherchannel counters, then ping the hell out of the 100.0.0.3 address:
sw4#sh int po1 count ethPort InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 3760 0 40 0
Fa0/19 188 2 0 0
Fa0/20 94 1 0 0
Fa0/21 5828 1 61 0Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 282 3 0 0
Fa0/19 188 2 0 0
Fa0/20 188 2 0 0
Fa0/21 94 1 0 0sw4#ping 100.0.0.3 re 10000 si 1500
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
—–output truncated—–
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 1/2/28 msNow let’s look at the etherchannel counters:
sw4#sh int po1 count ethPort InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 15512981 10018 323 0
Fa0/19 15481343 10008 3 0 <-note
Fa0/20 1249 7 3 0
Fa0/21 32739 7 338 0Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 15483747 10021 9 0
Fa0/19 15481343 10008 3 0 <-note
Fa0/20 1343 8 3 0
Fa0/21 1249 7 3 0
So why did one interface handle all of the pings? Let’s use another nifty little command to find out:
sw4#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-mac):
Non-IP: Source MAC address
IPv4: Source MAC address
IPv6: Source IP addresssw4#sh arp | i 100.0.0.4
Internet 100.0.0.4 – 000a.8a1c.c400 ARPA Vlan100
We are “load balancing” based on the source mac-address. The ping is sourced by 100.0.0.4 and the source-mac address will not change, so all of our pings took the same route. This is good to know for the real world as well. Depending on the traffic source, that 8-gig etherchannel you set up to the server may only be giving you 1 gig of possible bandwidth. 🙂
Cisco Documentation:
Here is an interesting post from GroupStudy:
I have my lab scheduled for August 23, that is, in the next 15 days. I almost feel defeated already, even though I can not identify many technical shortfalls with my knowledge and experience. I feel defeated because I have been made to believe NOT to expect to pass on the first attempt. Indeed I know many personal friends who I considered technical gurus, but had to do the exam at least twice.
Now my question is this : Is it realistic to expect to pass on the first attempt ? Or should I really walk in with my white towel already in the air?
Regardless, 23 August it is, San Jose.
Herbert.
There were a number of replies, but here is my favorite because of its message as well as a (somewhat humorous) peek into the lab:
Herb:
I passed my first time.
People were telling me not to EXPECT to pass the first time. I didn’t expect to pass. I still tried like hell though.
All the way up to last minute, when myself and 4 or 5 other candidates were sitting and waiting in the lab building at RTP, people were telling me.. “You’re not going to pass… so just take the test and walk out of here with a better understanding of what it feels like…”
I sat down in front of the PC in the lab, opened the lab book, and just went at it. That is all you have to do. Try to relax at lunch, eat something. Don’t think about the lab, then go back to it with a clear head.
At least that is what worked for me. There were other guys at lunch pacing the floor, unable to eat… one dude was literally pouring sweat. I felt bad for him. Don’t let it get to you like that. If you have been doing practice labs and making good progress, then you should be OK.
Don’t think about the results. If takes you two or three times, then screw it… thats normal anyway! Hell I’m prepping now for the SP track, and I have no expectation of passing the written or the lab on the first try. I hope I do, of course, but if I set myself up with those kinds of expectations, then it will only make it more difficult to recover from a failure.
Derick Winkworth, CCIE #15672
I am in the same boat as Derick was. I expect to fail on my first lab attempt, but I am going to do everything I can to pass it. I’m not going to be too depressed if I fail it, yet I am also not going to simply sit the exam in order to get the experience of the lab. First lab passes are pretty rare, and even the best engineers sometimes fail the lab on thier first attempt. Case in point, quadruple CCIE Scott Morris:
Great advice. If you go in with the idea that the average is somewhere over three times to pass the lab, then you can actually relieve some of the pressure for passing.
Way back when, I thought I was going to pass the first time, just because of the amount of time I studied and worked on everything. Didn’t happen. Time pressures, and my own time management problems worked against me.
When I went back home feeling bad, and going back to work, it was actually kind of amusing. Everyone at the place I was working (at least my group) threw a party. They weren’t celebrating my success since it didn’t happen, but were revelling in the fact that I was still human and needed an exam to prove that to me! (smirk)
On the other hand, one of the VPs of the company informed me I was thinking about things wrong anyway. If the average is three times, then think of it as a $3,750 exam. If you pass in less times than that, then you save money. Cool. But don’t let the pressures get to you.
Don’t expect it, and you won’t be disappointed, but as noted, try like hell anyway! Lots of people I know have passed the first time. Personally, I did it the second time. Everyone’s brain works differently though! Just make the most of it and give it your best shot! And even if you happen to walk in and get completely overwhelmed, do NOT leave the exam!!! View it as some really expensive lab rack time, and work on the lab anyway!
Best of luck to you!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
VP – Technical Training – IPexpert, Inc.
IPexpert Sr. Technical Instructor
http://www.ipexpert.com
Interesting….you can set the native vlan without having created the vlan first and IOS will not automatically create it for you:
sw1(config)#do sh run int fa0/13
Building configuration…Current configuration : 128 bytes
!
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
endsw1(config)#do sh vlan br [Note: VLAN 10 does not exist on this switch]
VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/14, Fa0/15, Fa0/22, Fa0/23
Fa0/24, Gi0/1, Gi0/2
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
A good way to verify whether or not the native VLAN exists on the switch is to view the switchport details for the interface:
When the vlan is not configured:
sw1#sh int fa0/13 switch
Name: Fa0/13
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 10 (Inactive)
—–output truncated—–
sw1#sh span vlan 10Spanning tree instance(s) for vlan 10 does not exist.
After configuring the vlan:
sw1#sh int fa0/13 switch
Name: Fa0/13
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 10 (VLAN0010)
—-output truncated—-
sw1#sh span vlan 10VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 32778
Address 0018.ba55.5b00
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 0018.ba55.5b00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
—-output truncated—-
*Note: in the case above adding the vlan to one side of the link does NOT bring the other side out of inactive (VTP notwithstanding):
sw2#sh int fa0/13 switch | i Native
Trunking Native Mode VLAN: 10 (Inactive)
Unless you are running vtp, you will need to configure the vlan on both sides of the link.
This is another good point to clarify with the lab proctor. The task may not specify that the native VLAN be created and it may not have already been created in another task. You will want to ask the proctor whether or not the VLAN needs to be created to get credit for the task. You may also want to read the rest of the exam closely to see if there are other tasks that depend on the existence of that VLAN.
