Archive for the ‘Uncategorized’ Category

h1

Been a while.

September 18, 2009

Its been a while, and for that im sorry.

I have been very busy watching VOD (Video On Demand) classes from IPexpert. Scott Morris has done these videos, and he is pretty good at it in my opinion. There are alot of new stuff as well. Things such as Multilink Frame-relay (FRF.16) and PPP over frame-relay. IRB (Integrated Routing and Bridging) was also new for me. Basically you can extend your L2 over a L3 ip routed network. All very interesting stuff.

I have also spent quite some time picking up my physical exercise plans. I am beginning to notice a difference in my attention span and general tiredness. Attention span going up while tiredness going down. This is good :)

Last time, i wrote about putting together a home lab compared to renting lab time, and what options you would have. I would like to give some more information on this here.

As far as i see it, first of all you need to figure out what sort of budget you are working on. Using rack-rental is more flexible budget wise, in that you can purchase the time you need, and nothing more. This will probably save you in the long run. The big drawback of this solution is that you can only use your allotted time on the rack. That means that if you have a slot for 8 in the evening until midnight, thats when you will practice your technologies. If you dont feel like it, or are not prepared to do it at that time, you waste the slot you paid for. You cant study something, and then wanting to test it out quickly, right there and then. As mentioned, this is a big drawback, at least for me.

The other option is to build your own home lab, where you can practice everything, and physically touch it! (at least some of it). This option is far more expensive no matter how good you are at finding the right stuff and the right price.

On a side note, if Cisco really wanted to help students out, they should have a rental plan in place. You would be able to rent the physical gear from them for a period of time, and return it after you are done with it. Ofcourse there are some costs involved in this, but it would mean you could get physical access to the exact gear thats being tested on the lab exam.

I chose to build my own lab. The main reason for this, is that i like to have gear available to me when i need it, and not go about selecting when i think i might need it. The last piece of this puzzle should arrive any day now. Will elaborate more when i get everything running.

After this, I need to relocate the lab to a different location, since my internet connection at home will be down for a while. I will then have access to the entire rack remotely at any time.

Right now… back to VOD.

h1

Study and flashcards.

August 15, 2009

I have mentioned it before, and i’ll do it again. Flash cards are great for remembering those pesky little details.

I wanted to share the flashcards I have created so far:

http://flashcarddb.com/cardset/24460-cisco-flashcards

Hopefully you can get some use out of them. Ofcourse they are some of the details I have a hard time remembering, but maybe you’ll have some use for them as well.

Enjoy!

On another note, I got access to another 3550 switch which should arrive sometime next week. That brings it to a total of 2x 3560’s and 2x 3550’s on the switch side. This should be able to cover the IPexpert R&S topology. Now I just need the remaining routers.

I also got access to a place where I can setup the lab when I relocate. This will put it on a permanent internet connection, so I can access it from everywhere. I have put down some  money to cover the costs of electricity for having it running 24×7 for the next 6 months at least.

All thats left is to get the rest of those USB NIC’s. I figure i need 12 more to make it complete. I have a guy who will check out if i can get a good discount on them when im buying that many. Hopefully i’ll get an answer to that sometime this week as well.

I am beginning to brainstorm some ideas regarding the study plan. I have also put away a decent amount of cash to pay for the bootcamp, which i hope i will be able to do in either december or january. This all depends on the material comming out from IPexpert on the new V4 blueprint.

Tomorrow is moving day, so no posts there, but hopefully ill get my USB 3G adapter sometime during the week, so I can access the wonderful lab from anywhere :) Its got a 5Gb cap on it, but just by ssh/telnet, i should come nowhere near that!

Now off to gather some more thoughts on the study plan!

h1

The battle for bandwidth.

July 15, 2009

So I saw a post over at Ioshints about bandwidth, how we, as consumers come to expect a certain bandwidth, and how ISP’s are dealing with these issues.

It is a fact that ISP’s greatly oversubscribe their networks, and keep selling more access-lines with an even greater bandwidth cap than ever before.

