http://itdualism.wordpress.com/2010/01/15/new-ccnp-track-more-details/

http://itdualism.wordpress.com/2010/01/25/new-ccnp-official-announcement/

http://itdualism.wordpress.com/2010/01/25/new-ccnp-books/

http://itdualism.wordpress.com/2010/01/27/tshoot-beta-free/

For something a little bit more official, check here: https://learningnetwork.cisco.com/docs/DOC-6393

Somewhere along the way I got de-railed on that quest. So it’s only fitting that the start of this New Year should be a re-dedication and a renewal of my goal to achieve the CCNP. So here we go….

P.S. Thanks to everyone who has been leaving me comments with advice and encouragement. I may not have been replying to the comments but know that I appreciate all your thoughts and well-wishes. Here’s for a productive 2010!

It has come across my mind to just cancel the test and get a refund. Then reschedule again for when I was actually ready. But stupid me kept thinking that if I did that then I surely will never take that test. The only assurance or driving force I had, if you will, is keeping the test date hoping that it will drive me towards studying more – and that I can always reschedule if I wasn’t ready.

I have been studying but just not as diligently and focused as I used to. Every day I take about 45 minutes are so to sit down and do some studying. It just doesn’t cut it compared to the hours per day that I used to do. Knowledge acquisition becomes very slow and retention seems to get weaker as longer days pass without touching the same subject again.

I need a new catalyst. And no, I don’t mean a new switch.

So far, I’ve had a lot of trouble trying to adjust back to my old study habits and patterns. My motivation has been sapped dry and focusing is very hard to achieve. I don’t think it has anything to do with my mom’s passing anymore. Sure it derailed my studies but I’m pretty sure I’m passed the grieving stage at this point.

I know for sure that since then I’ve been watching more TV than before. I think it goes hand in hand with the fact that during the time I’m taking care/watching my infant son, whether I’m holding him or feeding him, I also have the TV on. So the entertainment factor from watching TV more than likely takes away from my motivation to study.

Additionally, since starting P90X many months back, I’ve also tried to make exercise a regular part of my week. That alone takes an hour to an hour and a half a day, for about 3 days a week. At least I’m happy with the progress I’m making on this aspect.

Although I’ve slowed down considerably, I definitely have not stopped. I’m proud to say that I spent a good hour studying last night . It’s not nearly close to how much I used to study but good enough considering I wasn’t studying for days at a time. I’m just a little bummed that I’ve had to reschedule my BCMSN exam six times already. I was due to take it 2 weeks before my mom died. And ever since then, I’ve been rescheduling it just about every 2 weeks, hoping that the next two weeks would be it. But every 2 weeks come and I’m still not ready. In fact I’ve forgotten so much of the materials that I may have to start my review again from the start.

Anyway, my goal for the next two days is to complete my review on wireless LANs. Wish me luck.

The outpouring of love and support I’ve received from a few friends all over the world has been a source of great comfort for me. It’s amazing how simple messages of encouragement from someone you hardly even know or have never met can effect such a positive result.

Again thank for all the prayers.

I’ll probably take a short break.

So far I’m a little behind as far as what I had planned to have reviewed by this point in time. But that’s okay. I tend to do well and catch up on my reviews towards the last week when adrenaline is high and the fight mechanism in me is at its optimum level.

I got sick towards the latter part of last week and obviously, that hampered my progress over the weekend. I intended to cover a bulk of my reviews this past weekend but just didn’t have enough juice to keep it going.

So far here are the chapters that I have covered:

• VLANs – Fundamentals, operation, implementation/configuration, verification, troubleshooting.
• VLAN trunking
• VTP
• Spanning Tree (802.1D, 802.1W, 802.1s)
• PVRST+, MSTP
• STP enhancements such as Root Guard, BPDU Guard, BPDU Filtering, Loop Guard, UDLD
• Portfast, Uplinkfast, Backbonefast

Still left to go:

• Inter-VLAN
• EtherChannel
• CEF
• Redundancy (HSRP, VRRP, GLBP)
• Multicast
• Layer 2 Security (802.1x, VACL, etc)
• Voice
• Wireless
• There’s more but I’m too lazy to list all of them.

I was going through the BCMSN Study schedule on this blog and I realized how sorely lacking it is in details. So I figured after I pass the exam, I’ll make an attempt to organize this list with the dates I covered them and publish it on the schedule page for others’ reference.

Anyway, that’s all for now. I may or may not update before the exam so just keep checking your feeds.

Apparently the new CCNP Wireless certification track was announced at the Cisco Live 2009 that was held recently in San Francisco. Now I remember back in the early part of this year that there were some talks about Cisco talking about launching a new professional level wireless cert but never heard about it since. I did a quick search on all my blog feeds and not one has talked about it (Come on bloggers! I rely on you for the latest and most current news. What’s up, man?)   

Here’s more info for the curious minds (who, like me, still didn’t know):

Cisco Wireless Professional Certification

One of the pre-requisites is that you must have a CCNA wireless cert and/or any CCIE ceritfification. I’m not 100% on the latter pre-req.

Formal prerequisites for the CCNP Wireless certification are CCNA (Routing & Switching) and CCNA Wireless.  In order to pass the CCNP Wireless exams an individual should have:

• At least three to five years of job experience in network engineering
• A thorough understanding of wireless networking principles
• An in-depth understanding of the four courses

You must pass the required CUWSS (642-731), IUWVN (642-741),  IUWMS (642-746), IAUWS (642-736) exams to achieve CCNP Wireless certification.

 

CCNP Wireless courses and exams are available starting today July 24th, 2009.

Look here for more FAQ-type of information.

Anyway, I scheduled my exam for August 15, 2009. I needed something to push me to get done with this exam. I figured if the pressure of an upcoming exam is looming over my head, I might just get to hunkering down and hitting the books. So far it’s not working . It better work though in the next coming days.

Last week I finished the section on HSRP, VRRP, and GLBP. This week I’m tackling Layer 2 security while at the same time, going back to the beginning to start the reviewing. On paper, I should have enough days to get everything done. But in practice, my actions say otherwise.

Lately I’ve been watching a lot of TV or doing an unusual amount of web surfing at home. Did I suddenly open up my schedule to be able to do all these things? NO. My schedule is still the same. I get home around 5pm. We’re at the dinnner table by 6pm having a nutritious meal that my wife prepared. By 7pm, I’m either watering the vegetation outside or wrestling with my son. After that either I’m giving the kids a bath or helping put them to sleep. By 8pm it’s all my time. Usually I’d be studying until about 9pm. Then exercise for about an hour. Then back to studying again. Well now, instead of the studying, I end up either watching TV or spec’ing out the next motorcycle or car I”m going to buy – which in reality, I may never ever buy. It’s that cycle of the month again where I hit that funk. I’ll shake it off and get down to business.

Anyway, hopefully next time, the tune of this post would more… studyful – if there’s ever such a word.

I have followed his journey since the beginning and it’s nice to know that he has accomplished what is arguably one of the toughest certifications in our industry earlier than he set out for. He planned to take his CCIE lab exam by the end of 2009 but because of the upcoming birth of his first child, he thought he might give the lab a crack and hope that he can get it out of the way before his child is  born. And his preparation (and a little gamble) paid off .

Again congrats on the digits and fatherhood .

I’m trying to re-commit this whole month to my studying. I’ve taken a huge step back after my second child was born and added a new commitment to stay fit by working out everyday. That took a huge hit on my studies. However, I really want to shoot for taking the exam by mid august. Yes, I am moving the test date because there is no chance I can get it done by mid July. I’m already a month and a half behind on my schedule. I’ll post my original schedule on the “BCMSN  Study Schedule” page later. I know I’m not the best in updating but stay tuned for that. Hopefully I can also create a new modified schedule.

In other news: Had a great weekend this past… weekend Went to the beach on Friday with a very close family friend. We threw some football, watch the kids play, watch the kids run away and cry in fear from the sounds of the crashing waves , walked the pier, walked around the shops, get sun burned to a crsip .  On Saturday, we planned on taking the kids to see fireworks, but my older one had a slight fever so we stayed home instead and watched Superman on DVR. Then we saw some spectacular fireworks by our neighbors. On Sunday, it was my wife’s birthday so we went to a nice Cuban restaurant where she ordered seafood paella and subsequently caught a nasty stomach bug – or so we think.

That’s all for now. What’s in your wallet?

I’ve been dedicating about an hour and a half to working out everyday. Well, really its about 45 minutes of working out but theres 10 minutes of warm up here, and another 10 minutes of stretching there, then cooling down, then cleaning up. So that takes a good chunk of my evening already. To top that, my wife also has to take some online classes to keep her teaching credentials up to date. So the time that she has to study I have to help watch the kids. She’s been very generous about allowing me to study for hours at a time in the past, but now, I have return the favor.

Nowadays I have to make up for the lost study time by studying at work during break or slow periods. Even that doesn’t add up to a lot because I have been pretty busy at work.

Today though I had a little shot of motivation when a good buddy of mine, some french dude from france , passed his BCMSN exam today. Or yesterday, depending on what time zone you’re in. Head over to Nicolas Michel’s page and offer your congratulations when you get the chance. He’s a motorcycle racer so that makes him pretty cool

====================================================

Dear Tech Support,

Last year I upgraded from Boyfriend 5.0 to Husband 1.0 and noticed a distinct slow down in overall system performance, particularly in the flower and jewelry applications, which operated flawlessly under Boyfriend 5.0.

In addition, Husband 1.0 uninstalled many other valuable programs, such as Romance 9.5 and Personal Attention 6.5, and then installed undesirable programs such as NBA 5.0, NFL 3.0 and Golf Clubs 4.1.

Conversation 8.0 no longer runs, and Housecleaning 2.6 simply crashes the system.

Please note that I have tried running Nagging 5.3 to fix these problems, but to no avail.

What can I do?

Signed,
Desperate.

DEAR DESPERATE,

First, keep in mind, Boyfriend 5.0 is an Entertainment Package, while Husband 1.0 is an operating system.

Please enter command: ithoughtyoulovedme. html and try to download Tears 6.2 and do not forget to install the Guilt 3.0 update. If that application works as designed, Husband 1.0 should then automatically run the applicationsJewelry 2.0 and Flowers 3.5.

However, remember, overuse of the above application can cause Husband 1.0 to default to Grumpy Silence 2.5, Happy Hour 7.0 or Beer 6.1. Please note that Beer 6. 1 is a very bad program that will download the Farting and Snoring Loudly Beta.

Whatever you do, DO NOT under any circumstances install Mother-In-Law 1.0 (it runs a virus in the background that will eventually seize control of all your system resources.)

In addition, please do not attempt to reinstall the Boyfriend 5.0-program.These are unsupported applications and will crash Husband 1.0.

In summary, Husband 1.0 is a great program, but it does have limited memory and cannot learn new applications quickly. You might consider buying additional software to improve memory and performance. We recommend Cooking 3.0 and Hot Lingerie 7.7.
Good Luck Babe!

Tech Support

• In the traditional 802.1D spanning tree protocol, a switch operates in Per-Vlan Spanning Tree Plus (PVST+).
• In order to use RSTP, the spanning-tree mode must changed.
• The following interface configuration command makes sure that a port operates as an RSTP edge port:

Switch(config-if)#spanning-tree portfast

• This configuration is the same PortFast feature in 802.1D that ensures the port  transitions automatically from blocking to forwarding.

• Recall that a port that is operating in full-duplex mode is automatically considered by the switch point-to-point.
• To manually override the automatic determination, use the following interface config command:

Switch(config-if)#spanning-tree link-type point-to-point

Rapid Per-Vlan Spanning Tree Protocol (RPVST+)

• As we mentioned above, PVST+ is the default STP mode on Catalyst switches.
  • This mode allows one spanning tree instance for each VLAN active on the switch.
• To use the more efficient RSTP mode, configure the switch to begin using the Rapid PVST+ (RPVST+) mode using the following global configuration command:

Switch(config)#spanning-tree mode rapid-pvst

• When this configured on a production network, any STP process is restarted.

To configure the switch back to PVST+ mode, use:

Switch(config)#spanning-tree mode pvst

To verify the STP mode, use the following command:

Switch#show spanning-tree vlan vlan-id

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

• Convergence of RSTP is a sequence of handshakes (proposal and agreement)  propagated over point-to-point links.
  • When a switch needs to make an STP decision, a handshake is made with its nearest neighbor.
  • When that is successful, the handshake sequence is moved to the next switch and the next and moves on the rest of the spanning tree towards the edge.
• During the handshake sequence the switch takes proper steps to make sure loops are prevented before moving on to the next handshake sequence.

Example

Step 1

• Assume in figure 1 that the topology on the left is a non-redundant topology.
• An administrator decides to add a link between the Root and Switch A for redundancy.
• As soon as the links come up, the ports on the link between A and the root are put in blocking.

Figure 1a: Step 1 

Proposal and Agreement

• A negotiation (handshake) sequence is started between A and the root.
  • Both bridges exchange BPDUs.
• As soon as A receives the BPDU of the root, non-edge designated ports on A are blocked.
• This process is called synchronization.
• The following diagram illustrates the handshake sequence between A and the Root bridge:

Figure 1b: Proposal/Agreement Between Switch A and Root Bridge

1. In the figure above, when the new link is created between the Root and Switch A, both ports are initially put on blocking state. 
   • They both start in designate blocking status and both sends BPDUs with the proposal bit.
   • Port p0 of the Root bridge sends a superior BPDU.
2. Port  p1 of Switch A immediately knows that it is the new root port when it receives the superior information. Switch A starts a sync to verify that all of its ports are in-sync* with this new information.
   • Switch A proceeds to block the other non-edge designate ports (p2 and p3).
3. Switch A sends a BPDU back to the Root bridge - this time with the agreement bit set.
   • Switch A then tells the root bridge that it can go ahead and put its port in forwarding status.

*A port is in sync if it meets either of these criteria:

• The port is in blocking state, which means discarding in a stable topology.
• The port is an edge port. 

Step 2

• After the links between the Root and Switch A has converged, a new negotiation sequence is started on the links between Switch A’s neighbors – B and C.
• As you can see on the diagram on Figure 2, instead of blocking on the segment above Switch A, the network now blocks below Switch A.  

Figure 2: RSTP Convergence Step 2

• At this stage, the same proposal/agreement sequence discussed above happens between Switch A and Switch B.
  • Because there is no other non-edge designated ports (assume that the nodes on bottom of Switch A are edge devices) on Switch B, it has no ports to block in order to authorize Switch A to go to the forwarding state.
  • It immediately transitions to forwarding state.
• Switch A and Switch C initiate the same sync operation.
  • This time, when Switch C receives the proposal bit from Switch A along with the superior BPDU.
  • Switch C blocks its non-edge designated port (link between C and D)
  • Switch C then sends agreement BPDU to A and tells it to start forwarding.

Step 3

• The end of convergence process ends here, where the port on D stays blocking.
• The time it takes for the whole operation to complete happens within the speed of one BPDU transmission.

Figure 3: Final Topology

In Summary…

• RSTP convergence starts of with the switches sending proposals BPDUs.
• The recipient of the proposal makes sure it is synchronized by putting all its non-edge designated ports in blocking, effectively isolating itself from the rest of the topology.
• These blocked ports also send proposal messages to their nearest neighbors and those neighbors perform the synchronization operation themselves.
• This action creates a sort of moving “wave” of switches synchronizing all the way down the tree.
• Each “wave” independently makes decisions whether to forward or not, depending on the agreement message received from the neighboring switch. This way, the transition happens rapidly as opposed to waiting for the BPDU message to propagate to the whole topology before making a decision which port will ultimately by blocking and forwarding.

Topology Change

• With 802.1D, when a topology change is detected:
  • The switch that detects the change sends a Topology Change Notification to the root.
  • The Root sends a Configuration BPDU with the TC flag bit set towards the rest of the topology.
  • The switches down the tree ages out their CAM table (MAC address table) in 15 seconds (forward-delay time) to quickly delete old information.
• In 802.1w, topology change is only detected when a non-edge port transitions to the Forwarding State.
  • A port moving to blocking does not generate a TC BPDU.
• If a topology change is detected:
  1. A switch sends out BPDUs with their TC bit set out to all non-edge designated ports.
     • This happens for the duration of the TC While timer, which is 2 times the Hello interval.
  2. MAC addresses associated with the non-edge designated ports are flushed from the CAM table, thereby forcing the bridges to re-learn and re-populate its CAM database.
     • The port that received the TC message does not have to clear its learned MAC address.
  3. This process happens for every switch that receives the TC message. Each receiving switch starts the TC While timer and must also send out TC messages out their non-edge designated ports.
  4. While the TC While timer is active, the switches send BPDUs even on the root port. 
• This process floods the TCN to the entire much more quickly because the initiator immediately sends the TC information to the network instead of waiting for the Root bridge to take care of the notification. 

802.1D Compatibility

• In the event a designated port sends a proposal message and does not receive an agreement reply, it reverts to using the 802.1D rules of convergence – it mus wait the forward delay time before forwarding.
• 802.1D cannot understand 802.1w.
• If an RSTP switch receives an STP BPDU, the RSTP switch changes its mode to 802.1D on the port where it receives the STP BPDU. If the STP switch is removed from the topology, an administrator must re-configure the port manually back to RSTP – that is because it doesn’t know whether the STP switch is still present or not.

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

• Rapid Spanning Tree Protocol or RSTP or IEEE 802.1w was introduced by the Institue of Electrical and Electornics Engineers in 1998 .
  • The original STP 802.1D was introduced in 1985.
  • 802.1D – 2004 incorporates RSTP and obsoletes the original STP.
• RSTP selects one switch as the root port of an active spanning tree-connected topology and assigns port roles to individual ports on the switch, depending on whether the ports are part of the active topology.
• Adds port roles: Alternate and Backup roles.
• New port state: Discarding in addition to Learning and Forwarding

* UplinkFast, BackboneFast, and Portfast are Cisco proprietary enhancements to 802.1D

• Terminologies and parameters found in 802.1D remains primarily the same for RSTP.
• 802.1w is capable of reverting to 802.1D for interoperation with legacy bridges on a per-port basis.
  • Downgrading to 802.1D cancels the benefits of 802.1w for that paritcular segment.
• Per VLAN version of RSTP is called RPVST+ equivalent to 802.1D version PVST+
• With RSTP, if a swtich, switch port, or LAN experiences some kind of failure, rapid connectivity is possible.
  • A new root port and designated port of the connecting bridge transitions to forwarding through an explicit handshake protocol between them.
  • RSTP allows switch port configuration so that the ports transition to forwarding directly when the switch re-initializes.

RSTP Port States

• There are only 3 RSTP port states:
  • Discarding - This is a combination of  801.2D blocking, listening, and disabled states
  • Learning
  • Forwarding
• Port states are defined according to what the port does with incoming frames  - if incoming frames are dropped or ignored, outgoing frames are as well.
• RSTP decouples the role of a port from the state of a port.
  • 802.1D STP mixes the state of a port, whether blocking or forwarding traffic, with the role it plays in the active topology.
• RSTP considers there to be no difference between a port in blocking and listening states (ie both discard frames and no MAC addresses are learned).

RSTP Port Roles

• Root Port
  • The closest port (measured in “path cost”) to the root bridge.
  • The STA elects a single root bridge for the whole bridged network, per-VLAN, or STP instance.
  • The root bridge sends BPDUs that are better than the ones that any other bridge sends.
  • The root bridge is the only bridge that does not have a root port.
• Designated Port
  • For bridges in the same segment, the designated port is the port on the bridge, in that LAN segment, that is sending the best BPDU.
• Alternate Port
  • Becomes the root port if the active root port fails.
  • Blocked from receiving root BPDUs from another switch. An alternate port has to receive BPDUs from a different bridge than itself. See figure below.
• Backup Port
  • Becomes the designated port if the active designated port fails.
  • Blocked from receiving root BPDUs from the designated port for a shared LAN segment from the same bridge on which the port is located. See figure below.
• Disabled Port
  • Has no role within the operation of spanning tree.

Figure 1: Alternate Port vs Backup Port

 BDPU Format: 802.1D vs. 802.1w

• Recall that 802.1D BPDU (1byte) only used 2 bits in the Type field (either the most significant bit is set or the least significant bit)
• RSTP uses all 8 bits.

Figure 2: 802.1D vs 802.1w Frame Comparison

• With 802.1D, a non-root bridge generates a BPDU only when it receives one on its root port.
  • Here, there is more frequent relaying of BPDUs compared to the self-generated ones.
• With 802.1w, even if a bridge does not recieve a BPDU from a root it still send a BPDU every 2 seconds – this is self-generated.
  • This constant transmission of BPDUs act as keep-alive mechanism.
  • If three BDPUs in a row (three consecutive hello times) are not received, the bridge will assume that connectivity is lost.
  • This allows the aging of protocol information (max age) to occur much faster thereby detecting failure much faster.
• A mechanism similar to backbone fast allows RSTP to accept inferior BPDUs.

Rapid Transition to Forwarding State

• The major selling point of the 802.1w is its rapid transition.
• With 802.1D, even after the designated port has been established, it still waits the forwarding timers before the port transitions to forwarding. That’s 15 sec listening and 15 sec learning.
• RSTP actively confirms that a port can safely tranisition to the forwarding state without having to rely on any timer configuration.
• The type of port is used by RSTP to base its forwarding decision when a switch detects a failure:
  • Edge Ports
    • These are ports directly connected to end stations and are typically unable to form bridging loops.
    • Directly transitions to forwarding state bypassing the listening and learning stages.
    • They are equivalent to PortFast feature.
    • However, unlike PortFast, an edge port that receives a BPDU immediately loses edge port status and becomes a normal spanning tree port. 
  • Link Type (point-to-point)
    • RSTP can only achieve rapid transition to the forwarding state on edge ports and point-to-point links.
    • Derived from the duplex mode of a port:
      • A port in full-duplex is point-to-point.
      • A port in half-duplex is assumed to be on shared medium, such as a hub.
    • Switched networks today operate mostly in full-duplex and thus are treated as point-to-point links by RSTP. This makes then candidates for rapid transition to the forwarding state.

References:

1. Understanding Rapid Spanning Tree Protocol – Cisco Systems, Inc.

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

It also helped that I didn’t exercise/work out as consistently as I should’ve been. My son needed constant attention so I couldn’t really devote a un-interrupted work out time. So this week I’m restarting week 1 of my P90X program. So I didn’t get to work out much but I did watch as much basketball as there was on. For the unfamiliar, it was the championship series between Los Angeles Lakers and Orlando Magic. Of course everyone knew it was the Lakers’ championship to take. The games were merely formalities.   So congratulations to the Lakers and the city of L.A. for a much awaited championship banner. Seven years without a championship is just too long. At least for L.A.

Anyway, this week I plan to continue my studies and labs. I want to finish up on Spanning-tree (I still have RSTP and MST to go over) then move on to multilayer switching next week.

• When configuring Layer 2 channels, use the channel-group interface configuration command on the interface port or ports.
  • This command creates the port-channel logical interface.
• You cannot put a Layer 2 interface into a manually created port-channel interface.

Configure PAgP EtherChannel

When configuring EtherChannel use the following general template:

Switch(config)# interface type mod/num
Switch(config-if)# channel-protocol pagp
Switch(config-if)# channel-group number mode {on | [auto | desirable] [non-silent]}

• Lab testing showed that if ommited, verification defaults to PAgP negotiation protocol.
• Older switch models, such as Catalyst 2950, offer only PAgP option therefore the channel-protocol command is not even available.
• Channel group number can be from 1 to 64.
• Each interface in the EtherChannel bundle must be assigned to the same channel group number.
• PAgP defaults to silent mode with the Auto and Desirable mode, by default. It means it will not transmit PAgP packets.

Figure 1: This is the example topology used for this practice lab configuration

SW4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW4(config)#int fa0/1
SW4(config-if)#switchport
SW4(config-if)#channel-group 1 mode desirable
Creating a port-channel interface Port-channel 1

 

!

SW4(config-if)#int fa0/2
SW4(config-if)#switchport
SW4(config-if)#channel-group 1 mode desirable

!

SW4(config-if)#int fa0/3
SW4(config-if)#switchport
SW4(config-if)#channel-group 1 mode desirable

!

SW4(config-if)#int fa0/4
SW4(config-if)#switchport
SW4(config-if)#channel-group 1 mode desirable

The configuration of SW5 follows the same basic steps as with SW4. Only this time we’re using int range to configure a range of interfaces for EtherChannel with one swing.

SW5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW5(config)#int range fa0/1 – 4
SW5(config-if-range)#switchport
SW5(config-if-range)#channel-group 1 mode desirable
Creating a port-channel interface Port-channel 1
SW5(config-if-range)#

Verification

• SUmeans port channel 1 is a Layer 2 EtherChannel and is in use.
• The P flags on the ports indicate that they are active in the channel.
• Although assigned to PO1 channel group, port Fa 0/48 has a D flag because the physical connection on the other end does not exist.

Configure LACP EtherChannel

The following template configures LACP, inlcuding some parameters:

Switch(config)# lacp system-priority priority
Switch(config)# interface type mod/num
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group number mode {on | passive | active}
Switch(config-if)# lacp port-priority priority 

• The system priority defaults to 32, 768.
  • Ranges from 1 to 65, 535.
  • A lower system priority allows a switch to become the main decision maker about the EtherChannel.
  • If left to the default value, the lower MAC address wins.
• The lacp port-priority command allows you to configure an interface to be active port or on standby.
  • You can configure more interfaces than the maximum eight the system allows to be active.
  • By configuring ports with low port-priority, you ensure that they are active on the channel. With a higher priority they are reserved as standby.
  • For example, you may configure 4 ports with a lower priority to make it active in the channel. Then you may configure another 4 with higher priority value than the fist four - which puts them on standby. If one of the lower priority ports goes down, one of the standby ports become active.
  • The default priority is 32, 768. If all ports are left in default value, the lower port numbers (in interface number order) are used to select the active ports.
  • LACP port priority value can range from 1 to 65, 535.

The following is the SW4 configuration example (refer to the same topology diagram on figure 1):

SW4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW4(config)#lacp system-priority 150
SW4(config)#int rang fa0/1 – 4
SW4(config-if-range)#channel-protocol lacp
SW4(config-if-range)#channel-group 1 mode active
Creating a port-channel interface Port-channel 1

If a port priority were to be configured, it would look something like this:

SW4(config-if-range)#lacp port-priority 150

Similarly, configure SW5 as follows:

SW5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW5(config)#int range fa0/1 – 4
SW5(config-if-range)#channel-protocol lacp
SW5(config-if-range)#channel-group 1 mode active
Creating a port-channel interface Port-channel 1

Verify

• All ports Fa0/1 – 4 are active in the channel group
• The negotiation protocol used is LACP. 

Configure Layer 3 EtherChannel

• When configuring Layer 3 EtherChannels, you must manually create the por-channel logical interface first, using the interface port-channel global config command.
• After that , you can put the logical interface intot the channel group by using the channel-group interface configuration command.
• Use the no switchport interface command to put the interface in Layer 3 mode. 
• If you decide to move an IP address from a physical interface to an EtherChannel, delete the address from the physical interface first, then configura it on the port-channel.

SW5 config t
SW5(config)# interface port-channel 2
SW5(config-if)# no switchport
SW5(config-if)# ip address 10.10.10.1 255.255.255.0
SW5(config-if)# no shut

!

SW5(config)#int ra fa0/1 – 4
SW5(config-if)#no switchport
SW5(config-if)#channel-prot lacp
SW5(config-if)#channel-group 2 mode active

References:

1. Configuring EtherChannels – Catalyst 3550 Software Configuration Guide 12.1(13)EA1

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

• The Cisco EtherChannel technology is Cisco’s method of aggregating or bundling parallel links to scale bandwidth.
  • Port Trunking or Link Aggregation is the standard term for this technology. It is not to be confused with Cisco’s use of the word “trunking” which refers to the network link used to carry multiple VLANs between switches.
• It is standards-based built upon the IEEE 802.3-compliant Ethernet mechanisms for full-duplex autonegotiation and autosensing.
• It allows you to bundle up to eight individual links to form one logical link:
  • 8 Fast Ethernet (full duplex) = 1600 Mbps
  • 8 Gigabit Ethernet (full duplex) = 16 Gbps
  • 8 10-Gigabit Ethernet (full duplex) = 160 Gbps
• Whenever parallel links between switches are present, the possibility of bridging loops increase. However, with EtherChannel, this problem is avoided by bundling these parallel links into a single logical link.
• Although an EtherChannel link is seen as a single logical link, the speed of the link is not always the sum of all the physical links’ speed.
  • For example, if we have 8 FastEthernet physcial links bundled together (1600 Mbps at full-duplex), the logical link doesn’t operate at that speed.
  • Although it is capable of carrying a total throughput of 1600 Mbps, traffic is not equally distributed to all the links.
  • Instead, traffic is distributed through each individual FastEthernet links within the EtherChannel. And each link operates at its inherent speed, that is 200 Mbps at full-duplex.
  • If one link within that bundle is used more than the other, the link will carry more load than the other links.
  • There is a way to balance the load more evenly among all other links (discussed at a later post).
