Cisco Tips & Tricks

January 28, 2010

Spanning Tree 802.1d and RSTP 802.1w

Filed under: Switching, Technology and Software — ciscotips @ 9:37 pm

Great videos from Cisco Learning Network

For Spanning Tree Protocol ( 802.1d)

For Rapid Spanning Tree Protocol ( 802.1w)

November 8, 2009

CCIE notes for GLBP

Filed under: ccie, cisco, Technology and Software — ciscotips @ 5:47 am

Gateway load balancing protocol performs similar function to HSRP and VRRP. In both HSRP and VRRP,  group of routers participating in first hop-redundancy has one Active and can have multiple Client routers. At one single time, traffic is being passed through Active router, leaving client routers with unused bandwidth. Client routers will only become active once Active router in a group fails. We can create multiple groups and create different active routers but it results in extra administrative burden.

GLBP on the other hand can provide load balancing over multiple routers (gateways) using a Single Virtual IP and multiple Virtual mac-addresses. The bandwidth/traffic load is shared between multiple routers participating in the group rather than being handled by a single active router.

Following are the important points conceptually for GLBP.

  1. GLBP uses single Virtual IP and multiple mac-addresses to provide first-hop Gateway redundancy.
  2. In GLBP, there can be four routers/gateways in a group
  3. Hello messages are used to communicate with in the group destined to, udp port 3222 and they will be sent every 3 secs by default.
  4. initially group members will elect one AVG ( Active Virtual Gateway) and other routers will act as backup AVG’s incase the active AVG fails
  5. AVG will assign Virtual mac-addresses to other routers, they are known as AVF’s ( Active Virtual Forwarders)
  6. Each AVF assumes responsibility for  forwarding  packets sent to Virtual Mac’s assigned by AVG.
  7. AVG is responsible for answering ARP requests for Virtual IP’s

Configuring GLBP

R2(config-if)#glbp 1 load-balancing ?
  host-dependent  Load balance equally, source MAC determines forwarder choice
  round-robin     Load balance equally using each forwarder in turn
  weighted        Load balance in proportion to forwarder weighting

There are three different types of Load balancing algorithms in GLBP.


  1. The Mac-address of the host is used to determine which AVF’s  mac is the host directed towards.
  2. A given host is guaranteed to use the same Virtual Mac as long as number of VF’s in the GLBP group are constant
  3. Host dependant GLBP is not recommended in situation where there are small number of hosts, for example, less than 20


  1. GLBP places a weight on each device to calculate the amount of load sharing that will occur through MAC assignment
  2. Each GLBP router in a group will advertise its weight and AVG will act based on that value
  3. For example  we have two routers, Router A and Router B. If router A has double the bandwidth capacity then router B. Router A will be configured with the double weighting value of router B


  1. With Round-robin VF mac-address is used sequentially in ARP replies for the virtual IP
  2. This is the default type of GLBP algorithm
  3. It is suitable for any number of hosts.

Steps for  configuring GLBP

  1. enable GLBP with glbp 1 load-balancing
  2. glbp 1 priority ( Higher is better, default is 100)
  3. glbp 1 ip x.x.x.x
  4. glbp 1 preempt < To enable preempt, by default its disabled>
  5. glbp 1 authentication  ( Enabling authentication with in a group)


Show glbp

August 5, 2009

Protocol Overhead

Filed under: cisco, Technology and Software — ciscotips @ 9:40 pm

Protocol Overhead

How fast can you really go using a given media and protocol stack? We examine how much bandwidth is left for applications.


Ethernet frame format:

  • 6 byte dest addr
  • 6 byte src addr
  • [4 byte optional 802.1q VLAN Tag]
  • 2 byte length/type
  • 46-1500 byte data (payload)
  • 4 byte CRC
Ethernet overhead bytes:
  12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
  12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q

Ethernet Payload data rates are thus:
  1500/(38+1500) = 97.5293 %   w/o 802.1q tags
  1500/(42+1500) = 97.2763 %   with 802.1q tags

