Every wonder how to tell if you put a space at the end of your Cisco password? Well, if you have, or want to see if thats the case during troubleshooting try out this command:
show run | i _$
If you have a user like this in the output:
user cisco password cisco
It most likely means that the password cisco is really "cisco_" where the _ is a blank space! This also applies for items like ospf authentication, etc...
Monday, June 20, 2011
Wednesday, March 23, 2011
RMON - Absolute vs. Delta
I just wanted to put a link here as this is a topic that I never really chose to look that much into but it finally peaked enough interest tonight to do some research on it. Deepak simplified it so greatly in this post I found no real reason to rewrite it:
http://ieoc.com/forums/p/14069/125716.aspx
Here is Mr. Deepak Arora's post:
"Delta : For values that always increase
Absolute : For values that can increase or decrease
CPU utilization can go up or down (0% to 100%) so it would be an absolute value. Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value. We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.
One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained. If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’. For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared). This is either a poorly written task…or more likely you should use ‘delta’.
*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach certain value (say 1 million) but that’s a pretty strange/ineffective alarm.
HTH...
Deepak Arora"
Well done sir...well done.
http://ieoc.com/forums/p/14069/125716.aspx
Here is Mr. Deepak Arora's post:
"Delta : For values that always increase
Absolute : For values that can increase or decrease
CPU utilization can go up or down (0% to 100%) so it would be an absolute value. Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value. We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.
One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained. If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’. For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared). This is either a poorly written task…or more likely you should use ‘delta’.
*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach certain value (say 1 million) but that’s a pretty strange/ineffective alarm.
HTH...
Deepak Arora"
Well done sir...well done.
Sunday, March 13, 2011
EIGRP Ratio Calculation
This is a short post to discuss EIGRP ratio calculations. If you are so fortunate to be give a lab task that says.."We want Switch3 to route to 12.0.0.0 via Sw4 and Sw2 in a ratio of 3:1 respectively," this little thread should provide you with enough information to figure this task out on your own. Here goes:
This is our topology, and yes, 12.0.0.0 and the switches in the statement before are actually what we are going to use to do this. Currently all routers are in their the same EIGRP AS, and Sw3's routing and topology table for the route in mention looks like so:
I highlighted some of the pertinent portions of the config snippet. Heres the formula that I learned from Narbik for this type of situation:
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
Now this deems a bit of explanation...the left side of the equation is the route metric in the examples above, and we are multiplying this by 3 because thats what we want our ratio to be...3:1. So we want to figure out delay on the right (because that is what we want to manipulate here for EIGRP). The other stuff is pretty standard, 10^7/100000 defined by EIGRP for bw calculation, and the 100000 is defined as the minbw in the output above. 5200/10 is the delay in the above output divided by 10 to put it into the "tens of microseconds" category for EIGRP calculations. Finally x is delay, or better yet what we will end up with to add to our delay on the interface. Lets go!
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
476160 = 256 (100 + 520 + x)
476160 = 256 (620 + x)
1860 = 620 + x //--divided 476160 by 256
1240 = x //--subtracted 620 from 1860
So x = 1240...thats awesome. So do we just plug that in? One would think right, but we actually have one more step. If you were to plug that in, it would get you pretty close, but that needs to be added to what is actually on on our interface already. Lets look:
So our delay on there now is 100 microseconds. lets add that /10, or 10, to our previous x value.
1240 + 10 = 1250
Nice, lets see if that works!
Nope...hmm. Well we know that to do unequal cost load-balancing we need what? Variance of-course!
Now lets take a look..
And as I aptly named the picture...victory! Now I am honestly hoping that I dont get something like this in the real lab as it does take a little time to get it all perfected. Hopefully if I keep replicating the scenario I can get the whole process down to a minute or two. Well I hope this helped someone out there, if it did please leave a comment below! Thanks for the time.
I highlighted some of the pertinent portions of the config snippet. Heres the formula that I learned from Narbik for this type of situation:
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
Now this deems a bit of explanation...the left side of the equation is the route metric in the examples above, and we are multiplying this by 3 because thats what we want our ratio to be...3:1. So we want to figure out delay on the right (because that is what we want to manipulate here for EIGRP). The other stuff is pretty standard, 10^7/100000 defined by EIGRP for bw calculation, and the 100000 is defined as the minbw in the output above. 5200/10 is the delay in the above output divided by 10 to put it into the "tens of microseconds" category for EIGRP calculations. Finally x is delay, or better yet what we will end up with to add to our delay on the interface. Lets go!
3(158720) = 256 ( [10^7/100000] + [5200/10] + x)
476160 = 256 (100 + 520 + x)
476160 = 256 (620 + x)
1860 = 620 + x //--divided 476160 by 256
1240 = x //--subtracted 620 from 1860
So x = 1240...thats awesome. So do we just plug that in? One would think right, but we actually have one more step. If you were to plug that in, it would get you pretty close, but that needs to be added to what is actually on on our interface already. Lets look:
So our delay on there now is 100 microseconds. lets add that /10, or 10, to our previous x value.
1240 + 10 = 1250
Nice, lets see if that works!
Nope...hmm. Well we know that to do unequal cost load-balancing we need what? Variance of-course!
Now lets take a look..
And as I aptly named the picture...victory! Now I am honestly hoping that I dont get something like this in the real lab as it does take a little time to get it all perfected. Hopefully if I keep replicating the scenario I can get the whole process down to a minute or two. Well I hope this helped someone out there, if it did please leave a comment below! Thanks for the time.
Friday, March 4, 2011
Thursday, February 3, 2011
BGP Conditional Default Route
Pretty much everyone knows that you can inject a default route to a neighbor in BGP by using a command like so:
router bgp 300
neighbor 164.18.46.8 default-originate
This will unconditionally inject a default route to that neighbor. Note: They will still get all the other BGP routes as the router originating this command will not suppress the other routes just b/c it is injecting a default to them. To conditionally set a default route you can use the route-map option at the end of this neighbor command. See below:
router bgp 300
neighbor 164.18.48.8 default-originate route-map SW2-DEFAULT
neighbor 164.19.26.6 default-originate route-map R6-DEFAULT
ip access-list standard BGP-SW2
permit 192.168.2.0
ip access-list extended BGP-R6
permit ip host 192.168.2.0 host 255.255.255.0
route-map SW2-DEFAULT permit 10
match ip address name BGP-SW2
route-map R6-DEFAULT permit 10
match ip address name BGP-R6
So as you can see here the big difference is the access-lists right? One is a standard ACL, the other is an extended ACL. So whats the difference? Well the first one will allow the default to originate if there in an entry in the routing table that will match that route, no matter the mask (192/8 , 192.168/16, 192.168.2/24) ...all would work. The extended acl actually defines a mask, a /24 to be picky in this case.
This is just something I ran into and found interesting when I was trying to filter using that route-map option originally. I looked it up, and found it here BGP REFERENCE ...strange that I never used this enough to remember it in my CCIP studies!
router bgp 300
neighbor 164.18.46.8 default-originate
This will unconditionally inject a default route to that neighbor. Note: They will still get all the other BGP routes as the router originating this command will not suppress the other routes just b/c it is injecting a default to them. To conditionally set a default route you can use the route-map option at the end of this neighbor command. See below:
router bgp 300
neighbor 164.18.48.8 default-originate route-map SW2-DEFAULT
neighbor 164.19.26.6 default-originate route-map R6-DEFAULT
ip access-list standard BGP-SW2
permit 192.168.2.0
ip access-list extended BGP-R6
permit ip host 192.168.2.0 host 255.255.255.0
route-map SW2-DEFAULT permit 10
match ip address name BGP-SW2
route-map R6-DEFAULT permit 10
match ip address name BGP-R6
So as you can see here the big difference is the access-lists right? One is a standard ACL, the other is an extended ACL. So whats the difference? Well the first one will allow the default to originate if there in an entry in the routing table that will match that route, no matter the mask (192/8 , 192.168/16, 192.168.2/24) ...all would work. The extended acl actually defines a mask, a /24 to be picky in this case.
This is just something I ran into and found interesting when I was trying to filter using that route-map option originally. I looked it up, and found it here BGP REFERENCE ...strange that I never used this enough to remember it in my CCIP studies!
Sunday, January 30, 2011
Just a note for later....
Forward metric....in regards to OSPF External Type 2 routes
Got hit with this in a lab scenario today...honestly didnt even know it existed until I did a show ip route on a specific entry. I will do a lab this week with a bit more information, but it is definitely interesting.
Still labbing everyday for those listening in. 4-6 hrs per day/7days a week. Still feel weak in some areas, and looking forward to Narbik in 2 weeks!
Got hit with this in a lab scenario today...honestly didnt even know it existed until I did a show ip route on a specific entry. I will do a lab this week with a bit more information, but it is definitely interesting.
Still labbing everyday for those listening in. 4-6 hrs per day/7days a week. Still feel weak in some areas, and looking forward to Narbik in 2 weeks!
Saturday, January 22, 2011
Selective Packet Discard
Well I can officially add this hidden ios feature to my "bag of things I will probably not ever use in real life" tricks. It actually serves a cool function to prioritize the "important" router traffic within the input queues on an interface. Control plane traffic such as IP prec 6, IGP traffic, etc...can be placed in additional priority headrooms that will be serviced first over the regular input queue during times of congestion. Here are some Cisco links on it:
Doc 1
Doc 2
Doc 1
Doc 2
Friday, January 14, 2011
INE
Well as I have mentioned before I purchased Internetwork Experts CCIE v4 self-study package....damn. This is the most challenged...and humbled that I have been since beginning my Cisco certification/career journey several years ago. I originally hit the labs pretty fast and furious, and have in the last week really talked myself into slowing down...and going via best practice of reading the lab...drawing the diagrams, and trying to really understand whats going on in the network that I am working on. Sometimes this is a bit harder than it sounds, especially when you hit a level 9/10 lab, with multiple points of mutual redistribution, ipv6, multicast, rip, ospf, bgp, ospfv3, security, management, and qos....gets rough. But tonight I have had some epiphanies..slowing down and nailing task after task. I should keep it like this for a while...when the foundation is in tact I will work on speed.
Thursday, January 6, 2011
Catalyst QoS
Well I am still here....chugging away with 30+ hours a week or so towards CCIE lab preparation. It IS hard work....I spent the last week going through the two preparatory Lab Books for Narbik's class that I am taking from micronicstraining.com in February. I am really looking forward to this! Since finishing those up though, I am back going through some INE Volume II labs. Did one on Tuesday...got killed with some Catalyst QoS stuff that I had never seen before, and some IP services items that I had just forgotten. I am going back through Vol I today on the portions where I was lacking. I was going to do a brief thing here on Cat QoS, but I found a blog article from the guys at INE that say it better than I ever could.
http://blog.ine.com/tag/per-vlan/
http://blog.ine.com/tag/per-vlan/
Thursday, December 23, 2010
OSPF over Frame-relay
I just wanted to drop a line that has helped me tremendously the last couple of months. Its hard to remember sometimes what goes into an ospf config when using frame as your medium. Remember this:
"Non-broadcast Needs Neighbors"
If the network type is the default of non-broadcast, or point-to-multipoint non-broadcast you will have to include neighbor statements in your ospf configs. HTH's!
-Jason
"Non-broadcast Needs Neighbors"
If the network type is the default of non-broadcast, or point-to-multipoint non-broadcast you will have to include neighbor statements in your ospf configs. HTH's!
-Jason
Monday, December 13, 2010
Routing Protocols Comparison Poster
I kind of threw this together for my written. It is a pdf in its natural state, if you want a copy of the pdf email me at willroute4food at gmail dot com. Its just a good quick side-by-side of some of the major routing protocols. If you find an error, or something I should add please let me know in the comments (I do realize some of the numbers were thrown off in the conversion. The data does appear to be in the appropriate containers though). Thanks.
| | RIP (version 2) | OSPF | EIGRP | BGP |
| IP Protocol number, (TCP) | n/a | IP 89 | IP 88 | TCP 179 |
| Hello Address | 224.0.0.9 (can be set to broadcast at the interface level via ip rip v2-broadcast) | 224.0.0.5 –AllOSPFRtrs 224.0.0.6 –DR/BDR | 224.0.0.10 | Unicast hello to configured “neighbor” |
| Administrative Distance(s) | 120 | 110 | Internal – 90 External – 170 Summary -- 5 | EBGP – 20 IBGP – 200 |
| Metric (calculation) / Limits | Hop Count/ Limit is 15 hops, 16 is inaccessible | Cost = Autocostrefbw/interface bandwidth *Default is 100Mb for Autocostrefbw* | Cost = 256(BW + Delay) *formula with default K values) The maximum number of hops that EIGRP will accept is 100 by default, although the maximum can be configured to 220 with metric maximum hops. | IBGP – 0 Redistributed routes metric = IGP metric |
| Timers | Update-30 Invalid-180 Holdown-180 Flush-240 | Hello – 10/30 Dead – 40/120 | Hello – 5/60 Hold – 15/180 | Keepalive – 60 Holdtime -- 180 |
| Adjacency (neighbor) Requirements | Neighbor must be on a subnet off of primary interface included in “network” statement | 1. Pass authentication checks 2. Same primary subnet w/mask 3. Same OSPF area 4. Same Area type (flags) 5. NOT duplicate RIDS 6. Hello/Dead timers must match 7. Unless P2P (one must be DR/BDR) | 1. Pass authentication checks 2. Must have same AS number 3. Must believe that source IP of neighbor in hello is in that routers primary subnet (no secondary’s) 4. K values must match | 1. Source IP in connection request must match something in the local routers “neighbor” statements. 2. Routers ASN must match its corresponding ASN in “neighbor stmt 3. RIDS must be different 4. Must pass MD5 authentication |
| Passive Interface (yes,no) /Affects | Yes/Shuts off the sending of updates on the passive interface. Will still listen to updates and will update routing table accordingly | Yes/Stops sending hello’s /updates out of that interface. Note though, if included in the network statement the network on that interface will still be advertised to peers. | Yes/suppresses both incoming AND outgoing hellos/updates. Note that it will not allow neighbors to form. | n/a |
| Auto-summarization | Enabled by default | n/a | Enabled by default (wont summarize route that it does not “own”) | Disabled by default after 12.3 mainline |
| Summary Address | (conf-if) ip summary-address rip ip-address ip-network-mask default-information originate [route-map map-name] | ABR- area x range ip-address mask {advertise | no-advertise} cost cost (router) summary-address ip-address mask | (conf-if) ip summary-address eigrp [as] ip-address mask | aggregate-address address mask [as-set] [summary-only] [suppress-map map-name] [advertise-map map-name] [attribute-map map-name] neighbor x.x.x.x default-originate network 0.0.0.0 (OR STATIC ROUTE/REDISTRIBUTE) |
| Filtering Method(s) | distribute-list {access-list-number | prefix prefix-list-name [gateway prefix-list-name]} in [interface-type interface-number] | Inbound – distribute-list {prefix | route-map} in In/out – area (number) filter-list prefix (name) {in | out} | Distribute-list {access-list num/name} {prefix list-name} {in | out} {int type/num} | Prefix-lists, route-maps, filter-lists, etc…. |
| Authentication | Clear text or MD5 16 character limit Key chain RIP Key 1 Key-string cisco Int fa0/0 Ip rip authentication key-chain RIP Ip rip authentication mode md5 | 0 – none, 1 – clear text, 2 – MD5 Int fa0/0 Ip ospf authentication Ip ospf authentication-key {key} Int fa0/0 Ip ospf authentication message-digest Ip ospf message-digest-key {number} md5 {key} You can also declare the authentication type under the router OSPF process | MD5 only Key chain EIGRP Key 1 Key-string cisco Int fa0/0 Ip authentication mode eigrp [as] md5 Ip authentication key-chain EIGRP [as] EIGRP | MD5 only Neighbor x.x.x.x password [pass] |
| Offsets | Increases incoming or outgoing hop count on routing updates (CAN BE USED TO FILTER BY SETTING HOP COUNT > 15) Access-list 1 permit 10.10.10.0 0.0.0.255 Router rip Offset-list 1 out 5 serial0 //increases metric by 5 on that route// | n/a | access-list 1 permit 10.1.1.0 0.0.0.255 router eigrp 1 offset-list 1 out 3 FastEthernet0/0 | n/a |
Friday, November 26, 2010
CCIE R/S Lab Blueprint
Varies slightly from the written blueprint, so I thought that I would post it.
Exam Sections and Sub-task Objectives
| 1.00 | Implement Layer 2 Technologies | √ |
| 1.10 | Implement Spanning Tree Protocol (STP) | |
| (a) 802.1d | ||
| (b) 802.1w | ||
| (c) 801.1s | ||
| (d) Loop guard | ||
| (e) Root guard | ||
| (f) Bridge protocol data unit (BPDU) guard | ||
| (g) Storm control | ||
| (h) Unicast flooding | ||
| (i) Port roles, failure propagation, and loop guard operation | ||
| 1.20 | Implement VLAN and VLAN Trunking Protocol (VTP) | |
| 1.30 | Implement trunk and trunk protocols, EtherChannel, and load-balance | |
| 1.40 | Implement Ethernet technologies | |
| (a) Speed and duplex | ||
| (b) Ethernet, Fast Ethernet, and Gigabit Ethernet | ||
| (c) PPP over Ethernet (PPPoE) | ||
| 1.50 | Implement Switched Port Analyzer (SPAN), Remote Switched Port Analyzer (RSPAN), and flow control | |
| 1.60 | Implement Frame Relay | |
| (a) Local Management Interface (LMI) | ||
| (b) Traffic shaping | ||
| (c) Full mesh | ||
| (d) Hub and spoke | ||
| (e) Discard eligible (DE) | ||
| 1.70 | Implement High-Level Data Link Control (HDLC) and PPP | |
| 2.00 | Implement IPv4 | |
| 2.10 | Implement IP version 4 (IPv4) addressing, subnetting, and variable-length subnet masking (VLSM) | |
| 2.20 | Implement IPv4 tunneling and Generic Routing Encapsulation (GRE) | |
| 2.30 | Implement IPv4 RIP version 2 (RIPv2) | |
| 2.40 | Implement IPv4 Open Shortest Path First (OSPF) | |
| (a) Standard OSPF areas | ||
| (b) Stub area | ||
| (c) Totally stubby area | ||
| (d) Not-so-stubby-area (NSSA) | ||
| (e) Totally NSSA | ||
| (f) Link-state advertisement (LSA) types | ||
| (g) Adjacency on a point-to-point and on a multi-access network | ||
| (h) OSPF graceful restart | ||
| 2.50 | Implement IPv4 Enhanced Interior Gateway Routing Protocol (EIGRP) | |
| (a) Best path | ||
| (b) Loop-free paths | ||
| (c) EIGRP operations when alternate loop-free paths are available, and when they are not available | ||
| (d) EIGRP queries | ||
| (e) Manual summarization and autosummarization | ||
| (f) EIGRP stubs | ||
| 2.60 | Implement IPv4 Border Gateway Protocol (BGP) | |
| (a) Next hop | ||
| (b) Peering | ||
| (c) Internal Border Gateway Protocol (IBGP) and External Border Gateway Protocol (EBGP) | ||
| 2.70 | Implement policy routing | |
| 2.80 | Implement Performance Routing (PfR) and Cisco Optimized Edge Routing (OER) | |
| 2.90 | Implement filtering, route redistribution, summarization, synchronization, attributes, and other advanced features | |
| 3.00 | Implement IPv6 | |
| 3.10 | Implement IP version 6 (IPv6) addressing and different addressing types | |
| 3.20 | Implement IPv6 neighbor discovery | |
| 3.30 | Implement basic IPv6 functionality protocols | |
| 3.40 | Implement tunneling techniques | |
| 3.50 | Implement OSPF version 3 (OSPFv3) | |
| 3.60 | Implement EIGRP version 6 (EIGRPv6) | |
| 3.70 | Implement filtering and route redistribution | |
| 4.00 | Implement MPLS Layer 3 VPNs | |
| 4.10 | Implement Multiprotocol Label Switching (MPLS) | |
| 4.20 | Implement Layer 3 virtual private networks (VPNs) on provider edge (PE), provider (P), and customer edge (CE) routers | |
| 4.30 | Implement virtual routing and forwarding (VRF) and Multi-VRF Customer Edge (VRF-Lite) | |
| 5.00 | Implement IP Multicast | |
| 5.10 | Implement Protocol Independent Multicast (PIM) sparse mode | |
| 5.20 | Implement Multicast Source Discovery Protocol (MSDP) | |
| 5.30 | Implement interdomain multicast routing | |
| 5.40 | Implement PIM Auto-Rendezvous Point (Auto-RP), unicast rendezvous point (RP), and bootstrap router (BSR) | |
| 5.50 | Implement multicast tools, features, and source-specific multicast | |
| 5.60 | Implement IPv6 multicast, PIM, and related multicast protocols, such as Multicast Listener Discovery (MLD) | |
| 6.00 | Implement Network Security | |
| 6.01 | Implement access lists | |
| 6.02 | Implement Zone Based Firewall | |
| 6.03 | Implement Unicast Reverse Path Forwarding (uRPF) | |
| 6.04 | Implement IP Source Guard | |
| 6.05 | Implement authentication, authorization, and accounting (AAA) (configuring the AAA server is not required, only the client-side (IOS) is configured) | |
| 6.06 | Implement Control Plane Policing (CoPP) | |
| 6.07 | Implement Cisco IOS Firewall | |
| 6.08 | Implement Cisco IOS Intrusion Prevention System (IPS) | |
| 6.09 | Implement Secure Shell (SSH) | |
| 6.10 | Implement 802.1x | |
| 6.11 | Implement NAT | |
| 6.12 | Implement routing protocol authentication | |
| 6.13 | Implement device access control | |
| 6.14 | Implement security features | |
| 7.00 | Implement Network Services | |
| 7.10 | Implement Hot Standby Router Protocol (HSRP) | |
| 7.20 | Implement Gateway Load Balancing Protocol (GLBP) | |
| 7.30 | Implement Virtual Router Redundancy Protocol (VRRP) | |
| 7.40 | Implement Network Time Protocol (NTP) | |
| 7.50 | Implement DHCP | |
| 7.60 | Implement Web Cache Communication Protocol (WCCP) | |
| 8.00 | Implement Quality of Service (QoS) | |
| 8.10 | Implement Modular QoS CLI (MQC) | |
| (a) Network-Based Application Recognition (NBAR) | ||
| (b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ) | ||
| (c) Classification | ||
| (d) Policing | ||
| (e) Shaping | ||
| (f) Marking | ||
| (g) Weighted random early detection (WRED) and random early detection (RED) | ||
| (h) Compression | ||
| 8.20 | Implement Layer 2 QoS: weighted round robin (WRR), shaped round robin (SRR), and policies | |
| 8.30 | Implement link fragmentation and interleaving (LFI) for Frame Relay | |
| 8.40 | Implement generic traffic shaping | |
| 8.50 | Implement Resource Reservation Protocol (RSVP) | |
| 8.60 | Implement Cisco AutoQoS | |
| 9.00 | Troubleshoot a Network | |
| 9.10 | Troubleshoot complex Layer 2 network issues | |
| 9.20 | Troubleshoot complex Layer 3 network issues | |
| 9.30 | Troubleshoot a network in response to application problems | |
| 9.40 | Troubleshoot network services | |
| 9.50 | Troubleshoot network security | |
| 10.00 | Optimize the Network | |
| 10.01 | Implement syslog and local logging | |
| 10.02 | Implement IP Service Level Agreement SLA | |
| 10.03 | Implement NetFlow | |
| 10.04 | Implement SPAN, RSPAN, and router IP traffic export (RITE) | |
| 10.05 | Implement Simple Network Management Protocol (SNMP) | |
| 10.06 | Implement Cisco IOS Embedded Event Manager (EEM) | |
| 10.07 | Implement Remote Monitoring (RMON) | |
| 10.08 | Implement FTP | |
| 10.09 | Implement TFTP | |
| 10.10 | Implement TFTP server on router | |
| 10.11 | Implement Secure Copy Protocol (SCP) | |
| 10.12 | Implement HTTP and HTTPS | |
| 10.13 | Implement Telnet |
Subscribe to:
Posts (Atom)