• When bundling ports with EtherChannel:
  • All bundled ports must generally belong to the same VLAN.
  • If used as a trunk, bundled ports must be in trunking mode, have the same native VLAN, and pass the same set of VLANs.
  • Each port should have the same speed and duplex settings.
  • And each bundled port must be configured with identical spanning-tree settings.

EtherChannel Negotiation Protocols

I. Port Aggregation Protocol (PAgP)

• Cisco-proprietary.
• PAgP manages the automatic EtherChannel configuration and negotiation between switches.
  • Checks to make sure configuration is consistent on both ends of the link.
  • Manages link failures and addition of links.
  • Helps in network reliability by preventing STP loops or packet loss due to misconfiguration.
• EtherChannel formed only on ports that are configured for either identical static VLANs or trunking.
• If one of the bundled ports’ parameters are changed (ie VLAN, speed, duplex setting) PAgP also dynamically changes the parameters on the EtherChannel.

PAgP Modes

Options

The following options are available for the Auto and Desirable modes:

• Silent
  • Default option/keyword used for Auto or Desirable mode.
  • Allows ports to be added to an EtherChannel even if the other end of the link is silent and never transmits PAgP packets
  • Indicates that the switch does not expect PAgP frames from the partner device to prevent the switch from reporting the link to the STP as down.
  • This could be used to form an EtherChannel with a device such as a file server or network analyzer that does not participate in PAgP.
• Non-silent
  • Used with Auto or Desirable mode to indicate that the switch expects PAgP frames from the switch on the other end of the link.
  • This requires each port to receive PAgP packets before they can be added to the EtherChannel.
  • If a unidirectional link is detected (due to absence of PAgP packets received) the port status is reported to STP as down.

Mode Compatibilities

• On mode is compatible only with another port in the On mode.
• Auto mode is compatible only with Desirable mode.
• Desirable mode is compatible with Auto or Desirable.

II. Link Aggregation Control Protocol

• This is an industry standard based on IEEE 802.3ad (also known as IEEE 802.3 Clause 43, “Link Aggregation”)
• Just like PAgP, switches exchange LACP packets to learn parameters.
• On ports configured to use LACP, the protocol tries to configure the maximum number of compatibel ports in an EtherChannel, up to the maximum allowed by the hardware (eigth ports).
• There are different parameters that are used in LACP:
  • LACP System Priority
    • The lowest system priority is the one that makes decisions about what ports are actively participating in the EtherChannel at a given time.
    • The 2-byte system priority combined with the 6-byte switch MAC address form the system ID, which is used during negotiation with other switches.
    • This can be manually configured or automatically assigned by the swtich.
  • LACP Port Priority
    • LACP uses the port priority to decide which prots should be put in standy mode when there is a hardware limitation that prevents all compatible ports from aggregating.
      • For example, a set of 16 links defined for EtherChannel. Because only 8 are able to be bundled, the switch selects 8 ports with the lowest priorities and set as active. The other 8 goes on standby.
    • The 2-byte port priority + 2-byte port number makes up the port identifier.
    • The value can be determined by the switch or through manual configuration
  • LACP Administrative Key
    • Defines the ability of a port to aggregated with other ports, determined by:
      • Port’s physical characteristics such as: data rate, duplex settings, point-to-point or shared medium.
      • Manually configured restrictions.
    • LACP autmatically configures an administrative key value equal to teh channel group ID number on each port configured to use LACP.
    • It can also be manually configured.

LACP Modes

Resources:

1. Cisco EtherChannel Technology – Technology Whitepaper – Cisco Systems, Inc.
2. Understanding PAgP EtherChannel Configuration – Catalyst 6500 Configuration Guide 12.1E
3. Understanding LACP EtherChannel Configuration – Catalyst 6500 Configuration Guide 12.1E
4. IEEE 802.3 Standard - Click link –> Select User Type —> Accept/Begin Download. Go to “Clause 43, Link Aggregation”

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

I’m not stopping though. I just need to make sure that I continue to find that balance. Making sure that I continue spending that extra hour or two after work towards family time. In previous times, that was usually spent on reading, blogging, or labbing.

With my mom’s illness, I needed to make sure that I make that hour-long trip 3 times a week to spend 2-3 hours with my mom in the hospital. This has really taken a lot of time and patience on my part, but it is something that I gotta do. Seeing my mom in her present condition takes a lot of strength out of me and sucks out some of my mojo (lack of a better term). But this is also a time that tells me that I have to dig deeper inside and learn to fight through adversity. At least for my mom, if not for myself.

Lastly, I have taken on another challenge. Some of you who follow me on twitter know that I have been doing P90X. It’s an exercise program designed for coolness. So yeah, I’m trying to gain back coolness I sort of used to have in my earlier days. I call them my glory days – when I used to have a four-pack abs; or used to be able to almost dunk a basketball on an 8′ rim in my neighbors driveway; or pop a wheelie on my bmx bike for a cool 2 1/2 seconds. Coolness… here I come.

Next few  posts will be blog notes relating to EtherChannel technology.

I. Root Guard

• The Root Guard feature prevents surrounding switches from announcing themselves as Root Bridges.
  • When configured on a port, this feature forces that port to remain as designated port and prevent it from becoming a root port.
• Imagine a new switch that is introduced into the network with a bridge priority lower than the current root bridge. In a normal STP operation, this new bridge can become the new Root Bridge and disrupt your carefully designed network.
• The way this works is:
  • A switch learns the current Root Bridge’s Bridge ID.
  • If another switch announces a superior (lower) BPDU on a port where root guard is enabled, the local switch will not allow the new switch to become the root.
  • The port that receives the new superior BPDU is then transitioned to a state called root-inconsistent STP state (effectively the same as listening state).
  • No data can be sent or received in this state.
• The recommended design is to enable Root Guard on all access ports so that a root bridge is not established through this port.

Configure Root Guard

• Root Guard can only be enabled on a per-port basis.
  • It affects the entire port. Therefore it applies to all VLANs on that port.
• It is disabled by default.
• Use the following interface configuration command:

Switch(config-if)# spanning-tree guard root

Verification

To verify configuration, use the show running config command on the interface:

Switch#show running-config int Fa0/1
Building Configuration…
!
!
interface FastEthernet0/1
switchport mode access
spanning-tree guard root
end
!

The following command displays switch ports that are in root-inconsistent state.

• Use it to find out if any ports are disabled.

Switch# show spanning-tree inconsistentports

II. BPDU Guard

• BPDU Guard protects ports that have PortFast enabled.
• Theoretically, a port that has PortFast enabled is not expected to be used for another switch or any devices that produces BPDUs. If by mistake or malicious act, a switch is connected to a PortFast enabled port, a potential bridging loop can occur.
  • A BPDU received on this port could potentially advertise a new Root Bridge.
  • BPDU Guard puts the port in err-disable state if a PortFast enabled port receives a BPDU.
• An err-disabled port will have to either be manually enabled or automatically recovered through the err-disable timeout operation.

Configuring BPDU Guard

• BPDU Guard is disabled on all switch ports by default.
  • However, all ports that have PortFast enabled automatically enables BPDU guard.
• It can be enabled:
  1.  Globally so that one command enables all switch ports or;
  2.  On a per-interface basis.

Switch(config)#spanning-tree portfast bpduguard default

Switch(config-if)#[no] spanning-tree bpduguard enable

Verify Configuration

To verify that BPDU Guard is configured:

Switch#show spanning-tree summary total
Root bridge for:Bridge group 10, VLAN1, VLAN6, VLAN1000.
Extended system ID is enabled.
PortFast BPDU Guard is enabled
EtherChannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short

III. BPDU Filtering

• BPDU filtering prevents Catalyst switches from sending BPDUs on PortFast-enabled interfaces 
• BPDU Filtering effectively disables STP on the port it is configured on.
• Disabled on all switchports by default.
• According to text, BPDU filtering is not a recommended configuration.

Configuration

• Can be configured globally or per-interface.
  • If configured on an interface, the switch does not send BPDUs and drops all BPDUs it receives.
  • If configured globally, the switch changes the interface back to normal STP operation if the port receives BPDUs on the respective interface.
• To enable globally:

Switch(config)#spanning-tree portfast bpdufilter default

• To enable/disable on specific ports:

Switch(config-if)#spanning-tree bpdufilter {enable | disable}

• To verify:

Switch# show spanning-tree summary totals

Preventing Forwarding Loops and Blackholes

IV. Loop Guard

• With LoopGuard, if a switch stops receiving BPDUs on a non-designated port, the switch places the port into the STP loop-inconsistent blocking state (instead of transitioning through listening, learning and forwarding states.
• A port stops receiving BPDUs in cases like unidirectional link failure.
• When enabled, Loop Guard keeps track of the BPDU activity on non-designated ports.
  • While BPDUs are received, the port is allowed to behave normally.
  • When BPDUs go missing, loop guard moves the port into the loop-inconsistent state.
  • When BPDUs are received on the port again, loop guard allows the port to move through the normal STP states and become active.
• By default, loop guard is disabled on all switch ports.

Configuring Loop Guard

• Loop guard can be enabled on a global or per-interface basis:

Switch(config)#spanning-tree loopguard default

Switch(config-if)#[no] spanning-tree guard loop

• Even when configured on a switchport, it only blocks on a per-VLAN basis instead of blocking the whole port.
• Follow these guidelines when using loop guard:
  • Do not enable loop guard on PortFast-enabled or dynamic VLAN ports.
  • Do not enable PortFast on loop guard-enabled ports.
  • Do not enable loop guard if root guard is enabled.
  • Do not enable loop guard on ports that are connected to a shared link.

V. Uni-Directional Link Detection (UDLD)

• Cisco-proprietary UDLD STP feature helps prevent a situation where a uni-directional traffic causes loops to occur.
• A  unidirectional link is a condition on switch ports where a link remains in the up state but the interface is not passing traffic.
  • A typical occurrence of this happens on GBIC interfaces or Small Form-Factor Pluggable (SFP) modules where.
  • When there is uni-directional link, one end of the link (the one in Blocking state) will not receive BPDUs. When BPDUs are not received on the blocked ports, they will transition through the STP states and start forwarding – when they shouldn’t. This can eventually cause instability on the network or bridging loops to occur.
•  UDLD interactively monitors a port to see if the link is truly bidirectional.
• The goal for UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state.
  • In order to accomplish this, the target time must be less than the Max age timer plus two intervals of the Forward Delay timer
    •  20 + 15 + 15 = 50 seconds.
  • UDLD can detect a unidirectional link after about three times the UDLD message interval
    • 15 x 3 = 45 seconds
• How it works:
  • The switch will send a special Layer 2 UDLD frame identifying its swtich port at regular interval (15 seconds).
  • UDLD expects the other end of the link to echo back those frames, with the far-end switch’s port identification added with it. 
    • The echo must be received within 15 seconds. For 3550s, the default is 7 seconds.
    • If not, the switch determines the link to be unidirectional and err-disables the port.
• UDLD requires both ends of the link to be configured for UDLD.

UDLD modes:

• Normal Mode – when a unidirectional link is detected, the port is allowed to continue operation. UDLD merely marks the port state as undetermined and sends a syslog message.
• Aggressive Mode – The switch takes action to re-establish the link. UDLD sends a message out once a second for 8 seconds. If there is no response (echo) the port is transitioned to err-disabled.

Configuring UDLD

• UDLD is disabled by default.
• It can be configured globally or per-interface.

To enable globally:

• This method enables UDLD on fiber-optic ports only. Enable UDLD on interface configuration if configuring on other port types.

Switch(config)#udld {enable | aggressive} | message time seconds}

• enable – use for normal mode
• aggressive – for aggressive mode
• message time – set the message interval between 7 to 90 seconds.

To enable on the interface:

Switch(config-if)#udld port [aggressive]

References:

1. Spanning-Tree Root Guard Enhancement
2. STP Portfast BPDU Guard Enhancement
3. Understanding How Portfast BPDU Guard Works
4. Understanding How PortFast BPDU Filtering Works
5. Understanding How Loop Guard Works
6. Understanding and Configuring the Unidirectional Link Detection Protocol
7. Configuring UDLD – Catalyst 2960 Software Config Guide 12.2(46)SE

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

I. PortFast

• PortFast is an STP feature that allows an access port to immediately transition from blocking to forwarding – bypassing the listening and learning states.
• The purpose of PortFast is to minimize the time that access ports wait for STP to converge.
• The idea is that access port almost always have end-workstation plugged into them, therefore bridging loop is not a concern. And as such, there is no need for the protection of the whole STP cycle (listening and learning states).
• Even with PortFast enabled on a port, Spanning-tree detection is still working. If a loop is detected on that port, the port will move into Blocking state.
• On a PortFast enabled port, TCN BPDUs are not sent if it goes up and down.

Configuring PortFast

• PortFast is disabled by default.
• There are two methods that PortFast can be enabled:
  1. Globally – use this if configuring on a switch in the Building Access submodule, where all ports connect only to workstations and servers.
  2. Per interface – use for individual interface.
     • Remember to explicitly disable PortFast on uplink ports that connect to distribution layer switches.

Switch(config)#spanning-tree portfast default

Switch(config-if)# [no] spanning-tree portfast

• A special macro command can be used to simultaneously enable PortFast, set the port to access (non-trunking) mode, and disable PAgP (prevent EtherChannel):

Switch(config)# interface type mod/num
Switch(config-if)# switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled

Verifying PortFast Configuration

Switch# show spanning-tree interface fastethernet 0/1 portfast
VLAN0010      enabled
Switch#

II. UplinkFast

• UplinkFast is an STP feature that allows immediate convergence of a backup uplink when a redundant uplink fails.
  • Consider an access-layer switch with redundant connection to two distribution-layer switches. When one uplink goes down, the other uplink immediately goes off blocking state and starts forwarding.
  • The switchover bypasses the listening and learning states and converges within 5 seconds.
• UplinkFast is enabled for the entire switch and all VLANs.
• It is not allowed on the Root Bridge switch – because the feature works to keep track of possible paths to the root bridge itself.
• UplinkFast makes sure that the switch on with it is turned on does not become the Root Bridge. It also makes sure that the switch doesn’t become a transit switch to get to the Root Bridge.
  • The goal is to keep UplinkFast limited to leaf-node switches that are farthest from the Root.
• It raises the bridge priority to 49,152 – making it unlikely to be elected root bridge.
• All the switch ports cost is incremented by 3,000 to make it less likely to be used as paths towards the root for any downstream switches.

Configuring UplinkFast

• As mentioned earlier, UplinkFast affects all VLANs on the switches.
  • There is no support for configuring UplinkFast on a per-VLAN basis.
• To configure, enter the following global configuration command:

Switch(config)#spanning-tree uplinkfast [max-update-rate packets-per-second]

• The packets-per-second value is the number of multicast packets transmitted per second
  • The default is 150 pps.

Verifying UplinkFast Configuration

Switch# show spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 150 packets/sec.
UplinkFast statistics
———————–
Number of transitions via uplinkFast (all VLANs)            : 2
Number of proxy multicast addresses transmitted (all VLANs) : 52
Name                Interface List
——————–   ————————————
VLAN0001            Gi0/1(fwd)
VLAN0010            Gi0/1(fwd)
VLAN0100            Gi0/1(fwd)

III. BackboneFast

• BackboneFast reduces the default convergence time in situations where the root port is lost by an indirect link failure and the backup link leads through a different switch.
  • Indirect link failure occurs when a link that is not directly connected to a switch fails. Can you say, duh?
  • It does not support failure by a direct link.
• The convergence is reduced from 50 seconds to 30 seconds.
  • It doesn’t eliminate the Forward Delay time.
• A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port.
  • A switch considers the BPDU an inferior BPDU when a switch receives the BPDU from a designated bridge that identifies the root bridge and the designated bridge as the same switch.
    • In other words, the designated bridge thinks of itself as the new root, sending the inferior BPDU, because it lost its connection to the root bridge, sending the inferior BPDU.
• The receiver of the inferior BPDU waits the Max Age time before it will respond to the BPDU.
• While waiting for the Max Age timer to expire, BackboneFast begins to determine whether other alternative paths to the Root Bridge exists according to the following port types that received the inferior BPDU:
  • If the inferior BPDU arrives on a port in the Blocking state, the switch considers the Root Port and all other blocked ports to be alternate paths to the Root Bridge.
  • If it arrives on the Root Port, all blocked ports are considered to be alternate paths to the Root.
  • If arrived on Root Port while no other ports are on blocking state, the switch assumes that it has lost connectivity with the Root Bridge and assumes, then, that it has become the Root Bridge. Backbone Fast allows the switch to do so before the Max Age timer expires.
• If alternate paths are available on switches that receive inferior BPDUs, BackboneFast will send Root Link Queries (RLQ) out these alternate paths to see if upstream switches have connection to the Root Bridge.
  • The objective of the RLQ BPDU is to find out whether the current root switch is still up.
  • If the Root Bridge or a switch that has lost connection to the Root Bridge receives an RLQ Request, it will respond with an RLQ Reply. If an RLQ Reply is not heard, the RLQ Request propagates towards the Root Bridge until an RLQ Reply can be generated.
    • On the local switch, if an RLQ Reply is received on its current Root Port, then the path to the Root Bridge is intact and stable.
    • If received on a non-root port, an alternative Root Path must be chosen and the Max Age timer is immediately expired so that a new Root Port can be found.

Configuring BackboneFast

• For BackboneFast to function correctly, it needs to be enabled on all switches in the network.
• Use the following global configuration command:

Switch(config)#spanning-tree backbonefast

Verifying configuration

Switch#show spanning-tree backbonefast
BackboneFast is enabled

References:

1. Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays – Cisco Systems
2. Understanding and Configuring the Cisco UplinkFast Feature – Cisco Systems
3. Understanding and Configuring Backbone Fast on Catalyst Switches- Cisco Systems

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition)by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

I’ve been following her blog for quite some time. We’ve actually encouraged each other on towards our pursuits along the way.  What better way for her to encourage me than to see that she has passed and moving on to her last hurdle before gettign the CCNP  – that is, BSCI. Wishing her luck!!!

For now, I’m sticking with my current ways. I will continue to blog my notes until I can no longer sustain that system without seriously hampering my progress.

The single most defining feature that made me choose Tweetdeck is its ability to group different categories in separate columns.

For example, the first few columns group the standard default categories  (i.e. All Friends I’m following, Replies from friends, and Direct Messages). Then I can break down several categores in subsequent columns grouped under a certain keyword search or interest “groups”. This way it allows me to track different going ons in the Twitter world. It’s not as pretty as Twhirl, but it does the job for me the way I want it. It keeps me busy with unproductive work.

When I want to look productive, I use Spreadtweet2003:

Common Spanning Tree (IEEE version)

• The IEEE 802.1Q maintains a single instance of STP for all VLANs allowed in the trunk.
  • This instance is referred to as the Common Spanning Tree (CST).
• CST usually describes 802.1Q implementation on non-Cisco switches
• All CST BPDUs are transmitted over trunk links using the native VLAN with untagged frames.

Per-VLAN Spanning Tree (PVST)

• Cisco-proprietary version of STP.
• Operates a separate instance of STP per individual VLAN.
• Requires use of Cisco Inter-Switch Link (ISL) trunking encapsulation.
• BPDUs are never exchanged between PVST and CST.

Per-VLAN Spaning Tree Plus (PVST+)

• Also Cisco-proprietary.
• Interoperates with switches running PVST and CST, as well as other switches also running PVST+
  • Communicates with PVST by using ISL trunks.
  • To communicate with CST:
    • PVST+ exchanges BPDUs with CST as untagged frames over the native VLAN.
    • BPDUs from other instances of STP (other VLANs) are propagated across the CST portions of the network by tunnelling – using unique multicast address so that the CST switches forward them on to the downstream neighbors without interpreting them first.

Configuring Basic Parameters of PVST+

• By default, STP is enabled for all active VLANs and on all ports of a switch.
• If it was somehow disabled, ues the following global configuration command to enable it:

SW01(config)# spanning-tree vlan vlan-id

• It can also be re-enabled on for specific VLAN on a specific port by using the following interface configuration command:

SW01(config-if)# spanning-tree vlan vlan-id

Configuring the Root Bridge

There are 2 ways to configure a root bridge:

• Manually setting the bridge priority:
  • This is the preferred method.
  • The recommended priority value for primary is 4096 – assuming default values for everything else.
  • The recommended priority value for secondary is 8192 – assuming default values for everthing else.
    • More than one switch can act as backup root bridge.

SW01(config)# spanning-tree vlan vlan-id|vlan-list priority value

• Using a macro command:
  • Primary Root
  • When all else have default settings, using the macro sets the primary root priority value to 8192.
    • If the current root is configured with a value other than the default, the macro uses a value that is a step lower than the defaul value.
    • For example,  if current root switch is 4096, the root macro sets the priority at 4095.
  • On Catalyst switches that have the extended system-id enabled (bridge priority + VLAN ID) and all else are default, the primary root is assigned a value of 24,576.
    • If a current root has a priority value of less than 24,576, the switch sets a value of the priority to be 4096 less than the current priority value.
  • Secondary Root (Backup Root Bridge)
    • For Catalyst 3550 switches without the extended system ID support (software before Release 12.1(8)EA1), the switch priority is changed to 16384.
    • A Catalyst 3550 switch that supports the extended system ID as the secondary root, the STP switch priority is modified from the default value (32768) to 28672.
    • Can be configured on more than one switch – backup root bridge.

SW01(config)#spanning-tree vlan vlan-id root {primary | secondary}

Configuring Port Cost 

• To make STP choose a certain port over another for forwarding frames, assign a lower cost value to the niterface to make spanning tree select that first.
• Conversely, assign higher costs to interfaces that are less preferrable.
• The range of possible values:
  • 1 to 200,000,000 for interfaces that are configured as access ports
  • 1 to 65,535 for VLAN cost for an interface that is a trunk port.
• STP uses the port cost value when the interface is an access port.

spanning-tree cost port-cost

• STP uses VLAN port cost values when the interface is a trunk port.

spanning-tree vlan vlan-id cost port-cost

STP Timers

• Hello Time
  • 2 seconds
  • Time interval between configuration BPDUs sent by the Root Bridge.
• Forward Delay
  • 15 seconds
  • Time interval that a switch port spends in each of the Listening and Learning states.
• Max (maximum) age
  • 20 seconds
  • The length of time before a switch descards its stored BPDU.

Manually Configure STP Timers

SW01(config)#spanning -tree [vlan vlan-id] hello-time seconds
SW01(config)#spanning -tree [vlan vlan-id] forward-time seconds
SW01(config)#spanning -tree [vlan vlan-id] max-age seconds

• The timers can be change for a singe instance (VLAN) of STP on the switch by using the vlan vlan-id paramaters.
• By omiting the vlan keyword, the timer values are configured for all instances (all VLANs) of STP on the switch.
• The hello-time keyword can have a value of 1 to 10 seconds. Default is 2 secs.
• The forward-time keyword can have a value of 4 to 30 seconds. Default is 15 secs.
• The max-age keyword can have a value of 6 to 40 seconds. Default is 20 secs.

References:

1. Configuring Basic STP Features – Catalyst 3550 Configuration Guide 12.1(8)EA1
2. Configuring Root Switch – Catalyst 3550 Configuration Guide 12.1(8)EA1
3. Configuring Secondary Root Switch – Catalyst 3550 Config Guide 12.1(8)EA1

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition) by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

• A bridge starts out without knowledge of devices in the network. It listens for frames that come into each of its ports.
  • A frame that arrives on individual ports carries the source MAC address of the device that sent it. The bridge then assumes that the device that sent this frame is located behind this port.
  • All other ports will be listening to other frames and the bridge builds a table that matches the MAC addresses with port numbers that these frames came in from.
  • The bridge constantly updates its MAC address table as new frames are received or as frames change locations frmo one port to another.
• The bridge forwards frames by comparing the destination address with the information in the bridge table and forwarding the frame out the port that the bridge table has recorded.
  • Frames with a broadcast destination address is forwarded out all available ports, except the port the intially received the frame.
    • This is process of forwarding to all ports is called flooding. 
    • A bridge does not segent broadcast domains; only collision domains.
    • Frames whose destination address is unknown (unknown unicast) is treated as broadcast frame, therefore it’s flooded out all ports. When a reply to the unknown frame is heard back, it is learned by the bridge and added to the MAC address table.
• Frames that are forwarded across the bridge is not modified by that bridge. This is the property that makes it transparent. 

Spanning Tree Protocol (802.1D)

• Identifies and prevents bridging loops.
• Enables switches to be aware fo each other and allow redundantly connected switches to negotiate a loop-free path through the network.
• Discovers loops before they become available for use. Redundant links are effectively shut down to prevent the loops from forming.
• STP  is communicated among all connected swithces on a network.

Bridge Identifier

• Each switch is assigned a unique identifier called a bridge id.
• A bridge id is made up of:
  • Priority value (2-bytes/16-bits)
    • Tthis is the priority or weight of a switch in relation to all other swiches.
    • It can have a value of 0 through 65,535.
    • The default value is 32,768 (or 0×8000 in hex/1000 0000 0000 0000 in binary).
  • MAC address (6-bytes)
    • The MAC adddress used by a switch can come from the Supervisor module, the backplane, or a pool of 1,024 addresses that are assigned to every supervisor or backplane, depending on the switch model.
    • This address is hard-coded and unique, and cannot be changed be the user.

Bridge Protocol Data Units (BPDUs)

• BPDUs are sent by switches running STP to relay LAN topology information to other switches.
• Initially, switches are not aware of other switches in the network, therefore frames are sent with a destination addrss of the the well-known STP mulitcast address 01-80-c2-00-00-00.
• A switch uses the unique MAC address of the port where the BPDU frame is sent out off as its source address.
• Switches running STP use BPDUs to:
  • Elect a root bridge
  • Determine the location of redundant paths
  • Block certain ports to prevent loops
  • Notify the network of topology changes
  • Monitor the state of spanning tree

 BPDU Types

• Configuration BPDU
  • Originated by the root bridge and used for spanning-tree computation.
    • By generating the BPDU only at the root bridge, the STP bridges are guaranteed to have no mismatch in the timers.
  • Used to elect the root bridge.
  • Sent out all ports of the root bridge every 2 seconds.

BPDU Frame

BPDU Frame Format

• Topology Change Notification (TCN) BPDU
  • Generated by any switch when it detects a topolgy change.

 Topology Change Notification BPDU 

STP Operation

I. Root Bridge Election

• The root bridge is a point of reference that all switches use to determine loops in the network and agree on a loop-free topology.
• When a switch powers up initially, it thinks of itself as the Root Bridge. All other switches make the same assumption of themselves on initial boot up.
• The election process:
  • Every switch begins sending out BPDUs with a Root Bridge ID equal to its own Bridge ID and a Sender Bridge ID equal to its own Bridge ID as well
    • The Sender Bridge ID simply tells other switches who is the actual sender of the BPDU message.
  • Switches receive BPDUs sent by other switches and compare who has the better Bridge ID (bridge priority + MAC address) value. The lower the Bridge ID, the better.
    • If two Bridge Priorities are equal, the lower MAC address wins.
  • If a switch hears of a better bridge ID, its replaces its own Root Bridge ID with the better Root Bridge ID.
    • This bridge advertises the new (better) Root Bridge ID in its BPDU while still using its own Sender Bridge ID.
  • When the election converges, the switch with the best Bridge ID becomes the Root Bridge.
  • All ports on the Root Bridge act as designated ports.
    • Designated ports send and receive traffic as well as configuration messages (BPDUs).
  •  If a new switch is powered up on the network and it advertises a superior (lower) Bridge ID than the rest, it immediately takes over as the Root Bridge.

II. Root Port Election

• This process elects one root port on each non-root bridge on the network.
• The root port always points toward the current Root Bridge.
• Root ports send and receive traffic.
• The root port is the lowest-cost path from the non-root bridge to the root bridge.

Path Cost vs. Root Path Cost

• Path Cost
  • A 1-byte value associated with a particular switch link speed.
    • For example: a 100 Mbps link has a Path cost of 19.
    • See chart below for STP Path Cost values.
  • It is not contained in the BPDU
  • It is known only to the local switch where the port resides.
• Root Path Cost
  • This is the cumulative cost of all the links leading to the Root Bridge.
  • Only the root path cost is contained in the BPDU (remember: path cost is stays and known only the local switch).
  • The root path cost is determined as follows:
    1. The root bridge sends out a BPDU with a root path cost of 0 because its ports sit directly on the Root Bridge.
    2. When the next-closest neighbor receives the BPDU, it adds the path cost of its own port where the BPDU arrived. (This is done as the BPDU is received.)
    3. The neigbor sends out BPDUs with new cumulative value as the root path cost.
    4. The root path cost is incremented by the ingress port’s path cost as the BPDU is received at each switch along the way.
    5. Be aware that the root path cost is incremented only as BPDUs are received, not as they go out. Take this into account when computing the Spanning Tree Algorithm manually and computing a new root path cost.
  •  A switch stores the value of the root path cost in its memory. If a BPDU with a lower root path coast than its recorded value is received in another port, that port becomes the new root port.

STP Path Cost