So lets explore some of the factors in this bandwidth revolution!

The (very) near future:

New types of network devices and services is one of the reasons why people need more bandwidth. Also, traditional types of devices that was not internet enabled are now becomming just that. Think IP-phone, security systems, DVR’s and so on. Some of these are not bandwidth hogs, but they are very intolerant toward jitter and loss.

More and more content requires an even larger pipe. An example of this is the new Xbox360 offering of providing HD movies to the home. A requirement for this is at least 8Mbps connectivity. Thats 8Mbps effective bandwidth. Not what you pay for each month, but what you are actually getting. A real-life scenario of a typical family utilizing this offering, is 8Mbps purely for the movie for you and your spouse, maybe 1-2Mbps for one of your kids playing online games and maybe up to 1Mbps for the other kid to play around with photoalbums on facebook. Thats 11Mbps you need to avoid any bad user experience (choppy video, lost connections to game servers, and long waiting times on facebook).

From this perspective, the day where we absolutely must have 20Mbps to enjoy the offerings of a digital lifestyle is approaching rapidly. So where are we at now?

Current situation:

At home, I have an 8/2Mbps ADSL line. 8 Down, 2 Up. But even under the best of circumstances I never get more than 6Mbps. This is also a line from a very respectable service provider, which is rock solid, great support, and generally a good all-round ISP. Now in my case the difference can be due to simple distance, or bad wire drops somewhere (we all know ADSL’s inherent distance limitation). According to my ISP however, the impedance on the line should provide me with the full 8Mbps. Alas, my line could be experiencing oversubscription on something else than the access-link to the ISP (PPPoA).

Another example of how this scenario plays itself out. My dad’s house is in a fairly large city, very close to the POP of the ISP, and they firmly states they will provide him with 20Mbps down, but no matter what has been tried, nothing above 8Mbps is possible. The tech-support again, says it should be possible to at least double that stating impedance measurements again.

I could name several more cases like this where what you pay for is a factor of 2 more than what you get.

Thats the technical current situation, what about the non-technical side?

Well, this is where it gets pretty bad indeed. Almost all ISP’s im aware of has a large marketing department that is busy getting new customers as well as hanging on to the ones they have. The first part of this is the new users.

New ISP users:

How many of you have missed any commercials stating something along the lines of: “Now with 20Mbps connection, for the low price of X$/month”? Almost all of us have thought that this was a better deal than the one we have now. But as I outlined in the current situation, this is pretty much hot hair by the marketing department. There are so many cases where the small blueprint will tell you that this connection will only be 20Mbps if the copper (a bit more on the media type later on as i have some different experience here) is the best of the best, there are no cable hinderance in any way, the planet is aligned with the right stars on the right time of day and on and on. In reality you are not getting what you are paying for. Thats the hard fact in most cases.

Imagine going to a car dealership and being told that this certain model of a car will go 20Km/Litre, and later finding out it only does 10. How will you feel about this? will you be up in arms complaining? I certainly would. So why is this not happening in the ISP consumer market?

Well, for one thing, we are just now starting to see applications that fully utilize these bandwidth limitations. HD video, photographs all over the place, Web 2.0, streaming back and forth, file access from everywhere, data at your fingertips. Lack of knowledge by the consumers also does not lead to complaining at the ISP’s. If you tell your non-geeky friends to meassure their internet connectivity, do you think they could? I doubt it… Because of the successful marketing campaigns, all the knowledge they have of broadband is that bigger is better. In 7 out of 10 cases users wont attribute a bad internet experience as being the fault of the internet provider itself, but rather as because of the service they are using (facebook, online gaming and so on), or even if they do realize “this internet is slow”, they might think: “well, 20Mbps is not enough, I MUST get 30Mbps”, feeding into the ISP marketing campaigns again.

Current ISP users:

The second part of the marketing raving, is about keeping existing customers. In almost all markets, where competition is fierce you will see that the price-point is where competition really flares up. In the ISP market however, they (as in ISP’s) have managed to make it about more bandwidth for the same price! Again, I have several first hand examples of existing customers receiving a letter stating: “You will now  be upgraded to a 2x<whatever Mbps you had before> for the same low price each month!”, all in an attempt to keep their customer base from switching to another ISP whois advertising based on the above-mentioned way of doing things. “How can they do this?” is what im asked more and more often. Well, they dont. And in the best case its false advertising. There are laws for these sort of things, at least in Denmark, and im amazed no one is calling their bluff. Its all in an attempt to keep you as a paying customer.

These two types of behavior really p*sses me off alot. But its part of the ISP’s toolbox to stay in control.

So technically, whats really going on here?

Well, there’s quite a few things, many concerning bandwidth management and profiling users.

Profiling:

What follows is a guess on what ISP’s do to customers, since I dont have any direct relationships to any ISP’s, nor any experience in deploying ISP networks. I do however read alot about these technologies and about how users are experiencing their service, and from this i can make an educated guess on the technical decisions going on inside an ISP.

First of all, lets talk about idle times and unused bandwidth. Above I wrote alot about the near future, but at the present alot of sold bandwidth is unused. As im writing this, im sitting in a hotel room, using their wireless service. I have been using that for most of the day. I have some network applications open, including a webbrowser (Firefox) connected to about 15 sites, most of them just normal passive webpages, no constant reloading or anything but a few being the famous Web 2.0 are interactive and watching my every move and reloading content and so forth, I also have Microsoft Messenger running, Tweetdeck updating at regular intervals, my mail client (Thunderbird) also retrieving mails every now and again, on top of that Skype is also doing its thing. The only real constant bandwidth usage is from streaming internet radio and my pinging a few internet hosts. This is typical workstation usage for most people most of the time. I am using around 130Kbps a second, which seems to be right since my radiostream is a 96Kbps stream + the other stuff going on.

This “profile” also matches what im doing when im at home on my 8Mbps. My girlfriend is a heavy user of Facebook, always looking at photoalbums from friends and family. Lets say that we as a couple use 1Mbps on average during all daily hours. Lets also assume that my ISP was actually capable of providing me with the full 8Mbps downrange capacity. That still leaves 7Mbps on average to be consumed.

As you can see from this, this is a great opportunity for ISP’s to oversubscribe their networks. Even from the home to the DSLAM you are certainly able to do a 1:4 over subscription just to be on the safe side. This is even before data has ever reached the core of their network. With this sort of profile, ISP’s dont need to have a full 1:1 capacity from the DSLAM’s to their backbone, again giving them some leverage to avoid having to upgrade the line capacity between the DSLAM to the backbone. In alot of ISP scenarios, utilizing existing network infrastructure (translate: copper), is a huge saving compared to biting the bullet and digging down fiber cables.

Here comes the catch. How do you handle “out-of-profile” users? For example a family with a young teenager using P2P sharing programs? This one kid can bring down the “saved up” bandwidth, because he/she will be using the full bandwidth the line can provide. So again, if we use 8Mbps as an example, instead of having a profile stating 1:8, it will now be 1:1. If this happens all over the place, oversubscription is not possible because the ISP’s must try to deliver the CIR (Commited Information Rate), rather than the PIR (Peak Information Rate). In the end, if enough of these out-of-profile users are on the same segment, an investment in infrastructure is unavoidable… or is it?

As it turns out, it is not unavoidable. Technology makes profiling based on your network usage possible, and hence makes it possible to take action against those who you consider out-of-profile, even though they have done nothing wrong in regard to bandwidth utilization. We have seen this on the online newsoutlets of late. ISP’s throttling bandwidth if users are using P2P programs by doing TCP resets, bringing down the used bandwidth to the level they (ISP’s) want, instead of the CIR they sold to the customer.

Lets switch gears, and provide some good news. Fiber to the home. This is becomming more and more popular, especially in Scandinavia. This basically provides unlimited bandwidth from the home to the backbone. This is great right? Well, sort of. A problem arises here as well. ISP’s have put alot of money into fiber backbones, being able to handle alot of user load, but they still must go through other Tier ISP’s, and they must still pay for it. So even though a user can get 1 Gbps of connectivity to the ISP, that ISP cannot provide 1 Gbps to the rest of the internet, so you are scaled down there as well. Good news: You have unlimited bandwidth to the backbone.