TCP over Ethernet:
 Assuming no header compression (e.g. not PPP)
 Add 20 IPv4 header or 40 IPv6 header (no options)
 Add 20 TCP header
 Add 12 bytes optional TCP timestamps
 Max TCP Payload data rates over ethernet are thus:
  (1500-40)/(38+1500) = 94.9285 %  IPv4, minimal headers
  (1500-52)/(38+1500) = 94.1482 %  IPv4, TCP timestamps
  (1500-52)/(42+1500) = 93.9040 %  802.1q, IPv4, TCP timestamps
  (1500-60)/(38+1500) = 93.6281 %  IPv6, minimal headers
  (1500-72)/(38+1500) = 92.8479 %  IPv6, TCP timestamps
  (1500-72)/(42+1500) = 92.6070 %  802.1q, IPv6, ICP timestamps

UDP over Ethernet:
 Add 20 IPv4 header or 40 IPv6 header (no options)
 Add 8 UDP header
 Max UDP Payload data rates over ethernet are thus:
  (1500-28)/(38+1500) = 95.7087 %  IPv4
  (1500-28)/(42+1500) = 95.4604 %  802.1q, IPv4
  (1500-48)/(38+1500) = 94.4083 %  IPv6
  (1500-48)/(42+1500) = 94.1634 %  802.1q, IPv6

An excellent source of ethernet information is Charles Spurgeon’s Ethernet Web Site.


  1. 48-bit (6 byte) ethernet address have a 24-bit “Organizationally Unique Identifier” (OUI) assigned by IEEE + a 24-bit number assigned by the vendor.
  2. The minimum ethernet payload (data field) is 46 bytes which makes a 64 byte ethernet packet including header and CRC.
  3. The maximum ethernet payload (data field) is 1500 bytes which makes a 1518 byte ethernet packet including header and CRC. When 802.1q added an optional 4-byte VLAN Tag Header, they extended the allowed maximum frame size to 1522 bytes (22 byte header+CRC).
  4. The bit speed of 100 Mbps ethernet on the wire/fiber is actually 125 Mbps due to 4B/5B encoding. Every four data bits gets mapped to one of 16 5-bit symbols. This leaves 16 non-data symbols. This encoding came from FDDI.
  5. The original Ethernet II spec had a two byte type field which 802.3 changed to a length field, and later a length/type field depending on use: values 1536 and over are types, under 1536 lengths.

Gigabit Ethernet with Jumbo Frames

Gigabit ethernet is exactly 10 times faster than 100 Mbps ethernet, so for standard 1500 byte frames, the numbers above all apply, multiplied by 10. Many GigE devices however allow “jumbo frames” larger than 1500 bytes. The most common figure being 9000 bytes. For 9000 byte jumbo frames, potential GigE throughput becomes (from Bill Fink, the author of nuttcp):