III. Designated Port Election

•  On each segment where two or more switches have ports connected to a single common network link, only one of the links on that segment should forward traffic to and from that segment. That port is the Designated Port.
• The designated port has the lowest path cost to the root bridge.
  • Switches choose a designated port based on the lowest cumulative rootp path cost to the root bridge.
• In case of identical root path cost, resulting in a tie, the following criteria is used in the decision-making process (in order):
  1. Lowest root bridge ID
  2. Lowest root path cost to root bridge
  3. Lowest sender bridge ID
  4. Lowest port priority
  5. Lowest port ID

Electing a Designated Port

• In the diagram above, LAN segment V has 3 ports on that same link from each of the bridges: Bridge 5, 3, and 4. 
• Immediately, we can assume that Bridge 3’s LAN V port cannot be the designated port because it has a higher cost (20)  than the other two.
• Because Bridge 4 and Bridge 5 can reach the root bridge with a path cost of 10, they are considered a tie. In this case the Sender Bridge ID is used to determine which port becomes the designated port. Bridge 4 just happens to have the lower Bridge ID.
• Bridge 4 is also the Designated Bridge of the LAN V segment. The designated switch is simply the one closest to the root switch through which frames are forwarded to the root.
• The resulting outcome is that the segment V ports of Bridges 5 and 3 are blocked, and Bridge 4’s LAN V port is the only port allowed to forward frames.

STP States

The following describes the different states that switch ports go through during STP operation:

• Disabled
  • This is not part of the STP operation, but it is a special state that a port could be in when the following conditions are true:
    • The port is administratively shut down.
    • The system puts it in the state due to a fault condition.
• Blocking
  • When a port initializes, it remains in a blocking state so no loops can form.
  • In this state, a port cannot receive nor transmit frames.
  • It cannot learn MAC addresses
  • It can receive BPDUs.
  • Additionaly, ports that are put into standby mode to remove a bridging loop enter this state.
• Listening
  • Duration: 15 seconds (forward delay period)
  • Still cannot receive or send data.
  • It can receive or send BPDUs. This allows the port to become either Root Port of Designated Port.
  • If it doesn’t stay on root port or designated port status, it goes to blocking state.
• Learning
  • Duration: 15 seconds (forward delay period
  • After the Forward Delay period in the listening state, the port goes into learning state where it can start learning MAC addresses to add to the MAC address table.
  • Can send and receive BPDUs
  • Cannot yet send any data.
• Forwarding
  • Fully functioning state.
  • Can now send and receive data.
  • Continues to collect MAC addresses in its address table.
  • Sends and receives BPDUs.

References:

1. Internetworking Technology Handbook – Transparent Bridging
2. Spanning-Tree Algorithm Frame Format
3. Bridge Protocol Data Unit – Hill2dot0

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition) by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

Got pulled over by cops last night (2nd time in 6 months). But like last time, I was able to finagle my way with a warning. I made a wrong turn in a one way street because the street was stupid. Just kidding. I can’t blame the road. I was distracted because I was too engrossed on radio broadcast of the championship series of the Lakers/Nuggets game. So no ticket and the Lakers won a close one. Good times…

Anyway, back to some updates on my studies. I’ve began writing notes again. I’m writing each sections concurrently because I read two long chapters on STP, RSTP, etc since last week but never started my notes. I was reading about ten pages a day – some days better than others. I also tried to lab some and was less than satisfied from the  result of my efforts. I was just going through the motions in the lab and didn’t take the time to understand the mechanics of the labs. I shall lab again this week.

I looked at my schedule for the first time in a month and I am a little under four weeks and 5 chapters behind. I’m still going to try to take the exam in mid-July. After reading the whole text book on BCMSN, I felt that nothing was too over my head. I just needed to spend the time to, essentially, memorize facts. Concepts have always been pretty easy for me to pick up. It’s remembering little details that I have a hard time on.

I’m still trying to re-establish a solid study pattern and get right back to good ole times…

Then a few weeks ago, my wife bought the Twilight series and she got me into reading it. Yes, it was her fault. It was not a conscious decision on my part to read that trash – hey! One man’s trash is another man’s…. food.   But she got me hooked and I just had to finish reading all four books. In fact I read all four books in just over 2 weeks because I just wanted to get it over with. Ok, truth be told, I did enjoy the books. In a way it was an escape for me considering I’ve been reading thousands of pages of technical documents for the past year and a half. 

Anyway, as if all the distractions weren’t enough, last week my family was dealt with a major blow when my mom slipped into a coma after suffering some kind of heart attack. She was already checked in the hospital for a completely different reason prior to that episode. She was just sitting on her hospital bed talking and joking with my dad when she just collapsed all of a sudden.  She stopped breathing and her heart stopped beating. The staff tried to resuscitate her for 25 minutes but by then she had gone without oxygen in her system for just as long. Right now she is still intubated in the ICU, and is non-responsive to any external stimuli. Both of my brothers were called in from Iraq and Afghanistan, respectively and have been home since yesterday – helping my father out at the hospital since he prefers to stay there 24/7 to watch over my mom. We’re trying to get him to take a break for his own health but if that were my wife, I’d probably be doing the same. *By the way, thanks to all my Twitter friends for all the thoughts, prayers and support you’ve given me and my family the last few days. I really appreciate that a lot.

So that’s a short synopsis of the going-ons in my life the last few weeks. I’m still trying to study as much as I can but of course other priorities take precedence – like reading Twilight. j/k

Where are you at?

According to Cisco docs:

• The Layer 2 traceroute feature allows the switch to identify the physical path that a packet takes from a source device to a destination device.
• Layer 2 traceroute supports only unicast source and destination MAC addresses.
• It finds the path by using the MAC address tables of the switches in the path. When the switch detects a device in the path that does not support Layer 2 traceroute, the switch continues to send Layer 2 trace queries and lets them time out.
• The switch can only identify the path from the source device to the destination device.
  • It cannot identify the path that a packet takes from source host to the source device or from the destination device to the destination host.
• CDP must be enabled on all devices.
• The maximum number of hops is 10.
• Must be on the same subnet.

ont-sw01#traceroute mac ip 10.100.194.116 10.100.194.4
Translating IP to mac …..
10.100.194.116 => 1234.1fe6.1116
10.100.194.4 => 5678.4640.1114

Source 000f.1fe6.d8e9 found on ont-sw01
1 ont-sw01 (10.100.194.10) : Fa0/7 => Fa0/12
2 switch01 (10.100.194.41) : Fa0/15 => Fa0/6
Destination 5678.4640.1114 found on switch01
Layer 2 trace completed

=======================

ont-sw01#traceroute mac ip 10.100.194.116 10.100.194.1
Translating IP to mac …..
10.100.194.116 => 1234.1fe6.1116
10.100.194.1 => 4321.43da.1111

Source 000f.1fe6.d8e9 found on ont-sw01
1 ont-sw01 (10.100.194.10) : Fa0/7 => Fa0/2
Destination 4321.43da.1111 found on ont-sw01
Layer2 trace completed.
ont-sw01#

Reference:

1. Using Layer 2 Traceroute

• VTP is a Cisco-proprietary protocol that use Layer 2 trunk frames to distribute and synchronize VLAN information throughout a switched network.
•  VTP Manages the addition, deletion, and name changes of VLANs within a VTP domain.
• VTP messages are transmitted on swtiches’ 802.1Q and ISL trunks.
• By using VTP, misconfiguration and configuration inconsistencies are minimized.

VTP Domains

• A VTP domain is a switch or group of interconnected switches that share the same VTP environment or areas with common VLAN requirements.
• A switch can belong to only one VTP domain.
• Switches in different VTP domains do not share VTP information.
• Switches in a VTP domain advertise several attributes to their domain neighbor containing information about:
  • VTP management domain
  • VTP revision number
  • known VLANs
  • Other specific VLAN parameters

VTP Modes

•  Server Mode
  • This is the default VTP mode
  • VTP servers have full control over VLAN creation, deletion, and modification.
  • All VTP information is forwarded/advertised to other switches.
  • Received VLAN information is sychronized if they carry the latest information about the domain.
  • Each VTP domain must have at least one server so that all created, modified, or deleted VLANs and other VLAN information can be propagated.
  • Saves VLAN and VTP configuration in NVRAM in a file called vlan.dat (typically in Cisco Catalyst 6500/6000 series switches). In most other cases it is saved in flash.
• Client Mode
  • Cannot create, modify, or delete VLANs.
  • Listens to VTP advertisements from other switches and modify their VLAN configurations accordingly.
  • Forwards VLAN advertisements to other switches.
    • This mode is effectively a passive listening mode.
  • Does not save VLAN configuration in NVRAM
• Transparent Mode
  • Do not participate in VTP.
  • Creates, modifies, and deletes VLAN only on the local switch.
    • These changes do not propagate to other switches.
    • Does not synchronize its VLAN database with received advertisements.
  • In VTP version 1, switch does not relay VTP information unless VTP domain name and VTP version numbers match other switches.
  • In VTP version 2, they forward received VTP advertisements out their trunk ports regardless of VTP domain setting.
  • Saves VLAN configuration in NVRAM.

VTP Advertisements

• VTP switches send VTP information to other switches participating in VTP. They advertise:
  • VLANs (only VLANs 1 to 1005)
  • Configuration Revision Numbers
  • Other parameters such as VTP domain name and password.
• They are sent as multicast frames every 5 minutes or when there is a change.

Configuration Revision Numbers

• Each time a VTP server modifies its VLAN information, the configuration revision number is incremented by 1.
• If the configuration revision number that is being advertised is higher than the number stored on the other switches in teh VTP domain, the rest of the switches in the domain ovewrite their VLAN configurations with the new information being advertised.
• The VTP advertisement process always starts with revision number 0.
• It is important that any new switches that are added to the network have revision number 0 before plugging into the network.
• The VTP revision numnber is stored in NVRAM and is not affected by a reload of the switch.
• The following methods resets the revision number to 0:
  • Change the switch’s VTP mode to transparent and then change the back to server.
  • Change the switch’sVTP domain to a bogus name, then change the VTP domain back to the original name.
• VTP advertisements can originate from client-mode switches upon bootup.
  • They may also originate from server-mode switches as VLAN configuration changes.

3 Forms of VTP Advertisements

• Summary advertisements
  • Sent by VTP domain servers.
  • Sent every 300 seconds (5 minutes) or every time VLAN changes occurs.
  • List information about the VTP domain such as:
    • VTP version
    • Domain name
    • Configuration revision number
    • Time stamp
    • MD5 encryption hash code
    • Number of subset advertisements to follow.
• Subset advertisements
  • Sent by VTP domain servers after a VLAN configuration change occurs.
    • These advertisements list the specific changes that have been performed, such as:
      • Creating or deleting VLANs.
      • Suspending or activating a VLAN.
      • Changing the name of a VLAN.
      • Changing a VLANs MTU.
  • Subset advertisements can list the following VLAN parameters:
    • Status of the VLAN
    • VLAN type (Ethernet or Token Ring)
    • MTU
    • Length of the VLAN name
    • VLAN number
    • Security Association Identifier (SAID) value
    • VLAN name
  • VLANs are listed individually in sequential subset advertisements.
• Advertisement requests from clients
  • A VTP client can request any missing VLAN information.
    • For example:
      • A client has its database erased and after a reload the VTP domain membership has changed.
      • It hears a VTP summary advertisement with a higher revision number than it currently has.
  • When a client advertisement request is made, the  VTP domain servers respond with summary and subset advertisements to bring it up to date.

VTP Pruning

• By defualt, a trunk link transports traffic from all VLAN, unless specific VLANs are removed from the trunk.
• VTP pruning uses VLAN advertisements to determine when a trunk connection is flooding traffic needlesly.
  • It makes more efficient use of trunk bandwidth by reducing unnecessary flooded traffic.
  • Broadcast and unknown unicast frames on a VLAN are forwarded over a trunk link only if the switch on the receiving end of the trunk has ports in that VLAN.
• Consider the following network below:

• Traffic from Switch A is only forwarded to Switches B and D while traffic out to Switches E and C are “pruned”.
• This prevent uneccesary traffic sent to switches that do not have ports in the Red VLAN (where traffic was originated and destined to).

Configuring VTP

Configuring VTP Management Domain

switch(config)#vtp domain domain-name

Configuring VTP Mode

switch(config)vtp mode {server | client | transparent}

• Server Mode
  • Default mode
  • Each domain must have at least one server.
  • May be used even if other server and client switches are present – provides redundancy in case of server failure.
• Client Mode
  • One way to configure new switches as client mode so that it can learn existing VTP infromation from existing servers. Once it has learned the current configuration, it may be configured as a server if redundancy is desired.
•  Transparent Mode
  • VLANs can be created, modified, and deleted. But the changes remain in the local switch
  • Received advertisements from other switches, however, are forwarded to others.
  • This mode can help prevent the possibility of duplicate and over-lapping VLANs.

Configuring VTP Password

Switch(config)#vtp password password

• Password can only be configured on VTP servers and clients.
• Password string is not sent, rather the MD5 hash is sent in VTP server advertisements and used to validate received client advertisements.
• Password string can be 1 to 32 characters and is case-sensitive.

Configuring VTP version

 switch(config)#vtp version {1 | 2}

• Version 1 is the default
• They are not interoperable, ie. the same version must be used throughout the management domain.

Configuring VTP Pruning

switch(config)#vtp pruning

• If this command is used on a VTP server, it is advertised to the rest of the domain and all listening switches will also enable pruning.
• General purpose VLANs (2 – 1001) are eligible for pruning on all trunk links if needed.

Using the following interface configuration command, the list of pruning eligibility can be narrowed down:

switch(config-if)#switchport trunk pruning vlan {add | except | none | remove} vlan-list

• vlan-list – a list of eligible VLAN numbers (2 -1001), separated by commas or dashes.
• add – a list VLAN numbers added to the already configured list; this is a shortcut from typing a long list of numbers
• except - excludes the specified VLANs from being included in the pruning.
• remove – removes the specified VLANs from the already configured list.

 Verifying VTP

• show vtp status
  • Displays information about about the VTP configuration and current state in Cisco IOS.
  • The output describes the VTP version, the numbers of VLANs supported locally, the VTP operating mode, VTP domain name, and the VTP pruning mode.
• show vtp counters
  • Diplays statistics about VTP operation.

References:

1. Understanding VLAN Trunking Protocol (VTP) – Cisco System, Inc.
2. Configuring VTP –  Catalyst 3560 Switch Software Configuration Guide, 12.2(20)SE
3. Managing vlan.dat in Cisco Catalyst Switches Running Cisco IOS Software

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition) by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

• VLAN
• VLAN Trunking

VLAN

• Virtual LAN (VLAN) is a swiched network of hosts or end devices with a common set of requirements without regard to the physical locations of the users.
• VLANs have the same attributes as physical LANs but end devices can be grouped on the same LAN segment regardless of location.
• VLANs segment the network into its own separate Layer 2 broadcast domain.
  • Switches filter broadcast packets from all ports or devices that don’t belong to the same VLAN.
• VLANs are slightly different from a physical subnet:
  • A physical subnet consists of devices on a physical cable segment.
  • A logical subnet consists of devices that communicate with each other regardless of physical location – VLANs.

End-to-End and Local VLANs

• End-to-end VLANs
  • Also called campus-wide VLANs.
  • Span throughout the entire switch fabric of a network.
  • They may span several wiring closests or even buildings.
  • End-to-end VLANs group users according to common requirements.
  • In this design the 80/20 rule is utilized – that is, 80% of traffic stays within the local workgroup, whereas 20% is destined to remote resources (which is typically routed).
  • Beacuse all VLANs must be available at each access-layer switch, VLAN trunking must be used to carry all VLANs between the access- and distribution-layer switches.
• Local VLANs 
  • Local to a specific domain, such as Building Access switches and their respective Building Distribution submodule.
  • Range in size from a single switch in a wiring closet to an entire building.
  • Design moves toward an 20/80 rule where 20% of traffic is local and 80% is destined to a remote resource across the core layer.
  • Results in traffic crossing a Layer 3 router or multilayer switch to reach network resources – but still allows the network to provide secure and consistent method of data delivery.
  • Typically used in the Building Access submodule.
  • A typical VLAN organization configures the minimum number of VLANs on a single access switch within a wiring closet, rather than having VLANs from multiple departments configured on the same switch.
  • The goal of local VLANs is not to extend the VLANs beyond the Building Distribution submodule.
  • Local VLANs provide users with the same level of performance regardless of their location because Layer 3 devices also switch and route at wire rate due to hardware-switching.

End-to-end VLANs are not recommended in an enterprise network, unless there is a good reason. In an end-to-end VLAN, broadcast traffic is carried over from one end of the network to the other, creating the possibility for a broadcast storm or Layer 2 bridging loop to spread across the whole extent of a VLAN. This can exhaust the bandwidth of distribution- and core-layer links, as well as switch CPU resources. Now the storm or loop has disrupted users on the end-to-end VLAN, in addition to users on other VLANs that might be crossing the core. When such a problem occurs, troubleshooting becomes more difficult. In other words, the risks of end-to-end VLANs outweigh the convenience and benefits.

Static and Dynamic VLANs

• Static VLANs
  • Constitutes switch ports that are manually assigned to a particular VLAN.
  • End devices become members of a particular VLAN base on what port on the switch they are plugged into.
  • They can be configured via a VLAN-management application or the command line.
  • Each port receives a Port VLAN ID (PVID) that associates it with a VLAN number.
  • Works well where adds, moves, and changes are rare.
  • The port-to-VLAN membership is normally handled in hardware (ASICs) where it provides good performance because all port mappings are done at the hardware level, with no complex table lookups needed.
• Dynamic VLANs
  • Provide membership base on the MAC address of an end device.
  • Configuration is accomplished by using a VLAN membership Policy Server (VMPS).
    • VMPS contains a database that maps MAC addresses to VLAN assignments. 
    • The switch assigns a VLAN to a host based on information in the MAC address-to-VLAN mapping on the VMPS.
  • It is dynamic because when a host moves from one switch to another in the network, the switch will dynamically assign that particular host to the right VLAN.
  • A dynamic port belongs to only one VLAN at a time. Multiple hosts maybe on the same port but they must all belong to the same VLAN.

VLAN Ranges

Configuration

There are two methods to configure a VLAN:

1. Global configuration mode – relatively newer method that allows configuration of extended VLAN ranges.
2. VLAN database configuration mode – supports only the configuration of VLANs in normal range (1 – 1005).

Create VLAN in global configuration mode:

Switch#configure terminal
Switch(config)#vlan 100
Switch(config-vlan)#name Accounting

Create VLAN in database configuration mode:

Switch#vlan database
Switch(vlan)#vlan 100
VLAN 100 added:
     Name: VLAN0100
Switch(vlan)#vlan 100 name Accounting
Swtich(vlan)#exit
APPLY completed.
Exiting….

• Cisco recommends using global configuration mode to define VLANs.
• The VLAN database command mode is session oriented. When you add, delete, or modify VLAN parameters, the switch does not appy the changes until you exit the session by entering apply or exit command. Using the abort command will not apply the changes made to the VTP database.
  • The gloabl configuration command has been deemed an obsolete method.

Delete a VLAN

Switch#config t
Switch(config)#no vlan 100
Switch(config)#end

•  After a VLAN is deleted, the ports that belong to tha VLAN becomes inactive until it is assigned to another VLAN. Ports in inactive state do not forward traffic.

Assign a port to a VLAN

Switch#config t
Switch(config)#interface fa1/0
Switch(config-if)#description Host A
Switch(config-if)#switchport
Switch(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 100
Switch(config-if)#no shut
Switch(config-if)#end

•  The switchport command with no keywords configures interfaces as Layer 2 interfaces on Layer 3 switches.
• The switchport host command effectively configures a port for a host device.
  • This feature is a macro for enabling Spanning Tree PortFast and disabling EtherChanneling of a per-port basis.
• The switchport mode access command specifies the port as an access port. 
• The switchport access vlan command places a port in a particular VLAN.

VLAN Verification

• sh vlan id 
  • Displays information about a VLAN identified by VLAN number.

• sh vlan name
  • Displays information about a VLAN by name in Cisco IOS.

• sh running-config interface
  • Displays the current configuration of a particular interface.

• sh interface switchport
  • Shows detailed information about a specific swithcport

VLAN Trunking

• An access switchport can only support one VLAN. However, multiple IP subnets can exist on that single VLAN.
  • For example, a shared hub connected to one switch port with hosts plugged into the hub – one with IP 192.168.1.1/24 and the other with 192.168.2.1/24.
• A trunk port however, supports more than one VLAN on a single switch port.
  • Trunk ports carry traffic for multiple VLANs across a single physical link.
  • It can be used to connect to another switch (to extend Layer 2 operations across an entire network, such as end-to-end VLANs) or connect a switch to a router (for example, router-on-a-stick)
  • A trunk link is not assigned to a specific VLAN. Rather, one or many VLANs can be transported on a single trunk link.
• Cisco supports trunking on Fast Ethernet and Gigabit Ethernet links, as well as aggregated Fast and Gigabit Etherchannel links.

Trunking Protocols

• In order for a switch to distinguish between traffic belonging to different traffic, there are two trunking protocols that are used to identify or tag the frames.
  • Inter-switch Link (ISL)
  • IEEE 802.1Q
• When a VLAN frame is transmitted over a trunk link, a unique identifier is placed in the frame header. A switch that receives the frame examines the identifier to determine which VLAN it belongs.
  • the identifier is removed by the receving switch.
  • If the frames traverses another trunk link, the forwarding swich adds back the VLAN identifier into the frame header.

Inter-switch Link Protocol (ISL)

• Cisco-proprietary.
• High-end routers and appliances support ISL.
  • Later Cisco Catalyst switches no longer support ISL.
• Non-ISL devices receiving an ISL-encapsulated frame may consider them transmission errors if the header plus data frame exceeds the MTU size
• Devices that do not support ISL simply drops the frame.

• The ISL frame has a header that is 26 bytes and an additional 4 bytes for the ISL FCS header. 30 bytes is added to the original frame.
• Notice in the diagram that it contains two header fields.
  • The original header field stays the same from its original frame. The second is generated by the ISL trunk port.
• The ISL encapsulation leaves the original frame un-modified.
• The source VLAN is identified with a 15-bit VLAN ID field in the header (see image above).
• Although primarily used for Ethernet media, ISL can be used to carry Token Ring, FDDI, and ATM frames over Ethernet ISL by using the 3-bit Type field in the ISL header.
• Because tagging information is added at the beginning and end of each frame, ISL is sometimes referred to as double tagging.

IEEE 802.1Q Protocol

• As opposed to ISL, this method of frame identification is standardized.
• Instead of encapsulating the frame with a header and trailer, 802.1Q inserts the tagging information inside the frame and modifies several fields. For this reason, it is typically called single tagging or internal tagging.

• 802.1Q inserts a 4-byte tag just right after the source field. The fields in the tag are as follows:
  • Tag Protocol Identifier (TPID) - 2-byte field that has value of 0×8100.
  • Tag Control Information (TCI) – the other 2-bytes. Broken down as:
    • PRI – a 3-bit priority field used to implement class-of-service (CoS) functions in the accompanying 802.1Q/802.1p prioritization standard.
    • Canonical Format Indicator (CFI) – 1-bit field that indicates the frame format (0 for Ethernet and 1 for Token-ring). Also known as canonical format, or little-endian or big-endian format.
    • VLAN ID – 12-bit VLAN field.
• 802.1Q uses an internal tagging mechanism that modifies the original frame (note the “X” on the original FCS field), recalculates the CRC value for the entire frame with the tag, and inserts the new CRC vlaue in a new FCS.
  • In comparison, ISL encapsulates the entire frame and adds a second FCS and does not modify the original frame FCS.

Baby Giants

• Note that both ISL and 802.1Q taggin methods add to the lenthg of an Ethernet frame.
  • ISL adds 30 bytes to each frame for a total of 1548 bytes on each ethernet frame.
  • 802.1Q adds 4 bytes for a total of 1522 bytes per frame.
• Because Ethernet frames cannot exceed 1518 bytes, the additional VLAN tagging information can cause the frame to become too large.
  • Frames that are larger than 1500 bytes (but smaller than 2000 bytes) are called baby giants.
• Switches usually report these frames as Ethernet errors or oversize frames.
• To properly handle and forward baby giants, Catalyst switches use proprietary hardware with the ISL encapsulation method. In the case of 802.1Q encapsulation, switches can comply with the IEEE 802.3ac standard, which extends the maximum frame length to 1522 bytes.

Native VLAN

• 802.1Q trunks define a native VLAN for frames that are not tagged by default.
• Switches transmit any Layer 2 frames from a native VLAN on the trunk port untagged.
• The receiving switch forwards all untagged packets to its native VLAN.
• The native VLAN is the default VLAN configuration of the port.
• When the port is not trunking, the access VLAN configuration defines the native VLAN.
• In the case of Cisco switches, the default VLAN is VLAN 1 and is configurable.
• Two devices that are trunking has to have the same native VLAN configuration on both sides of the link.
  • Misconfiguration may cause Layer 2 loops or blackholes.
  • CPD issues a “VLAN mismatch” console error message if native VLANs don’t match.
• Tagged or not, a switch will forward Layer 2 frames received on an 802.1Q trunk port.
  • ISL drops unencapsulated frames. All frames, including native VLAN are encapsulated.

Dynamic Trunking Protocol (DTP)

• Cisco-proprietary point-to-point protocol that negotiates a common trunking mode between two switches.
• DTP negotiates the operational mode of directly connected switch ports to a trunk port and selects an appropriate trunking protocol.
• DTP should be disabled if a switch has a trunk link connected to a non-trunking router or firewall interface because those devices cannot participate in DTP negotiation.
  • A trunk link can be negotiated between two switches only if both switches belong to the same VLAN Trunking Protocol (VTP) management domain or if one or both switches have not defined their VTP domain (that is, the NULL domain).
  • If the two switches are in different VTP domains and trunking is desired between them, you must set the trunk links to on mode or nonegotiate mode. This setting forces the trunk to be established.

 VLAN Trunk Configuration

Switch(config)# interface type mod/port
Switch(config-if)# switchport

• The switchport command puts the port in Layer 2 mode.

Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}

• The switchport trunk encapsulation command configures the type of enccapsulation for the port:
  • isl – VLANs are tagged by encapsulating each frame with the Cisco ISL protocol.
  • dot1q – VLANs are tagged in each frame using the IEEE 802.1Q standard protocol. The native VLAN is sent normally and is untagged.
  • negotiate – The default configuration, negotiates the encapsulation to select either ISL or 802.1Q, whichever both ends of the trunk support. If both ends support both types, ISL is used.

Switch(config-if)# switchport trunk native vlan vlan-id

• The swichport trunk native vlan command is used to define the untagged or native VLAN as vlan-id (1 to 4094).
• By default, 802.1Q trunks use VLAN 1 as the native VLAN.
• ISL trunks has no effect on this command because ISL does not support untagged VLANs.

Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove} vlan-list}

• The switchport trunk allowed vlan command defines which VLANs can be trunked over the link.
• By default a switch transports all active VLANs (1 to 4094) over a trunk link.
• There are times that trunk links should not carry all VLANs. Because trunk links are also part of the VLAN, it and broadcast traffic are forwarded to every switch port on the VLAN. If the VLAN does not exist past the far end of the trunk link, there is no reason to propagate broadcast accross the trunk.
• The following are some parameters:
  • vlan-list – An explicit list of VLAN numbers, separated by commas or dashes.
  • all – All active VLANs (from 1 to 4094) will be allowed
  • add vlan-list – A list of VLAN numbers will be added to the already configured list; this is a shortcut to keep from typing a long list of numbers.
  • except vlan-list – All VLANs (1 to 4094) will be allowed, except for the VLAN numbers listed; this is a shortcut to keep from typing a long list of numbers.
  • remove vlan-list – A list of VLAN numbers will be removed from the already configured list; this is a shortcut to keep from typing a long list of numbers.

Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

• The switchport mode command sets the trunking mode to any of the following:
  • trunk – Sets the port in permanent trunking mode.
  • dynamic desirable (default setting) – The port attemtps to actively convert the link to trunking mode. It “asks” the other end of the trunk link to bring up a trunk. If the far-end switch prot is configured as trunk, dynamic desirable, or dynamic auto mode, trunking is negotiated successfully.
  • dynamic auto – The port turns into a trunk link only if the far-end of the switch actively requests it. If both ends are dynamic auto, the trunk does not form. If the other end of the switch is trunking mode or dynamic desirable mode, trunking is negotiated.

Example: Configure a Port for ISL Trunking

Switch#conf t
Switch(config)#interface FastEthernet 0/48
Switch(config-if)#switchport
Switch(config-if)#switchport trunk encapsulation isl
Switch(config-if)#switchport mode trunk

Example: Configure a Port for 802.1Q Trunking

Switch#conf t
Switch(config)#interface FastEthernet 0/48
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode dynamic desirable
Switch(config-if)#switchport trunk allowed vlan 1 – 100
Switch(config-if)#no shut

Verification Commands

• sh running-config interface fa0/48
  • Displays port information for trunking.
