Head on over and congratulate:

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

Caveat lector: Some information I share herein are findings from my own research and are not found in any documented sources where it can be confirmed or supported. Often times my findings had conflicting results and however you choose to act based on the information I provide should be taken with extreme care. In other words, I don’t know what the hell I’m talking about and if you find out that I was wrong and you still chose to take what I said as reputable fact, then you clearly overestimated my intelligence.

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?

Just how many IP addresses can you have with IPv6? To put it in dramatic contrast (and for fun), we’ll put the numbers in comparison to the current and more popular IPv4 implementaation:

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

This was brought to my attention this morning:

..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.

• PIM stands for Protocol Independent Multicast.
• The “protocol independent” part of the name refers to the fact that PIM uses the unicast routing protocol table to locate unicast addresses, regardless of how the table learned the addresses.
  • That is, the table could be formed by any unicast routing protocol such as EIGRP, OSPF, etc. and it does not have any bearings about its relationship with PIM.
• Unlike some unicast routing protocols, however, no routing updates are sent between PIM routers.
• Keep in mind that unicast routing protocols use multicast packets (or broadcast in some cases) to send their routing update traffic.

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.

Multicast Sessions

• 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.

Multicast

• 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.

I did not study one lick this weekend. I thought I was going to put in at least 5 hours combined, but I didnt realize how busy I was going to be. It seemed like I was in church the whole time. On friday night, I was able to study for about an hour, but I had to leave for church to attend choir practice after that. Saturday morning was spent mostly in church, partly practicing and the rest was playing the piano for a Mass. In the afternoon, I had to attend a friend’s baby shower. Then on Sunday morning, had to sing for church again and after that went to another church to attend a friend’s baby’s baptism. That was followed by a nice reception at a hole-in-the-wall Mexican restaurant, but with excellent food.

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.

Who’s talking and what some think:

• 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

Recently, I’ve been thinking – one of the rare moments that I do – if I should press on with getting my CCNP or not. Here’s where I’m at: I know that I want to one day pursue the CCIE. First I thought I’ll get there when I get there. But now (largely because of support and encouraging wave of the CCIE community and their own pursuit) I am more firm in my desire to go for it. I am more confident that I’m not alone or just a stranger stuck in a solitary and lonely pursuit of it. There’s actually a lot of folks out there that are trying it and going for it; folks that are more advanced in their knowledge of the technologies, as well as those who don’t know jack – take me for example.  

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.