To boil it all down, the ISP’s are oversubscribing lines. The customers think they are getting what they are paying for. The marketing departments are making promises they cant keep. The customers keep throwing money at stuff they are not getting.

What im calling for is transparency. Dont screw your customers by selling them snake-oil. Let them know what they are getting, and tell them you are profiling. Dont keep customers based on false promises.

At some point, if this all continues, you will have a bubble that will burst. Customers wants new media, in more ways than ever before. They will be very unsatisfied realizing they cannot get that media, because the bandwidth they thought they had, and have been paying for for years, simply doesnt exist in reality.

Its an undeniable fact that investments in more and more bandwidth is nessecary. It is also undeniable that the cost of these investments are too much to bear for many ISP’s without increasing cost of access. Until then, the ISP’s are profiling. So do the right thing, and let your customers know about it!

These things need to reach some sort of equilibrium to make ends meet. Otherwise we are all doomed!! :)

Had to get that off my chest. Thanks!

h1

Spanning Tree (802.1D) – Part 1

July 1, 2009

Ive spent the last couple of days playing around with the traditional Spanning-tree protocol (802.1D), which has been used for many years, but is pretty slow to converge.

As most of you know, Spanning-tree protocol (STP), is used to build a loop-free L2 topology. This is done to avoid bridging loops, where your frames gets sent around and around endlessly.

STP does this by assigning ports a certain role and a state. It uses BPDU’s, bridge protocol Data Units, to communicate with other switches.

The first task of STP is to elect a root-bridge (switch) of the network, which is a central point in the L2 network. From a design perspective, its placement is very important as it will handle most of the traffic load, and links toward it will be put into a state where data passes through. So make sure the switch is beefy and correctly placed in your network.

The root-bridge is elected by use of two things passed along in the BPDU. Namely, priority and Mac address. Priority takes precedence, and the Mac address will be used as a tie-breaker.

The Bridge ID format comes in two varieties, the old style and the new style. Originally the Bridge ID was 8 bytes in total, with the first 2 bytes being the priority and the remaining 6 bytes the mac address. The new format takes the first 4 bits to the priority field, and the next 12 bits to be the VLAN ID, the last 6 is still the mac address. This way a BPDU can be seperated to which vlan it belongs to.

Root Port:

When the root bridge has been aggreed upon by all switches, each switch needs to find the optimal way to reach the root. This is done by comparing the BPDU’s received on all interfaces. The BPDU which will result in the least interface cost, becomes the best path to the root, this port is called the root-port. So the cost you ask, what is the cost? Each interface with a certain bandwidth has a cost in STP. By the new definition a 100 Mbit interface has a cost of 19. A gigabit interface a cost of 4, 10Gbit is 2, and if there’s still a 10Mbit, that has a cost of 100.

So each switch sends out to its neighbors, what its own cost to reach the root is, and the neighbor then adds its cost to that neighbor. As said, the one with the least cost, becomes the root port. The root port, is always in a forwarding state, which means it can pass data through the port.

Other Ports:

What about the other ports? The other ports can either be a designated port, or a blocking port. But thats more their state. A designated port, is a port that forwards data onto a link-segment because it had the best cost to reach the root. How is this selected? Well, either by the best cost to the root, or the best priority of the switch sending the BPDU, or by Mac address as a tie-breaker. The switch that wins on that segment puts its interface into a forwarding state. The one that looses, puts its interface into a blocking state, which means that the port will not pass any data. This is where the bridging loop is broken. By selecting some ports to block.

On the root bridge, all ports are designated, and hence in a forwarding state. This is a direct result of being the root-bridge.

Port States:

A port can be in a single state at any given time. These states are:

  • Disabled
  • Blocking
  • Listening
  • Learning
  • Forwarding