• sh int fa 0/48 switchport
  • Displays switchport information for trunking
• sh int fa 0/48 trunk
  • Displays trunk information for a particular port

References:

1. Catalyst 3550 Multilayer Switch Software Configuration Guide, 12.1(9)EA1 – Creating and Maintaining VLANs
2. Inter-Switch Link and IEEE 802.1Q Frame Format – Cisco Systems, Inc.

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BCMSN course, consider purchasing Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition) by Richard Froom, Balaji Sivasubramanian, and Erum Frahim and CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby ; as well as following the links on the reference section of this entry.

Yes, I’m a proud father of a new baby boy (my 2^nd). His name is Noah Ryan and he was born  April 09, 2009.

Now I will have to re-think my study schedule as this little dude will most likely take up a lot of my time and attention – as it should. For the last couple of days, I haven’t had the time nor the energy to study. Even the few moments when I could’ve studied, I just didn’t have the motivation. However, my wife believes that I just need to re-adjust and get back to some sort of routine and in no time, I’ll find a good balance for studying and family time. God bless her for her.

I still want to stick to my original goal of taking the BCMSN exam either in late July or early August. How I’m going to do that, I still don’t know.  But hopefully things will work out just fine. I might have to cut down on blogging my notes and focus more on doing practice questions and labs. I guess we’ll see how it goes. At least I’ll try to blog about and document my progress regardless of how I proceed in my studies.

I almost feel unprepared for what to do next as  I have not scheduled the next phase of my study plan. I suppose I can forgo studying tonight and work on planning out my next schedule.  Obviously this next phase will be at a much slower pace. This is where I will throw in all the other components of my preparation – lab, Exam guide, Cisco.com supplements, etc. Since I’ve penciled in the end of July as my targeted exam date I’m hoping to use up the rest of this month, May and June to focus heavily on the second phase. Then the rest of July will be spent on review.

This plan does not take into account conditions and circumstances brought about by the new baby we’re about to have. So wish me luck.

Mon, 13-Apr-09: Chapter 18: Read pp. 856 – 876 – Cisco wireless clients, Configure basic WLAN, End of chapter.

Well this weekend was very productive for me as far as reading goes. I’ve managed to regain a huge lead I had in the beginning in terms of pages read so far. Right now I’m on the wireless section and am looking to finish the book either tonight or tomorrow at the latest. I did cheat a little bit by skipping one chapter (chapter 16 – Metro Solutions (MAN)). The book mentions that the chapter is not covered in the exam and the topics don’t appear in the BCMSN blueprint either. Besides I did buy a book on Metro Networks  a couple of weeks ago to read on my spare time – just based on general interest. But for now the main focus is to get through the first phase of the readings and move on to the second phase for a more focused and in depth study.

I haven’t been able to do as much reading this week as I had hoped. After my son’s 3-yr birthday party last Saturday, I got sick and was not able to keep ahead of my readings. Thankfully though, I read ahead the prior week so I’m actually still on pace with my schedule. The only downside is that I probably won’t be able to finish ahead of schedule.

Las night my wife started feeling some contractions which put us on a vigilant mode just in case the baby decides to come out sooner. So it’s becoming more urgent that I ramp up my readings just so I can finish the first phase of my studies before the baby comes. If not, that’s ok. That just means I’ll need to make a more stringent adjustment on my schedule to make sure I’m keeping a reasonable study schedule and at the same time not ignoring my fatherly and husbandly duties in this time of change -  a good change!

Tonight I will be starting with the QoS chapter and hopefully be able to progress at the same pace I was going for the last 2 weeks. I say hopefully because I’m a little doubtful. QoS is an entirely new subject for as I’ve never touched it before. Whereas, the previous weeks were pretty much a series of CCNA switching review with a some added new materials. We’ll see how it works out at the end of the week.

• BGP: Frequently Asked Questions
• EIGRP Frequently Asked Questions
• IP Routing Frequently Asked Questions
• ODR: Frequently Asked Questions
• OSPF: Frequently Asked Questions
• Cisco IOS Multicast Q&A

But while looking over some of the FAQs contained in them, I was surprised to discover how many of the very same questions appeared on the BSCI exam (albeit worded and used on the exam a little differently – but the same information nonetheless).

In my opinion, in order to get the most out of the FAQs, you’ll have to thoroughly understand the theories behind each technologies first – this is done by reading your theory books. Once you understand the general makeup and operation of the protocols, the FAQs can serve as review questions that  can be used to verify how much of the details you can remember. The way I would use them in the future is to categorize each protocols, copy the questions into a set of index cards/flash cards (or something similar) and drill myself until I’ve memorized the information.

Head over to Netengineer.org (aka. CCIE Paradise) and congratulate Andy Lee for passing the CCIE lab on Friday.

This past weekend, I concentrated mostly with an overview of Spanning Tree and its operation.  I also watched a little bit of IPExpert’s free vLecture on spanning tree. I’m a little bit ahead of my reading schedule as I’ve already finished the scheduled reading on Chapter 5. It was a little challenging getting through that chapter for some reason. I felt like CCNA all over again when I struggled with Spanning Tree. I don’t find it a difficult subject. It’s just that somehow the concept doesn’t stick as well. Good news is, I understand it much better than I did when I first learned it in CCNA. And I didn’t find too much new materials. In fact I’ll probably re-read the CCNA material during the second phase of my studies as I found Wendell Odom’s style of writing much easier to digest – and I somehow feel that the CCNA material was more “in depth” in its coverage. Or maybe it’s just my perception because it was completely new to me last year and much more overwhelming in details.  I’ve started Chapter 6 today and I’m shooting to finish that tonight – hopefully even start chapter 7 tonight. Chapter 6 is very short. There is only a little over 25 pages. I can probably knock 20 pages of it during downtimes at work. I’m hoping to get as much reading this week as I can because I might not have much time to read next weekend as we are celebrating my son’s 3-yr birthday party.

This week’s scheduled reading is posted below. I’ve already read ahead so I’ve completed the scheduled readings up to Friday. I’m starting the Saturday schedule tonight and hopefully be able to stay ahead of the game in case my wife gives birth a little earlier than expected.

Mon, 16-Mar-09: Chapter 1: Read pp. 3 – 30 – Enterprise Network Architectures: Enterprise Composite Model, SONA, IIN, etc
Tue, 17-Mar-09: Chapter 1: Read pp. 31 – 60 – Continuation of Enterprise Model, Intro to Catalyst switches
Wed, 18-Mar-09: Chapter 2: Read pp. 61 – 92 – Data-link layer technologies, Multilayer switched network design.
Thur, 19-Mar-09: Chapter 3: Read pp. 95 – 125 – Initial Catalyst switch configurations, IOS File System (IFS), Software images.
Fri, 20-Mar-09: Chapter 3: Read pp. 125 – 147 – Basic switch troubleshooting practices.
Sat, 21-Mar-09: Chapter 4: Read pp. 149 – 185 – VLANs: configuring , verifying , Private VLANs, VLAN trunking.
Sun, 22-Mar-09: Chapter 4: Read pp. 185 – 215 – VLAN Trunking Protocol (VTP), End of chapter exercises.

Well now I’m almost back into full swing. I’ve already read about two and half chapters of the Cisco Press Study Guide since Monday. I’m hoping I can get through all 800 or so pages of the book in under a month before I begin to re-read and do a “deep-dive” into each chapters.  I’m back on the drawing boards again in terms of my study strategy. My strategy from the last exam (although effective) just took way too long than I wanted. I’m hoping I can find a better strategy this time.

Of course, I will make another attempt to publish my study schedule on a separate page (see tabs above). I will try to be more concise and cleaner in my approach. The BSCI study schedule was a bit of a mess - I’m actually planning on updating it with some notes of my previous progress just for the benefit of those trying to compare their progress to mine.

And true to my style, I will continue the bulleted notes of my studies that you’ve been accustomed to seeing over the last year. I’m just not sure when I’m going to start publishing my notes. I want to complete the study guide cover to cover first and then maybe start my notes when I do the chapter by chapter deep dives. I haven’t quite decided on that yet.

As far as the materials I’ll be using, so far I have:

1. Building Cisco Multilayer Switched Networks (BCMSN) (Authorized Self-Study Guide) (4th Edition) by Richard Froom, Balaji Sivasubramanian, and Erum Frahim – This is going to be the primary text I’ll be using. It has some decent lab exercises at the end of each chapters similar to the ones from BSCI study guide.
2. CCNP BCMSN Official Exam Certification Guide (4th Edition) by Dave Hucaby – I bought this primarily for the practice test engine companion CD that comes with it. It has considerably fewer pages than the study guide but hopefully, it will help reinforce the topics I need to learn for exam purposes.
3. Cisco.com Documentation – This was an invaluable resource for me while studying for BSCI. I’ve printed pages upon pages of configuration guides, tech notes, white papers for individual technologies I covered. I have them all categorized and neatly compiled in 3-inch binders.
4. Dynamips/Dynagen - I’m not sure how much of it I will use but I’m going to try to get the interface from the emulated software to interface with the real switches.
5. Catalyst Switches:
   • 2 x 3550 Catalyst switches – I ordered them from Ebay and I shoud receive them any day now.
   • 3 x 2950 Catalyst switches – These are ones I’ve collected over the past year while studying for CCNA and BSCI.
   • 1 x 2924 Catalyst switch – I just bid on it on Ebay and happened to win. It was a decent price for adding a bit more complexity for lab topologies

Other things I’m considering getting, but haven’t decided on yet:

• CCNP Building Multilayer Switched Networks (BCMSN 642-812) Lab Portfolio  - I got the one for BSCI but I hardly used it.
• CBT Nuggets or Train Signal - It’ll depend how I feel about my progress during my readings. Price is also an issue.

The plan is to study 2-3 hours on the weekdays and 4-5 hours on the weekends. I’m pretty good with the weekday schedule, but the weekend schedule is pretty tough for me so I’ll see what comes of that. I’ve been tracking my study hours (using a stop watch) as well for the last few months and I find it helpful for assessing how I’m progressing. 

My goal is to attempt and pass the exam by the end of July – if not sometime in August. That gives me about 4 to 5 months. That is a tall order for me as we are expecting our second child in less than a month from now. There is no telling what my schedule is going to be like in terms of studying.

• A more significant achievement was accomplished by Brandon Carroll and gaining his digits by passing a difficult CCIE Security lab on Friday. Head over to his blog to congratulate him.
• Also, another fellow blogger passed his BSCI exam yesterday. Head over to Dani’s (aka Newton’s CCIE Pursuit blog) and leave your congratulatory comment for a huge step forward toward attaining his CCIE goals.

I STUDIED!!!

That’s right. I started studying for the BSCI just right after I passed my CCNA exam last year – that’s approximately 9 months ago. Not counting the 1.5 months that I was not studying for BSCI  due to a project at work, I studied for this test for a total of about 6 months – give or take a few.

Here’s how I did:

Implementing EIGRP operations: 88%
Implement multiarea OSPF operations: 70%
Describe integrated IS-IS: 85%
Implement Cisco IOS routing features: 80%
Implement BGP for enterprise ISP connectivity: 81%
Implement IPv6: 75%

Score needed to pass: 790
My score: 855

Obviously, it is not a perfect score. But I am extremely happy with the results given that my initial feeling just after I finished the exam was that I probably scored in the low 800s - I was hoping that at least. There was a big part of me that thought I was screwed and that I probably should think about rescheduling again. I honestly didn’t know (based on my performance during the test) whether I passed or not.

I took the test in Irvine, CA – about one hour away from where I live. There are other testing centers within 15 minutes of me but I chose this testing center because it is the only one close enough that offered exam dates on weekends. I arrived at the testing center about 10 minutes late and had to wait another 30 minutes because the room was packed. I’ve never seen that place as busy before from the last three times I’ve been there. There were usually only 4-5 people there in my previous trips. <Just got interrupted by my 3yr old: “Are you writing about routers again?’ LOL! Precious!> Normally I’m cool with distractions since I can be pretty good with blocking things out. But for some reason, it was hard for me to concentrate this time. I attributed that to nerves. For the last two weeks I hit the books really hard and was unrelenting in my studies – reviewing from 7pm – 1am. I told my wife that I felt good about this test - that I’m very confident I was going to pass. However, I started feeling the jitters and nervousness around Thursday and Friday before the test. My wife thought it was because of stress. I thought its a combination of that, lack of sleep, and an unusual high dose of caffeine over a prolonged period - something I don’t ingest on a regular basis.

I found the test extremely challenging. For someone who does not work with Cisco devices on a regular basis or does not have at least 2 or 3 years of experience with it, you will find that the exam really exposes not only your ability to memorize little bits of minutiae, but also how you use that knowledge to apply it to different kinds of scenarios that you might not necessarily see on a regular basis. That’s probably an obvious statement. But that was just the very thought that kept playing in my head over and over. Even then I started wondering how someone who works with these technologies every day would feel about the test. There were some questions that I thought might have applied to real world scenarios, and there are some that I thought were just purely theoretical and that would never be done in the real world. But then again what do I know? I just hit Ctrl-Alt-Del all day for my users.

Here are some more of my thoughts about this exam (especially for those looking to take it soon):

• There is a pretty hefty dose of multicast on this exam. If you are using the study guide by Teare and Paquet, you might find that the materials provided in the books might not be enough. I know for sure I saw some things in there that I’ve never seen on the book. Either I never saw it, or just ignored it.    Pay close attention to the details in that section. Learn to interpret the show commands. I can’t say which show commands so it’s probably in your best interest to know them all.
• Come in prepared for IPv6. I thought I did. And for the most part I think it wasn’t too bad. But there was a section where I spent a considerable amount of time tyring to figure out. I think I did. Again, I saw things on IPv6 that I thought they would not test. The way the study guide covered IPv6, I got the impression that there are things that were not going to be tested on the exam – based on the amount of coverage (or lack thereof) given to them in the book. And again I was caught surprised by it. I think I did ok on the question though.
• Coming into the test, I was most confident with IS-IS and BGP. And although I spent twice as much studying OSPF than all the others, it’s strange that I received the fewest points on it. Reading Cisco forums over the last month gave me an indication that IS-IS was one of the big three that stumped most people (multicast and IPv6 being the other 2). However, I didn’t see it that way about IS-IS. I thought it was straightforward and easy. If you read the section of the BSCI study guide thoroughly, you should do fine with IS-IS. With BGP, I supplemented it with Doyle’s Routing TCP/IP, Volume II (CCIE Professional Development).
• One surprising area I didn’t expect to do as well on (but ironically did do well) is EIGRP. That and routing update manipulation (distribute-lists, route maps) were the ones I dreaded and hoped not to see too much of on the exam. Well, I pretty much knew that I’d see a good amount of EIGRP. But I was hoping not a lot of route maps, access-lists, etc. But there is a fair amount of it, so know it. 
• It’s been said before in the forums and anyboby else who has taken the exam before: ”Time Management“. I think I managed my time just perfectly. By the time I clicked the answer on the last question, there was exactly 30 seconds left on the exam. I did spend a good 15 minutes on a couple of different sims though. But picking up from the last two tests I’ve taken, I learned not to double-read the questions and learn to scan it a little faster. Because I made myself do this, I also forced my brain to concentrate better knowing that I will only get one chance to read the question. Of course I didn’t do this technique for every question. Obviously there are some that will be worded a little bit funny and you’ll have to re-read it again. But try not to do this for every question because you’ll definitely run out of time. What I did was scan the multiple choices, read the question, then read the choices again. I made sure I only gave myself 1 minute at most to answer the questions. If you’re prepared, there will be some that’ll only take you 10 seconds before you can come up with the answer in your head before even seeing the choices. I love those types of questions.
• Be mindful of what you are clicking. I missed a lot of points on a scenario-based question when I clicked “next” question instead of clicking the button for the next section of the same question. I know I got the first one right, but I’ll never know how I would have done on the next few scenarios. So be careful. Manage your time but don’t be too careless.
• This is more of a gripe than anything: I got one sim question where no matter how many times I typed in a command, the wrong value comes up when you do a “sh run”. I know I was typing it correctly and I double, triple, quadruple, and multiple checked. I lost 5 minutes doing this over and over. I did the “no” command to delete the specific config, did a “sh run” and showed that it wasn’t there. Saved the config, and did another “sh run” to verify it was still deleted. Reconfigured again and made sure I was typing it correctly. Yup, it’s correct, alright! Did another “sh run” and a different value was showing up again from what I typed in. I was so frustrated that I wanted to click the comment button to tell Cisco what a piece $#!t the simulator was. Why can’t they just use the real IOS? Anyway, I ended up doing a ”copy start run” to restore it to the original config. That worked. I made my config and didn’t bother verifying. I was just hoping I got partial points. It’s a moot point now that I passed. But I was very frustrating and could be a difference from borderline failing or borderline passing. Hopefully those taking it in the future won’t have the same experience.  

Here’s a summary of how I prepared for the exam:

• Study materials:
• Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition).
• Bits and pieces of Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development).
• BGP section of Routing TCP/IP, Volume II (CCIE Professional Development)
• CCNP Building Scalable Internetworks Lab Portfolio - used sparingly. 

 

• Like I said earlier, I spent 6 months of cumulative studying, spread out in a span of close to 9 months. An advantage of this, obviously, is that it gave me a lot of time to let concepts sink in and become almost second nature. I don’t know if I would recommend this approach though. My original plan was for this to be a four-month thing, maybe 5 months at the most. With that said, I would go with 4-5 months if given the choice. Most people with a lot of experience can do it in 2-3 months.
• Study between 2-3 hours a day. When I started studying, I spent 1.5 hours in the morning (from 7am – 8:30pm) and about 1 to 1.5 hours at night (from 9:30 – 11pm). Sometime during the year, my schedule at work changed so that I could no longer study in the morning. So I went from about 8 – 11 or 9 -12 at night. And I did this almost everyday picking a day here and there to take a break.
• I created a study schedule which I followed as close as possible. This is very important in that it allowed me to track my progress and visualize where I need to be at certain points in the future. You need to be flexible with the schedule, however. Because I have a family, a job and other obligations in my community, I had to make sure I can track my progress closely and not stray away too far from my plans.
• I spent a lot of time labbing. Although I own a decent rack of routers and switches, it was much more convenient for me to use Dynagen/Dynamips. In fact you’ll find that all of the lab exercises that I have blogged about in the past were done using Dynamips. Every now and then I’d fire up the old routers and switches to blow off some dust and rust.
• During the past month of reviewing, I went to specific forums such as techexams.net and networking-forum.com and searched the forums for threads with “BSCI and fail” on them. I copied all the posts that had anything to do with people failing the exam and took notes on what particular areas people had trouble with. Not surprisingly, the big three that people mostly talked about were IPv6, Multicast, and IS-IS.
• Lastly, I blogged as much as I can about the things I was learning. I found this helped me slow my learning down a little bit and helped me think about the subjects in a more interactive way. 

There you go. I’m sure there’s much more I can write about but I’m tired. So hopefully the little bits of information I have can help others taking the exam – or compare their experiences with mine.   

I am so relieved that this one is out of the way – for now. It’s been nine months since I started studying for this exam and I’m glad I passed on my first attempt. Reading from various forums about the horrors and difficulties others have had passing for the first time, I was a bit wary and at the same time confident that I was going to pass. And I did!

I’ll be celebrating tonight with the family and go out on a rare dinner at a restaurant. I’ll write up my thoughts later for those of you wondering about the test, especially those gearing up to take it soon. Laters!

In the course of reading through the BSCI authorize self-study guide, I’ve come across a multicast example where the author talks about the concepts behind the multicast IP to MAC address mapping.

• In order to achieve the translation between a Layer 3 IP multicast address and Layer 2 multicast MAC address, the low-order 23 bits of the IP address (Layer 3) is mapped into the low-order 23 bits of the MAC address (Layer 2).
• The high order 4 bits of the Layer 3 IP address is fixed to 1110 to indicate the Class D address space between 224.0.0.0 through 239.255.255.255
  • Ethernet MAC addresses start with 01:00:5E, allowing for a range from 01:00:5E:00:00:00 through 01:00:5E:7F:FF:FF.
• With 32 total bits present in an IP address and 4 high order bits of it set at 1110, we are left with 28 bits of unique IP addresses we can use (32 - 4 = 28).
• But remember, 23 low-order bits out of the 28 available bits are mapped to the MAC address, giving us 5 remaining bits of overlap.
• With the 5 bits of extra overlap, there are  32 (2⁵ = 32) IP multicast address that map to one MAC multicast address.

The problem is, the book does not explain or show how it solved the mapping. So I went about researching how it was done. If you happened to be studying for BSCI, I am referring to the section of the BSCI: Authorized Self-Study Guide, by Teare and Paquet, that starts on page 598 – 600.

The following is an example of how we arrive with those 32 IP addresses that map to a single MAC address:

For reference, use the following conversion chart for converting hex to binary and vice versa

Let’s start by using the example MAC address given in the book :

01:00:5e:0a:00:01

1. Convert the hexadecimal MAC address 01:00:5e:0a:00:01 to binary
   • 0000 0001 : 0000 0000 : 0101 1110 : 0000 1010 : 0000 0000 : 0000 001
   • Here’s a breakdown of the conversion bit by bit:
     
2. Isolate the 23 low-order binary bits from the converted MAC address:
   • 0000 0001 : 0000 0000 : 0101 1110 : 0000 1010 : 0000 0000 : 0000 0001
3. Take the low order 23 bits from step 2 and plug it into the low-order 23 bits of the IP address (do this in binary):
   • 1110 xxxx : x000 1010 : 0000 0000 : 0000 0000
     • 1110 -  First 4 high-order bits of the IP address for the multicast address space (224.x.x.x).
     • xxxx x - 5 remaining bits after the 23bits of the IP address is mapped to the MAC address plus the 4 high order bits 1110. This is equal to 32 total IP addresses.
4. Convert the binary equivalent of the IP addresses to decimal, replacing the x variables with all the values to get all 32 possible IP addresses:
   • 1110 0000 : 0000 1010 : 0000 0000 : 0000 0001 = 224.10.0.1
   • 1110 0001 : 0000 1010 : 0000 0000 : 0000 0001 = 225.10.0.1
   • 1110 0010 : 0000 1010 : 0000 0000 : 0000 0001 = 226.10.0.1
   • 1110 0011 : 0000 1010 : 0000 0000 : 0000 0001 = 227.10.0.1
   • 1110 0100 : 0000 1010 : 0000 0000 : 0000 0001 = 228.10.0.1
   • 1110 0101 : 0000 1010 : 0000 0000 : 0000 0001 = 229.10.0.1
   • 1110 0110 : 0000 1010 : 0000 0000 : 0000 0001 = 230.10.0.1
   • 1110 0111 : 0000 1010 : 0000 0000 : 0000 0001 = 231.10.0.1
   • 1110 1000 : 0000 1010 : 0000 0000 : 0000 0001 = 232.10.0.1
   • 1110 1001 : 0000 1010 : 0000 0000 : 0000 0001 = 233.10.0.1
   • 1110 1010 : 0000 1010 : 0000 0000 : 0000 0001 = 234.10.0.1
   • 1110 1011 : 0000 1010 : 0000 0000 : 0000 0001 = 235.10.0.1
   • 1110 1100 : 0000 1010 : 0000 0000 : 0000 0001 = 236.10.0.1
   • 1110 1101 : 0000 1010 : 0000 0000 : 0000 0001 = 237.10.0.1
   • 1110 1110 : 0000 1010 : 0000 0000 : 0000 0001 = 238.10.0.1
   • 1110 1111 : 0000 1010 : 0000 0000 : 0000 0001 = 239.10.0.1
   • 1110 0000 : 1000 1010 : 0000 0000 : 0000 0001 = 224.10.0.1
   • 1110 0001 : 1000 1010 : 0000 0000 : 0000 0001 = 225.138.0.1
   • 1110 0010 : 1000 1010 : 0000 0000 : 0000 0001 = 226.138.0.1
   • 1110 0011 : 1000 1010 : 0000 0000 : 0000 0001 = 227.138.0.1
   • 1110 0100 : 1000 1010 : 0000 0000 : 0000 0001 = 228.138.0.1
   • 1110 0101 : 1000 1010 : 0000 0000 : 0000 0001 = 229.138.0.1
   • 1110 0110 : 1000 1010 : 0000 0000 : 0000 0001 = 230.138.0.1
   • 1110 0111 : 1000 1010 : 0000 0000 : 0000 0001 = 231.138.0.1
   • 1110 1000 : 1000 1010 : 0000 0000 : 0000 0001 = 232.138.0.1
   • 1110 1001 : 1000 1010 : 0000 0000 : 0000 0001 = 233.138.0.1
   • 1110 1010 : 1000 1010 : 0000 0000 : 0000 0001 = 234.138.0.1
   • 1110 1011 : 1000 1010 : 0000 0000 : 0000 0001 = 235.138.0.1
   • 1110 1100 : 1000 1010 : 0000 0000 : 0000 0001 = 236.138.0.1
   • 1110 1101 : 1000 1010 : 0000 0000 : 0000 0001 = 237.138.0.1
   • 1110 1110 : 1000 1010 : 0000 0000 : 0000 0001 = 238.138.0.1
   • 1110 1111 : 1000 1010 : 0000 0000 : 0000 0001 = 239.138.0.1
5. All the 32 IP addresses on step 4 map to MAC address 01:00:5e:0a:00:01

Convert IP Multicast Address to Multicast MAC Address

Conversely, a multicast IP address can be converted to its equivalent MAC address. Once you’ve figured out how to convert from Layer 2 MAC to Layer 3 IP, doing the reverse is easy.

To start, we can pick any address from the 32 IP addresses we converted above. Let’s pick a random one like 227.138.0.1

1. First convert the address 227.138.0.1 to binary:
   • 11100011 : 10001010 : 00000000 : 00000001
   • We’re only concerned with the red colored portion which represents the low-order 23bits of the IP address.
     
   • Notice that we are dropping the high order bit of the second octet.
     
2. Convert those 23 bits to hexadecimal:
   • 0A:00:01
3. We already know that the first 3-bytes (24 bits) of the MAC address is 01:00:5E. This was established earlier in the article. Simply append the result on step 2 to the first 3-bytes and you have your MAC address:
   • 01:00:5E:0A:00:01
   • *You can pick any of the 32 Ip addresses we have on the list above and you will always get 01:00:5E:0A:00:01 as your MAC address following the steps just mentioned.

To summarize:

• 1^st octet – Notice that the first octet is left alone.
• 2^nd octet – You only need to convert the last 7 bits to hex. The second octet in decimal is 138. But if you drop the highest order bit, it becomes a decimal 10 or hex 0A.
• 3^rd octet – Convert it directly to hex.
• 4^th octet – Convert it directly to hex.

I just opened my feed reader this morning to go through news, developments and fun reads and was greeted by good news about another one of our friends passing his CCIE lab exam. After all these discussions about new changes with the lab exam and how it will affect current and future lab takers, it’s good to know that this quest is not as  insurmountable as it seems. But on the same token, it speaks volumes about his skills and knowledge of the material.

Head on over to ccietobe.blogpspot.com to congratulate our new title holder. I always thought his posts were…. colorful!

I’ve been following his blog since the early part of last year. Thumb through some of his posts and experience some of his early struggles with self-doubt, an addition to the family, and work-load. It’s a nice account of persistence and hard-work paying off.

As for me, posts are on hold as I’m preparing to take my BSCI exam in a couple of weeks. But if you’re just dying to know what I’m doing and your day is not complete without me   follow me on twitter and route my world 140 characters at a time…

I just LOL’ed on that last part.

I had a basketball game last night, in a league I’ve been playing in for the last few years. I sorta got into a little elbowing match with another player. He was going after a loose ball and I “sorta” held him so that I can gain an advantage on getting the ball first. Rightfully so, the ref called a foul on me and I conceded knowing full well that I committed the infraction. The opposing player, however, did not appreciate me holding him and from then on, he made it a personal mission throughout the game to “express” his feelings towards me. Every chance he got, he tugged on my jersey (one time, so hard that it ripped a seam), elbowed me in the back whenever I posted him up, and talked trash to try to get into my head.

Of course, I returned the favor.  

The point  isn’t really about  barbarism or heroism on the court (or the field, if you like football). It really is about knowing your place at the right time and the right moment. The opposing dude and I were going at it for the duration of the game. But we also realize that this is a game. Just a game. This has nothing to do with what life is about or what the outcome of the game has to do with you in the real world – they won by the way. We may try to get the better of each other through intimidation, aggressive play, or pure skill. But in the end, we are all the same and equal.

After the game I went into the restroom to wash up and change. The same person with whom I was scuffling with just earlier entered the rest room while I was… well doing what most do when in the restroom :) After a brief moment of silence, we just started talking like we were old friends. As if nothing ever transpired between us just moments earlier.  There was no “I apologize I was a little rough out there” or “my bad for introducing my elbow to your face” or “you suck”. There was an unspoken code of conduct that we just instinctively understood.

What the hell am I talking about?