Theoretical maximum TCP throughput on GigE using jumbo frames:

	(9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
	  |   |  |  |     |   |  | | | |       |         |
	 MTU  |  |  |    MTU  |  | | | |      GigE      Mbps
	      |  |  |         |  | | | |
	     IP  |  |  Ethernet  | | | |      InterFrame Gap (IFG), aka
	  Header |  |    Header  | | | |      InterPacket Gap (IPG), is
		 |  |            | | | |      a minimum of 96 bit times
	       TCP  |          FCS | | |      from the last bit of the
	    Header  |              | | |      FCS to the first bit of
		    |       Preamble | |      the preamble
		  TCP                | |
	      Options            Start |
	  (Timestamp)            Frame |
			     Delimiter |
				 (SFD) |

Theoretical maximum UDP throughput on GigE using jumbo frames:

	(9000-20-8)/(9000+14+4+7+1+12)*1000000000/1000000 = 992.697 Mbps

Theoretical maximum TCP throughput on GigE without using jumbo frames:

	(1500-20-20-12)/(1500+14+4+7+1+12)*1000000000/1000000 = 941.482 Mbps

Theoretical maximum UDP throughput on GigE without using jumbo frames:

	(1500-20-8)/(1500+14+4+7+1+12)*1000000000/1000000 = 957.087 Mbps


An excellent paper on ATM overhead was written by John Cavanaugh of MSC. A postscript copy can be found here. Based on that paper:

  -------------------------- DS3 ------------------------------
  Line Rate           44.736 Mbps
  PLCP Payload        40.704                       (avail to ATM)
  ATM Payload         36.864                       (avail to AAL)
                     MTU=576  MTU=9180 MTU=65527
  AAL5 Payload        34.501   36.752   36.845     (avail to LLC/SNAP)
  LLC/SNAP Payload    34.028   36.720   36.841     (avail to IP)
  IP Payload          32.847   36.640   36.830     (avail to transport)
    UDP Payload       32.374   36.608   36.825     (avail to application)
    TCP Payload       31.665   36.560   36.818     (avail to application)

  -------------------------- OC-3c ------------------------------
  Line Rate           155.520 Mbps
  SONET Payload       149.760                      (avail to ATM)
  ATM Payload         135.632                      (avail to AAL)
                     MTU=576  MTU=9180 MTU=65527
  AAL5 Payload        126.937  135.220  135.563    (avail to LLC/SNAP)
  LLC/SNAP Payload    125.198  135.102  135.547    (avail to IP)
  IP Payload          120.851  134.808  135.506    (avail to transport)
    UDP Payload       119.112  134.690  135.489    (avail to application)
    TCP Payload       116.504  134.513  135.464    (avail to application)

  -------------------------- OC-12c -----------------------------
  Line Rate           622.080 Mbps
  SONET Payload       600.768                      (avail to ATM)
  ATM Payload         544.092                      (avail to AAL)
                     MTU=576  MTU=9180 MTU=65527
  AAL5 Payload        509.214  542.439  543.818    (avail to LLC/SNAP)
  LLC/SNAP Payload    502.239  541.966  543.752    (avail to IP)
  IP Payload          484.800  540.786  543.586    (avail to transport)
    UDP Payload       477.824  540.313  543.519    (avail to application)
    TCP Payload       467.361  539.605  543.420    (avail to application)


  1. DS3 and SONET frames are 125 usec long (8000/sec).
  2. PLCP packs 12 ATM cells per DS3 frame, for 96 kc/s (8000×12).
  3. An STS-3c frame (OC3c) is 2430 bytes long (270 bytes x 9 rows), 90 of which are consumed by SONET overhead (9 bytes x 9 rows section and line overhead and 1 byte x 9 rows path overhead), 2340 bytes are payload (260 bytes x 9 rows). The payload is called the Synchronous Payload Envelope (SPE).
  4. An STS-12c frame (OC12c) is 9720 bytes long, 333 of which are SONET overhead, 9387 bytes are payload (SPE). Note that this is slightly larger than four STS-3c SPE’s (4×2340=9360), the advantage of “concatenated” OC12c vs. OC12.
  5. ATM cells are 53 bytes long: 5 header and 48 payload.
  6. AAL5 adds an 8 byte trailer in the last 8 bytes of the last cell, padding in front of the trailer if necessary. This results in 0-47 bytes of padding in an AAL5 frame. In the worse case, you have seven bytes of padding in one cell, and 40 bytes of padding plus the 8 byte AAL5 trailer in the following cell.
  7. RFC1483 defines two types of protocol encapsulation in AAL5
    • LLC/SNAP – adds an 8 byte header containing LLC (3 bytes), OUI (3 bytes), and PID/EtherType (2 bytes)
    • VC-mux – adds no additional bytes by sending only a single protocol type per VC
  8. IPv4 usually adds 20 bytes. IPv6 would add 40 bytes. Plus any options but assumed zero here.
  9. UDP adds an 8 byte header. (ICMP is also an 8 byte header)
  10. TCP adds a 20 byte header plus any options. A common option on high performance flows is timestamps which consume an additional 12 bytes per packet.

On the physical layer (single pt-to-pt hop), one out of every 27 cells is an OAM cell. The above calculations don’t take that into account, but that’s another 3.7% reduction!

We should add calculations for ping packets and 1500 byte packets.

So what is the largest packet that we can fit in a single ATM cell? If you are using AAL5, you have a 40 byte payload to work with. For IPv4, you could have a 20 byte header + a 20 byte IP payload. A UDP or ICMP payload could be up to 12 bytes (both use 8 bytes after the IP header). So a “ping -s8” through “ping -s12” should fit in one ATM cell and still give you a round trip time.


Packet Over SONET (POS)

Packet over SONET (POS) uses PPP with HDLC to frame IP packets. These add a five byte header and a four byte trailer under normal circumstances. No padding is required, except for any possible idle time between packets. Byte stuffing is used (see notes below) which can expand the length of the POS frame.

       Flag Byte (0x7e)
       Address Byte (0xff = all stations)
       Control Byte (0x03 = Unnumbered Information)
          Protocol - 2 bytes, 1 byte if compressed      +
          Payload - 0-MRU bytes                         | PPP part
          Padding - 0+ bytes                            +
       Frame Check Sequence (FCS) - 4 bytes (2 in limited cases)
       Flag Byte (0x7e)
       [Interframe fill or next Address]

HDLC has no set frame size limit, nor does PPP specify the payload size, you just keep reading until you see a Flag byte. PPP however specifies that the Maximum Receive Unit (MRU) default is 1500 bytes and that other sizes can be negotiated using LCP. These LCP messages have a 16-bit length field, so a properly negotiated maximum payload would be 65535 bytes. [It would be possible to configure a sender/receiver pair to go beyond 65535 and simply not negotiate a size with LCP. No one does this however.] Most POS hardware seems to have a 4470 or 9180 byte MRU.

So we get:

  -------------------------- OC-3c ------------------------------
  Line Rate           155.520 Mbps
  SONET Payload       149.760                      (avail to POS)
  POS Payload         *** to do ***                (avail to IP)

  -------------------------- OC-12c -----------------------------
  Line Rate               622.080 Mbps
  SONET Payload           600.768                      (avail to POS)
                         MTU=1500   MTU=9000
  POS Payload (no stuff)  597.185    600.168           (avail to IP)  9 overhead
  POS Payload (rnd stuff) 592.583    595.520                          20.71875 overhead
  POS Payload (max stuff) 299.486    300.234                          1509 overhead

  ~TCP Payload w/ts rnd   572.040    592.079


  1. Only one flag byte is required between frames, i.e. the flag byte that ends one frame can also begin the next.
  2. It is possible for the HDLC Address and Control fields to be “compressed”, i.e. non-existent. This is negotiated by PPP’s Link Control Protocol (LCP). The RFC’s however recommend that they be present on high speed links and POS.
  3. The protocol field can be compressed to one byte (negotiated by LCP), but this is also discouraged on high speed links and POS.
  4. IP -> PPP -> FCS generation -> Byte stuffing -> Scrambling -> SONET/SDH framing
  5. The Frame Check Sequence (FCS) for POS should be 32-bits. RFC2615 allows for 16-bits (the PPP default) only when required for backward compatibility, and only on OC3c. Even on OC3c 32-bit is recommended. The FCS length is configured, not negotiated. The FCS-32 uses the exponents x**0, 1, 2, 4, 5, 7, 8, 10, 11, 12, 16, 22, 23, 26, 32.
  6. Byte stuffing escapes any Flag (0x7e) and Escape (0x7d) bytes by inserting an Escape byte and xoring the original byte with 0x20. [PPP can also escape negotiated control characters but this is not used in POS.] Byte stuffing can at worse double the payload size (e.g. data of all 0x7e). For uniform random data one in every 128 bytes would be stuffed, for an overhead of 0.775%.
  7. The stuffed data is then scrambled with 1+x**43 (the same used for ATM) to prevent certain data patterns from interfering with SONET.



  • RFC1661 The Point-to-Point Protocol (PPP), July 1994
  • RFC1662 PPP in HDLC-like Framing, July 1994
  • RFC2615 PPP over SONET/SDH, June 1999


POS with Frame Relay encapsulation

Frame Relay (FR) encapsulation can be used on POS instead of HDLC/PPP. There are not any RFC’s about Frame Relay over SONET, nor does the Multiprotocol over Frame Relay RFC1490 discuss SONET or POS, but Cisco starting doing this and others have followed.


  • RFC2427 Multiprotocol Interconnect over Frame Relay, September 1998

Generic Framing Proceedure

A new way to do POS uses PPP over GFP-F (Generic Framing Proceedure, Framed) instead of HDLC. In both the HDLC and GFP-F cases, SONET / SDH VCAT (Virtual Concatenation) is used. GFP-F also allows Ethernet frames (100, GE and 10GE) and Resilient Packet Ring (RPR) frames to be sent over SONET/SDH VCAT. GFP can also map to G.709 (part of the Optical Transport Network (OTN) series).

A GFP User Frame:

  • 4 byte Core Header
    • 2 byte PDU Length Indicator (PLI)
    • 2 byte Core Header Error Control (cHEC)
  • Payload – up to 65535 bytes
    • Payload Header (4-64 bytes)
      • 2 byte Type
      • 2 byte tHEC
      • 0-60 byte Extension Header including an optional 2 byte eHEC at the end.
    • Payload (min of 1600 should be supported, larger by agreement)
    • Payload FCS (optional)

A PLI of 0-3 indicates a GFP control frame. cHEC is a CRC-16 that protects the core header only (single bit error correction, multi bit error detection).


Multi Protocol Label Switching (MPLS)

Multi-Protocol Label Switching (MPLS) adds four bytes to every frame. As described in RFC3032 the 32-bit label includes:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
|                Label                  | Exp |S|       TTL     | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

     Label:  Label Value, 20 bits
     Exp:    Experimental Use, 3 bits
     S:      Bottom of Stack, 1 bit
     TTL:    Time to Live, 8 bits

Serial Lines (T1,T3)

To do

  • DS-3 is specified as 44.736 Mbps +/- 20 parts per million (ppm). So one DS-3 can vary from another by up to 1789 bps.
  • Bit-stuffing is used to accommodate rate mismatches as you mux up the DS-n hierarchy.

P. Dykstra,, March 2001, last update April 2003



June 10, 2009

Cisco Revising CCIE R&S Certification

Filed under: bgp, ccie, cisco, IP Routing, Technology and Software — ciscotips @ 8:10 pm

The upcoming Version 4.0 of Cisco CCIE® Routing and Switching certification will test hands-on troubleshooting, Multiprotocol Label Switching (MPLS), and VPN networking


To reflect the growth of the network as a service platform, Cisco is revising the certification requirements for CCIE Routing & Switching (CCIE R&S)–the expert level certification for network engineers. The new requirements were developed with assistance from Cisco enterprise customers and reflect the expectations of employers across industries.


The competencies required for CCIE R&S v4.0 certification were released on May 5, 2009, and are available on the Cisco Learning Network under the CCIE R&S v4.0 Written Exam topics and CCIE R&S v4.0 Lab Exam topics. Exams based on the new requirements are scheduled for release on October 18, 2009, and will immediately replace the currently available v3.0 exams. Candidates who plan to take their exams on October 18, 2009, or later should prepare using the new v4.0 exam topics.


Both the written and lab exams will be refreshed with new questions and will cover MPLS and VPN networking. The written exam will add scenario-based questions to the multiple choice questions, and the lab will now require hands-on troubleshooting of preconfigured networks, in addition to configuration. Exam duration and pricing will remain the same, with the two-hour written exam at USD$350 and the eight-hour lab at USD$1400.


A beta version of the new CCIE R&S v4.0 written exam (351-001) will be available to all customers in the July–August 2009 timeframe at a discounted price of USD$50. An announcement will be made when scheduling begins.


Cisco 360 Learning Program Updates Available

Cisco 360 Learning Program components aligned to the new CCIE R&S certification standards will be available on May 11, 2009.  All current students will have access to the new materials throughout their subscription period.  New materials include additional lessons on MPLS and troubleshooting, enhanced coverage of these topics in the instructor-led workshops, an updated Practice Lab Workbook for self-paced practice, and new Performance Assessments that gauge skill level and offer mentoring feedback.


CCIE Assessor, the first CCIE R&S practice lab, will be retired on June 5, 2009, and will be replaced by the 10 eight-hour assessment labs available through the Cisco 360 Learning Program. Find out more


Frequently Asked Questions

1  –  Q: What exactly is being changed on the CCIE R&S written exam?


A: The CCIE R&S v4.0 written exam will be refreshed with new questions to reflect the current job role expectations of employers. Scenario-based questions will be added to the multiple choice questions. New topics include the skills associated with planning and evaluating network changes, implementing MPLS, Layer 3 VPN, IPv6, EIGRP and multicast; and configuring performance-based routing.  More information is available on the CCIE Written Exam Overview page.



2  –  Q: What exactly is being changed on the CCIE R&S lab exam?

A: The CCIE R&S v4.0 lab exam will be refreshed with new questions to reflect the current job role expectations of employers. The equipment in the testing lab will be updated with Cisco 1800 and 3800 Series Integrated Services Routers running Cisco IOS® Software Version 12.4(T) and Cisco Catalyst® 3560 Series Switches running Cisco IOS Version 12.2 Advanced IP Services. The biggest change will be the testing of hands-on troubleshooting for the first two hours of the eight-hour exam. Candidates will be presented with a series of trouble tickets for preconfigured networks, and they will need to diagnose and resolve the network fault or faults—a realistic and challenging job task. Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section, since their equipment will need to be reinitialized for the configuration portion of the exam.

To make time for new material, CCIE R&S v4.0 exams will put less emphasis on equipment operation and concepts generally understood at the professional level. These skills are still assumed, but will not be the sole objective of CCIE test questions. Go to the Lab Exam Study/Learn section for more information.



3  –  Q: Now that the CCIE R&S v4.0 has been announced, can I still take the CCIE R&S v3.0 exam? How long will it be valid?


A: The CCIE R&S v3.0 written exam will be available through October 17, 2009, at all Pearson VUE testing centers. Passing the v3.0 written exam qualifies a candidate to take any available version of the CCIE R&S lab exam. As with all CCIE written exams, a passing score on v3.0 written exam will remain valid for three years, as long as the candidate attempts the lab exam once within the first 18 months. If the lab is not attempted, the written exam becomes invalid and the candidate will have to retest using whatever written exam is available at that time.



4  –  Q: If I take the CCIE R&S written beta test in July or August 2009, will I still be able to schedule the CCIE R&S v3.0 lab exam?


A: Scores on CCIE written beta tests are not available until 4 to 6 weeks after the close of the beta period. At this time, there is no guarantee the CCIE R&S v3.0 lab exam will still be available when a beta test candidate receives his or her score. Beta testers should plan on taking the CCIE R&S v4.0 lab test to achieve certification.



5  –  Q: If I don’t pass the CCIE R&S v4.0 written beta exam, can I take it again in five days?


A: No, a candidate can only take a CCIE written beta test once during the beta testing period.




6  –  Q: Will there be any changes to the recently-added Core Knowledge portion of the exam, the part with the short-answer questions?


A: The questions in the Core Knowledge section of the lab exam may cover any area on the CCIE R&S v4.0 Lab Exam topics.




7  –  Q: What can a candidate expect in the troubleshooting portion of the lab exam?


A: Troubleshooting is allotted two of the eight hours required for the CCIE lab exam. Candidates will be presented with a series of trouble tickets for preconfigured networks and will need to diagnose and resolve the fault or faults. As with previous CCIE labs, the network will need to be up and running for the candidate to receive credit.  Candidates who finish the troubleshooting section early can move on to the configuration section, but they will not be allowed to go back to the troubleshooting section.



8  –  Q: Does a candidate have to pass both the troubleshooting and configuration sections in order to pass the entire CCIE R&S v4.0 lab exam and earn a CCIE?


A: Candidates will receive a single pass/fail grade on the entire exam, including both configuration and troubleshooting. Failing score reports will give an indication of where the candidate scored lower, to help the candidate prepare for another attempt.



9  –  Q: Will the CCIE R&S mobile lab exam also be updated?


A: Yes, CCIE R&S mobile labs use the same lab version as Cisco office locations, and they will switch to the v4.0 lab exam on October 18, 2009 as well.



10  –  Q: Which exam will be used for recertification?


A: As of October 18, 2009, CCIEs who take the CCIE R&S written exam for recertification will be given the v4.0 exam and should prepare using the exam topics found on the Cisco Learning Network.



11  –  Q: Are the previous Cisco 360 components applicable to the CCIE R&S v4.0 exams? Should candidates studying for CCIE R&S v4.0 exams wait for the new Cisco 360 materials to begin work?


A: The learning components available at first launch of Cisco 360 are still relevant to candidates studying for the CCIE R&S v4.0 certification exams. No Cisco 360 Learning Program components are being retired.  There is no need for candidates to wait for revised Cisco 360 material to begin their study and practice. The subscription model ensures that Cisco 360 customers can take advantage of all new content as it is released and do not need to wait.

October 27, 2008

Compute an access-list to match even or odd networks

Filed under: Access-lists, ccie, IP Routing, Router, security, Technology and Software — ciscotips @ 10:16 pm

One of my old student who is preparing for CCNP asked me on how to write an access-list for permitting/denying even or odd networks. So I am just pasting my email reply to him

Here is a simple tip to write an access-list for even or odd networks.

Lets say we are asked to permit all odd or permit all even for ?

We’ll play the game with last octet or I should say the least significant bit of last octet.

-If it is 0, the IP address will be Even

-If it is 1, the IP address will be Odd = – odd =  – odd =   even =   even

FOR Even Networks

The IP address will be

With the wild card mask as

254 = 11111110

Here, 0 means DO CARE of the last bit in IP address (must be ZERO)

Hence ACL will be

access-list 1 permit

For Odd Networks

The IP address will be

With the wild card mask as

254 = 11111110

Here, 0 means DO CARE of the last bit in IP address (must be ONE)

Hence ACL will be

access-list 1 permit


October 24, 2008

Day 3, 4 and 5 of Narbik’s Bootcamp

Filed under: bgp, ccie, IP Routing, QOS, Technology and Software — ciscotips @ 6:22 pm

Sorry for posting late, Narbiks bootcamp was fun. Its worth attending his bootcamp if you are somewhere in the mid-tier of your CCIE preparation. Narbik recommends to cover Soups-to-nuts before you attend his bootcamp and he is right., otherwise it can be too much of information for you in 5 Days. Here is what he covered in last three days.

Day 3:- BGP

It was a big day for me. Day 3 is a BGP day, youy have  almost 200 pages worth of BGP labs. Narbik’s BGP  lecture style is totally different then the conventional CCIE Instructors. He doesn’t start BGP with Attributes or BGP states. He attacks on BGP optimization and then buiold you towards attributes and other advance topics. Simply awesome. He will start with MSS ( Maximum segment size) , Scan time, Advertising Interval and then take you to Memory pools, templates and Peer-groups. At last he will talk about BGP states, Aggregation, Attributes and some awesome route-filtering techniques. I will say that was my best BGP class.

Day 4:- RIPv2 and QoS

Another big day which was dedicated to Qos and 2 hours worth of lecture for RIP v2.  He showed what RIPv2 is worth of. People normally ignore RIP but if you know what all you can do with RIP. You will never be disappointed to use it for your small size network. He covered optimization, RIP updates,Filtering,redistribution,authentication  building it on some advanced scenarios.

Qos:- Qos

Qos was never my strong topic, although I am using it regularly in my job but I always struggled on few advanced topics. I should not have a problem in Qos after attending Narbik’s lecture.  Narbik started Qos with Queuing. He covered, CBWFQ, LLQ, filtering,CBWRED,Shaping, CAR,policing and SRR. Pretty good lecture indeed!

FInal Day ( Day 5 Multicast and CCIE lab tips).

Narbik covered multicast Addressing, Delievery Methods, Manipulating MCast Traffic, Dense,sparse modes, MSDP,ANycast and udp helper. I still have to work on Multicast labs but I am sure  I can practice on it  and grasp what I need most for my Lab.

As I am going through Narbik’s Advance 6 volume CCIE workbooks, I will try to post tips and tricks on various technologies going forward.

July 29, 2008

Is cuil really Cool-Google’s challenge?

Filed under: Technology and Software — ciscotips @ 4:39 am

Cuil can be a great tool for searching cisco related docs on the web. It claims to have a better indexing and largest database then any available search engine 🙂

Here is a small review from cnet.

April 30, 2008

My CCIE Lab experience

Filed under: cisco, Technology and Software — ciscotips @ 10:10 pm

I was all geared up for my CCIE R&S lab in san jose.  I was a bit nervous as most of my lab practice came from job experience, plus some online workbook scenarios. Not to mention that I relied more or less on a non-conventional style of study. Dynamips was definitely a great help especially if you are running your dynamips on UBuntu Linux ( I love it).

I arrived in San Jose 2 days before my lab, and tried to manage my stress and jet lag. I promised myself that I would not look back in to my notes, but guess what i was so stressed that I started looking back in to my Qos,multicast and IP securtiy notes. I tried to have a good night sleep before the exam, but I was not able to sleep. I was getting cisco dreams all night.

I woke up at 6:30 in the morning and got ready for the exam, I had a yogurt for my breakfast as it was my wife’s suggestion. Arrived at site, checked in and the front desk guy asked for my ID, then he checked  me in with other candidates waiting in the lobby. I could see some going through notes and other just confused and lost. Proctor arrived at 8:15 and he acquainted us with rules and regulations.

by the lunch hour I was pretty confident as i thought I was doing well but right after the lunch I had some doubts, I skipped a few questions and moved on to the next. I finished rest of the tasks and the time was already 4:30. 30 minutes to go and i had still few tasks left which i had skipped earlier. I went back to the tasks and tried to finish all of them. By the time I finished all the tasks , my time was up.

I came out still confident and with a great hope that I would clear the lab. I was awake again whole night as the proctor told me that I would get a result the next morning. I checked my mail almost three times in the night but nothing fruitful came out of it. In the morning at almost 7:15 AM, I checked my mail again and I could see a mail from cisco. I logged in to Cisco with my CCO id, my heart was beating fast. To my surprise, I could see FAIL next to my score. What went wrong , I asked myself. My technology score was black and white enough to show me where I messed up.

For my secont attempt, I’ve signed up for Narbik’s bootcamp in June, and am planning to retry my lab within a few weeks of completing the bootcamp.

March 5, 2008

Cisco Graphical Simulator or GNS3

Filed under: cisco, Router, Switching, Technology and Software — ciscotips @ 6:38 pm

What is GNS3 ?

GNS3 is a graphical network simulator that allows you to design complex network topologies and to launch simulations on them.

To allow complete simulations, GNS3 is strongly linked with :

  • Dynamips, an IOS emulator which allows users to run IOS binary images from Cisco Systems.
  • Dynagen, a text-based front-end for Dynamips.

GNS3 is a excellent complementary tool to real labs for administrators of Cisco networks or people wanting to pass their CCNA, CCNP, CCIP or CCIE certifications.

It can also be used to experiment features of Cisco IOS or to check configurations that need to be deployed later on real routers. This project is an open source product that may be used on multiple platforms, including Windows, Linux, and MacOS X.

Features overview

  • Designing high quality complex network topologies.
  • Emulating Cisco routers.
  • Simulating simple Ethernet, ATM and Frame Relay switches.
  • Load and save in Dynagen’s INI-like format.
  • Image export (JPEG, PNG, BMP and XPM).

Important notice: users must provide their own Cisco IOS to use GNS3.

January 31, 2008

Cisco Open source tools

Filed under: cisco, IP Routing, security, Switching, Technology and Software — ciscotips @ 3:13 am

I came across a great resource, Cisco-centric Open Source Community (COSI). COSI is an Internet-based community that develops free Cisco tools and makes them available for download from its Web site. There are almost 50 utilities available for download. The scripts and utilities all include documentation, and the community has developed all of these tools to work with Cisco IOS routers, switches, firewalls, or CiscoWorks management software.

COSI’s Web site also offers other advantages. Clicking the link to download a script takes you to a community download page, which also features discussion forums for questions and support of these tools. It’s important to remember that Cisco’s Technical Assistance Center (TAC) doesn’t support these tools, so you must count on your own skills and the help of others in the community.

A tradeoff: These tools are not ideal for new Cisco IOS users or anyone who doesn’t have some Linux experience. Many of these tools help automate more advanced Cisco admin tasks when administering a midsize to large Cisco network

Older Posts »

Blog at