The disabled state, simply means that the port is not active in the STP. Most likely because it have been shut down. The blocking state is the state a port will reach if it is not a root port, and not a designated port either. A blocking port does not forward data frames, nor does it send BPDU’s. All it does is listen to BPDU’s, listening for any topology change.

The listening state is the state a port will enter when there has been a topology change. In this state the port sends and receives BPDU’s to determine root port and designated port on a segment. No data frames are forwarded in this state.

The learning state is the next-to last steps in order for a port to enter a forwarding state. In this state the port is listening to data frames, but not actually forwarding them. It does this in order to populate its CAM table, or mac-address-table, so that it wont flood more than nessecary when it starts forwarding frames.

In the last state, forwarding, we have a fully functional port, that is forwarding data frames, and all is working as it should. It relays BPDU’s received from the root on the root port, onto any designated ports, and if its the root port it just listens for these BPDU’s.

Timers:

Lets talk a bit about the timers that STP uses in order to complete its mission:

  • Max-Age
  • Forward Delay

The first one is the Max-Age timer, and to be honest, this one has really given me a lot of grief. What I can cook it down to, is how long a port will keep the best BPDU it has learned on this port. So every time the best BPDU goes through a switchport, it resets the Max-Age timer. This becomes important when you start learning inferior BPDU’s on the port, as I will demonstrate later. The Max-Age timer is 20 seconds by default. This value is propagated through BPDU’s from the root.

The second timer, is called the forward-delay. This delay is being used when going from one state to another. Namely from the listening state to the learning state, and the learning state to the forwarding state. This timer is also set on the root switch, and propagated down the spanning-tree. Defaults to 15 seconds.

So lets take a look at a topology to discuss STP’s behavior:

As you can see, we have 4 switches in this topology, with the links shown. I have marked each link being L1, L2 and so forth. Also note several other things, The cost of each link is also being depicted along with the port role of each port on each device.

In this topology Switch A has been selected the root bridge. This could be a direct result of it having the best priority, or simply the lowest MAC address. Either way, it has become the root switch, and the one all the other switches will reach somehow. Remember that all ports on the root bridge are designated ports.

Next the 3 switches have determined their root-port, marked as R in the topology drawing. This is a direct result of being the lowest cost path to reach the root. Lets examine this in further detail to clarify the root port selection. Lets take SWB as an example. When SWB first knows that SWA is the root switch, it has two ports to reach it through, if you look at the drawing, it can reach it directly through L1 or indirectly through L2 to SWC and then from SWC on L4 to SWB. On L1, the root bridge will send out a BPDU stating a cost of 0. This is natural since it doesnt cost anything to reach itself. SWB will receive this BPDU and add the cost of the link to the total path cost, which is now 19. SWB performs the same action for the BPDU being received from SWC. SWC also receives  BPDU with a cost of 0, adds 19 to the BPDU and relays it to SWB, SWB then adds 19 on top of that and the result is 38. So which is better, 19 or 38? Alas, it chooses L1 as its root port. This same procedure occurs on all three non-root switches, and ends up in them all figuring out their root ports.

The next big thing, is the designated port. One designated port is selected on any given link. The port sends out BPDU’s and forwards data (It is up to the “other end” to block the data). Lets proceed using SWB and SWC as our example. When each of them has determined their root port, they send out the relayed BPDU onto the L4. So what port becomes the designated port? Well, there is a selection like in all things Cisco :)

  • Lowest cost to root
  • Lowest Bridge ID
  • Lowest Port priority
  • Lowest Port number.

What this means is that the lowest Bridge ID, becomes the switch with the designated port. In this case it happened to become SWC (maybe its an older switch with a lower MAC address. Its irrelevant for further discussion). The same thing happened on L5 where SWD became the switch with the designated port.

All other ports, transition to the Blocking state, and shuts down for forwarding data. This is how the bridging loop is stopped.

Now we have a converged L2 network. All the links that should be up are up, and all ports that should be blocking are blocking. In my next post I will discuss certain topology change scenarios from this same L2 topology. Discussing directly connected link failure and loss of BPDU’s in the network and how that affects convergence. Stay tuned.