I’ve been getting a lot of opportunities to interact with different engineers (networking, Cisco, etc) in my profession with whom I hold certain admiration for – via twitter, blogs, etc. These are folks who have greater experience than I; some even CCIEs. These are people who I want to be like someday – like that 80s jingle, “I wanna be like Mike”. The more I get to interact with them the more I realize their humanness and that there is not much that separate us outside of our profession. They may be a whole lot better than I in maximizing efficient BGP routes and configuring prefix filtering. But in the real world, there is an understanding between us engineers that what you know in your profession doesn’t make you any better than the next. We all discuss things like cars, movies, the weather, etc like nothing separates us despite our paygrade or skill level. It could be intimidating to even talk to them or ask them question sometimes for fear of sounding stupid. But take away BGP, take away OSPF.. or IS-IS or anything networking… and we’re all the same scared and unsure people trying to figure out the next step.

It’s kinda like basketball.

To start, here’s the setup for the exercise:

Figure 1: A simple topology

Dynamips .net Config:

# OSPF Neighbor Exchange Lab Topology
autostart = False
ghostios = true
sparsemem = true

[localhost]

   [[7200]]
        image = \Program Files\Dynamips\images\C7200-JK.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 96
        ghostios = True

   
    [[ROUTER A]]
        Fa0/0 = B Fa0/0
        model = 7200
        console = 2001

    [[router B]]
        model = 7200
        console = 2002

Down State

Figure 2: Router A – interface added to OSPF

• When the router is enabled on the LAN, it starts in the Down state and starts sending out hello packets to multicast address 224.0.0.5.
• When in Down state, it doesn’t mean that the interface or router itself is down. It’s just that it hasn’t received any Hellos from any neighbors.
• When an interface is enabled on OSPF, it starts sending out Hello packets to multicast 224.0.0.5 as seen in the figure above.
• Notice also that after sendnig Hello packets 4 times (40 seconds) and not finding an OSPF neighbor, it takes it upon itself to elect itself as a Designated Router (DR) for that LAN segment.

Init State

• The init state indicates that a router sees HELLO packets from the neighbor, but two-way communication has not been established. A Cisco router includes the Router IDs of all neighbors in the init (or higher) state in the Neighbor field of its HELLO packets. For two-way communication to be established with a neighbor, a router also must see its own Router ID in the Neighbor field of the neighbor’s HELLO packets.

Figure 3: Router B turns on OSPF on Fa0/0

Figure 4: Router A Goes to Init State

• At 4:43:11 PM, Router B’s Fa0/0 is enabled for OSPF. Almost immediately it starts sending out Hello packets.
• Within a few tenths of a second (at 4:43:17) Router A receives a packet from Router B with its database summary.
• Router A also transitions to the Init state, indicating that although it has received something from Router B, nowhere in those packets is Router A’s Router-ID.
  • Remember, in order for the relationship two transition to the next level (two-way state), the receiver must receive a Hello from the other neighbor which contains its (Router A’s) own Router ID.
• However, aside from needing to receive its own Router-ID in the neighbor field of the neighbors Hello packet, receiving a DBD from the neighbor also puts the state into a two-way state.
  • Looking at the output in figure 4, it confirms that Router A did receive a DBD from Router B.

Two-way State

• In order to attain the 2-way state, a bi-directional communication has to be established between two routers.
  • That means that each router has seen the other’s hello packet.
• When the router receiving the hello packet sees its own Router ID in the received Hello packet’s neighbor field.

Figure 5: Router A in Two-way State

Figure 6: Router B in Two-way State

• I mentioned earlier that receiving a DBD from the neighbor puts the state in a 2Way.
• In this particular example, Router B sent Router A a DBD as soon as it came up (see figure 4) and within milliseconds, Router A went from Init state to a 2way state.

DR Election

• At the end of this state, DR and BDR elections also occur:

Figure 7: Router A – DR Election

Figure 8: Router B – DR Election

• Recall that the router with the highest OSPF priority on a segment will become the DR for that segment.
  • In this case, the OSPF priority is not modified therefore they remain tied at default value of 1.
• In case of a tie, the following Router-ID criteria is followed in order of highest priority (#1 being the best):
  1. Statically configured Router-ID using router-id command.
  2. Highest loopback interface.
  3. Highest active interface.
• In the figures above, none of the provisions just mentioned are actually used. In fact, notice that Router A is the DR despite having a lower IP address.
  • To determine why, look back at when the neighbor exchange started. On the very first figure (figure 2) Router A has established itself as the DR when there were no neighbors up at the time. A DR will not give up its status even if a new interface with a higher priority in its Hello packet comes up. So even though Router B with better priority comes up, it will not preempt the already established DR.
  • You can change this by reloading the router or if the OSPF routing process restarts.

Exstart State

• If the routers involved in the neighbor process are connected on a point-to-point link, the routers become Full after exchanging Hellos.
• On Ethernet links, after the DR and BDR election has been established, a master-slave relationship is formed.
  • The router with the higher router-id becomes the master and initiates the exchange.

Figure 9: Router B – Exstart

Figure 10: Router A – Slave

• Notice that even though Router A is the DR, it doesn’t necesarrily become the master. Remember that the DR/BDR election can take place using a higher priority configured on the router. Or in this case, because Router A was elected a DR first, despite having a lower router ID.
• Router B becomes master because it has a higher router-id regardless of who the DR is.

Exchange State

Figure 11: Router A  – Exchange

Figure 12: Router B – Exchange

• Notice in the figures above that  OSPF routers exchange database descriptor (DBD) packets as they tranisition to the Exchange state.
  • DBDs contain link-state advertisement (LSA) headers that describe the contents of the LSDB.
• Each DBD packet has a sequence number which can be incremented only by master. These
• Notice also that the routers send link-state request (LS REQ) packets. Once received the router sends link-state update packets (which contain the entire LSA) to fulfill the requested information.
• The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.

Loading State

• This is when the actual exchange of link state information happens.
• Link State requests are sent based on information provided by the DBDs -  information such as outdated or missing LSAs. The neighbor then sends the requested information back contained in Link State updates (LSUs).
  • All LSUs need to be acknowledged.

Figure 13: Router A: Loading-Full State

Figure 14: Router B: Loading-Full State

Full State

• Routers achieve Full neighbor adjacency at this state. Network and router LSAs are exchanged and router databases are fully synchronized.

If you’re interested on adding this to your wordpress blog, just follow the link: http://www.viper007bond.com/wordpress-plugins/clean-archives-reloaded/  -  the least I can do for a free plugin.

This was posted on GroupStudy a while back and got some pretty funny responses.  As if the post itself wasn’t entertaining enough, some responses were equally hilarious (follow the link to read the subsequent comments).

Subject: Another New One
From: "Hiriam Masheed Nuwalla MCSE+I" <gs@xxxxxxxxxxx>
Date: Thu, 22 Mar 2007 08:52:55 -0600

Hi Group,

I just complete my MCSE+I and now I have need for CCIE. I have joined group
because I must have CCIE in 30 days, maybe I can wait for 45 days, but no
longer. I want to finish before May starts, for I have futbol league to play
in then.  If I get the CCIE in 30 days, then maybe I try for a second in the
next 15 days. I need to get CCIE so I can make a bigger money. I hear this is
a good group for to join.

The MCSE have many more tests so I think CCIE may not be as difficult as I
hear. One day I pass two exams, one right after another for the MCSE. This is
also "Expert" level certification, just like CCIE. Some people may not know
this, but a Windows server can be setup like a router. I have done this many
times. I have very high IQ and can study sometimes 2 - 4 hours without a
break.

I see a question about a subnet mask. Is it necessary to know the subnets
other than a 255.255.255.0? I have set these networks up many times, and am
almost an expert with them. One time there were 4 of these networks all
working through a windows box, and I did this in less than 2 hours, and this
include time it take to reboot servers.

I have bought a router on ebay for to help study with. I want to use web
browser for to configure this router, but I cannot seem to get it to come up.
I use the telnet program (From a Windows Server   to log into this router but
all there is a command line. It look almost like an old DOS program. I hope
Cisco does not still emulate DOS when Windows has been around many years. This
could a big mistake for them.

If anyone need help on setting routers, let me know. I will be willing to
help. Also, it seems Cisco allow test taker to look at website during CCIE
exam. In the MCSE program there is no help available. You must not look at any
material while taking exam. I think it should be fun to have a book open
exam.

Do you think I should get a Voice CCIE, or a Security CCIE for the second CCIE
I get. I am not familiar with the differences between them? I did recently set
up Security for Microsoft Vista, so maybe Security should be the way to go.

Also I want to say to Darby. You seem like a nice man (i hope you are man, not
woman. if so i apologize). You should try for to relax a little more and take
care of your health. If you can't get CCIE this week, you will be able to get
it next week. I know sometimes you get in a hurry, but your health is more
important than passing exam this week. Just make up study on the weekend and
take exam the following week. You should trust yourself more and not spend so
much money on instructions. Do you have relationship with your instructor? You
seem very close.

One more question. What does HTH mean?

HTH,

Hiriam

ip default-network network-number

• The network-number will be announced to other routers as the last-resort gateway.
• In order for the router – where this command is configured – can consider the network as a candidate default route, the network must be reachable by this router.
• In addition, the network number in the command must also be passed to other EIGRP routers so that those routers can use this network as their default network and set their gateway of last resort to this default network. This could be:
  • An EIGRP-derived network in the routing table.
  • Generated with a static route and redistributed into EIGRP.

The following scenario is based on the example given in page 96 of the BSCI study guide.

Dynampis .net Config file:

# EIGRP ip-default network Command - page 96 Of BSCI study guide
autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        fa0/0 = B fa0/0
        s1/0 = C s1/0
        model = 7200
        console = 2001
        idlepc = #this is a system-specific setting

    [[router B]]
        model = 7200
        console = 2002
        idlepc = #this is a system-specific setting    

    [[router C]]
        model = 7200
        console = 2003
        idlepc = #this a system-specific setting

Router A Configuration:

!
interface FastEthernet0/0
 ip address 10.5.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 172.31.5.1 255.255.255.252
 serial restart-delay 0
!
!
router eigrp 1
 network 10.0.0.0
 network 172.31.0.0
 auto-summary
!
ip classless
ip default-network 172.31.0.0
!

• The command ip default-network 172.31.0.0 is configured on Router A to allow 172.31.0.0 network as a candidate default network.
• The command network 172.31.0.0 passes the network 172.31.0.0 to Router B, so that router B can use it as its default network and set its gateway of last resort to this network.

Router B configuration:

interface FastEthernet0/0
 ip address 10.5.1.3 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 1
 network 10.5.1.3 0.0.0.0
 auto-summary
!
ip classless
!

Router C configuration:

!
interface Serial1/0
 ip address 172.31.5.2 255.255.255.252
 serial restart-delay 0
!
router eigrp 1
  network 172.31.0.0
 auto-summary
!
ip classless

Router B: IP routing table:

B# sh ip route

Gateway of last resort is 10.5.1.1 to network 172.31.0.0

D*   172.31.0.0/16 [90/2172416] via 10.5.1.1, 00:10:38, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.5.1.0 is directly connected, FastEthernet0/0

• The EIGRP-learned 172.31.0.0 network is marked as a candiate default network indicated by the * in the routing table.
• The gateway of last resort is also set to 10.5.1.1 (Router A) to reach the default network 172.31.0.0.

Router A: IP routing table

A(config)#do sh ip route

Gateway of last resort is 0.0.0.0 to network 172.31.0.0

 *   172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
D*      172.31.0.0/16 is a summary, 00:12:27, Null0
C       172.31.5.0/30 is directly connected, Serial1/0
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:12:27, Null0
C       10.5.1.0/24 is directly connected, FastEthernet0/0

• In earlier versions of IOS, the router on which the ip default-network command was configured would not set the gateway of last resort.
• As highlighted above, it now sets the gateway of last resort to 0.0.0.0, to the network specified – 172.31.0.0.

no auto-summary

• OSPF and IS-IS RIP and EIGRP perform automatic network summarization by default.

Example:

• The diagram above shows a RIPv2 network where autosummarization occurs.

Dynamips .net Configuration:

autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = \Program Files\Dynamips\images\c7200-js-mz.124-3\C7200-JS.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        S1/0 = B s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router B]]
        s1/1 = C s1/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router C]]
        model = 7200
        console = 2003
        idlepc = 0x607016a0

Router A Config:

!
interface FastEthernet0/0
 ip address 172.16.2.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 172.16.1.1 255.255.255.0
 serial restart-delay 0
!
router rip
 version 2
 network 172.16.0.0

Router B Config:

!
interface Serial1/0
 ip address 172.16.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial1/1
 ip address 192.168.5.2 255.255.255.0
 serial restart-delay 0
!
router rip
 version 2
 network 172.16.0.0
 network 192.168.5.0
!

Router C Config:

!
interface Serial1/0
ip address 192.168.5.1 255.255.255.0
serial restart-delay 0
!
router rip
version 2
network 192.168.5.0
!

• In the RIPv2 network above, Router B performs a defualt behavior of automatically summarizing the 172.16.1.0/24 and 172.16.2.0/24 networks learned from B’s connected subnet and A’s advertised subnet.

C# sh ip route
Gateway of last resort is not set

R    172.16.0.0/16 [120/1] via 192.168.5.2, 00:00:05, Serial1/0
C    192.168.5.0/24 is directly connected, Serial1/0

• In Router C’s routing table, notice that it, indeed, learns of a summarized route from it’s neighbor 192.168.5.2, which is Router B.
• A simple no auto-summary command on Router B, changes the routing table on Router C.

B(config)#router rip
B(config-router)#no auto-summary

• Now looking at Router C’s IP routing table, we see:

C# sh ip route
Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
R       172.16.0.0/16 [120/1] via 192.168.5.2, 00:00:29, Serial1/0
R       172.16.1.0/24 [120/1] via 192.168.5.2, 00:00:00, Serial1/0
R       172.16.2.0/24 [120/2] via 192.168.5.2, 00:00:00, Serial1/0
C    192.168.5.0/24 is directly connected, Serial1/0

• Notice now that both 172.16.1.0/24 and 172.16.2.0/24 networks are advertised with both prefix and subnet mask.

• Classful routing protocols do not include subnet mask information in their routing updates.
• A router sends the entire subnet address when an update packet involves a subnet of the same classful network as the IP address of the transmitting interface.
• If sending an update about a subnet of a network across an interface belonging to a different network, the router will send the classful summary route. This is called autosummarization across the network boundary.

Example:

Dynagen configuration:

autostart = False
ghostios = true
sparsemem = true

[localhost]

[[7200]]
image = C7200.BIN
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
npe = npe-400
ram = 160

[[ROUTER A]]
S1/0 = B s1/0
model = 7200
console = 2001
idlepc = 0x6082d7a0

[[router B]]
s1/1 = C s1/0
model = 7200
console = 2002
idlepc = 0x607016a0

[[router C]]
model = 7200
console = 2003
idlepc = 0x607016a0

Router A Config:

interface FastEthernet0/0
 ip address 10.1.0.1 255.255.0.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 10.2.0.1 255.255.0.0
 serial restart-delay 0
!
router rip
 network 10.0.0.0
!
ip classless

Router B Config:

interface FastEthernet0/0
 no ip address
 shutdown
 duplex half
!
interface Serial1/0
 ip address 10.2.0.2 255.255.0.0
 serial restart-delay 0
!
interface Serial1/1
 ip address 172.16.2.2 255.255.255.0
 serial restart-delay 0
!
router rip
 network 10.0.0.0
 network 172.16.0.0
!
ip classless

Router C Config:

interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
 duplex half
 no keepalive
!
interface Serial1/0
 ip address 172.16.2.1 255.255.255.0
 serial restart-delay 0
!
router rip
 network 172.16.0.0
!
ip classless

Router B: show ip route
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 2 subnets
R       172.16.1.0 [120/1] via 172.16.2.1, 00:00:20, Serial1/1
C       172.16.2.0 is directly connected, Serial1/1
     10.0.0.0/16 is subnetted, 2 subnets
C       10.2.0.0 is directly connected, Serial1/0
R       10.1.0.0 [120/1] via 10.2.0.1, 00:00:21, Serial1/0

• In the output above, Router A advertises the 10.1.0.0 subnet to router B because the interface connecting them belongs to the same major classful 10.0.0.0 network. When router B receives the update packet, it assumes that the 10.1.0.0 subnet uses the same 16-bit mask as the one used on its 10.2.0.0 subnet.
• Similarly, Router C advertises the 172.16.1.0 subnet to router B because the interface connecting them belongs to the same major classful 172.16.0.0 network. Therefore, router B’s routing table has information about all the subnets that are in use in the network.

Router A: show ip route
Gateway of last resort is not set

R    172.16.0.0/16 [120/1] via 10.2.0.2, 00:00:16, Serial1/0
     10.0.0.0/16 is subnetted, 2 subnets
C       10.2.0.0 is directly connected, Serial1/0
C       10.1.0.0 is directly connected, FastEthernet0/0

• In the output above however, router B summarizes the 172.16.1.0 and 172.16.2.0 subnets to 172.16.0.0 before sending them to router A. Therefore, router A’s routing table contains summary information about only the 172.16.0.0 network.

Router C: show ip route
Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
C       172.16.2.0 is directly connected, Serial1/0
R    10.0.0.0/8 [120/1] via 172.16.2.2, 00:00:02, Serial1/0 

• Similarly above, router B summarizes the 10.1.0.0 and 10.2.0.0 subnets to 10.0.0.0 before sending the routing information to router C. This summarization occurs because the update crosses a major network boundary. The update goes from a subnet of network 10.0.0.0, subnet 10.2.0.0, to a subnet of another major network, network 172.16.0.0. Router C’s routing table contains summary information about only the 10.0.0.0 network.

• Applicable in a hub-and-spoke topology only.
• Uses Cisco Discovery Protocol (CDP)
  • Sent as multicast
  • Sent every 60 seconds by default
    • cdp timer adjusts the timer.
  • Enabled by default.
  • Except ATM where CDP must be explicitly enabled.
• Configured on hub router
  • router odr global configuration command.
• Stub router can’t have an IP routing protocol. In fact, no IP routing protocol is considered a stub by ODR.
• WAN links such as dialer links and Frame Relay, use broadcast keyword in mapping statements.

Example:

autostart = False
ghostios = true
sparsemem = true

[localhost]

    [[7200]]
        image = C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER A]]
        S1/0 = B s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router B]]
        s1/1 = C s1/0
        s1/2 = D s1/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router C]]
        model = 7200
        console = 2003
        idlepc = 0x607016a0

    [[router D]]
        model = 7200
        console = 2004
        idlepc = 0x607016a0

Here’s the configs:

Router B (Hub Router):

interface Loopback0
 ip address 10.4.1.1 255.255.255.255
!
interface Serial1/0
 ip address 10.1.1.1 255.255.255.252
 serial restart-delay 0
!
interface Serial1/1
 ip address 10.2.2.1 255.255.255.252
 serial restart-delay 0
!
interface Serial1/2
 ip address 10.3.3.1 255.255.255.252
 serial restart-delay 0

Router A:

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface Serial1/0
 ip address 10.1.1.2 255.255.255.252
 serial restart-delay 0

Router C:

interface Loopback0
 ip address 172.16.2.1 255.255.255.0
!
interface Serial1/0
 ip address 10.2.2.2 255.255.255.252
 serial restart-delay 0
!

Router D:

interface Loopback0
 ip address 172.16.3.1 255.255.255.0
!
interface Serial1/0
 ip address 10.3.3.2 255.255.255.252
 serial restart-delay 0
!

• As soon as ODR is configured and running, routes from the stub routers are identified in the hub router’s routing table with an o character (shown below)
• Notice in the example that the metric is 1, and the administrative distance for ODR is 160.
• Also, do not confuse the o character of ODR routes with the O character of OSPF routes.

B#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 3 subnets
o       172.16.1.0 [160/1] via 10.1.1.2, 00:00:56, Serial1/0
o       172.16.2.0 [160/1] via 10.2.2.2, 00:00:54, Serial1/1
o       172.16.3.0 [160/1] via 10.3.3.2, 00:00:55, Serial1/2
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.3.3.0/30 is directly connected, Serial1/2
C       10.2.2.0/30 is directly connected, Serial1/1
C       10.1.1.0/30 is directly connected, Serial1/0
C       10.4.1.1/32 is directly connected, Loopback0

After reading Greg Ferro’s tips on study methods yesterday, I was motivated to follow some of his suggestions. Last night I spent a good two and a half hours of solid studying – no TVs, no music, no IMs, no Internet (except when I had to look up things on the Doc pages). It worked for that time. Hopefully I can keep up this type of intensity for the next month.   In fact, in addition to the no-ADD-inducing-activites he mentioned, I even used a stopwatch to time my study sessions. I’ve done it before and even wrote about it in my previous posts. The challenge is to consistently improve on those study skills. I’m also considering picking up one of the iPod flahscard apps, similar to the one he mentioned on his post.

For the remaining of this week, I plan to get through the static routing and RIP portion of the materials and hopefully get started on EIGRP on the weekend. I’ve already finished my third time reading throught chapter 2 (with notes). I’ll hopefully be able to get through a couple of nights of labbing – or maybe one, since I have the impression that this part is not covered as deeply on the exam compared to the other protocols. I may also decide to create a high-level overview of my study schedule that I can follow – and also post on my BSCI study schedule page, which I regretfully neglected. Why? It turns my BSCI study schedule page is the most visited page on my site – 300 hits on that one page for the last 2 months. And regretfully it has been my most negelected. I’ve actually received many emails (ok, just two) asking me to update it. Sorry guys if I was such a disappointment.

Anyway, anybody have experience with Boson test engines vs Transcender for CCNP? I’m considering getting one of those.

Figure 1: IPv6 Addressing Configuration Exercise Topology

Task 1: Configure IPv6 globally on the routers and configure addresses on all interfaces.

• Use the following chart to configure the parameters:

• Dynamips/Dynagen .net configuration for the proceeding lab excercise.

[localhost]

    [[7200]]
        image = \\\\C7200.BIN
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        npe = npe-400
        ram = 160

    [[ROUTER P1R1]]
        Fa0/0 = P1R3 Fa0/0
        S1/0 = P1R2 s1/0
        model = 7200
        console = 2001
        idlepc = 0x6082d7a0

    [[router P1R2]]
        Fa0/0 = P1R4 Fa0/0
        model = 7200
        console = 2002
        idlepc = 0x607016a0

    [[router P1R3]]
        s1/0 = P1R4 s1/0
        model = 7200
        console = 2003
        idlepc = 0x607016a0

    [[router P1R4]]
        model = 7200
        console = 2004
        idlepc = 0x607016a0

Configure the following on all routers:

• Enable IPv6.
• Enable CEFv6.
• Configure IPv6 global address on all fa0/0 and s1/0 interfaces.

Here is an example of the configuration for P1R1

Figure 2: P1R1 Configuration

• IPv6 is enabled by configure the ipv6 unicast-routing global configuration command.
• Enable CEFv6 by configuring the ipv6 cef global configuration command.
  • This enables Cisco Express Forwarding (CEF) for IPv6, which is a Layer 3 IP switching technology for the forwarding of IPv6 packets. When CEFv6 is enabled, network entries that are added, removed, or modified in the IPv6 Routing Inforamtion Base (RIB), as dictated by the routing protocol in use, are reflected in the Forwarding Information Bases (FIBs), and the IPv6 adjacency tables maintain Layer 2 next-hop addresses for all entries that are in each FIB.
• Use the ipv6 address address/prefix-length [eui-64] interface configuration command.
  • The eui-64 paramater forces the router to complete the addresses’ low-order 64-bits using an EUI-64 format interface ID.

Verify that IPv6 has been configured on interface fa0/0:

Figures 3 & 4: Output of sh ipv6 interface command:

• Notice the highlighted link-local address that was automatically configured on the interfaces.
• Also notice the addresses that have been configured with the ipv6 address command, with the specified prefix and interface ID in EUI-64 format.

Task 2: Enable OSPF on all routers.

• Enable IPv6 OSPF on each router.
• Configure the router ID for each router, based on the chart above.
• Enable IPv6 OSPF in area 0 on all enabled FastEthernet and Serial interfaces.

Figure 5: IPv6 OSPF Configuration on P1R4

• Use the ipv6 router ospf process-id global configuration command to enable OSPFv3.
• A router ID must be configured using router-id router-id router configuration command.
• Use the ipv6 ospf process-id area area-id [instance instance-id] interface configuration command to enable OSPF for IPv6 on an interface.
  • The network area command used in OSPFv2 is not used in OSPFv3. Rather, interfaces are directly configured to specify which IPv6 networks are part of the OSPFv3 network.

Verification

Figure 6: Show IPv6 OSPF Interface

• The figure above shows IPv6 is enabled on all interfaces, with process ID 100 in area 0.

Figure 7: Show Ipv6 OSPF Neighbor

• Shows both neighbors of router P1R4.

Figure 8: Show IPv6 Route

• Displays the IPv6 routing table.

I’ve been finishing up some lab exercises the last few days. Today was specially hard studying because my body is just aching from soreness all over. We just started our basketball league with old friends whom I’ve been ballin with for the last few years. It’s good way for me to keep in shape since, with all the studying I do, that really is the only physical activity I get to involve myself in. I’m hoping that in the next few weeks, I’ll get in better shape, which in turn will help with my stamina specially in those long study hours.  Ultimately, I’ll need all that stamina when the new baby arrives.

What time is it?

• Unicast
  • A packet sent to a unicast address is delivered to the interface identified by that address.
  • There are two defined types of unicast addresses:
    • Global Unicast
    • Link-Local Unicast
    • Site-Local Unicast, is a unicast type that has been deprecated (RFC 3879)
  • The IPv6 unicast address space encompasses the entire IPv6 address range, with the exception of the FFoo::/8 range, which is used for multicast addresses.
• Anycast
  • A new type of address that is assigned to a set of interfaces on different devices; identifies multiple interfaces.
  • A packet sent to an anycast address goes to the closest interface identified by the anycast address. The closest interfaces is determined by the routing protocol’ measure of distance.
  • Example: unicast address can be use for load balancing and content delivery services.
  • Anycast address syntax are indistinguishable from gloabl unicast addresses because anycast addresses are allocated from the global unicast address space.
• Multicast
  • Also assigned to a set of interfaces on a different node.
  • A packet sent to a multicast address is delivered to all interfaces identified by that address.

Broadcast Address

• There are no broadcast addresses in IPv6. Broadcasts are replaced by multicasts and anycasts.
• Mulitcast prevents most problems that occur with broadcast; such as broadcast storms in IPv4.

IPv6 Addressing Model

• All types of IPv6 addresses are assigned to interfaces, not nodes.
• An IPv6 unicast address refers to a single interface.
  • Since each interface belongs to a certain node, any interface on that node can be used with a unicast address as an identifier for that node.
• A single interface may be assinge multiple IPv6 addresses of any type (unicast, anycast, multicast).
• Every IPv6-enabled  interface must contain:
  • At least one loopback (::1/128).
  • and one local-link address.
• Optionally, a single interface may have multiple unique local and global addresses.

IPv6 Address Representation

• IPv6 addresses are written as hexadecimal numbers with colons between each set of four hexadecimal digits.
  • Each hexadecimal field is 16 bits.
• The format is:
  • x:x:x:x:x:x:x:x, where ‘x‘ is a 16-bit hexadecimal field.
  • This format is sometimes called “coloned hex” format.
• Following is an example address:

2035:0001:2BC5:0000:0000:087C:0000:0000A

There are 2 rules that apply to IPv6 address syntax to shorten the notation:

1. Any number of successive 0s (zeros) can be replaced with a pair of colons (::), once within an address.
   • A pair of colons can only be used once because an address parser identifies the number of missing 0s by separating the two parts and entering 0 until the 128 bits are complete. If two :: notations were used, there would be no way to identify the size of each block of 0s.
2. Leading 0s within each set of four hexadecimal digits can be omittted.
   • It is not necessary to write the leading 0s in an individual field, but there must be at least one numeral in every field, except for the case of the first rule where the successive 0s are replaced by “::“.

The address in the example above can be shortened as:

2035:1:2BC5::87C:0:A

IPv6 Address Interface Identifiers

• Interface Identifiers in IPv6 unicast addresses are used to identify unique interfaces on a link.
• They may be also be thought of as the “host portion” of an IPv6 address.
• Interface IDs are required to be unique within a link/subnet prefix.
  • They may also be unique over a broader scope.
  • The same interface ID may be used on multiple interfaces on a single node, provided that they are attached to different subnets.
• Interface IDs may be derived from their interface’s link layer address (MAC address). If so the scope of that ID is assumed to be universal (global).
• Note the uniqueness of interface identifiers is independent of the uniqueness of IPv6.
  • For example, a global unicast address may be created with a local scope interface identifier and a link-local address may be created with a universal scope interface identifier.
• Interface identifiers are always 64 bits and are dynamically created based on Layer 2 media and encapsulation.
• The most common type of Layer 2 address is the IEEE 802 MAC address used in Ethernet.
  • MAC addresses are 48 bits divided into two 24-bit blocks:
    • The upper 24 bits are called Organizationally Unique Identifier (OUI). Different organization have their preassigned OUI
    • The lower 24 bits are used as unique identifiers for the specific vendor hardware device.
  • Interface IDs are constructed in the EUI-64 format, based on the 48-bit MAC address and inserting the 16-bit FF:EE between the upper 3 bytes (upper 24 bits) and the lower 3 bytes (lower 24 bits.
    • The seventh bit in the high order byte of the resulting interface ID is set to binary 1 to indicate the uniqueness of the interface ID.
    • The seventh bit is refered to as the Universal/Local (U/L) bit.
    • This bit identifies whether this interface is locally unique on the link or whether it is universally unique.

• The following shows the process of converting to EUI-64:
  • Focusing on the upper above, you take the first 3 bytes (OUI portion) of the Ethernet address and arrange it to the left of the interface ID.
  • The lower 3 bytes (vendor code) is arranged to the right of the interface ID.
  • Right in the middle, insert the 16-bit hexadecimal of FF:EE (or 1111 1111:1111 1110 in binary).
• To convert to Modified EUI-64:
  • Change the 7^th bit of the first byte (the U/L bit) from 0 to 1.
  • The eighth bit in an IPv6 interface identifier, also known as the “G” bit, is the group/individual bit for managing groups.

IPv6 Global Unicast Address

• The IPv6 global aggregatable unicast address, aka the IPv6 global unicast address is the equivalent of the IPv4 global unicast address.
• A global unicast address is an IPv6 address from the global unicast prefix.
• The global unicast address typically consists of:
  • A 48-bit global routing prefix,
  • A 16-bit subnet ID or Site-Level Aggregator (SLA),
  • And a 64-bit interaface ID (typically in EUI-64 bit format).

• Except for addresses that start with 000, all global unicast addresses have a 64-bit interface ID
• Addresses with prefix of 2000::/3 (binary 001)through E000::/3 (binary 111), excluding the FF00::/8 (binary 1111 1111) multicast addrsses, are required to have a 64-bit EUI-64 address format.
  • The IANA allocates the IPv6 space in the range of 2001::/16 to the registries.
• A 16-bit subnet field called the subnet ID could be used by inidividual organizations to create their own local addressing hierarchy and to identify subnets. A subnet ID is similar to a subnet in IPv4, except that an organization with an IPv6 subnet ID can support up to 65,535 individual subnets.

IPv6 Link-Local Unicast Address

• Link-local addresses have a scope limited to the local link. They refer only to a particular physical link/network.
• They are typically used for special purposes such as address resolution or neighbor discovery. The equivalent IPv4 address is the 169.254.0.0/16 auto-configured address when no DHCP is available.
• They are dynamically created on all IPv6 interfaces by using a specific link-local prefix FE80::/10 and a 64-bit interface identifier.

• Nodes on a local link can use link-local addresses to communicate. The nodes do not need globally unique addresses to communicate.
• IPv6 routers must not forward packets that have link local source and destination addresses to other links.

IPv6 Anycast Addresses

• An IPv6 address is a global unique address that is assigned to more than one interface.
• A packet sent to an anycast address is delivered to the closest interface – as defined by the routing protocols in use – identified by the anycast address.
• Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats.
  • Essential, anycast addresses are same unicast addresses assigned to more than one interface.
  • The nodes to which the addresses are assigned must be explicitly configured to know that it is an anycast address.
• An anycast address must not be used as the source address of an IPv6 packet.
• An anycast address must not be assigned to an IPv6 host – only assign to IPv6 routers.

IPv6 Multicast Addresses

• Mulitcast addresses are defined by the prefix FF00::/8.
  • The first octet consists binary 1111 1111.
  • The next octet consists of the Flag and Scope parameters.

• The Flag parameter consist of 4 bits. Each bit is defined as follows:
  • Bit 1 = 0; reserved
  • Bit 2 = R flag; Rendezvous Point flag
  • Bit 3 = P flag; Indicates if address is based on unicast prefix.
  • Bit 4 = T flag; 0 if address is permanent; 1 if temporary.
• The Scope parameter is a 4 bit scope, with values as follows:
  • 1 = Interface-Local scope
  • 2 = Link-Local scope
  • 4 = Admin-Local scope
  • 5 = Site-Local scope
  • 8 = Organization-Local scope
  • E = Global scope
  • An example, FF02::/16 is a permanent multicast address with a link-local scope.
    • Binary is: 1111 1111 0000 0010
    • The second to the last bit (= 2) indicates a Link-local scope.
    • The 0 in the T Flag indicates it is permanent.
• The multicast address FF00:: to FF0F:: have the “T” flag set to 0 and are reserved. Some common examples of the assigned addresses are:
  • FFO2::1 – All nodes on a link (link-local scope)
  • FF02::2 – All routers on a link
  • FF02::5 – All OSPFv3 routers
  • FF02::6 – All OSPFv3 DR routers
  • FF02::9 – All RIP routers on a link
  • FF02::1:FFXX:XXXX – Solicited-node multicast on a link, where XX:XXXX is the rightmost 24 bits of the corresponding unicast or anycast address of the node. This is similar to ARP in IPv4.

• The multicast Group ID consists of the lower 112 bits of the multicast address.

Resources:

1. RFC 4291: IP version 6 Addressing Architecture
2. TCP/IP Guide – IPv6 Identifiers and Physical Address Mapping
3. RFC 3587: IPv6 Global Unicast Address Format
4. IPv6 Addressing at a Glance – Cisco Technology Whitepapers
5. IPv6 Multicast at a Glance – Cisco Technology Whitepapers

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; as well as following the links on the resources section of this entry.

I couldn’t help but feel like I’m so far away from my goal and it almost seems so easy to just give up. Reading about some of the stories of the latest CCIE candidates who have passed their exams, both in the blog world and the forums, is ironically, both inspiring and exhausting. Inspiring in a way that it motivates me to just want to hit the books even harder and exhausting in a way that I know there is so much work to be done and I’m barely scratching the surface. But at this moment in time, right now, it feels like it’s so tiring to just think about this whole quest (might have something to do with the fact that I had another long day at work today, my son is sick and being a little un-cooperative this evening, and it’s almost 1am).

It’s funny because just the past few days, as I was reading/posting about some of the few CCIE examinees that just passed, I was pretty motivated and uplifted. Reading about their struggles and accomplishments re-invigorated my desire. And my desire was turning into pure motivation. I guess somehow my ever-expanding tendency for instant gratification (from instant answers from google and up-to-the-minute updates on everything in my newsfeeds ) is skewing the reality that attaining something of value can’t be had that easily; that because I want something so bad and can’t have it as quickly as I would like is screwing  with the reality that I’m know – the reality of instant answers and instant updates.

Or maybe I just need to go to sleep…

RFC 1925
Network Working Group                                  R. Callon, Editor
Request for Comments: 1925                                          IOOF
Category: Informational                                     1 April 1996

                      
The Twelve Networking Truths



Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo documents the fundamental truths of networking for the
   Internet community. This memo does not specify a standard, except in
   the sense that all standards must implicitly follow the fundamental
   truths.

Acknowledgements

   The truths described in this memo result from extensive study over an
   extended period of time by many people, some of whom did not intend
   to contribute to this work. The editor merely has collected these
   truths, and would like to thank the networking community for
   originally illuminating these truths.


. Introduction



   This Request for Comments (RFC) provides information about the
   fundamental truths underlying all networking. These truths apply to
   networking in general, and are not limited to TCP/IP, the Internet,
   or any other subset of the networking community.


. The Fundamental Truths



   (1)  It Has To Work.

   (2)  No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

        (2a) (corollary). No matter how hard you try, you can't make a
             baby in much less than 9 months. Trying to speed this up
             *might* make it slower, but it won't make it happen any
             quicker.

Callon                       Informational                      [Page 1]

 
RFC 1925            Fundamental Truths of Networking        1 April 1996

   (3)  With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

   (4)  Some things in life can never be fully appreciated nor
        understood unless experienced firsthand. Some things in
        networking can never be fully understood by someone who neither
        builds commercial networking equipment nor runs an operational
        network.

   (5)  It is always possible to aglutenate multiple separate problems
        into a single complex interdependent solution. In most cases
        this is a bad idea.

   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection.

   (7)  It is always something

        (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
            have all three).

   (8)  It is more complicated than you think.

   (9)  For all resources, whatever it is, you need more.

       (9a) (corollary) Every networking problem always takes longer to
            solve than it seems like it should.

   (10) One size never fits all.

   (11) Every old idea will be proposed again with a different name and
        a different presentation, regardless of whether it works.

        (11a) (corollary). See rule 6a.

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

Callon                       Informational                      [Page 2]

 
RFC 1925            Fundamental Truths of Networking        1 April 1996

Security Considerations

   This RFC raises no security issues. However, security protocols are
   subject to the fundamental networking truths.

References

   The references have been deleted in order to protect the guilty and
   avoid enriching the lawyers.

Author's Address

   Ross Callon
   Internet Order of Old Farts
   c/o Bay Networks
   3 Federal Street
   Billerica, MA  01821

   Phone: 508-436-3936
   EMail: rcallon@baynetworks.com

He is the 3rd contributor for ccciecandidate.com to pass the CCIE lab on his first attempt. It started with Ethan Banks, followed by Keith Tokash, and just recently Carl Burkland. There certainly is an enviable pattern of success going on over there.

So to all my faithful readers, this is my last post on this blog. I’ll be heading over to cciecandidate.com and be a mainstay on that site.

Just kidding!

IPv6 Address Space

• IPcv6 increases the  number of address bits by a factor of 4 – from 32 bits to 128 bits.
• With 32 bits, IPv4 allows for 4,294,967,296 addresses – about 2 billion are usable.
• With 128 bits, IPv6 allows for approximately 3.4 x 10³⁸.
  • Note, however, that increasing the number of bits for the address also increased the IPv6 header size.
  • The header fields that contain the IPv6 address is 256 bits (source and destination bits combined) in size. Compare that to 64 bits in IPv4 (32bit-source address + 32bit-destination address).

IPv6 Packet Header

• The IPv6 headers has 40 octets, compared to the 20 octets in IPv4 header.
• IPv6 has fewer fields, and the header is 64-bit aligned to enable fast, efficient, hardware-based processing.
• The IPv6 address fields are four times larger than in IPv4.
• The following illustration compares the IPv4 and IPv6 headers:

• Note that the IPv6 (main) header displayed above is an illustration of the basic structure of the header,  differentiated from “IPv6 extension headers” to be described shortly.
• Notice that although IPv6 has increased its address size (source & destination fields) by 4 times, the main header is designed for a more  simplified format.
• One of the important changes is the absence of familiar fields from the previous IP version such as:
  • Internet Header Length (IHL)
  • Service Type
  • Identification
  • Flags
  • Fragment Offset
  • Header Checksum
  • Options and Padding
• The following describes the various fields in the new IPv6 header:
  • [4-bit] Version
    
    • Bit size the same as IPv4.
    • The value of this field is 6, to describe version 6.
  • [8-bit] Traffic Class
    • Similar to Type of Service (ToS) in IPv4. Functionality is the same between the two versions.
    • This field used to represent the priority (read QoS) by which packets are delivered.
  • [20-bit] Flow Label
    • New for IPv6.
    • Used by the source of the packet to tag the packet as being part of a specific flow. For example, a packet’s sender can specify a series of packets, say VoIP packets, as a flow. It can then request particular service for this flow.
    • This mechanism allows multilayer switches and routers to hand traffic on a per-flow basis rather than per-packet, for faster packet-switching perfomance.
    • Can also be used for QoS.
  • [16-bit] Payload length
    • Replaces the Total Length field present in the IPv4 header.
    • As opposed to the IPv4 where it measures the total length of the whole packet, in IPv6 it only measures the number of bytes of payload. In other words, it measures the whole packet minus the 40 bytes of the main header.
  • [8-bit] Next Header
    • Similar to the protocol field in the IPv4 header.
    • It can be a trasnport-layer packet, such as TCP or UDP, or it can be an extension header.
    • It has two uses:
      1. If the datagram has extension headers, this field specifies the identity of the first extension header (which is the next header in the diagram).
      2. If it’s just the main header and no extension headers, it serves the same purpose as the old IPv4 protocol and has the same values.
  • [8-bit] Hop Limit
    • This is similar to the TTL field in the IPv4 header -  a more appropriate name since the TTL is really more about the number of hops than a measure of time.
    • Each router decreases this field by one, just like in IPv4.
    • Because there is no checksum in the IPv6 header, an IPv6 router can decrease the field without recomputing the checksum. Recomputation costs processing time.
    • If this field ever reaches 0, a message is sent back to the source of the packet and the packet is discarded.
  • [128-bit] Source Address
    • The originator of the packet.
  • [128-bit] Destination Address
    • The intended recipient of the packet.
  • The basic IPv6 header consists of 320 bits, or 40 bytes, or 40 octets.
  • Extension Headers
    • These are optional information that are placed between the IPv6 header and the upper layer header in a packet. They are discussed below.
• The most significant deletion in IPv6 is the IPv4 header checksum field. Because link-layer technologies perform checksum and error control and are considered relatively reliable, an IP header checksum is considered redundant.
  • Without the IP header checksum, upper-layer checksums, such as UDP, are mandatory with IPv6.

IPv6 Extension Headers

• IPv6 extension headers follow the main header and preced the protocol header and the payload fields in IPv6 packets.
• The Next Header field indentifies the type of header following the main IPv6 header.
• These fields are used for special purposes  to provide flexibility. They are only added when they are needed.
  • By having these fields, they are only attached when there is a need for it, and they are not used when not needed. This allows the main header to remain small when the extension headers are not required for any special purposes.
• Generally, extension headers are not examined or processed by any node other than the node to which packet is destined.
  • The one exception is the hop-by-hop options header, which must be examined and processed by every node along a packet’s delivery path, including the source and destination nodes
• The following is a list (in order) and description of the functions of each extension headers, following the main IPv6 header:
  • Hop-by-hop Options Header
    • When used, this header is processed by every node it passess.
    • Identified by a Next Header value of 0 in the IP6 header.
    • Example uses are for a Router Alert, including for Resource Reservation Protocol (RSVP) and Multicast Listener Discovery (MLD) messages.
  • Destination Options Header
    • Used to carry information that need to be examined only by the node where packet is destined.
      • Or each destination specified by a routing header.
    • Identified by a Next Header value of 60 in the IPv6 header.
    • They follow any hop-by-hop option headers.
    • Alternatively, it can follow any Encapsulating Security Payload (ESP) header, in which case the destination options header is processed only at the final destination.
    • An example where this can be used is Mobile IPV6.
  • Routing Header
    • Used by an IPv6 source to list one or more intermediate nodes to be “visited” on the way to a packet’s destination.
    • Identified by a Next Header value of 43.
  • Fragment Header
    • Used by an IPv6 source to fragment a packet that is larger the maximum transmission unit (MTU) for the path between itself and a destination device.
      • Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along the packet’s path.
      • To send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment as a separate packet. The receiver re-assembles the packet.
      • The fragment header is used in each fragmented packet.
    • Identified by a Next Header value of 44.
  • Authentication Header and Encapsulating Payload Header
    • Next Header values:
      • AH = 51
      • ESP = 50
    • Used within IPSec to provide authentication, integrity, and confidentiality of a packet.
    • Identical for both IPv4 and IPv6.
  • Upper Layer header
    • Typical headers used inside a packet to transport data.
    • Two main protocols (with Next Header values) are:
      • TCP = 6
      • UDP = 17

MTU Discovery

• In IPv6, upper layers are encouraged to avoid sending messages that require fragmentation.
• IPv6 routers no longer perform fragmentation. Only the source can now do fragmentation; nor routers.
• Since routers cannot fragment datagrams, a feedback process has been defined using ICMPv6 that lets routers tell source devices that they are using datagrams that are too large for the route.
  • In this process, source IPv6 devices attempt to send packet at the size specified by upper IP layers, such as transport and application layers.
  • If the device receives an ICMPv6 “packet too big” message, it retransmits the MTU discover packet with a smaller MTU. This process is repeated until the device receives a response that the discover packet arrived intact. The device then sets the MTU for the session.
• IPv6 has a minimum size of  1280 bytes. In IPv4, routers and physical links were required to handle a minimum MTU size of 576 bytes.

Resources:

1. RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
2. TCP/IP Guide.com – Internet Protocol version 6
3. RFC 1981: Path MTU Discovery for IP version 6
4. RFC 4302: IP Authentication Header
5. RFC 4303: IP Encapsulating Security Payload (ESP)
6. IPv6 Headers at a Glance – Cisco Technology Whitepapers

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; as well as following the links on the resources section of this entry.

1. Cisco Expert Blog Ricardo Martins CCIE# 23373 R&S -
2. joshatterbury.com – CCIE # 23347 R&S

So I spoke with 3 different Pearson/Vue people and the verdict is in:  2-1 in favor of “yes”, you can take advantage of the Come Back 2009 promotion (very similar to the secondchance promotion from a while back) even if you are not re-certifying:

Here’s the official announcement from Pearson/Vue website:

“Come Back 2009” Promotion

Here’s how to redeem your Cisco “Come Back 2009” Exam:

Register for an exam at full price. If you fail the exam, you may schedule a free retake of the same exam by entering the promotion code: COMEBACK2009 at the time of registration.

Offer only valid for Career Certifications and Specialization Exams (not valid on online exams or the CCDE Practical Exam – 352-011). NOTE: All exams needed for a certification must be taken to gain back your certification.

Now earlier I had conflicting answers from Pearson about whether or not a testee examinee can take advantage of the promotion even though it is their first time taking the test (for it says in the announcement: All exams needed for a certification must be taken to gain back your certification). The first person I spoke with this morning said, no, you can’t. It is only for those who have their certs lapse or in danger of lapsing. But he wasn’t really sure of the details so he told me to call Cisco and gave me the number. I then called Cisco only to hear that she (the “supposedly” Cisco person I spoke with) has never heard of such a promotion and the only promotion they have is for Cisco employees. She then told me that it is a Pearson Vue promotion and that I should ask them.

So, not wanting to be left in the dark, I called Pearson again (about an hour later) and spoke with another. This person says that, “Cisco ‘prefers’ that only those who have let their certs lapse should use the promotion”. But, anyone should be able to use it regardless of their standing. So now I have two conflicting versions.

I thought I’d wait again a few more hours and call -  for a tie-breaker. This time, the nice gal confirmed that I “should” be able to use it too.

“Should” be? Why not “definitely” be?

Whatever!

I guess the only way to find out is if you fail a test and try it. Just don’t shoot the messenger if it doesn’t work. I’m just telling you what I heard from the people the “supposedly” work at Pearson Vue.

As for me, I dont really care if I fail or pass – well obviously I care that I pass. But the truth is, I’m more  concerened about the fees. If I can re-take any exam, then failing the test is not much of a big deal for me. Failing will just show me where I need to improve. I read somewhere that success is when all failures have been exhausted. So secretly, I’m hoping to fail. Just kidding.

But I’m glad this one is back. Now I’m ready to fail a test just to try out the promotion. Just kidding again.

Somehow, there still a lingering feeling of uncertainty. Do you?

IPv4 (32-bit address) = 2³² = 4,294,967,296

IPv6 (218-bit address) = 2¹²⁸ = 340, 282, 366, 920, 938, 463, 463, 374, 607, 431, 768, 211, 456

I don’t even know what -illion that amounts to. Although something tells me that it’s not nearly close enough to infinitillion.

Here’s a few more math for you curious types:

You may or may not realize it, but 128 bit addresses allow for 2¹²⁸=340,282,366,920,938,463,463,374,607,431,768,211,456 total theoretically assignable addresses. To understand just how large that number is, recognize that the surface area of the earth is usually considered to be about 196,950,000 square miles.[6] There are 5280*5280 square feet in a square mile, and 12*12 square inches in a square foot. Multiplying 196,950,000*5280*5280*12*12, we find that the approximate surface area of the earth is 790,653,726,720,000,000 square inches.

If you divide 340,282,366,920,938,463,463,374,607,431,768,211,456 (the upper bound on the number of IPv6 addresses) by 790,653,726,720,000,000 (the approximate surface area of the earth in square inches) that implies you can assign over 3.7×10^21, addresses per square inch of the earth’s surface. That should be enough addresses for most requirements, at least for the foreseeable future!

In that case, I don’t suppose I can order a few million of those IP addresses? Oh nothing… in case I want to bling out our dog with IP addresses all over it’s body.

Reference

1. Joe St Sauver, University of Oregon,  “What’s IPv6…and Why Is It Gaining Ground?”
2. “Oops! How Many IP Addresses?” – IEEE: Spectrum Online

..Guess I don’t have to worry about the routing portion of the CCNP. I’ll just do it anyway. Just for fun

Disclaimer: This is obviously an oversight on Cisco’s part. So please don’t go blaming me if you complete the 3 required tracks only to find out that you’re one short of attaining the CCNP. If you do, I’d just point my fingers at you and laugh.

Terminologies

Distribution Trees

• When forwarding multicast packets, multicast-enabled routers use PIM to dynamically create distribution trees that control the path that IP multicast traffic takes through the network to deliver the packets to all receivers
• 2 Types of Distribution Trees
  • Source Tree
    • A source tree is created for each source router sending to each multicast group.
    • The root is at the source and has branches through the network to the receivers.
    • It is also know as source-routed or shortest  path trees (SPTs) because the tree uses the most direct and shortest path to the receivers.
  • Shared Tree
    • A shared tree has one path or tree that is shared between all sources for each multicast group.
    • The shared tree uses one single common root called a rendezvous point (RP).
    • Sources would initially send their packets to the RP. From there the data is forwarded through the shared tree to the destination members.

Reverse Path Forwarding (RPF)

• This refers to the forwarding of multicast traffic away from the source, rather than forwarding to the receiver. It is the opposite operation of unicast routing.
• For multicast, the source IP address refers to the known source, and the destination IP address denotes a group of unknown receivers.
• RPF avoids routing loops by using the unicast routing table to determine the upstream (toward the source) and downstream (away from the source) neighbors and ensures that only one interface on the router is considered to be an incoming interface for data from a specific source.

• RPF check procedure:
  • Step 1. Router looks up the source address in the unicast routing table to determine if it has arrived on the interface that is on the reverse path back to the source.
  • Step 2. If packet has arrived on the interface leading back to the source, the RPF check is successful and the packet will be forwarded.
  • Step 3. If the RPF check in 2 fails, the packet is dropped.
• RPF is a fundamental concept in multicast routing that enables routers to correctly forward multicast traffic down the distribution tree. RPF makes use of the existing unicast routing table to determine the upstream and downstream neighbors. A router will only forward a multicast packet if it is received on the upstream interface. This RPF check helps to guarantee that the distribution tree will be loop free.

PIM Modes

• There are 2 main PIM modes:
  • Sparse Mode (PIM-SM)
    • Sparse mode uses a “pull” model to send multicast traffic.
    • Uses shared tree distribution, therefore an RP is required.
    • Sources register with RP.
    • When active receivers actively request to join a specific multicast group, routers along the path of these receivers register to join that group.
      • Using unicast routing table, these routers calculate whether they have a better metric to the RP or to the source itself.
      • Whichever device has a better metric, the join message is forwarded to that device.
  • Dense Mode (PIM-DM)
    • Dense mode uses a “push” model to flood multicast traffic to the entire network.
    • Uses source trees.
    • In this mode, routers that have no need for the data (because they are not connected to receivers that want the data or to other routers that want it) request that the tree is pruned so that they no longer receive the data.
• PIM Sparse-Dense mode is a hybrid of the 2 main PIM modes.

Multicast Distribution Trees

Source Distribution Trees

• Source trees are the simplest form of a multicast distribution tree.
• The root of the tree is at the source.
• It is also called a shortest path tree because it uses the shortest path through a network.

• In the above diagram, it illustrates an example of a shortest path tree (SPT) for group 224.1.1.1.
• The root is the source (Host A).
• Packets are forwarded according to the source and group address pair along the tree.
• The forwarding state associated with the source tree is referred to by the notation (S, G), pronounced “S comma G“.
  • S is the IP address of the source and G is the multicast group address.
  • Using this notation, the SPT for the example above is (192.1.1.1, 224.1.1.1)
• The (S, G) notation implies that a separate SPT exists for each individual source sending to each group.
  • For example, if Host B is also sending traffic to group 224.1.1.1 and Hosts A and C are receivers, the a separate (S, G) SPT would exist.
  • In the case of Host B being the source, the notation is (192.2.2.2, 224.1.1.1)

With source trees,  a separate tree is built for every source S sending to group G.

Shared Distribution Trees

• Unlike source trees whose root is at the source, shared trees has a single common root placed at some chosen point in the network.
• This shared root is called a Rendezvous Point (RP).

• In the figure above, the root is located at Router D for multicast group 224.2.2.2.
• Sources send their traffic to the root and the traffic is forwarded down the share tree to reach all receivers.
  • In the example above, multicast traffic from the sources (Hosts A and D) travels to the root (Router D) and then is forwarded down the shared tree to the receivers (Hosts B and C).
• Because all sources in the multicast group use a common shared tree, the forwarding state for the shared tree is identified with the notation (*, G), pronounced “star comma G“.
  • * means all sources, and G represents the multicast group.
  • Therefore, the shared tree in the figure above is notated as (*, 224.2.2.2).

Comparison

• Shortest Path Trees
  • Have the advantage of creating the optimal path between the source and receivers. This will guarantee the minimum amount of network latency for forwarding multicast traffic.
  • However,  because routers must maintain path information for each source, they use more memory and processing power.
• Shared Trees
  • Have the advantage of requiring the minimum amount of state in each router. This will lower the overall memory requirements for a network that only allows shared trees.
  • The disadvantage of shared trees is that under certain circumstances the paths between the source and receivers might not be the optimal paths. This could lead to some latency in packet delivery.

PIM Modes

PIM Dense Mode (PIM-DM)

• PIM-DM initially floods multicast traffic to all parts of the network.
• The traffic is sent out of all non-RPF interfaces where there is another PIM-DM neighbor on a directly connected member of the group.
• In figure 1 below:
  • multicast traffic is flooded throughout the entire network.
  • Traffic is received via each router’s RPF interface (interface in the direction of the source).
  • Multicast traffic is sent out each router’s non-RPF interface to all of its PIM-DM neighbors.
  • This flooding also results in some traffic arriving via the non-RPF interfaces as is the case for Routers A, B, C, and D.
  • Packets arriving via the non-PRF interfaces are discarded.

Figure 1: PIM-DM Initial Flooding

• In Figure 2 below:
  • PIM-DM prune messages (in red dotted arrows) are sent to stop unwanted traffic.
  • Prune messages are sent on an RPF interface only when the router has no downstream receivers for multicast traffic from the specific source.
  • In the example below, there is only one receiver, therefore all other paths are pruned.
  • Prune messages are also sent on non-RPF interfaces to shut off the flow of multicast traffic because it is arriving via an interface that is not on the shortest path to the source.

Figure 2: PIM-DM Pruning Unwanted Traffic

• The next illustration shows the result of pruning the unwanted multicast traffic:

Figure 3: PIM-DM Results After Pruning

• Although the flow of multicast traffic is no longer reaching most of the routers in the network, the (S, G) state still remains in all of them and will remain there until the source stops sending.
• In PIM-DM, all prune messages expire in 3 minutes.
  • After that, the multicast traffic is flooded again to all the routers.

PIM-Sparse Mode (PIM-SM)

• PIM-SM is described in RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM).
• Uses shared distribution trees, but it may also switch to use source distribution trees.
• Based on a pull model, traffic is forwarded only to those parts of the network that need it.
• PIM-SM uses an RP to coordinate forwarding of multicast traffic from a source to receivers.
• Senders register with the RP and send a single copy of multicast data through the RP to the registered receivers.
• Group members are joined to the shared tree by their local designated router (DR).
• A shared tree that is built this way is always rooted at the RP.
• It is preferred over PIM-DM for all production networks regardless of size and membership density.

• In the above diagram, an active receiver wants to join multicast group G.
• The last hop router (router attached to the Receiver) knows the IP address of the RP router for group G.
  • It sends a (*, G) join for this group toward the RP.
  • The (*, G) join travels hop-by-hop toward the RP building a branch of the shared tree that extends from the RP to the last-hop router directly connected to the receiver.
  • At this point, group G traffic may flow down the shared tree to the receiver.

Resources:

1. Multicast Distribution Trees – Cisco Systems
2. Reverse Path Forward (RPF) check procedure
3. RFC 3973, Protocol Independent Multicast – Dense Mode (PIM-DM)
4. RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM)

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

• Several ways for multicast applications to learn about the available sessions or streams:
  • The application may join a predefined group where another multicast application sends announcements about available sessions.
  • The application may contact an appropriate directory service.
  • Clicking on a webpage URL of the sessions.
  • Email announcement of the session.
• Another option is to use an application called Session Directory (sd) that acts like a TV guide with multicast content.
  • A client application runs on a PC and lets the user know of available contents.
  • To learn about the content, this directory application uses either the:
    • Session Description Protocol (SDP) or,
    • Session Announcement Protocol (SAP)
  • The Session Directory application and the Session Description Protocol are sometimes called SDR or sdr.
    • In Cisco documentation SDP/SAP is referred to as sdr.