h1

Weekend roundup.

June 22, 2009

So I have started my review process. I have some things on my list that I need an in-depth look into.

Among these are:

  • IPv6 tunneling types.
  • Web Cache Communication Protocol (WCCP).
  • Some Frame-Relay workings, like FRF.12 and FRF.9.
  • Switching section in BCMSN, particularly MST.
  • Frame-relay traffic shaping.

These are the big ones I need to tackle. On top of this I need to review the entire exam certification guide. If I have time, I will also try to define all the terms, which is one of the tasks they (exam cert. guide) suggests that you do.

h1

PIM-SM, part 1

May 29, 2009

I knew it would be tricky before I even started with the multicast section, but not this hard :)

So I wrote about PIM-DM and its flooding behavior, and how it would make sure data was flowing from the source to the receivers. I will try to give some information about PIM-SM and also some further information on IGMP.

First of, lets define what protocols handles what:

  • IGMP (Internet Group Management Protocol).
  • PIM-SM (Protocol Independent Multicast – Sparse Mode).

IGMP is a protocol that allows end hosts to communicate with their directly connected routers. That means that when a receiver wants to “tune” into a multicast stream, it tells the router(s) about this through IGMP.

Querier:

A querier is selected for each LAN. The job of the querier is to keep a consistent state about which members are on this lan. There are two versions of IGMP currently in use (though IGMPv2 is the dominant one now), IGMPv1 and IGMPv2. The reason I bring up the versions is because the querier is elected differently depending on which version is in use. IGMPv1 relies on network layer protocols (such as PIM) to elect a DR (more on this later) and it will use this elected router as the IGMP querier. IGMPv2 has its own election process, where the router with the lowest IP address on the lan becomes the querier.

So how does the querier perform its job role? Well, each 60 seconds, it sends out an IGMP general query, which basically asks hosts: “What groups (if any) do you need data from?”, the hosts then reply with an IGMP report. This report is sent with the destination being the multicast group they wish to join/receive data from.

PIM-SM:

So now that we know how hosts inform routers on what they want, lets take a look at how a multicast-routing protocol works, specifically PIM-SM. PIM-SM is alot more complex than PIM-DM. The reason behind this is the difference in the basic assumption on who needs to receive data. If you remember from the previous post, PIM-DM assumes there are receivers on every subnet on the internetwork. PIM-SM starts out with the total opposite assumption, that there are only a few receivers scattered around the internetwork. The effect of all of this, is that we cant just flood the entire network, based on a push model, but we more or less need a pull model, where only parts of the network that needs multicasts will receive it. So how do you accomplish this?

As it turn outs, we need to select a central point in our internetwork, which will be the central point of connecting data. This central point is called the Rendevouz Point. (How this Rendevouz Point is selected is a topic on its own which I will cover in later posts). Remember we are still using the concept of trees, but where we in PIM-DM treats the source as the “root” of the tree, in PIM-SM we use the Rendevouz Point (here after RP) as the root.

When all routers know where this RP is located, when they want to receive data from a multicast group, they goto the RP instead of to the source. The “stream” of data will then flow from the RP down to the receiving routers and in the end to the receving hosts.

Before I go into further details it is important to figure out the mechanisms that are in place to perform these operations, hence some definitions below.

Lets define a few things regarding the usage of (*,G) and (S,G) entries:

  • (*,G) entries in PIM-SM always point towards the Rendevouz Point.
  • (S,G) entries will point in the direction of the source (not the RP).
  • RPF interface, Reverse Path Forwarding interface. The interface that points either to the RP (in case of (*,G) entries) or the source (S,G) entries).

Lets use this topology:

Assume that the source and the R1 router is connected on one lan, and the Receiver and R4 are on a seperate lan. Now the goal is for the receiver to receive the data the source is sending. Also, notice that R3 has been selected as the RP for this network.