• The Session Description Protocol tool (or SDR tool) is an application that allows:
  • Session description and its announcements.
  • Transport of session announcement via multicast group 224.2.127.254.
  • Creation of new sessions.
• On the receiver side, SDR allows receivers to see available groups/sessions. To join the session, click on the link.
• On the sender side, SDR allows new sessions to be created and avoid address conflicts
• RFC 3266, Support for IPv6 in Session Description Protocol (SDP), defines the standard set of variables that describe the sessions.
  • This RFC is obsoleted by RFC 4566, SDP: Session Description Protocol.
  • Most of the variables that defines SDP were inherited from the SDR tool.
  • The transport itself is not defined in the RFC. The packets describing the session may be trasported via the following mechanisms:
    • SAP, defined in RFC 2974, Session Announcement Protocol, carries the session information.
    • Session Initiation Protocol (SIP), defined in RFC 3261, SIP: Session Initiation Protocol, is a signaling protocol for Internet conferencing, telephony, instant messaging.
    • RFC 2326, Real Time Streaming Protocol (RTSP), control protocol for multimedia sessions. Allows controls such as forward, rewind, pause, play, and also carries session information.

IGMP

• IGMP is used to register hosts to the router when joining and leaving multicast groups.
• This registration process allows the router to be aware of what host to forward data streams destined to a specific multicast group.
• Hosts identify group memberships by sending IGMP messages to their local multicast router.
• Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.

IGMP is used between hosts and their local router.

IGMP Version 1

• Defined in RFC 1112, Host Extensions for IP Multicasting.
• Two types of messages:
  • Membership Query
  • Membership Report
• Multicast routers periodically send membership queries (every 60 to 120 seconds) to multicast address  224.0.0.1 (all-hosts).
• Hosts send memebership reports to the multicast address they want to join. Hosts either send reports if they want to join or to respond to membership queries.
• To minimize bandwidth and processing overhead, only one member per group, on each subnet, responds to a query. This process is called report suppression.
• For a multicast traffic to be forwarded to a segment, there has to be at least one active member present.
• IGMPv1 lacks the mechanism for hosts leaving the group.
  • Hosts can leave a group silently, at any time, without notifying the router.
  • Even when there is no longer any host in the group, the multicast session will continue to forward traffic until several query intervals find no response. This leads to inefficiency.

IGMPv1 Message Format

IGMP Version 2

• Defined in RFC 2236, Internet Group Management Protocol, Version 2.
• Due its predecessor’s  limitations, IGMPv2 came to be. Most of the changes between version 1 and version 2 deal with the issues of leave and join inefficiencies.

The following are some important changes in IGMPv2:

• Group-specific queries
  • Allows a router to query membership only in a single group instead of in all groups. This provides an efficient way to find out if any members are left in a group without asking all groups for a report.
  • Membership query vs. group-specific query:
    • Membership query sends multicast to all host address 224.0.0.1
    • Group-specific query for a group “G” is multicast to the group “G” multicast address.
• Leave Group message
  • Mechanism for hosts to notify the router that they are leaving the group.
  • This specification includes the timing of when Leave Group messages must be sent.
• Querier election mechanism
  • The router with the highest IP address on the same segment becones the designated querier.
• Query-interval response time
  • Indicates to the members how much time they have to respond to a query by issuing a report.
  • Controls the “burstiness” of a report

IGMPv2 Message Format

• IGMPv2: Joining a Group
  • When joining a multicast group, members do not have to wait for a query to join. They simply send an report indicating that they want to join.
  • This reduces the latency for a host joining if no other members are present.
• IGMPv2: Leaving a Group
  • When a host leaves a group, it announces its intention to leave by sending a Leave group message to  multicast 224.0.0.2 – all multicast routers.
  • When the router receives the Leave Group message, it sends a group-specific query to check if there is any other members left in the group.
    • If another member is still present, it sends back a report and the router continues to send multicast traffic to the group.
    • If there is no longer any member present, no membership report comes back to the router. The group subsequently times out.
    • It takes approximately from 1 to 3 seconds from the time that the Leave Group message is sent until the group-specific query times out and multicast traffic stops flowing for that group.

IGMP Version 3

• Defined in RFC 3376, Internet Group Management Protocol, Version 3.
• It is proposed standard that adds the ability to filter multicasts based on multicast source so that hosts can indicate that they want to receive traffic only from particular sources within a multicast group.
• This helps in making the utilization of routing resources more efficient.
• IGMPv3: Joining a Group
  • Upon joining a group, the joining member sends a report to 224.0.0.22.
  • This report might specify a source list, which is used for source filtering.
    • A source list is a list of multicast sources that the host will accept packets from or a list of multicast sources that the host will not accept packets from.
  • A source list help avoid delivering multicast packets from specific sources to networks where there are not interested receivers.
• IGMPv3: Operation
  • The router sends periodic queries to the members of the group while all IGMPv3 members respond with reports that contain multiple group state records.

The show ip igmp interface command helps determine what verison of IGMP is running.

Multicast in Layer 2

• Because IGMP is a Layer 3 (Network Layer) protocol, switches are not able to participate in IGMP and are not aware of which hosts attached to them might be part of a particular multicast group.
  • This can be a problem especially when most hosts don’t attach directly to routers, instead they are connected to a Layer 2 switch, which in turn connect to routers.
  • Additionally, mulitcast traffic is forwarded to all ports of a VLAN even if only one device on one port requires the actual multicast stream.
• To go around the problem, Cisco Catalyst switches implements a mechanism where mulitcast MAC addresses can be manually associated with various ports on the switch.
  • This solution is not very scalable because IP multicast hosts dynamically join and leave groups.

CGMP

• Cisco Group Management Protocol (CGMP) is a Cisco Systems proprietary protocol.
• The protocol runs between a router and a switch.
• The routers inform each of their directly connected switches of IGMP registrations that were received from hosts through the switch. The switch then forwards the multicast traffic only to ports that those requesting hosts are on rather than flooding the data to all ports.
• CGMP is based on a client/server model where the router may be considered a CGMP server, and the switch a client.
• CGMP Operation:
  • When the router sees an IGMP control message, it creates a CGMP packet that contains:
    • the request type (join or leave)
    • the Layer 2 multicast MAC address
    • and the actual MAC address of the client
  • The packet is sent to the well-known CGMP multicast MAC address 0×0100.0cdd.dddd, to which all CGMP switches listen.
  • The switch interprets the CGMP control message and creates the proper entries in its MAC address table (also called its forwarding table or content-addressable memory [CAM] table) to constrain the forwarding of multicast traffic for this group to only the appropriate ports.

IGMP Snooping

• With IGMP Snooping, the switch eavesdrop on the IGMP messages sent between the routers and hosts, and updates its MAC address table accordingly.
• The switch is required to be IGMP aware in order to listen to IGMP messages.
• The switch intercepts all IGMP packets that go through it from host to router and vice versa.
• Using IGMP snooping can have considerable increase in performance for the switch because of the fact that it has to examine every Layer 2multicast packets that pass through it in order to identify the IGMP packets.
  • To avoid serious degradation in performance, a Layer 3 switch is better option.

Resources:

1. RFC 4566, SDP: Session Description Protocol
2. RFC 2974, Session Announcement Protocol
3. RFC 3261, SIP: Session Initiation Protocol
4. RFC 2326, Real Time Streaming Protocol (RTSP)
5. RFC 1112, Host Extensions for IP Multicasting
6. RFC 2236, Internet Group Management Protocol, Version 2
7. RFC 3376, Internet Group Management Protocol, Version 3

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

• IP Multicast is a technology that allows data to be delivered over networks to a group of destinations as efficiently as possible.
• IP Multicast delivers source traffic to multiple recievers without additionaly burden on the source or the receivers while using the least network bandwidth of any competing technology.
• Data is sent from the source as one stream; this single data stream travels as far as it can in the network.
• Devices only replicate the data if they need to send it out on multiple interfaces to reach al members of the destination group.
  • Mulitcast packets are replicated in the network by Cisco routers enabled with Protocol Independent Multicast (PIM) and other multicast protocols.

Multicast vs. Unicast

• In Multicast, packets are not duplicated when sending to multiple receivers. Instead, they are sent in a single stream.
  • Downstream routers replicate the packets only on links where receiving hosts exist.
  • The source of multicast traffic (the sender) does not have to know the addresses of the receivers.
• Unicast transmission sends multiple copies of data packets; one copy for each receiver.

Multicast Applications

• One-to-Many
  • One sender sends data to many receivers.
  • May be used for audio or video distribution, push-media, announcements, monitoring, etc.
  • May become many-to-many if feedback is required from the receivers.
• Many-to-Many
  • Any number of hosts send to the same multicast groups.
  • Two or more receivers also act as senders and a host can be a sender and a receiver simultaneously.
• Realtime Applications include:
  • TV, Radio, corporate broadcasts, financial data delivery, whiteboard collabaration, e-learning, video-conferencing.
• Non-realtime Applications include:
  • File transfer, data and file replication, and video on demand (VoD)

Advantages of Multicast

• Enhanced effieciency – multiple streams of data can be replaced with a single transmission. Server and CPU loads are also reduced.

Reduced traffic load: Example of all clients listening to a the same 8-kbps audio stream

• Optimized performance – Eliminates traffic redundancy because fewer copies of the data require forwarding and processing.
• Support for distributed applications.

Disadvantages of Multicast

• Most multicast applications user the User Datagram Protocol (UDP) transport mechanism.
  • As a result, there is no insurance for reliable delivery of data due to the best-effort delivery mechanism that is true of UDP. Therefore, reliability must lie at the application layer itself.
    • An example of this would be packet drops in a voice application. A drop in a voice packet cannot benefit from retransmission of the lost data because once a voice data is lost, it doesn’t make sense to recreate the lost packet for real-time use such as VoIP.
  • Because of UDP’s inherent lack of a windowing mechanism present in TCP, network congestion and degradation could occur.
• Duplicate packets may occur when multicast topologies change.
• Out-of-sequence delivery of packets to the application can also occur if the topology changes. The Mulicast application design should take this into account in the planning process.

IP Multicast Addresses

IP Class D Address

• IANA has assigned the Class D IPv4 address space range of 224.0.0.0 through 239.255.255.255.
• The Internet Assigned Numbers Authority (IANA) hands out the assignment of multicast addresses.

Reserved Link Local Addresses

• 224.0.0.0 through 244.0.0.255
• The IANA has reserved the range 224.0.0.0/24 for use by network protocols on a local network segment.
• Packets with these addresses are not to be forwarded by a routers.
• They have TTL value of 1.
• This range is also known as local network control block.
• Some well known IP multicast addresses are:
  • 224.0.0.1 – All hosts
  • 224.0.0.2 – All multicast routers
  • 224.0.0.5 – OSPF routers
  • 224.0.0.6 – OSPF DRs
  • 224.0.0.9 – RIPv2 routers
  • 224.0.0.10 – EIGRP routers
  • 224.0.0.12 – DHCP server/relay agent

Globally Scoped Addresses

• 224.0.1.0 through 238.255.255.255
• These addresses are used to multicast data between organizations and across the Internet.
• The IANA has reserved some of these addresses for multicast applicationsm such as Network Time Protocol (224.0.1.1)

Limited Scope Addresses

• 239.0.0.0 through 239.255.255.255
• Also known as Administratively Scoped Addresses.
• They are defined by RFC 2365.
• They are reserved for use inside private domains – local group or organizations.
• Routers are typically configured with filters to prevent multicast traffic in this address range from flowing outside of an AS or any user defined domain.
• The IANA further subdivides this group into the following scopes:
  • Site Local Scope
    
    • 239.255.0.0/16
      
    • 239.252.0.0/16
      
    • 239.253.0.0/16
      
    • 239.254.0.0/16
  • Organizational Local Scope
    • 239.192.0.0 to 239.251.255.255

Layer 2 Mulitcast Address

• In 802.3 standard, bit 0 of the first octet is used to indicate a broadcast and/or multicast frame.

• This bit 0 is an indication of the frame’s destination towards an arbitrary group of hosts (mulitcast) or, in the case of broadcast, all hosts on the network (address 0xFFFF.FFFF.FFFF)
  • IP multicast makes use of this bit to transmit IP packets to a group of hosts on a LAN segment.

Ethernet MAC Address Mapping

• The IANA owns a block of Ethernet MAC addresses that start with 01:00:5E in hexadecimal.
• The lower half of this block is allocated for multicast addresses:
  • 0100.5e00.0000 – 0100.5e7f.ffff available for MAC addresses.
• The low-order 23 bits of the IP mulitcast address is mapped into the low-order 23 bits of the MAC address, shown in the figure below:

• In the figure above, there are 28 bits of unique address space available for an IP multicast address:
  • 32bits minus the first 4 bits containing the 1110 Class D prefix.
• As mentioned earlier, there are 23 bits mapped into the IEEE MAC Addresses.
  • Therefore, there are five (28-23 = 5) bits of overlap.
  • 2^5 = 32 addresses
• There is a 32:1 overlap of IP addresses to MAC addresses. In other words 32 IP multicast addresses map to the same MAC multicast address.

Resources

1. Internet Protocol IP Multicast Technology – Cisco Systems
2. IP Multicast Technology Overview – Cisco Systems
3. Iana.org – Internet Multicast Addresses

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

As far as  this week is concerned, though, I’m hoping for a more productive output. So far today, I’ve already studied for a good 3 hours. I started reviewing multicast at work  and hope to be able to put some notes on here soon. For the last couple of hours, I’ve been working on some BGP AS_Path configuration. It looks like this whole week will be spent doing all BGP labs combined with Multicast  reviews and note-taking. I hope to be able to get through the rest of Multicast section for the next two weeks: reading and notes this week, labs next week.

• Caue Wailemann – Cisco Network Engineer
• CCIE Pursuit
• Default Route
• Himawan Nugroho
• Mar Apuhin – CCIE Pilot
• Richard Bannister – CCIE Quest
• Tassos – CCIE in 3 MonthsIP Expert Blog
• Pashtuk – Just Another CCIE
• Nickleby Thane – The CCIE Journey

But since I cleared the CCNA, it’s been my semi-long-term goal to go for the CCNP next. Seems like the natural progression. But as I plowed through my trek to get through the first hurdle – passing BSCI – my approach towards my studies has began to evolve. My focus is no longer just passing the BSCI. But instead, I’m going deeper into the technologies with the idea that I will be taking this knowledge towards my IE pursuit.

This is good and all. But what ends up happening is that my original goal of getting  through the BSCI in 5 months (6 months top) is now going into its 7th month. I’m not really as worried about that as much as about abandoning a solid strategy. By now my original strategy has changed since I didn’t accomplish that goal of clearing the BSCI in 6 months. That is, of course, not to say that I haven’t accomplished anything. In fact, I have learned so much in that last 6 months. I’ve gone pretty deep into my studies that I know OSPF more than I’ve ever have. The same goes for BGP. I read the chapters on these technologies more than twice. I read the Doyle chapters at least once with scattered follow ups. I did labs. I wrote a lot of notes. But feeling confident about BGP and OSPF is not enough to pass the BSCI. I still have to go back to review EIGRP, RIP, Multicast, IPv6, et al.

Herein lies my dilemma. Since I’ve spent more time on OSPF and BGP over anything else, it came at the expense of the other technologies I should be focusing on just as equally. And because I’ve invested this much already, I’m feeling that I might as well spend as much on the other technologies and shift my focus on learning them just as well as opposed to limiting myself to a timeline for getting throught this track – in essence, go deeper into the technologies as a CCIE candidate would. This would mean that it’ll be 6 more months before I’ve gone through the whole BSCI blueprint thoroughly. That’s quite a long time to prepare for just the BSCI. Of course that’s not nearly long enough if I were actually preparing for the CCIE. So I’m thinking, I should just shift my focus towards CCIE preparation.

On the other side, if I were to work on acquiring knowledge just enough to pass the BSCI and the subsequent tracks that follow, then I would have a better and measurable strategy, than just going all out. And doing just enough may not be as bad as one might think. It might actually even be more effective. By focusing just enough of the basics (or intermediate knowledge), without going too deep into the technologies, it allows n00bs like me to cover a wider spectrum of technologies without risking exhaustion or overwhelming oneself.  It could allow the brain to retain more knowledge for long term use – say, for CCIE prep. Going through each track, to me, seems like the best way to measure ones progress – passing (or failing) each test gives somewhat of general idea where one is at. Reminds me of that qoute: “yard by yard, everything is hard; inch by inch, anything’s a cinch”, or something like that. And really, it was my origininal intention all along to just get through the CCNP tracks before going too deep. It’s just that somewhere along my preparation, I got too caught up that I went deep much too fast than I might have been able to handle. Come to think of it, I’ve gone through so much information already, that I might only be able recognize a concept if you asked me about it, but not be able to expound on it as profoundly as I should.

So, in summary:

1. I could forget the CCNP and focus the next few years preparing myself for the CCIE:
   • It will free me from the self-imposed timeline that limit me from exploring all technologies as wide and deep as I can.
   • I will be going after what my end goal is anyway – CCIE.
   • By going through the CCIE blueprint, I will be covering most CCNP related materials anyway.
   • I’m already digging deep into the technologies, no sense to ease up now.
2. Stay the course and stick with the original plan:
   • By taking carefully measured steps, I can slowly build up to my ultimate goal - the CCNP would be merely a consequence.
   • It’ll prevent sensory overload (brought on by the demands of CCIE preparation) to the point of exhaustion.
   • Having a smaller and more manageable area of focus will improve my chances of success.
   • Spreading out the information allows for better chances of learning and remembering the materials.
   • “Yard by yard, everything is…”, well you know the rest.

Here’s another thought: maybe I’m really not as smart as my mom said I was. She also said early on that I was really really ridiculously good looking, only to be disappointed when I found out that  she only said that to get me to eat my peas. Then again, maybe my bearings are all screwed up and I somehow I have this crazy idea that all this should be easy.

Well, I’m glad I wrote this post. Because reading it back to myself, I just wrote some pretty good arguments for and against either points. Arguments that I can use to help me clear my mind and stick to a plan.

I just need to get back in gear and get my priorities in order. I need to refocus my efforts towards finally seating that darn BSCI exam.  One thing I’ve been taught about goal setting and achievement is that you take pieces of the overall goal one small piece at a time and slowly work your way towards the whole. How do you eat an elephant? One bite at a time – I was always amused by that saying. Because its true. Except, elephant meat is hard. One bite will almost surely chip a tooth or two. Well I’m slowly chipping away. One thing I need to do more of is labbing. I’ve almost completely neglected that part of my studies. Too much reading and not enough practice.

I just had another quick and fun project at work to help setup site to site vpn with another company that we’re working with. This time I wasn’t alone in implementing since I had to work with the other network engineer of the aforementioned company. All in all the experience was cool. I was way more compfortable with the project this time around compared to when I was doing it all by myself. I also found that looking at the configuration was a lot easier since I knew what I wanted to look for in the configs and knew what elements are involved when configuring a simple and straightforward ipsec vpn.

Supposedly my boss also wants me to start a new interesting project.

He said “would you like to tack on another challenge”.

“Yes, of course”, says the I. ”

“I want you to learn as much as you can about QoS, and implement it.”

“Nice!”, I thought. No specificity. No directives. Just learn and do it. I’m sure he’ll give me more directions as to what he wants later. But at least I get to have an excuse to learn something new and have a reason for it . Anyway, he says the project is not going to be overly complex or even big. Basically just to ensure certain applications have clear sailing when all is said and done.

Anyway, I still need to refocus and revisit my goals. Probably time to renew my new year’s resolution. By the way, last years new year resolution, I totally accomplished it and ran with it. This year, I’m just renewing it and hopefully it’ll carry me through the next.

Yeah. That’s what I said.

But fortunately for one dude down under, he managed to acquire his new digits. Head on down and congratulate CCIEDownUnder.

• Local preference is a well-known discretionary attribute that tells the routers in an AS which path is the preferred path to exit the AS.
• If an internal BGP speaker receives a multiple routes to a destination, the router compares the LOCAL_PREF attribute of the routes.
  • The path with the higher local preference is chosen.
• Local preference is exchanged only among routers in the same AS, among internal BGP neighbors; it is not passed to other autonomous system (ie other EBGP peers).

• In the figure above, AS100 receives advertisement for network 172.16.1.0/24 from two different points.
• As Router A receives the advertisement from Router C, Router A sets the LOCAL_PREF to 50.
• Likewise, when Router B receives the advertisement to the same network (172.16.1.0/24), Router B sets the LOCAL_PREF to 100.
• These local preference values will be exchanged between IBGP neighbors, Routers A and B.
• Based on the higher value LOCAL_PREF for Router B, Router B will be use as the exit point for AS 100 to reach network 172.16.1.0 in AS 200.

Multi-exit Discriminator (MED) Attribute

• Whereas the local preference attribute affects traffic leaving the AS, The MED attribute influences incoming traffic.
• Also called the metric. A lower metric is preferred. As is true with most “metrics”, the lowest metrics means the shortest distance, and thus the preferred one.
  • MED is set to 0 (zero) by default.
• This attribute is carried in EBGP updates and allows an AS to indicate to another AS its preferred incoming points.
• By default, a router compares the MED attribute only for paths from the neighbors in the same AS.
• The MED is exchanged between two directly connected autonomous systems only.
  • MEDs are not passed beyond the receiving AS.

• In the Figure above,  a subscriber in AS 200 is dual-homed to a single ISP (AS 100).
• Within AS 100, IBGP is being used between the routers. The MEDs from AS 200 are exchanged between these internal peers so that they both know which route to prefer.
• MEDs also do not go past beyond the receiving AS. IF AS 100 advertises 172.16.1.0/24 to another AS, for instance, it does not pass along the MED set by the originating AS; AS 200 in this case.
• Additionally, MEDs are not compared if two routes to the same destination are received from two different autonomous systems.
  • For example, 172.16.1.0/24 is advertised from AS 200 and another AS, the MEDs are not compared.
  • MEDs are meant only for a single AS (with multiple entry point) in order to compare which entry point to prefer.

Community Attribute

• Communities are optional transitive attributes that is designed to simplify policy enforcement. It is one way to filter incoming or outgoing routes.
• BGP communities allow routers to tag routes with a community indicator and allow other routers to make decisions based on that tag.
  • It Identifies a route as a member of some community of routes that share some common properties.
  • An example might be an ISP that assigns a particular COMMUNITY attribute to all of its customers’ routes. The ISP may then set its LOCAL_PREF attribute based on the COMMUNITY value instead of basing it on each inidividual route.
• The community attribute was originally a Cisco-speficific attribute. But now a RFC standard through RFC 1997.

Weight Attribute (Cisco Only)

• The weight attribute is a Cisco-specific attribute.
• It is configured locally on the router and is not communicated or propagated to other routers.
• The weight ha a value between 0 to 65,535.
  • By default, all routes generated by the local router have a weight of 32,768.
  • All routes learned from a peer have a weight of 0.
  • The higher the weight, the more preferable the route.
• The weight attribute applies when using one router with multiple exit points out of an AS.
  • Contrast it with the local preference attribute where it is used when two or more routers provide multiple exit points.

• In the figure above, Router A receives an advertisement for network 172.16.1.0/24 from Routers B and C.
  • Router A knows about more than one route to the same destination.
• The route coming from Router B has an associated weight of 50.
• The route coming from Router C has an associated weight of 100.
• Both paths for network 172.16.1.0 will be in the BGP routing table, with their respective weights.
• The route with a higher weight will be installed in the IP routing table.

Resources:

1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
2. RFC 4451 – BGP MULTI_EXIT_DISC (MED) Considerations
3. RFC 1997 – BGP Communities Attribute
4. RFC 1998 -An Application of the BGP Community Attribute in Multi-home Routing

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

• Whenever a route update passes through an AS, the AS number is prepended to that update when it is advertised to the next EBGP neighbor.
• The AS-path attribute is the list of AS numbers that a route has traversed to reach a destination, with the number of the AS that originate the route at the end of the list.
• The AS-Path attribute avoids routing loops by the local AS simply rejecting any route object that contains its own AS in the AS_PATH attribute.
• The BGP system prefers the route object with the shortest AS_PATH attribute length.

• In the above figure, AS1 originates a network 10.0.0.0/8 and advertises it to AS2 and AS3. AS1 adds its own AS number to the AS_PATH.
• AS2 and AS3 learns of the route with an associated path vector of <AS1>.
  • AS2 advertises the route to its neighbor AS 4. AS2 prepends its own AS number to the AS_PATH.
  • AS3 advertises the route it learns from AS1 to AS5. AS3 prepends its own AS to the AS_PATH.
• AS4 learns of the route from AS2 with an associated path vector of <AS2, AS1>.
• AS 5 eventually learns two paths to 10.0.0.0/8.
  • One with a path vector of <AS3, AS1>
  • Another with path vector of <AS4, AS2, AS1>
• AS5 will select the shortest path to reach 10.0.0.0/8. This path is the one that goes though AS3 –> AS1.
  • This path that AS5 chose will also be advertised to its adjacent AS peers.
• Loop prevention mechanism on BGP will not allow AS5 to advertise the same path to AS1 because AS1 is already in the path vector.

Next-Hop Attribute

• The next-hop attribute indicates the next-hop IP address to reach a destination.
• The next-hop IP address is not always the address of a neighboring router.
  • For EBGP, the next-hop is the IP address of the neighbor that sent the update.
  • For IBGP, it stipulates that the next hop advertised by EBGP should be carried into IBGP.
    • It is not necessarily the connected IGP neighbor that is advertised as the BGP next hop address.

Example 1

• Consider the diagram above, Router B learns the network 172.16.0.0 from Router A, with the next-hop IP address of 10.10.10.3. Likewise, A uses 10.10.10.1 as the next hop IP address to get to 172.20.0.0.
• Because the rule for IBGP states that the next hop advertised by EBGP should be carried into IBGP, Router B advertises to its IBGP peer Router C the network 172.16.0.0, with the next hop of 10.10.10.3 (not 172.20.10.1 as we’re accustomed to seeing in the IGP world).
• It is important that Router C knows how to reach the 10.10.10.0 subnet, otherwise packets destined for 172.16.0.0 could be dropped.
  • Router C can learn about network 10.10.10.0 by IGP or static route.
• An IGP uses the IP address of a routing update (route source) as the next-hop address.
• BGP uses a separate field for each network to record the next-hop address.
• IBGP neighbors use recursive lookup to reach BGP next-hop address by using its IGP entries in the routing table.
  • Router C learns about 172.16.0.0 from Router B (route source 172.20.10.1) with Router A (10.10.10.3) as the next hop.
  • Router C, therefore, installs the route to 172.16.0.0/16 in the routing table with a next hop of 10.10.10.3
  • With Router B using an IGP to announce network 10.10.10.0/24 to Router C, Router C also installs 10.10.10.0/24 in its routing table with a next hop of 172.20.10.1.
  • When Router C sends a packet to a destination in the 172.16.0.0. network, it looks up the network in the routing table and finds a BGP route with a next hop of 10.10.10.3.
  • Because it is a BGP entry, Router C completes a recursive lookup in the routing table for a path to network 10.10.10.3.
    • There is an IGP route to network 10.10.10.0 in the routing table with a nesxt hop of 172.20.10.1.
  • Router C then forwards the packet destined for the network 172.16.0.0 to 172.20.10.1.

Example 2: Next-Hop Attribute on Multiaccess Network

• In the above diagram, Routers B and C in AS 65000 are running an IGP.
  • Router B can reach network 172.30.0.0 via 10.10.10.2.
  • Router C can reach network 172.20.0.0 via 10.10.10.1.
• B and C are also running IBGP between each other.
  • Router B is running EBGP with Router A.
  • Router C is running EBGP with Router D.
• When B sends a BGP update to A about 172.30.0.0, it gives 10.10.10.2 (Router C) as the next hop, and not it’s own address.
  • This feature is called a third-party next hop.
    • A BGP speaker can advertise to an external peer an interface of any internal peer router in the next hop component, provided the external peer to which the route is being advertised shares a common subnet with the next hop address. – RFC 2858.
    • It basically means that in a multi-access network, a BGP router can use the a next hop address that is not necessarily its own, by changing the next-hop attribute, in order to avoid inserting additional hops into the path.
• In the scenario above, If Router A needs to send update to AS 64600, Router B tells Router A to install the AS 64600 networks with next hop address of 10.10.10.2 (Router C)
  • To get to AS 64600, Router A must go through AS 65000.
  • Router B advertises AS 64600 networks to Router A because they have neighbor relationship. But because Router B does not handle traffic to AS 64600, and Router C has neighbor relationship with Router D in AS 64600, Router B tells Router A to get to AS 64600 through Router C. This is of course dependent on Router A and C being on the same subnet.

Example 3: Next-hop Attribute on NBMA

• In the above figure, Routers A, B, and C are connected via Frame Relay.
• Router B has a Frame Relay map entry for Router C, therefore it can reach network 172.30.0.0, using 10.10.10.2 as the next hop address.
• Router B, with a an EBGP neighbor relationship with Router A, sends a BGP update to Router A about 172.30.0.0, using 10.10.10.2 as the next hop address.
• A potential problem can occur if there is no way for Routers A and C to communicate directly because of missing Frame Relay map entry to each other.
  • One solution, of course, is to add a Frame Relay map entry between the two.
  • Another option is a configuration feature called next-hop-self.
    • This configuration is set on Router B by configuring itself to advertise its IP address as the next-hop attribute.