Step 1 is the receiver sending out an IGMP report stating that it wishes to receive data from group 233.0.0.1. R4 being the only router on the lan picks this up and figures out, “hey im the DR, I must send this join up towards the RP”. Step 2, it does this by sending an (*,G) join, specifically a (*,233.0.0.1) join to the RP. This entry has an outgoing interface list of the lan on which the receiver is located and an incomming interface toward the RP (the RPF interface for the (*,G) entry). When this join is received by the RP (R3) as step 3, by PIM-SM rules, it too must create an (*, 233.0.0.1) entry. The entry will not have an incomming interface, because R3 IS the RP. It will however have an outgoing interface list, pointing directly toward R4.

This can be visualized as such:

At this point we have now created a shared tree from the RP to R4, which in turn will deliver the data to the receiver. (Note that right now we dont have any data flowing from the source at all).

Lets look at the states in the multicast routing table on R4 and R3:

R4:

(*, 233.0.0.1), 01:29:45/00:02:06, RP 192.168.0.1, flags: SJC
Incoming interface: serial1/0, RPF nbr 192.168.0.1
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 01:29:45/00:02:06

R3:

(*, 233.0.0.1), 01:31:19/00:03:10, RP 192.168.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
serial0/0, Forward/Sparse, 01:30:51/00:03:10

Notice that on R4, we have an incomming interface pointing towards the RP, the next hop neighbor being 192.168.0.1, which in this case is the RP itself, but it could be the next-hop router toward the RP. However on the RP itself, the incomming interface is Null and there’s no RPF neighbor. This indicates that this router is the RP.

So far, all is good, we have created a shared tree and our routers are behaving, but what about the actual data? Well, PIM-SM is a unidirectional protocol which means that it cannot go “up and down” its trees. Everything must flow downwards. In PIM-DM this was not an issue, since that was all that it did. So how do we get the data from the source to the RP itself? The answer is called the register message. When the source begins sending data, its DR on its lan will pick up that a source has data to send. It then searches for which RP to use, and in our case, finds that it must use R3. It then sends a unicast Register message to R3, with the multicast data included in this packet. When this is received by R3, it knows that a certain source has data to send for a certain group of which it has a shared tree. The RP then does something pretty slick. It sends (S,G) joins toward the source, in reality building a source tree (SPT) from the source (the closest router to the source) down toward itself.

When this SPT has been created, the RP sends a Register stop message to inform the closest router to the source (R1) to stop sending multicast traffic encapsulated in unicast packets (thats the whole point of multicast), because it receives the flow of data natively through the SPT tree.

Specifically it creates an (S,G) entry, and sends an (S,G) join towards R2, which also creates an (S,G) entry (along with the mandatory (*,G) entry), and sends a join toward R1. Now, when R1 started to receive traffic from the source, it automatically created an (S,G) entry with an incoming interface toward the source, but initially with no outgoing interface (because of the register message), but upon receipt of the (S,G) join from R2, it now populates the outgoing interface list to include the interface toward R2.

Our status right now is that we have successfully had a receiver join the multicast group 233.0.0.1. We have also managed to get our source to register to the RP through the register message. On top of that, the RP has set up a SPT (source tree) to the source, creating a way for data to flow from the source to the RP. Finally we have a scenario where data is flowing from the source down to the RP through a SPT and then further down to R4 by a shared tree, and our receiver receives his multicast stream! Great no?

Thats the closing statement of part 1 of this PIM-SM post. Next time I will write a bit about the optimization of PIM-SM. Stay tuned!

h1

ONT – Whats the deal?

January 15, 2009

I skimmed over the ONT blueprint, and it sure seems like alot of voice. I am not quite sure howcome theres that much voice material on there. It bothers me quite frankly, because I dont find the voice part particularly interesting. But alas, I digress, theres just one way to the CCNP, and thats through ONT.

I need to come up with a good study plan, to take into account my anxiety. So the deadline will not be set for quite some time. I am determined to use just as much time exercising as I do studying. A better use of google calendar will be part of this process. I will also use that for tracking my daily schedule as well.

Now, im on to planning in Google Calendar :)