As mentioned earlier, the IP address of the next-hop is not always the address of the directly attached neighboring router. There are some rules that apply to determining the next-hop address:

1. If the advertising router and receiving router are external peers (ie they are in different autonomous systems), the IP address of the advertising router’s interface is the next-hop address.
2. If the advertising router and receiving routers are internal peers (in the same AS), and the destination is withing the same AS, the next-hop is the address of the router that advertised the route.
3. If the advertising router and the receiving router are internal peers and the destination of the update is in a different AS, the next-hop is the IP address of the external peer from which the route was learned.

Origin Attribute

• A well-known mandatory attribute that specifies the origin of routing updates.
• It can be one of three values:
  1. IGP
     • The NLRI was learned from a protocol internal to the originating AS. BGP routes are given an origin of IGP when a network command is used to advertise the route via IGP.
     • An origin of IGP is given the highest preference of the ORIGIN values.
     • An origin of IGP is indicated with an “i‘ in the BGP table.
  2. EGP
     • This means that the route is learned from Exterior Gateway Protocol (EGP). This is not supported on the Internet because it only does classful routing and does not support CIDR.
     • This is the next preferred to IGP.
     • Indicated by an “e“ in the BGP table
  3. Incomplete
     • This mens that the origin of the route is unknown or learned by other means.
     • Usually a result of a route being redistributed into BGP, because there is no way to determine the original source of the the route.
     • Lowest preferred ORIGIN value.
     • Indicated by a “?“ in the BGP table.

Resources:

1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems
2. An Introduction to BGP – the Protocol – The ISP Column – Geoff Huston
3. BGP AS-Path – Cisco IOS Hints and Tricks
4. RFC 2858 – Multiprotocol Extensions for BGP-4

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

• Attributes can be:
  • Well-known or Optional
  • Mandatory or Discretionary
• The path attributes described above fall in four categories:
  • Well-known mandatory
  • Well-known discretionary
  • Optional transitive
  • Optional nontransitive

Well-Known Attributes

• A well-known attribute is one that all BGP implementations must recognize and propagate to BGP neighbors.
  • Well-known mandatory – must appear in all BGP updates.
  • Well-known discretionary – does not have to be present in all BGP updates.

Optional Attributes

• Attributes that are not well-known.
  • Transitive – a BGP process should accept the path in which it is included, even if it doesn’t support the attribute, and it should pass the path on to its peers.
  • Non-transitive – a BGP process that does not recognize the attribute can ignore the Update in which it is included and not advertise the path to its other peers.
• BGP routers that implement an optional attribute might propagate it to other BGP neighbors, based on its meaning.
• BGP routers that do not implement an optional transitive attribute should pass it to other BGP routers untouched and mark the attribute as partial.
• BGP routers that do not implement an optional non-transitive attribute must delete the attributes and must pass it to other BGP routers.

Defined BGP attributes:

• Well-known mandatory
  • AS-Path
  • Next Hop
  • Origin
• Well-known discretionary
  • Local Preference
  • Atomic Aggregate
• Optional Transitive
  • Aggregator
  • Community
• Optional Non-transitive
  • Multiexit-discriminator (MED)

• Cisco also has its own defined weight attribute for BGP.
  • It is configured locally on a router and is not propagated to any other BGP routers.

BGP Attribute Type Codes

• Type code 1 – Origin
• Type code 2 – AS-path
• Type code 3 – Next-hop
• Type code 4 – MED
• Type code 5 – Local preference
• Type code 6 – Atomic aggregate
• Type code 7 – Aggregator
• Type code 8 (Cisco-defined) – Community
• Type code 9 (Cisco-defined) – Originator-ID
• Type code 10 (Cisco-defined) – Cluster list

Resources:

1. Border Gateway Protocol – Internetworking Technology Handbook – Cisco Systems

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

However, it seems that the initial surge has tapered off and now most CCNP blogs that I follow on a frequent basis has started dropping off the radar. What happened to you guys?

Calling out:

• CCNP Adventure
• Cisco Blackbelt
• Deon Botha – Network Ninja
• Joey Boyer – Network Bit
• Justin Reeves – CCNP Journey (actually his blog just recently went activate again. )
• CCNP Pursuit
• Michael Hocutt – CCNP2B
• IT Daddy
• Suffah – Cisco Fun
• CCNP or Bust
• Anyone else I missed? If you’re a new blogger or thinking about starting up, maybe it’s time to add your name on the list.

The CCIE bloggers are prolific in their presence. And I get a lot benefit following their blogs. But I’d like to hear more about the folks on the same pursuit as I am. I’d like to hear about your methods, your struggles, and your accomplishments so far. Have you guys lost motivation? Are you struggling a lot in your studies (like I am)? Does the pursuit seem insurmountable? Have you changed your goals recently?

Let’s have some updates, guys!

Anyway, you can follow me and all my exploits at: http://twitter.com/RouteMyWorld.

• BGP Peer = BGP Neighbor.
  • A BGP peer is a BGP speaker that is configured to form neighbor relationship with another BGP speaker for the purpose of directly exchanging BGP routing information with one another.
  • Any router running BGP is a BGP speaker.
• A BGP router forms a direct neighbor relationship with a limited number of other BGP routers.
  • The Internet represents tens of thousands of autonomous systems. It is virtually impossible for one router to have direct neighbor relationship with all the routers that run BGP.

External BGP Neighbors

• EBGP – BGP is running between routers in different AS.
• IGP is not run between EBGP neighbors.
• In order to successfully exchange routing updates between two routers, TCP on each side must successfully pass the TCP 3-way handshake before BGP session can be established.
  • The IP address used in the neighbor command must be reachable without using an IGP. The best way to accomplish this is:
    • Pointing to an address that is directly connected, which is generally the case.
    • Or, use static routes to that IP address.

Internal BGP Neighbors

• IBGP – When BGP is running between routers within the same AS.
• IBGP allows routers within the same AS to exchange BGP information and all routers have the same BGP routing information about the outside autonomous systems.
• As long as routers can reach each other in order to perform TCP handshake and set up the BGP neighbor relationship, it doesn’t matter how they are connected. They can be connected in by:
  • A directly connected network.
  • Static routes.
  • Internal routing protocol (e.g. RIP, OSPF, EIGRP, etc.)
• Because multiple paths generally exist within an AS to reach other routers, a loopback address is usually used in the BGP neighbor command to establish IBGP sessions.

IBGP is required on all routers in a transit path in order for IBGP route propagation to work properly.

IBGP in a Transit AS

• Border Gateway in ‘BGP’ was coined because BGP was originally intended to run along the borders of an AS, with the routers in the middle of the AS ignorant of the details of BGP. But it is no longer the case.
• Transit AS – An AS that routes traffic from one external AS to another external AS.
  • A typical transit AS is an ISP.
  • In the diagram below, AS 65102 routes traffic from AS 65101 to AS 65103. This makes AS 65102 a transit AS.

• All routers in a transit AS must have complete knowledge of external routes.
  • In theory, this goal can be accomplished by redistributing BGP into the IGP running on the edge routers.
  • The method of redistributing all BGP routes into an IGP is, however, not good practice. Because the current Internet routing table is extremely large, this method is simply impractical.
• The more practical method for creating complete transparency for all routing information in an AS is by running IBGP on all routers within the AS.

IBGP in a Nontransit AS

• Non-transit AS – An AS that does not pass routes between the ISPs.
  • A typical example is an organization that is multihoming with two ISPs.
• BGP specifies that routes learned through IBGP are never propagated to other IBGP peers.
  • This is a mechanism to prevent routing loops.
  • By default, each BGP speaker is assumed to have a neighbor statement for all other IBGP speakers in the AS. This makes it a full mesh IBGP.
  • The default assumption by all routers running BGP within an AS is that each BGP router exchanges IBGP information directly with all other BGP routers in the AS.
  • In a full mesh, when the BGP router receives a change update from an external AS, that BGP router for the local AS is responsible for updating all other IBGP neighbors of that change. All the other neighbors will not update their other IBGP neighbors because they will assume full-mesh topology, thus, all updates are sent only by the original sending IBGP neighbor.
  • If the sending IBGP neighbor is not fully meshed with other IBGP neighbors, there will be inconsistent routing tables and routing loops or routing black holes can occur.

Full Mesh is when all BGP speakers have a neighbor statement for all other IBGP speakers in the AS

BGP Partial-Mesh Example

• In this example, when Router B receives updates from Router A, B sends updates to Routers C & D. However, it doesn’t send it to Router E because it does not have IBGP neighbore relationship with E.
• C & D will not send updates to E because by design, they are expected to assume full mesh neighborship so that B will send the update to E.
• E does not learn of any networks through B and does not use Router B to reach any networks in AS 65101 or other autonomous systems behind AS 65101.

BGP Full-Mesh Example

• The above diagram shows a fully meshed BGP toplogy.
• When router A sends update to Router B. Router B replicates the updates to C, D, and E.
• Because Router A and Router E are not directly connected, OSPF (or whatever IGP is running) will be used to route the TCP segment containing the BGP update from Router A to Router E.
• In a fully meshed IBGP, each router assumes that every other internal router has a neighbor statement that points to each IBGP neighbor.

Example: BGP Not in All Routers

• In the example above, Routers A, B, E, and F are the only ones running BGP.
• Through an EBGP session, Router A advertises network 10.0.0.0 to Router B. Router B in turn advertises the network to Router E, using IBGP. E advertises it to Router F.
• If Router F tries to send packets to network 10.0.0.0 via router E, Router E will try to send the packet to its BGP peer, Router B.
  • But in order to reach Router B, the packets must go through Router C or D.
  • Because Routers C or D are not running BGP, they don’t have a route to network 10.0.0.0. Therefore the packets are discarded.
• Assuming Routers C or D have default routes to the exit points, B and E, when Router E sends the packets to E or D, there is a good chance that C or D will send it back to router E. In turn, router E will resend it back again, eventually creating a loop.
• In order to solve all these problems, BGP must be implemented on Routers C and D.

All routers in the path between IBGP neighbors within an AS, known as the transit path, must also be running BGP. These IBGP sessions must be fully meshed.

BGP Synchronization

BGP Synchronization Rule

The BGP synchronization rule states that if an AS provides transit service to another AS, BGP should not advertise a route until all of the routers within the AS have learned about the route via an IGP

The synchronization rule is best understood with an example:

• Consider the following scenario above:
  • In the above picture, Router C sends updates about network 170.10.0.0 to Router A.
  • Routers A and B are running IBGP, so Router B receives updates about network 170.10.0.0 via IBGP.
  • In order for Router B to reach network 170.10.0.0, it has to send the traffic through router E.
    • Router E has no knowledge of network 170.10.0.0 because Router A does not redistribute network 170.10.0.0 into an IGP that is running between them.
    • Therefore, traffic the Router B sends to network 170.10.0.0 via Router E is dropped.
  • If Router B advertises to AS 400 that it can reach 170.10.0.0 before Router E learns about the network via IGP, traffic coming from Router D to Router B with a destination of 170.10.0.0 will flow to Router E and be dropped.
• In the above scenario, the synchronization rule states that:
  • If an AS (such as AS 100) passes traffic from one AS to another AS, BGP should not advertise a route (route 170.10.0.0 in this case) before all routers within the AS (AS 100) have learned about the route via IGP.
  • In this case Router B waits to hear about network 170.10.0.0 via an IGP before it sens an update to Router D.
• There are cases where synchronization can be disabled to allow BGP to converge faster. However, this can result in dropped packets if the following conditions are not met before disabling:
  • Your AS does not pass traffic from one AS to another AS.
  • All the transit routers in the AS run BGP.
• In the past it was best practice to redistribute BGP into IGP running in an AS.
  • In this case, IBGP was not needed for all routers in the transit path. By default, synchronization was on to make sure packets did not get lost.
• As the Internet grew, it has become more and more impractical to redistribute every single prefix into the IGP, therefore best practice was changed to not redistributing BGP into the IGP.
  • This required using IBGP on all routers in the transit path. In this case, synchronization was no longer needed. Thus, it is now off by default.

Synchronization Rule

• Enable synchronization if there are routers in the BGP transit path in the AS that are not running BGP.
  • With synchronization on, BGP should not advertise a route before all routers in the AS have learned about the route via IGP.
  • A router learning a route via IBGP waits until the IGP has propagated the route within the AS and then advertises it to external peers.
• Disable synchronization if routers in the transit path in the AS are running full-mesh IBGP.
  • With synchronization off, BGP can use and advertise to external BGP neighbor routes learned form an IBGP neighbor that are not present in the local routing table.

TCP and Full Mesh

• Because of its ability to move a large volume of data reliably, TCP is an appropriate transport mechanism to use for BGP.
• As opposed to the one-to-one windowing capability of OSPF or EIGRP, TCP allows BGP to take advantage of its unique window scaling capability to handle a huge volume of traffic, such as the Internet routing table.
• TCP sessions cannot be multicast or broadcast because TCP has to ensure the delivery of packets to each recipient.
  • Because TCP cannot use broadcasting, BGP cannot use it either.

BGP Tables

• BGP keeps a separate table from the IP routing table.
• Some of the common nomenclature use to describe the BGP table are:
  • BGP Table
  • BGP topology table
  • BGP topology database
  • BGP routing table
  • BGP routing database
• The router can be configured to share information between the BGP table and the IP routing table.
• BGP also has a neighbor table containing a list of neighbors with which it has a BGP connection.
• BGP adjacency must be configured explicitly for each neighbor. A TCP relationship is formed with each configured neighbor.
  • To keep track of the adjacency state, a BGP/TCP keepalive message is sent every 60sec.
• After an adjacency is established:
  1. The neighbors exchange the BGP routes that are in their IP routing table.
     • Each router collects these routes from each neighbor with which it successfully established and adjacency and places them in its BGP forwarding database
  2. All routes that have been learned from each neighbor are placed in the BGP forwarding database.
  3. The best routes for each network are selected from the BGP forwarding database using the BGP route selection process.
  4. The best routes are offered to the IP routing table.
  5. Each router compares the offered BGP routes to any other possible paths to those networks in its routing table, and the best route, based on administrative distance, is installed in the IP routing table.
     • EBGP routes have an AD of 20.
     • IBGP routes have AD of 200.

BGP Message Types

• BGP defines the following message types:
  • Open
    • The first message sent by each side.
  • Keepalive
    • If the open message is acceptable, a keepalive message confirming the open message is sent back by the side that received the open message.
  • Update
    • When the open is confirmed, the BGP connections is established, and update, keepalive and notification messages can be exchanged.
  • Notification
    • These are sent in response to errors or special conditions.

BGP Message Type: Open

An open message includes the following information:

• Version – an 8-bit field that indicates the version of BGP. The highest common version that both routers support is used. Current version is BGP-4.
• My Autonomous System – A 16-bit field that indicates the sender’s AS number. The peer router verifies this information; if it is not the AS number expected, the BGP session is torn down.
• Hold Time – A 16-bit field indicating the maximum number of seconds that can elapse between the successive keepalive or update message from the sender. Upon receipt of an open message, the router calculates the value of the hold timer to use by using the smaller of its configured hold time and the hold time received in the open message.
• BGP Router Identifier (Router ID) – 32-bit field that indicates the BGP identifier. The BGP router ID is chosen the same way the OSPF ID is chosen:
  1. Statically configured
  2. Highest loopback Address
  3. Highest active IP Address
• Optional parameters - A length field indicates the total length of the optional parameters in octets. These parameters are Type, Length, and Value (TLV)-encoded.
  • Session authentication is one example.

BGP Message Type: Keepalive

• BGP does not use any transport protocol-based keepalive mechanism to determine whether peers can be reached.
• Instead, keepalive messages are exchanged between peers often enough to keep the hold timer from expiring.
  • If the negotiatied hold time interval is 0, periodic keepalive message are not sent.
• A keepalive message consists of only a message header.

BGP Message Type: Update

• An update message has information on one path only.
  • Multiple paths require paths require multiple messages.
  • All attributes in a message refer to that path, and the networks are those that can be reached through that path.
• An update message might include the following fields:
  • Withdrawn routes – A list of IP address prefixes for routes that are being withdrawn from service, if any.
  • Path attributes – The AS-path, origin, local preference, and so forth (will be disussed in next post).
    • The attribute type consists of the attribute flags, followed by the attribute type code.
  • Network layer reachability information – A list of IP address prefixes that can be reached by this path.

BGP Message Type: Notification

• A BGP router sends a notification message when it detects an error condition.
• The BGP router closes the BGP connection immediately after sending the notification message.
• Notification messages include an error code, and error subcode, and data related to the error.

BGP Neigbor States

• BGP is a state machine that takes a router through the following states with its neighbors:

• • Idle
  • Connect
  • Active
  • Open sent
  • Open confirm
  • Established
• Only when the connection is in the established states are update, keepalive, and notification messages are exchanged.

• Keepalive messages consist of only a message header and have a length of 19 bytes.
  • The are sent every 60 seconds by default.
  • Other messages might be between 19 and 4096 bytes long.
• The default hold time is 180 seconds.

Resources:

1. Cisco – Internetworking Case Studies Using the Border Gateway Protocol for Interdomain Routing
2. Synchronization – Using BGP for Interdomain Routing – Internetworking Case Studies – Cisco

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.

• BGP routers exchange network reachability information, called path vectors, made up of path attributes.
• The path vector information includes:
  • A list of the full path of BGP AS numbers (hop-by-hop) necessary to reach a destination network.
• Other attributes include:
  • IP address to get to the next AS (next hop attribute)
  • Information about how the networks at the end of the path were introduced into BGP (origin code attributes).
  • There are other attributes that will be discussed later.
• The BGP AS path is guaranteed to be loop free.

A router running BGP does not accept a routing update that already includes its AS number in the path list, because the update has already passed through the AS, and accepting it again we result in a routing loop.

• By applying routing-routing policies to the path of BGP AS numbers, routing behavior can be enforced at the AS level to determine how data will flow through the AS.
  • These policies can be implemented for:
    • All networks owned by an AS.
    • Certain CIDR block of network numbers (prefixes).
    • Individual networks or subnetworks.
  • These policies are based on the attributes carried in the routing information and configured on the routers.
• BGP can advertise only the routes it uses.

BGP specifies that a BGP router can advertise to its peers in neighboring autonomous systems only those routes that it uses. This rule reflects the hop-by-hop routing paradigm generally used throughout the current Internet.

• There are some policies that cannot be supported by hop-by-hop routing and thus require other technique in order to implement.
  • One example is that BGP does not allow one AS to send traffic to a neighboring AS with the goal of manipulating the traffic to take a different route from that taken by traffic originating in that neighboring AS.
  • In other words, you cannot influence how a neighboring AS will route your traffic, but you can influence how your traffic gets to a neighboring AS.
• To illustrate the idea enumerated on the two bullet points above, consider the following example:
  • In the above diagram, AS 64520 advertises to AS 64512 only its best path: 64520 64600 64700
  • This path is the only path through 64520 that AS 64512 sees.
  • All packets that are destined for 64700 via 64520 take this path, because it is the AS-by-AS (hop-by-hop) path that AS 64520 uses to reach the networks in AS 64700.
    • AS 64520 doe not announce any other paths because it does not choose any of the other possible paths as the best paths, based on the BGP routing policy in AS 64520.
  • Even if AS 64512 knows of any other paths through AS 64520 and wants to use it, AS 64520 will not allow the packets to route to any other paths, because AS 64520 selected 64520 64600 64700 as its best path, and all AS 64520 routers will use that path based on BGP policy.
    • BGP does not enable one AS to send traffic to a neighboring AS intending that the traffic take a different route from that taken by traffic originating in the neighboring AS.
  • AS 64512 has an option to use AS 64520 or AS 64530 to reach AS 64700 based on its own BGP routing policies.

When to Use BGP

• BGP is more appropriate to use when at least on of the following conditions exists:
  • The AS allows packets to transit through it to reach other autonomous systems (for example, it is a service provider).
  • The AS has multiple connections to other autonomous systems.
  • Routing policy and route selection for traffic entering and leaving the AS must be manipulated.
• BGP allows an enterprise to differentiate between its traffic and traffic from its ISP. Therefore BGP is an option if this differentiation is required.
  • A static route to an ISP will not distinguish whether a certain traffic is from the enterprise or from the ISP.
• BGP is the protocol that is used to implement an agreement between to or more autonomous systems to exchange updates.

When Not to Use BGP

• BGP should not be used if the following conditions are true:
  • A single connection to the Internet or another AS
  • Lack of memory or processor power on routers to handle constant BGP updates.
  • Limited understanding of route filtering and the BGP path-selection process.

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

• BGP is categorized as an advanced distance vector protocol.
• It is defined in RFC 4271, A Border Gateway Protocol (BGP-4).
• It uses Transmission Control Protocol (TCP) as its transport protocol.
  • It uses TCP protocol 179 to deliver BGP information.
  • These TCP segments are carried inside IP packets.
  • By contrast:
    • RIP uses UDP as its transport mechnism
    • IS-IS resides on the network layer.
    • OSPF and EIGRP reside directly above the IP layer.
  • TCP somewhat simplifies the delivery mechanism of BGP by handling acknowledgment, retransmission, and secquencing of packets.
  • TCP uses the concept of sliding windows when handling deliveries of packets. This allows a larger number of update packets to be received at one time. This can be a difference of an OSPF, for example, that will handle routing for 100 subnetsm while BGP can easily handle 200,000 subnets.
    • In contrast with BGP, OSPF and EIGRP use a one-for-one windowing, such as when OSPF or EIGRP has to send multiple packets, the next packet cannot be sent until an acknowledgment from the last packet sent is received.
      • TCP uses a dynamic window, which allows for up to 65,576 bytes to be outstanding before it stops and waits for an acknowledgment.
• BGP is an Interdomain Routing Protocol (IDRP), which is also an EGP.
• The main goal of BGP is to provide inter-domain routing system that guarantees the loop-free exchange of routing information between autonomous systems. BGP routers exchange information about paths to destination networks.

Autonomous System

A set of routers under the single technical administration, using an Interior Gateway Protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other [autonomous systems].

-RFC 4271

• Interior Gateway Protocol (IGP)
  • A routing protocol that exchanges routing information within an autonomous system (AS). Examples are: RIP, OSPF, EIGRP, IS-IS.

• Exterior Gateway Protocol (EGP)
  • A routing protocol that exchanges routing information between different autonomous systems. BGP is the most predominant example.

• The Internet Assigned Numbers Authority (IANA) allocates the AS numbers
• Within IANA, several regional  corporations administer and registers IP addresses and AS for their respective region.
  • African Network Information Centre (AfriNIC) – African continent.
  • Asia Pacific Network Information Centre (APNIC) – Asia/Pacific.
  • American Registry for Internet Numbers (ARIN) – Canada, US, parts of Caribbean and islands in North Atlantic Ocean.
  • Latin American and Caribbean IP Address Regional Registry (LACNIC) – Latin America and parts of the Caribbean.
  • Reseaux IP Europeens Network Coordination Centre (RIPE NCC) – Europe, Middle East, and Central Asia.
• The AS designator is a 16-bit number ranging from 1 to 65535.
  • RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System (AS), provides guidelines for the use of AS numners.
  • AS range numbers 64512 to 65535 is reserved for private use.

Comparing BGP to Other Routing Protocols

• Most link-state routing protocols such as OSPF and IS-IS require a hierachical design – it allows a large network to be broken down into smaller networks called areas.
• EIGRP and BGP do not require a hierarchical topology.
• Internal routing protocols such as RIP, OSPF, EIGRP, and IS-IS use path costs (quickest path) to get to their destination, using certain metrics.
  • RIP uses hop-counts. The fewer the better
  • OSPF uses cost, based on bandwidth as its metric.
  • IS-IS uses a metric based on bandwidth, which defaults to 10.
  • EIGRP uses a composite metric, with bandwidth and accumulated delay considered by default.
• BGP, in contrast to the protocols mentioned, does not look at speed for the best path. Rather, it uses multiple BGP attributes to influence traffic flow between Autonomous Systems.
  • BGP-enabled routers use path vectors or attributes – network reachability information.

BGP in an Enterprise Network

• BGP is more suitable in an enterprise if using multiple ISPs to connect to the Internet.
  • If the enterprise has only one connection to one ISP, BGP might not be the best choice.
• BGP allows an enterprise with multiple connections to decide the best and optimal path by manipulating BGP path attributes.
• External BGP (EBGP) – when BGP is running between routers in different AS.
• Internal BGP (IBGP) – when BGP is running between routers in the same AS.

Multihoming

• Multihoming is when an autonomous system has more than one connection to the Internet.
• Typical reasons for multihoming are:
  1. Reliability – If one connection to the Internet fails, the other connection is available.
  2. Performance – By using better paths for certain destinations, performance may be increased.
• Multihoming can be accomplished with multiple connections to a single ISP or multiple connections to mulitple different ISPs.
• It is preferable to multihome with multiple ISPs instead of one:
  • It has redundancy with multiple connections
  • It is not limited to the policy of a single ISP
  • Has more paths to the same networks for better policy manipulation.
• Three common ways to multihome with BGP are:
  1. Passing only a default route to the AS – each ISP passes only defualt route to the internal routers
  2. Passing only a default route + specific routes owned by the ISP - each ISP passes defualt route and their own routes to the AS internal routers, or all internal router in the trqansit path can run BGP and pass routes between them.
  3. Passing all routes to the AS - Each ISP passes all route to the AS, with all internal routers int he transit path running BGP and passing all the routes between them.

Option 1: Only Default Route

• With this option, a router within an AS learns about multiple default routes – these are routes sent by the ISPs.
• In this case the local IGP chooses the best default route for this router and installs it to the routing table. From its perspective, the router takes the default route with the least-cost IGP metric.
  • The IGP default route will then route packets destined to the external networks to an edge router of this AS, which is running EBGP with the ISPs.
  • The edge router will use the BGP default route to reach all external networks.
• For incoming traffic, the decision about which route to take is decided within the ISP
• Some limitations of this option are:
  • Path manipulation cannot be performed because only a single route is being recieved from each ISP
  • It is extremely difficult to manipulate bandwidth. It can be accomplished only by manipulating the IGP metric of the default route.
  • Diverting some of the traffic from one exit point to another is challenging because all destinations are using the same default route for path selection.

Option 2: Send Default Routes and Partial Routes

• With this option all ISPs pass default routes and select specific routes to the AS.
• Generally, the partial routing table that is sent to the AS include the networks that the ISP and its customers own.
• If an ISP passes the partial route information to a customer, this customer can redeistribute these routes into its IGP. By doing this, packets destined to an outside network can take the nearest exit point based on the best metric of the specific network- as opposed to taking the nearest exit point base on the default route.
• Routes to other autonomous systems that were not passed by the ISPs are decided by the IGP metric that is used to reach the default route within the AS.

Option 3: Full Routes From All Providers

• All ISPs pass all routes to the AS, and IBGP is run on at least all the routers in the transit path in the AS.
• This option allows the internal routers of the AS to take the path through the best ISP for each route.
• Uses a lot of resources within the AS because it must process all the external routers.

Resources:

1. Border Gateway Protocol – Wikipedia
2. RFC 4271: A Border Gateway Protocol (BGP-4)
3. RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System (AS)

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet, as well as following the links on the resources section of this entry.

On Thursday night I completed my challenge and clocked in 1:43:04 of study time. I know it’s not exactly 2 hours that I set out to do. But I gave myself some leeway because I never clocked the time I setup lab and some missed time on the clock as well. Also I was under pressure to get the studying done because I had to learn a few songs that night before leaving on Friday night for the weekend retreat.

I just want to jot down a few thoughts about the weekend. It definitely was something that I probably needed in this moment of my life right now. Although I was busy switching roles from being the music guy to a dish-washer , I had the opportunity to listen in to some very good talks. Since it is a spiritual retreat, a lot of it was centered on religious topics. I think what I enjoyed the most, though,  were the talks that centered on the family and the issues that affect family life. As a father and a husband, I constantly need a reminder what I’m doing all this for. All this studying and pursuit to becoming a better engineer is inspired by my desire to be a better provider for my family. And I guess sometimes I lose track of that especially when I am too deep into my studies. There are even occasions where I ignored my son while studying when I was supposed to be watching him.

During the retreat, I was particularly inspired by a gentleman, about my age, who was invited to speak to our guests about importance of family in the context of Christian living. The cool thing about it is that I knew this guy from a while back from playing in a basketball league together. I only knew him from seeing him on the courts, but I never had a deeper insight into his life until he had spoken to us. After he spoke I took some time to congratulate him and talk to him a little bit more about his ideas on family living. I was pleased to learn that his goals for his family is in line with my goals for our family. His wife is a stay at home mother, raising their two beautiful kids to be stewards of greatness. And no matter how poor they get, he says, he makes sure that they remain that way. And I believe him. Because no mater how successful he has become as a banker, I see them driving a very modest vehicle, and living in a modest home.