text:
Trip Hawkins may have done our craft an unintentional disservice. While he's a pioneer in our business of video games and will be admired for generations to come, he's also the one that gave us the title "producer." Back in 1982 Hawkins, a founder of Electronic Arts, began using the term with the idea that we were "managers of creative artists", just like movie or music producers. There is truth to that. We do manage very creative people. However, the producer discipline can and should be considered so much more. When you ask what it means to be a Games Producer to an actual Games Producer you'll often get some hand wavy answer that speaks of "sheparding," "firefighting," and to "by God, get things done." I believe, however, that this ambiguous understanding about what we do leads to practices and methods within production that are simply uninformed and sometimes non-existent. Quite frankly, these are old school definitions and we're beyond that. Producers with no training likely have no formal methodologies. They have no real established and verified best practices. They operate mostly on instinct and apply practices they've created themselves over time. Some even scoff at training without understanding the benefits education offers. This lack of formal training is simply not acceptable in these days of AAA multi-million dollar game budgets.
And there's the rub. How do we make producers understand that they are much more than what their own discipline has led them to believe? And if producers don't know what they are, why would a team of talented creative artists, designers and programmers, often well trained in their own craft, know what they are either?
This article is based on my own experiences and past mistakes. I completely understand and accept that some people will disagree with me. I welcome all opinions and discussion. The job of producer can vary widely from company to company. While I'm passionate about this topic I certainly don't profess to know everything there is to know. Only through collaboration will I be able to formulate and improve on my findings. Your thoughts are appreciated so please share them with me directly at email@example.com
I am often asked "How do I become a producer?" by game players, college graduates, QA analysts, etc. It's a question that, sadly, they have often received poor guidance on. Also, it's the wrong question. You want to be a Good, Informed Producer. A "GIP", if you will allow the indulgence. It's actually pretty simple. There are plenty of other ways to be one but here's a path that worked for me:
Year 1 - 4: Go to college. Major in Business or Computer Science. Work in a gaming QA department for 1 year while finishing school. Graduate.
Years 5 - 7: Get a job in a Production Assistant role. Do that for 3 years and work your way into more responsibility or even get promoted. Take project management courses at night while still maintaining your production job. Maybe even take the Project Management Professional test conducted by the Project Management Institute and pass. (The PMP® certification isn't absolutely required so long as the producer is well educated in project management practices and methodologies. PMP focuses on very traditional project management and is a good foundation but it must be augmented with other training such as Agile practices.)
Year 8: You are now ready to be an Informed Producer. Maybe not Good…but at least informed.
This roadmap is one way to set prospective producers up for success. I actually didn't follow this exactly but in retrospect I wish I would have. There are other ways to become an informed producer however this is pretty straightforward. I recommend training in a variety of capacities but based on my experience I believe in the ascribed steps. Being an entrepreneur that starts and runs a company can work beautifully too, if not better in many cases. Nothing makes a person truly understand the many facets of our business more quickly than running his or her own company. This takes you down the road of hopefully being a good leader, but not necessarily an informed producer. You can cut corners but relying only on "learning from experience" will set you down the wrong road. You may have force of will, learned from mentors, experience, charisma, etc. which may make you a good leader, but you'll always be an uninformed producer without training and you'll lack some basic tools to make you better. A good producer exhibits qualities like leadership, dedication, tenacity, professionalism, ethics, etc., but these alone aren't enough and are too vague to be relied upon alone. Production experience by itself will not make you an informed producer, though it may make you good. In the end, being an informed and good producer is the goal. "Good" is subjective. "Informed" is fact.
It should be noted, however, that I am not advocating that producers become project managers. Most project managers in our industry are all about the schedule and its management. Producers usually have another key responsibility that the project manager generally doesn't have and that's to communicate and champion the vision of the game to the team, sponsors and outside stakeholders. The producer may not come up with the vision, but the producer is the one that must protect it at all costs. The project manager (sometimes known as development manager/director) does not generally carry the vision and, instead focuses solely on schedules, risk analysis, processes and planning. It's imperative for a producer to be armed with this same knowledge and training to help augment the execution of the vision he or she holds, even if the project manager's sole focus is solely this role. The role of producer can vary from company to company. In some they are more like project managers and in others they are little more than note takers. Either way, the producer must add value to the team and training is a vital step to do so. Put in another way by my friend Patrick Gilmore, Studio Head at Double Helix, "Development Directors are in charge of the literal tradeoffs—team size, organization and cadence, schedule, budget, milestones, tracking, work breakdowns, construction frameworks, pipelines and techniques. Producers are often in charge of the blind tradeoffs—quality, scope, priority, richness and depth, polish, pacing, compulsions, narrative, vision and cohesiveness, competitive product, feature relevance, unique selling points and the feeling of "wholeness" of the game."
If you do a Google search for books on producing you'll find some, but not many. Personally, I like the book by Quincy Jones called "Q on Producing." http://www.amazon.com/The-Quincy-Jones-Legacy-Series/dp/1423459768 His core message: producers should bring the best out of creative people. While this is an admirable philosophy he tells producers little about how to actually do it. Music is also a drastically different business. Engineers, artists and designers aren't musicians. At the core they are not even game makers; they are software developers. Games are just the type of software they are lucky enough to create. Software development is complex, often made up of large teams and larger personalities. The producer needs to know how to harness and focus that creativity while managing a software project at the same time. On the other hand there's an enormous amount of data available on project management training. There are classes anyone can take, there are certificates anyone can earn and there are tests anyone can pass. There are only a few related to the role of producer, however, and this is at the core of the problem. It's a murky, undefined field of study.
In my humble view, there are thematic core components to being a good, informed producer. In no specific order they are…
Communicate, then Repeat: Communication is often noted in project post mortems as the #1 problem teams run into. It's also a very broad category since there are so many things that must be communicated and so many people that must not only receive the message but understand it too. Project vision, work, scope, goals, dates, features, pipelines, tracking, schedule, etc., etc. all need to be communicated in all directions. That's a very short list and there are a myriad of other topics. The best way to communicate most subject matter is almost always face to face. If you never leave your seat and ONLY rely on email you're simply doing it wrong. Email is supportive, face to face is critical. Face to face is also faster since the back and forth conversation iteration is immediate and can be reacted to on the spot. A person may not even read an email till the end of the day, if at all. It's been said that 55% of communication is nonverbal. Face to face, even over Skype is the only way to collect this. I believe there are generally two types of overall communication: 1) Direct and 2) Osmotic. Direct communication is just as it sounds, directive. It's a request for someone to take action. As a producer I'm asking you to do "X". Face to face discussion, supported by email, daily stand ups, scheduling, milestone content and deadlines can all be examples of directive communication. Osmotic communication is supportive and all around a team members. It drifts into their consciousness through environmental factors or even overheard conversations. (Incidentally, this is exactly why I will never sit in an office. The buzz of the team around me can be an excellent way to collect information.) Milestones posted on walls, concept art, posters outlining the team values, video monitors summarizing the sprint goals, Scrum boards, etc. are all environmental. The idea is to surround a team with the creative vision of the title as well as all the key, high level info they need to do good work on time. It's immersive. Poor communication on a project is always the fault of the production staff. It's the producer's responsibility to make sure it happens. Communication is also a two way street. Producers must actively question, engage and even interview team members to collect data on the project health and status, especially in the planning phase. The producer doesn't have to know all the answers but he or she must find ways to engage the team and stakeholders to find them.
Own and Plan the Project Plan Vision. To put this another way, plan, plan, plan…and then plan some more. Then expect it all to change daily or even more frequently. Your team requires producers to know what's on the horizon so that risk can be mitigated, minimized, removed or accepted. Producers need healthy participation and collaboration from the team experts and stakeholders with the goal of clearing the road for the title. The tools available in proper project management can aid this effort. Scope Management Plans, Delphi Analysis, Work Breakdown Structures, activity scheduling, budgeting, Risk Registers, etc. All these tools are available to anyone with the proper training. This is a good reason why producers should be trained in project management. Producers without training don't know what they don't know. Many producers without training rely on their own crafted tools and processes. Some may work but many others may not be optimal. Or, worse, they have no tools and processes and instead rely on brute force of will to get the job done. It should be noted that it is impossible to plan game projects out at the start. Games are actually full of smaller, achievable little projects and the subsequent phases should be broken down as new information is discovered. Agile development expects and embraces these changes and attempts to manage uncertainty.
Track, Trust and Verify: Holding the team accountable for the goals they collaboratively set with production is a key responsibility of the producer. The producer must engage the team to help build the honest, iterative plans. The producer must also make sure team members are delivering on their plan. Frequent checking and monitoring of status is crucial so that change requests can be evaluated and the project course adjusted as it progresses toward the finish. Game projects are complex. They have millions of different inputs that must converge on a single output. A producer must have a great understanding of the entire problem space of a project so that he or she may make course corrections when required. They must perform the ABCDs…Always Be Collecting Data.
Historically our industry generally reacts to project scope change by simply working the team harder. This has led to many neglected children and marriages and often games that are subpar due to poor resourcing, bad decision making and underdone features. As the adage goes, we need to work smarter, not harder. While I don't believe crunch can be removed from a creative endeavor I do think it can be planned for and managed better. Game developers are some of the hardest working people on the planet and squeezing an extra 10% from these dedicated people isn't always the best answer; it's usually just the easiest. It takes no production IQ to tell people to work the weekend. Producers need to track, monitor, gather metrics and control the inevitable changes that occur during a project lifecycle. Without this data clear decision making is impossible and the team (and project) will pay the price.
Tools & Processes: As mentioned previously the study of project management comes with it standardized tools to help the GIP understand and manage scope, changes, stakeholder buy in, project goals and success criteria, among others. I'm not referring to tools like software. Hansoft, Project, Jira, etc. are all fine tools but in this case I'm referring to project management tools such as Risk Registers, Scope Statements and Project Charters. I'm also referring to project management methodologies like Scrum, Dynamic Software Development Method, Kanban and even Waterfall. A producer needs to be familiar or even an expert in various methodologies since different ones might be more applicable to different phases of the project. These tools are independent of the software used to track the project, though some, such as Hansoft or Greenhopper are designed specifically for Agile methodologies.
Know your Pipelines: The work flow process in a project must be intimately known by the producer. The producer must know the overall roadmap for a project and the work flow pipelines are at the core. At the end of the day the producer is helping move around assets and ideas so that they may be executed as fast as possible to the assigned quality bar. The pipelines are how this work moves from person to person and ultimately into the game. Without understanding them the producer will be unable to fix or even optimize workflows.
Encourage Frequent Failure: I'm a big fan of prototyping. In a nutshell prototyping simply means creating a demonstrable feature as quickly and as small as possible that proves the core idea before investing a lot of people's time only to watch it fail. Often this may not even be a piece of running software. It can also be a document or a movie. Whatever proves the feature and minimizes the risk that the feature or idea will not work. Prototyping allows experimentation and the team to fail quickly. He or she MUST accept iteration as a reality. Only through failure will the team learn and make corrective action and come to the right decisions.
Set the Rules: Teams work best when they are clear on the title vision and the rules for working that are expected of them. The rules of operation are things like "everyone must respond to their email at least twice a day", "everyone must attend the standup at 10:30" or "everyone must update their task list before the standup." They can also be values such as "we are committed to trying new processes and methods" or "we value communication transparency". Your rules should be set in collaboration with the team.
Commit, then Deliver: (This one is again from Patrick Gilmore, Studio Head of Double Helix). "The producer's job is to make commitments to an organization or group of stakeholders, then work with the team to deliver on those commitments. Success is dependent upon knowing what the team is capable of, understanding how to help the team focus, and also on managing and communicating with stakeholders. Junior producers fail on one side or the other—they overcommit and grind their teams, or don't know how to build quality and so can't be trusted the next time they need to commit to stakeholders."
Execute now: The mindset of a GIP can be described with one word: Urgency. Everything must be done as soon as possible so the producer can have time to navigate the unknown unknowns that are sure to pop up in the project. Nothing can wait till tomorrow. If a problem is large the producer must have a plan on how to break down the issue into smaller, consumable and attackable issues…and then focus the team toward doing so, all the while juggling the other immediate issues on facing the team. No problem can be delayed, even though a Producer must sometimes wait due to resourcing priorities. Stack rank the issues, come up with plan and then "do".
Beacon of Ethics: The Producer should be the guiding light when it comes to executing a project in an ethical and moral way. Most of this can simply be achieved through open and honest communication. This can build trust with the team when they know the producer is being straight with them on what's expected of them.
Carry the Creative Vision: The Producer needs to fully understand the title's creative vision. What will the title "do" for gamers? Creatively what is it trying to attain? To be clear, I used the word "carry", not "create" the vision. Anyone can create the project vision, though it usually comes down to the Creative or Design Director. If that's the case the producer should support, defend and communicate that vision, regardless of who creates it. Consider the producer something like a knight and the creative vision is the crown. It must be protected and championed. I also didn't use the word "own" the vision. Again, this usually falls to the Creative or Design Director. The owner of the creative vision tells the team where to dig the well. The carrier does whatever is necessary to make sure the water gets to the thirsty folks without spilling.
Beware the Dirty Phrase "But We've Always Done it this way…": This has been called the most dangerous phrase in our business. Leaning on old techniques will lead a producer down a black hole without a conscious effort to improve. The producer MUST be adaptable and willing to change for the betterment of the team and project. Nothing creates a bad producer faster than success. If a producer picks up bad habits early but happens to deliver a great title despite these habits there's no motivation for corrective action. Worse, he or she won't even know corrective action should be taken.
Be a Lifelong Learner: I believe producers MUST commit to lifelong learning about their craft. Read books, take classes, interview other producers, interview team members about what they think a producer should be, etc. Too often I've found that producers are content with on the job learning. The problem is that habits picked up this way are a small microcosm of lessons outside their sphere. Also, they are sometimes simply wrong!
Be a Servant of the Team: In game making, the team is the absolute most important thing. While a producer is a leader he or she often should lead by servicing and providing for all the needs of the team. One of my old bosses used to say "The game is a reflection of the team." A poorly run, unhappy team will probably deliver a poor, unhappy game. The producer must do everything to protect the team and allow them to do the great, creative work required. I've heard it said producers should be a "S--t Umbrella." There's a lot of truth in that.
Be Humble and Actively Listen: The producer usually isn't the smartest person in the room. We work with experts in their craft. Always be humble and treat them with respect. Above all, listen to them with enthusiasm.
Granted, this article comes off slightly preachy…and for that please accept my apologies. It's a trend I've been seeing in our business lately and I care very much that we improve our craft and the teams around us. We are in an industry that is not unlike a teenager. We think we know it all but we're still immature. Only by pointing at the elephant will we all acknowledge that it's in the room. In the end we're the only ones that can make it so. I welcome competing theories so please feel free to offer them. In the end only collaboration and discussion about this topic will progress our discipline.
|Matt Powers
Very nice Harvard - well written, interesting, and informative. I definitely agree with your points. I would recommend any producer or someone interested in being a producer give this a read. Thanks for putting it all down.
|Tyrone Rodriguez
"Engineers, artists and designers arent musicians. "
But I don't think all engineers, artists, designers and musicians share one thing at least--they're all artists of their own craft.
|Harvard Bonin
Thanks Tyrone. You are correct. There is artistry, even in coding. My key point is that I believe software developers operate in a much more complex field. I'm not minimizing the craftsmanship of a musician but I do believe there are more difficult challenges in game making due to the size of teams these days. That said, I could be very wrong as I'm not a musician.
|Sean Decker
Great article Harvard. Nice way to break down some of the many roles of "Producers" and give prospective producers an understanding of what they can do to be successful.
|Sami Saari
Thanks for this Harvard. Im currently a student in Oulu Game Lab (Finland) working as a producer for a pretty ambitious project. Having a background/education in digital media production and marketing, I still find it so overwhelming especially because of the lack of tools at my disposal. Still theres a lot in the post that indicates Im on the right path so thanks for the encouragement.
|Mikail Yazbeck
Thanks so much for making this great write-up. I'm sending it around our studio now.
|Andrew Dovichi
Producers sure do love their acronyms. Speaking of which, the typo in this line wasn't intentional right?
"They must perform the ABDCs Always Be Collecting Data."
Thanks for taking the time to write this up, very informative.
|Harvard Bonin
Good catch. Thanks Andrew. Now corrected.
|Josep Martinez
Very nice article. In my opinion a good an easy way to explain the other peopl what our role is, that by the way it might be a little hard to explain when meeting somebody that is not from the games industry.
|Morten Skaaning
This is a fine and well meaning article. All the fancy words aside you especially want two things from producers (these two are hard):
1) You want them to *not* change the game every five minutes. Imagine a game as a giant oil refinery and the people in charge want to experiment with producing espresso, ketchup or women's shoes.
2) If 1) is actually happening then the producers must also extend the deadline for the project. Games are *very* complex and no one can polish a turd if dihoerra is rampent
If producers could fix these two problems the game industry would be a much better place..
|Robert Hyder
Enjoyed the article Harvard. Passed it around to a few of my friends.
This one section gave me a little pause though:
"Everything must be done as soon as possible so the producer can have time to navigate the unknown unknowns that are sure to pop up in the project. Nothing can wait till tomorrow."
While it is important to move quickly, I have seen this taken to destructive extremes. Sometimes things do need to wait until tomorrow. Sometimes there does need to be time to think. People do need to go home. The key is to know when something is truly important and when it's just another thing that needs to be accomplished in good time. The producer who runs around with his/her hair on fire at all times loses the trust of their team because they seem out of touch and out of control.
Just my two cents. Really good stuff though.
|Harvard Bonin
Hi Robert, you make a good point. I should have written that a bit more clearly. I should have used something like "Focus on the work." My main thrust is that the producer should be laser focused on getting things done. I do not advocate moving just to move.
Harvard, good write-up. Is it fair to say I can see your "EA" showing? Producers at EA are expected to be very versatile not singularly focused.
Two things
1) I appreciate the distinction you make about Producer are not Project managers - Sadly this industry has moved down the path of making Project managers take a the title of producer (Because it sounds sexy, thanks to to movies?) while a producer should be a competent project manager that should not be his first objective.
2) Your opening statement is slightly flawed. Historically, Trip wanted Game Developers to be Rock stars (remember the Album covers?) and based the role on the music industry, specifically his friend Jerry Moss, a music producer. (http://en.wikipedia.org/wiki/Video_game_producer) it is a much more fitting role. Because we orchestrate many smart, creative, technical people to a product greater than we could reach alone. but at the same time we are the inflection point to the needs of business, finance, marketing, while being the internal and external face of the product.
in recent years people have forgotten this story and everyone wanted to be a Producer but nobody wants to be a Project manager, so we started giving people the title they wanted but the job they didn't. Have you ever gone to a Producer round table at GDC? It's a PMP convention, a valuable skill, one I have done well in the past when needed but it's not the role as originally intended, or as it's seen when you are dealing with a world-class producer.
Good words, check wiki.
|Harvard Bonin
Thanks for the clarification Nick. I'll amend accordingly. Good thoughts here.
|Joel Nystrom
What about the distinction between Production and Development? I've overseen over 50 SKU's, and I can't say that we've ever been in production. To me, the distincton is that in development, you invent new stuff on a daily basis, and therefore need different planning methods, than when you are producing a well-defined product that you can produce assembly-line style.
I can see how AAA enter "production" once the game is feature complete though. If they truly stick to not adding a single new feature or changing anything. But I wonder how often that is the case in reality.
|Harvard Bonin
Production is the management and leadership of development. However, "production" generally refers to the execution phase in project management. That's when the whole team is on boarded and the unknowns should be mostly known. Its as close to a production line in something like cars as we get (which is not close).
I've found that there are seven phases in game making...Initiation, Concept, Pre-Production, Onboarding, Execution and Closure...and they are almost always all jumbled up in game development.
|Harvard Bonin
Please check out my new post regarding my Scrum experience.
|Joonas Laakso
Thanks for the thoughts! I've been scouring the internet for different takes on production as I'm preparing my new full-day lecture on game production. Very useful distinctions and arguments here.
Studios would really benefit from figuring out what exactly their producer roles are all about. I've known a few producers and they all approach the job very differently; it feels like a job that becomes all about your personality. Still, having a good idea about the project management responsibilities versus management versus leadership versus product (vision) championing would be a healthy thing to have.
|sameer puthran
I am so Happy to be reading your article Mr Harvard. Honestly i am a producer who works by instinct, experience and as per the job requirements as per the company. Bur totally agree on the management training. I have taken up the PMP traning course to upgrade myself further. Just wanted to know whether such courses cover up the scrum, agile and working on processes on Jira. I am very much following your post. Please reply on this


text:
Word: يتكلما
Added on: 2013-05-23 Listened: 4 timesin: Add categories to يتكلما
Pronunciation in Arabic [ar] Back to Arabic
- Pronunciation by superabdo (Male from Egypt)
0 votes
- Could you do it better? different accent? Pronounce يتكلما in Arabic
Accents & languages on maps
- Random word: واحدةُ
by Google Translate English translation:
يتكلما = Speak
Modify word:
· Add languages
· Add categories
Report word:
Is there anything wrong with this word?
Please report it here.

subset: commoncrawl


text:
Managing IP Networks with Cisco RoutersBy Scott M. Ballew
1st Edition October 1997
1-56592-320-0, Order Number: 3200
352 pages, $34.95 US
Sample Chapter 5: Routing Protocol Selection
In this chapter:
Static vs. Dynamic Routing
Classification of Dynamic Routing Protocols
Selecting a Routing Protocol
In previous chapters, I have focused the discussion on network design and router selection. While these topics are important if you are building a new network or planning whole or partial replacement of an existing network, they're only of theoretical interest if you already have a network in place. In this case, which is far more common, you don't get to choose your topology, media, or router vendors. You're stuck with the decisions you and your predecessors have made. At best, you can design your ideal network, and think about how to migrate to that design over the coming years.
This chapter shifts from the theoretical aspects of network design to the more practical aspects of network management. While there will certainly be some theoretical discussion, especially in the first few sections, theory will be balanced with a more practical discussion of configuration issues, whether for a new network or an existing network.
Static vs. Dynamic Routing
Before exploring the issues surrounding the selection and configuration of dynamic IP routing protocols, it is appropriate to discuss static routing as an alternative. In Chapter 1, The Basics of IP Networking, we saw that each machine in an IP network makes decisions about how to reach a destination by consulting its own private routing table. Rather than computing the entire path to a destination, it merely selects the next hop leading to that destination, and relies on the next hop machine to select a further hop that gets the packet closer to its destination. Independent hop-by-hop routing requires that all machines have a consistent view of how to reach all destinations in the network. If consistency is lost, two or more machines (presumably routers) can form a routing loop, and the packet never makes it to its destination.
To achieve consistency, a network administrator can either manually configure each machine with a precomputed set of routes that he or she knows to be consistent, or the machines can communicate routing information to each other through some kind of protocol. The first approach is known as static routing, and the second as dynamic routing.
Advantages of Static Routing
Static routing has some enormous advantages over dynamic routing. Chief among these advantages is predictability. Because the network administrator computes the routing table in advance, the path a packet takes between two destinations is always known precisely, and can be controlled exactly. With dynamic routing, the path taken depends on which devices and links are functioning, and how the routers have interpreted the updates from other routers.
Additionally, because no dynamic routing protocol is needed, static routing doesn't impose any overhead on the routers or the network links. While this overhead may be minimal on an FDDI ring, or even on an Ethernet segment, it could be a significant portion of network bandwidth on a low-speed dial-up link. Consider a network with 200 network segments. Every 30 seconds, as required by the RIP specification, the routers all send an update containing reachability information for all 200 of these segments. With each route taking 16 octets of space, plus a small amount of overhead, the minimum size for an update in this network is over three kilobytes. Each router must therefore send a 3 Kb update on each of its interfaces every 30 seconds. As you can see, for a large network, the bandwidth devoted to routing updates can add up quickly.
Finally, static routing is easy to configure on a small network. The network administrator simply tells each router how to reach every network segment to which it is not directly attached. Consider the network shown in Figure 5-1. This network has three routers connecting five network segments together. Clearly, the only path from Router1 to a host on
172.16.3.0/24goes through Router2. Likewise, the only path to hosts on subnet
172.16.4.0/24goes through Router3.
Figure 5-1. A small network using static routing
Here are the relevant fragments of the configurations of these three routers using static routing. Note that each router configuration must contain a static route for the networks attached to the other routers, but not those directly attached to the router itself.
Configuration for Router1:Configuration for Router2:
hostname router1 ! interface ethernet 0 ip address 172.16.1.1 255.255.255.0 ! interface ethernet 1 ip address 172.16.2.1 255.255.255.0 ! ip route 172.16.3.0 255.255.255.0 172.16.1.2 ip route 172.16.4.0 255.255.255.0 172.16.1.2 ip route 172.16.5.0 255.255.255.0 172.16.1.2Configuration for Router3:
hostname router2 ! interface ethernet 0 ip address 172.16.1.2 255.255.255.0 ! interface ethernet 1 ip address 172.16.3.1 255.255.255.0 ! interface ethernet 2 ip address 172.16.5.1 255.255.255.0 ! ip route 172.16.2.0 255.255.255.0 172.16.1.1 ip route 172.16.4.0 255.255.255.0 172.16.3.2
hostname router3 ! interface ethernet 0 ip address 172.16.3.2 255.255.255.0 ! interface ethernet 1 ip address 172.16.4.1 255.255.255.0 ! ip route 172.16.1.0 255.255.255.0 172.16.3.1 ip route 172.16.2.0 255.255.255.0 172.16.3.1 ip route 172.16.5.0 255.255.255.0 172.16.3.1
Each configuration starts by giving the router a name, and then defines an IP address and subnet mask for each of the router's interfaces. For example, on Router2, the second Ethernet interface (
ethernet 1) is assigned the IP address
172.16.3.1, and the netmask
255.255.255.0. Similar commands defining addresses and netmasks for local interfaces will appear in all router configurations, regardless of whether a router is participating in a dynamic routing protocol. If the configurations stopped here, each router would have entries in its routing table for the networks attached to its own interfaces, and no others. But the configurations go on to define static routes showing how to reach networks attached to the other routers. Each
ip routestatement defines a static route to the destination indicated by the network number and mask by way of the router IP address listed. For example, the first
ip routestatement in Router3's configuration defines a route to
172.16.1.0, with a mask of
172.16.1.0/24) via the router at
172.16.3.1. The static routes, together with the the local interfaces, let each router populate its routing table with information about each destination and the next hop to reach it.
While this small network doesn't require many static routes to achieve complete connectivity, and Router1 and Router3 could get by with static default routes pointing to Router2, it is easy to see that the configurations for a large network with hundreds of network segments and routers would be very complex.
And the Disadvantages of Static Routing
While static routing has advantages over dynamic routing, it is not without its disadvantages. The price of its simplicity is a lack of scalability. For five network segments on three routers, computing an appropriate route from every router to every destination is not difficult. However, many networks are much larger. Consider what the routing might look like for a network with 200 network segments interconnected by more than a dozen routers. To implement static routing, you would need to compute the next hop for each network segment for each router, or more than 2,400 routes! As you can see, the task of precomputing routing tables quickly becomes a burden, and is prone to errors.
Of course, you could argue that this computation need only occur once, when the network is first built. But what happens when a network segment moves, or is added? While the computation may be relatively easy, to implement the change, you would have to update the configuration for every router on the network. If you miss one, in the best case, segments attached to that router will be unable to reach the moved or added segment. In the worst case, you'll create a routing loop that affects many routers.
Finally, because static routing is, by definition, static, it cannot use redundant network links to adapt to a failure in the network. Consider what would happen to our network if we add an additional interface to Router3 and connected it to
172.16.2.0/24, but left routing unchanged. If Router2 fails, Router3 would be unable to adapt to the change in the network topology and would still be unable to reach hosts on
172.16.1.0/24. This inability to adapt to network failures, even when redundant paths are available, and the problems associated with scaling, are the primary motivations behind dynamic routing.
Advantages of Dynamic Routing
The chief advantages of dynamic routing over static routing are scalability and adaptability. A dynamically routed network can grow more quickly and larger, and is able to adapt to changes in the network topology brought about by this growth or by the failure of one or more network components.
With a dynamic routing protocol, routers learn about the network topology by communicating with other routers. Each router announces its presence, and the routes it has available, to the other routers on the network. Therefore, if you add a new router, or add an additional segment to an existing router, the other routers will hear about the addition and adjust their routing tables accordingly. You don't have to reconfigure the routers to tell them that the network has changed. Similarly, if you move a network segment, the other routers will hear about the change. You only need to change the configuration of the router (or routers) that connect the segment that moved. This reduces the chance that errors will occur.
The ability to learn about changes to the network's configuration has implications beyond adding new segments or moving old ones. It also means that the network can adjust to failures. If a network has redundant paths, then a partial network failure appears to the routers as if some segments got moved (they are now reached via alternate paths), and some segments have been removed from the network (they are now unreachable). In short, there's no real difference between a network failure and a configuration change. Dynamic routing allows the network to continue functioning, perhaps in a degraded fashion, when a partial failure occurs.
And the Disadvantages of Dynamic Routing
I would be a liar if I told you that dynamic routing has no disadvantages. Chief among the disadvantages is an increase in complexity. Communicating information about network topology is not as simple as saying, "Hey, I can reach the following destinations..." Each router participating in the dynamic routing protocol must decide exactly what information to send to other routers; more important, it must attempt to select the best route for reaching other destinations from the candidates it learns about from other routers. In addition, if a router is going to adapt to changes in the network, it must be prepared to remove old or unusable information from its routing table. How it determines what is old or unusable adds to the complexity of the routing protocol. Unfortunately, the better a protocol handles the various different situations in a network, the more complex it is likely to be. This complexity tends to lead to errors in the protocol's implementation, or differences in how vendors interpret the protocol.
In order to communicate information about the topology of the network, routers must periodically send messages to each other using a dynamic routing protocol. These messages must be sent across network segments just like any other packets. But unlike other packets in the network, these packets do not contain any information to or from a user. Instead, they contain information that is only useful to the routers. Thus, from the users' point of view, these packets are pure overhead. On a low-speed link, these messages can consume much of the available bandwidth, especially if the network is large or unstable.
Finally, some or all of the machines in a network may be unable to speak any dynamic routing protocol, or they may not speak a common protocol. If that is the case, static routing may be your only option.
With all the disadvantages listed of both static and dynamic routing, you may be wondering what the best choice is. Only you can say for sure what is best for your network, but there is a reasonable middle ground that limits the complexity of dynamic routing without sacrificing its scalability. This middle ground is a hybrid scheme, in which part of the network uses static routing and part uses dynamic routing.
Hybrid Routing Schemes
In a hybrid routing scheme, some parts of the network use static routing, and some parts use dynamic routing. Which parts use static or dynamic routing is not important, and many options are possible. One of the most common hybrid schemes is to use static routing on the fringes of the network (what I have called the access networks) and to use dynamic routing in the core and distribution networks. The advantage of using static routing in the access networks is that these networks are where your user machines are typically located; these machines often have little or no support for dynamic routing. Additionally, access networks often have only one or two router attachments, so the burden of configuring static routing is limited. It may even be possible to define nothing more than a default route on these stub networks. Because of the limited connections to these networks, you usually don't need to reconfigure routing on a stub network when it gets moved to a new place in the network.
On the other hand, distribution and core networks often have many router connections, and therefore many different routes to maintain. Therefore, routers in these components of the network usually can't get by with a default route. Routers (and hosts) in the central parts of the network need complete routing information for the entire network. Furthermore, routers in the core and distribution networks usually need to be informed of changes in the connectivity of access networks. While it is certainly possible to inform each router manually when an change occurs, it is usually easier and more practical to allow a dynamic routing protocol to propagate the changes.
Another advantage of using static routes in your access networks is control. Depending on the structure of your network administration, you might not be able to control what happens in access networks. These may be handled by departmental LAN coordinators that do not report to you. When this is the case, it is often simpler to configure static routing with the access networks, and only run the dynamic routing protocol between routers and machines over which you have direct control. Because a dynamic routing protocol implies a certain level of trust, it is often safer not to use a dynamic routing protocol with such departmentally controlled access networks. In short, when dealing with routers not under your direct control, it is best to use static routing where you can, and to use dynamic routing only where you must.
Another type of hybrid routing structure to consider is based on network bandwidth issues rather than on administrative control. In this type of hybrid structure, you would run dynamic routing protocols on your high-speed LAN and WAN links, and use static routing for connections that cross lower-speed links. As an example, consider a multi-campus network at a university. Within each campus, there may be multiple routers, interconnected by Ethernets, FDDI, and other high-speed links. However, the link between the campuses may well be a 56 kbps WAN link. If the two campuses have separate network address spaces, it is unlikely that the routes between the campuses will change. In this case, the only advantage to using dynamic routing between the campuses is that packets that cannot be delivered to a machine on the other campus because of an internal network failure can be stopped before they traverse the low-speed link. However, this is the exceptional case. The normal case is that internal network operation is stable.
With this in mind, it is reasonable to ask how much bandwidth the dynamic routing protocol is taking on the low-speed link. While most routing protocols are designed to minimize the impact of the routing updates on the link, the overhead is non-zero. It may be better to use dynamic routing within each campus, but to use static routing for the inter-campus link, where bandwidth is at a premium.
Static routing between campuses connected by a slow link may even be worthwhile if the campuses share a common address space (perhaps a single class B-sized network aggregate). However, more work may be necessary. The problem with a common address space is that changes on one campus typically need to be visible to the dynamic routing protocol on the other campus. One solution to this problem is to divide the address space between the two (or more) campuses so that each is its own smaller aggregate, as shown in Figure 5-2. If you can divide the address space, you can simplify static routing between the campuses by working with the aggregates.
Figure 5-2. Two campuses sharing a common address space
In the figure, Router1 only needs a static route for the aggregate
172.16.128.0/17. Likewise, Router5 only needs a static route for the aggregate
172.16.0.0/17. This allows each campus to allocate subnets in their portion of the common address space independently, and yet keep static routing between the campuses simple.
A final problem with our multi-campus hybrid routing scheme occurs when the inter-campus link moves between routers. For example, what happens if the link is moved from Router1 to Router3? Router configurations on Campus 2 are unaffected, since the same IP addresses for the serial link can continue to be used, and the changes necessary on Campus 1 need not be extensive. Clearly, Router1 and Router3 must know of the change. After all, even without routing to deal with, they need to have interface configuration changes made. But does Router2 need to be reconfigured to know that the link to Campus 2 has moved? Not if the routers are all configured to include information about their static routes in the dynamic routing protocol.
Most routers have some ability to propagate information from one routing source to another. We usually think in terms of exchanging routing information between two dynamic routing protocols, but passing information about static routes into a dynamic routing protocol is really just a special case. We won't go into the details here of how this is done because it will be easier to explain once we have talked about the dynamic routing protocols and how to configure them, but you should be aware that including static routes in your dynamic routing protocol updates is an easy way to confine configuration of static routes to a minimum of routers.
Now that we have covered static, dynamic, and hybrid routing schemes, you should have a plan for where you would like to use dynamic routing, and where you will use static routing. The next step is to think more about dynamic routing protocols, and decide which are appropriate to use.
Classification of Dynamic Routing Protocols
Dynamic routing protocols can be classified in several different ways. I will discuss two classifications: exterior protocols versus interior protocols, and distance-vector versus link-state protocols. The first classification is based on where a protocol is intended to be used: between your network and another's network, or within your network. The second classification has to do with the kind of information the protocol carries and the way each router makes its decision about how to fill in its routing table.
Exterior vs. Interior Protocols
Dynamic routing protocols are generally classified as an exterior gateway[1] protocol (EGP [2]) or an interior gateway protocol (IGP). An exterior protocol carries routing information between two independent administrative entities, such as two corporations or two universities. Each of these entities maintains an independent network infrastructure and uses an EGP to communicate routing information to the other. Today, the most common exterior protocol is the Border Gateway Protocol (BGP). It is the primary exterior protocol used between networks connected to the Internet, and was designed specifically for such purposes.
In contrast, an interior protocol is used within a single administrative domain, or among closely cooperating groups. In contrast to the exterior protocols, IGPs tend to be simpler and to require less overhead in a router. Their primary drawback is that they can't scale to extremely large networks. The most common interior protocols in IP networks are the Routing Information Protocol (RIP), Open Shortest Path First (OSPF), and the Enhanced Interior Gateway Routing Protocol (EIGRP).[3] The first two are open standards adopted or developed by the Internet community, while the third is a proprietary protocol designed by Cisco Systems for use on their routers.
While it is possible to use an interior protocol as an exterior protocol, and vice versa, it is seldom a good idea. Exterior protocols are designed to scale to the largest of networks, but their inherent complexity and overhead can quickly overwhelm a small or medium-sized network. On the other hand, while interior protocols are fairly simple and have little inherent overhead, they don't scale well to larger networks. Because of the difference in focus between interior and exterior protocols, I will not discuss exterior protocols in this chapter. Instead, I will reserve our discussion of exterior protocols to later chapters where we will be discussing connections to the world outside of your organization.
Distance-Vector vs. Link-State Protocols
Another way to classify dynamic routing protocols is by what the routers tell each other, and how they use the information to form their routing tables. Most protocols fit into one of two categories.
The first of these categories is distance-vector protocols. In a distance-vector protocol, a router periodically sends all of its neighbors two pieces of information about the destinations it knows how to reach. First, the router tells its neighbors how far away it thinks the destination is; second, it tells its neighbors what direction (or vector) to use to get to the destination.[4] This direction indicates the next hop that a listener should use to reach the destination, and typically takes the form "send it to me, I know how to get there." For example, RIP route updates simply list a set of destinations that the announcing router knows how to reach, and how far away it thinks each destination is. The receiver infers that the next hop to use is the announcing router. However, an update can also take the form "send it to this other router who knows how to get there." This second form is usually used only when the router that should be used to reach the destination cannot (or will not) speak the routing protocol being used by the other routers. Not all routing protocols support this form of third-party route update.
The other part of the protocol, the distance, is where distance-vector protocols differ. In each case, the protocol uses some metric to tell the receiving routers how far away the destination is. This metric may be a true attempt at measuring distance (perhaps using a periodic measure of the round trip time to the destination), something that approximates distance (such as hop count), or it may not measure distance at all. Instead, it may attempt to measure the cost of the path to the destination. It may even involve a complex computation that takes into account factors like network load, link bandwidth, link delay, or any other measure of the desirability of a route. Finally, it may include an administrative weight that is set by a network administrator to try to cause one path to be preferred over another.
In any case, the metric allows a router that hears about a destination from multiple routers to select the best path by comparing the "distance" of the various alternatives. How the comparison is made depends heavily upon how metric is computed. For example, the metric in RIP route updates is defined to be a hop count, in which one hop is supposed to represent handling by one router. A destination with a hop count of 16 is considered unreachable. When a router receives RIP updates from different routers referring to the same destination network, it selects the router that is announcing the lowest metric. If this metric is lower than the metric for the route that is currently in its routing table, the router replaces its routing table entry with the new information from the other router.
In order to allow the information to propagate throughout the network, each router includes in its announcements all the destinations to which it is directly attached, as well as all destinations that it has heard about from other routers. When a router includes the information it has learned from other routers, the routing protocol requires it to adjust the metric to reflect the additional distance from itself to the router from which it learned the information. In the case of RIP, this means that before a router announces information that it has learned, it adds one hop to the metric for each of these destinations. In this way, the farther you get from the destination, the higher the metric will be.
In contrast, in a link-state protocol, a router doesn't provide information about destinations it knows how to reach. Instead, it provides information about the topology of the network in its immediate vicinity. This information consists of a list of the network segments, or links, to which it is attached, and the state of those links (functioning or not functioning). This information is then flooded throughout the network. By flooding the information throughout the network, every router can build its own picture of the current state of all of the links in the network. Because every router sees the same information, all of these pictures should be the same. From this picture, each router computes its best path to all destinations, and populates its routing table with this information. How a router determines which path is best is up to each protocol. In the simplest case, a router may simply compute the path with the least number of hops. In a more complex protocol, the link-state information may include additional information to help a router determine the best path. Such information may again include the bandwidth of the link, the current load on the link, administrative weights, or even policy information restricting which packets may traverse the link. For example, a given link might not be allowed to carry confidential information.
Distance-vector and link-state protocols have their own strengths and weaknesses. In a properly functioning and configured network, either type yields a correct determination of the best path between any two points. However, this is not to say that there are not tradeoffs involved in selecting one type of protocol over another.
The drawbacks of distance-vector protocols
In general, distance-vector protocols are simpler to configure and to understand than link-state protocols. They are also typically less processor intensive, freeing more of the router to other tasks, such as forwarding packets. Their major drawbacks, though, are often the result of their simplicity. One of the chief drawbacks is that there is typically no indication of how a router knows about a destination that it has included in an update. For example, consider the simple three-router network shown in Figure 5-3. Router1 tells Router2 about the network
192.168.100.0/24. Router2 will, of course, tell Router3 about it, but it may also tell Router1. Likewise, Router3 may tell Router2 that it knows how to get to the same network, even though its path to that network is through Router2.
Figure 5-3. A simple three-router network
Normally, this is not a problem because each router compares the metric it is hearing to the metric in its routing table and selects the best path. But what if Router1 loses its connection to
192.168.100.0/24due to a hardware failure? It stops telling Router2 about it, and eventually Router2 removes the entry from its routing table (it will either time it out, or it will be told by Router1). However, it may then hear about the network from Router3, and think it should add this "new" path to its routing table and tell Router1. Of course, it also tells Router3, which discovers that the path through Router2 has gotten worse. No matter, it updates the metric in its routing table, and adjusts the metric it announces in its routing updates the next time it sends one to Router2. This now causes Router2 to update its metric, and announce a slightly worse route to Router3, which then re-announces it back to Router2 with an even higher metric. Eventually, they hit whatever value the protocol has declared to be "infinity." When this happens, both routers remove the route from their tables.
Depending on how high the protocol has set the infinity value, and depending on how often the routers send updates to each other, this period of unstable and inaccurate routing can last from fractions of a second to minutes. Clearly, you don't really want your routing tables to be unstable for minutes at a time every time a piece of your network fails! Most distance-vector protocols have added some additional complexity to help avoid these situations. The first thing they typically add is a concept called split-horizon. In split-horizon, when a router is building its routing update for a particular interface, it omits any reference to routes it has learned from routers reached by that interface. In our example, this means that Router2 tells Router3 about
192.168.100.0/24, which it learned from Router1, but it omits any reference to this network when it sends its update to Router1. Likewise, Router3 refrains from telling Router2 about this network, since it was Router2 that told it about it in the first place. A slight modification to split-horizon updates is poison reverse. In poison reverse processing, instead of omitting the route from its routing update, the router includes it, but flags it as unreachable. This causes any receiver that might be depending on the invalid route to remove the destination from its routing table.
The result is that simple network instability like the situation described above does not happen. However, neither split horizon nor poison reverse solves the whole problem. If there is a cycle in the network that connected Router3 to Router1, perhaps through Router4, as shown in Figure 5-4, a routing loop may occur even with poison reverse. In this network, Router1 tells Router2 and Router4 about its connection to
192.168.100.0/24, probably with the same metric value. They in turn tell Router3 about this network, again probably using the same metric. Router3 selects one of these paths (probably whichever it heard first) and enters it in its routing table.
Figure 5-4. Poison reverse is not sufficient to avoid routing loops in a network with a cycle
Let's assume that Router3 selects the path through Router2. Because of poison reverse, it would send that route back to Router2 with an unreachable metric, as it is supposed to. However, because it chose not to use Router4's path, it will not perform poison reverse processing on that link, but instead includes the route to
192.168.100.0/24through Router2 in its updates to Router4, which ignores the update and prefers the route through Router1.
All goes well until the link between Router1 and
192.168.100.0/24fails. At that time, Router1 ceases advertising this route to Router2 and Router4. These routers, in turn, cease sending the route to Router3, but it is possible that Router4 will hear Router3's advertisement before the process is complete. Since it does not have this route, it installs it in its routing table, and informs Router1 of this apparently new information. Router1 then informs Router2, which continues sending the information to Router3.
The loop will eventually be broken, as each router will increase the metric as it passes routing information around the loop; eventually, the metric will reach the protocol's infinity value. How long it takes the routers to count to infinity, as this behavior is called, depends heavily on how often they update each other, what the protocol's infinity value is, and how many routers are involved in the loop. The solution to this new problem is to introduce a hold-down interval. When a router learns that a destination is no longer reachable along the path it was previously using, it starts a timer during which it ignores any other routing information it might hear about this destination. The idea is to allow other routers to learn about the failure before it starts depending on their routes. In our example, when Router1 determines that it can no longer reach
192.168.100.0/24, it begins a hold-down period for this destination. During that time it ignores the updates it hears from Router3. If the hold-down period is long enough, by the time Router1 starts listening again, Router3 will have learned that its path to the destination is invalid, and won't be advertising it.
The drawback to the hold-down interval is that it is hard to know how long the interval should be. After all, how long does it take for all of the routers that you might hear from to learn that a destination is not reachable? This is especially bad for a protocol like RIP. In its simplest form, RIP sends a routing update every 30 seconds. Because there is no acknowledgment of these updates, it is possible that one could get lost. Additionally, while an update includes information about what is reachable, it does not normally include information about what is no longer reachable, so there is no indication to a router that it should remove a route that is no longer valid.
To allow for lost updates, RIP sets a timer for each route that it learns. Every time it hears an update for a route, it resets the timer. If it doesn't hear an update for 180 seconds, it removes the route from the routing table and stops advertising it to its neighbors. In this way, if an update gets lost, the routes it would have contained do not immediately get removed from the routing table. Presumably, they will be in the next update, and their timers will be refreshed then.
In practice, this means that it can take a long time for a routing change to make it through a large network. Consider once again the network with three routers shown in Figure 5-3. When Router1 determines that it has lost its connection to
192.168.100.0/24, it simply ceases to advertise it in its updates to Router2. Router2, however, continues to believe that it has a route to this network for three minutes from the last time it heard about it from Router1, and continues to send updates containing this destination to Router3. After three minutes, Router2 determines that Router1 must have lost its route, so it removes the route for
192.168.100.0/24from its routing table, and ceases informing Router3 about this destination. However, Router3 will continue to use the old information for up to three minutes more itself.
Now consider what happens if we keep adding to the network until we have dozens of routers. If each router has to wait three minutes from the time the router closer to a failed network stops advertising a route, it is conceivable that a route might not be completely gone from the network for as much as 45 minutes! It is clearly unreasonable that the hold-down interval for a network should be even a significant fraction of this time. To help reduce the time that a network has inconsistent routing information, distance-vector protocols often allow routers to include negative reachability information for routes that they have recently advertised, but can no longer reach. Negative reachability information allows routers to find out immediately that some route is no longer valid. For RIP, negative reachability information takes the form of a route with a metric of
16. Other protocols tag such information in whatever manner is appropriate.
Negative advertisement helps speed the propagation of route failure through the network, but it doesn't eliminate the delays. When Router1 discovers that its connection to
192.168.100.0/24has been lost (or restored), its next update to Router2 will contain this information. In the case of RIP, if it just sent an update, it could be up to 30 seconds until this update occurs. Further, once Router2 hears from Router1, it may also have to wait up to 30 seconds before it can notify Router3, which will wait up to 30 seconds, and so on. Even though this information traverses a large network quickly, especially compared to the time it takes for a route to time out, it can still take a few minutes for all of the routers in the network to hear about the change and update their routing tables. This delay between the time a network change occurs and the time all of the routers have adjusted to it in a consistent manner is known as convergence time. A long convergence time is clearly a problem for any routing protocol.
To minimize convergence time, a distance-vector protocol may allow flash or triggered updates. A triggered update is sent whenever a router's routing tables change in a way that would affect its routing updates. If each router uses triggered updates, and includes negative reachability information, it is possible for information about the failure of Router1's connection to
192.168.100.0/24to speed through the network to all routers in a matter of a few seconds, thereby shortening the convergence time and thus the time that routers need to be in a hold-down interval.
But, like everything else, it isn't that simple. If triggered updates aren't carefully controlled, an intermittent failure can ripple back and forth through the network, consuming the routers' time with processing routing updates rather than forwarding packets. A common solution is to lengthen the hold-down timer slightly, and to introduce a short interval timer that is set after every flash update. During this interval, the router suppresses new flash updates to help dampen the effects of the original failure.
The other major drawback to distance-vector protocols also stems from their simplicity. Because the network topology can change, either because of link failure or the addition or removal of network segments, all dynamic routing protocols must update routers about the changes. In a distance-vector protocol, updates are usually performed by periodically broadcasting (or multicasting) routing packets on some or all of a router's interfaces. Often, these routing updates contain complete routing information, as the sending router sees it. Periodic updates are useful for keeping the routers on a network segment informed, but they introduce additional network overhead during periods of network stability (the majority of the time, we hope). Some newer distance-vector protocols such as Cisco's EIGRP only announce changes to the routing tables, but these protocols still tend to be the exception, rather than the rule.
So, while a distance-vector protocol tends to be conceptually simple for humans to understand, and easy for a router's processor to work with, this simplicity can result in unusual behavior in response to a network failure, and often results in long convergence times between the failure of a network component and the re-establishment of consistent, stable routing in all routers. It may also result in the consumption of network bandwidth and router processing power even during periods of relative stability. While changes to the protocol can help lessen these problems, once you've added poison reverse, hold-down intervals, triggered updates, and so forth, the protocol is no longer simple, either to understand or to process.
The drawbacks of link-state protocols
Link-state protocols have some important advantages. Because a link-state protocol computes its routes based on the topology of the network as indicated by the link-state updates, it can't form a loop in response to a partial network failure, like a distance-vector protocol might. Further, because a change in link-state gets flooded throughout the network immediately and causes all routers to update their topology map and routing tables, convergence time is minimal. Finally, because most link-state protocols are designed to send link-state updates only when the state of a link changes, they tend to conserve network bandwidth and router processing power during periods of network stability.
While a link-state protocol avoids loop-forming behaviors, long convergence times, and stable-state resource consumption, they have their own drawbacks. Chief among these is complexity. Complexity is primarily an aspect of the protocol's implementation, but it often shows up in configuration as well. In fact, OSPF, an interior protocol, is a more complex protocol than even BGP, an exterior protocol. Fortunately, in a typical configuration, most of this complexity is hidden from the user.
Why are link-state protocols so complex? Consider what we have said about how the routers determine their routes. They collect all of the link-state updates from other routers and build a topology map of the network. Using this map, they compute the best path to each destination. The first complexity is generating the topology map. While a human being can easily draw pictures based on instructions about what is connected to what, a computer must have a way to represent the resulting picture in a way that allows it to carry out its processing. The standard way to do this is to use one of numerous types of graphs. Each type of graph has its own set of operations that it supports well, and another set that are nearly impossible to perform on it. A lot of research has been devoted to describing different types of graphs and the operations they support. Often, a protocol specification does not detail how the protocol should be implemented. It may not even specify what types of data are needed. However, even if the types of data are identified in the protocol specification, how the data are represented (i.e., which type of graph and how the graph is represented) is often left to the implementer. A poor selection can result in subtle failures in the resulting code on the router.
The second complexity in implementing a link-state protocol has to do with computing the best path to all destinations. While there are algorithms for computing the best path using a variety of graphs and metrics, it is again up to the implementer to select one and implement it correctly. Mistakes can also have interesting results in the finished product.
But implementation complexity shouldn't be a concern to the network administrator if the resulting code works correctly. However, even if the code is correct, a complex implementation usually requires more processing power and memory in the router. For example, the topology graph will take time to generate, and must be stored. In fact, it must be stored indefinitely, since link-state updates only contain information about changes in the network topology. The additional memory and processing requirements cause some network administrators to stay away from link-state protocols, but this is not their only concern. A greater concern is the complexity, or the perceived complexity, of configuring a link-state protocol.
Most link-state protocols are more complex to configure than most distance-vector protocols. However, if the configuration interface is implemented well, and if it includes a set of reasonable defaults, it is possible to configure a "no frills" link-state protocol with little more effort than a distance-vector protocol. The complexity of configuring a link-state protocol should only appear if you want to depart from the defaults.
Both link-state and distance-vector protocols will result in correct routing in a stable network, and should eventually converge on a new set of routes after a network failure. Therefore, which type of protocol you select for your network is a matter of personal preference. If the complexity of link-state protocols is not to your liking, or if you are concerned about the consumption of resources on your routers, try to select protocols that use a distance-vector algorithm. On the other hand, if you want the fast convergence and low bandwidth consumption of a link-state protocol, or don't want to deal with the odd loop-forming behavior of a distance-vector protocol, then select a protocol from the link-state family.
Selecting a Routing Protocol
Now that most of the background information about dynamic routing protocols is behind us, it is time to talk about what criteria you should consider when selecting a dynamic routing protocol. You may have a preference for either a link-state or a distance-vector protocol. But deciding what kind of protocol to use without considering other options can severely limit your choices, de-pending on what your router vendor supports. A more useful approach is to consider which protocol or protocols best suit your needs, and then use a preference for one type over another as a weighting factor later in the decision.
One of the most important criteria is how quickly the protocol adapts to changes in the network. Earlier, we identified this as convergence time and said that it was the amount of time between a change in the network and the reestablishment of consistent and correct routing tables. Ideally, you want this time to be small enough to be unnoticed by users.
Traditionally, the next most important criterion is resource consumption. However, with the current push for more efficient use of the IP address space, it is likely that you plan to use variable-length subnet masks. If this is the case, then support for variable-length masks is probably the most important feature your routing protocol must have. After all, if your routing protocol does not support your use of variable- length subnet masks, they won't do you much good.
The third criterion you should consider is how much of your network resources the routing protocol consumes. Consider not only the network bandwidth consumed by the protocol messages, but also how much processing power and memory is required in your routers. A link-state protocol will typically do better on the bandwidth consumption, and a distance-vector protocol will do better with processor and memory consumption, but this is not always the case.
Next, consider how well your prospective protocols deal with multiple paths to a destination. This may or may not be critical in your network, and how much weight you give it depends on your network design. If you have no redundant paths, you probably won't care about how well your protocol supports them. Still, while you may not have redundant paths today, you may add them in the future and you might need to change protocols to support them. Even if one of your prospective protocols does not normally support multiple paths, consider whether your router vendor's implementation does anyway. For example, RIP does not normally support multiple paths to a destination network, but the RIP implementation in a Cisco router does handle such redundancy, and will even do load sharing across multiple paths with equal costs (metrics).
You might also need to consider how well your network protocols will scale to the size you expect your network to achieve. Link-state protocols usually scale better, but some distance-vector protocols, such as Cisco's EIGRP, have proven themselves in networks with 1,000 or more routers.
Finally, you may have to consider whether a protocol is an open standard or a proprietary protocol. This may be because of policy constraints of your organization, or it may be because you must support multiple vendors' routers in your network. A protocol that is only spoken by half of your routers isn't terribly useful to the other half. Table 5-1 summarizes these criteria for the most common interior routing protocols you are likely to be considering.
Table 5-1: Summary of Common Routing Protocol Features
Convergence Time
Bandwidth Consumption
Resource Consumption
Multi-path Support
no a
Scales Well
Routers Non-IP Protocols
a Some vendors may support multiple paths in RIP.
From the table, it may seem that EIGRP is the ideal choice. It is fast, consumes little resources, supports VLSM, and scales well. But it is also proprietary, and unless you have a single vendor for all your routers, and that vendor happens to be Cisco Systems, you will immediately be faced with multiple routing protocols in your network. The complexity involved in running multiple routing protocols should not be taken lightly, so give careful thought to any proprietary routing protocol or solution before you make your decision.
Once you have selected a protocol, or have at least narrowed your choices down to one of two, it is time to start thinking about how you would configure your protocol to achieve your network goals and solve any problems that you may have in your network. The next chapter presents several common scenarios that are likely to arise, and shows how to use each of the protocols in Table 5-1 to solve that problem. While looking at these examples, you may discover that your chosen protocol may make it difficult for you to solve some specific problem in your network; or, if you have not chosen a specific protocol, seeing how each of your prospects works for or against your specific network situation may provide you with the remaining information you need to select between them.
1. The Internet Protocols originally called routers gateways. This usage is no longer common, but it still appears in routing protocol discussions.
2. Not to be confused with the Exterior Gateway Protocol version 2 (also known as EGP), which is one of many exterior gateway protocols.
3. EIGRP has largely supplanted IGRP, its predecessor, because EIGRP has all the advantages of flexibility and simple configuration while improving on speed and resource consumption. It is also capable of being a unified routing protocol both for IP and some non-IP protocols, eliminating the need to run multiple routing protocols in a multi-protocol network. I will point out any significant differences between the two.
4. The mathematical definition of a vector is direction and length. Unfortunately, when network engineers refer to a distance-vector protocol, they refer to the direction only. To avoid confusion, we will try to limit the use of the term.
Back to: Managing IP Networks with Cisco Routers
© 2001, O'Reilly & Associates, Inc.


text:
"Back in first grade, I was a brat who couldn't be bothered with team sports. Didn't care much about anything that didn't affect me. But he was the one who made me understand how important it is to be part of a team; a community."
Actually, you know what - I'm not even going to bite my tongue on this one because Tyler's tag is fucking bullshit right now. Seriously, are we going to say that his plot of revenge is pointless, and that you are upset because he hurt Caroline? Oh my fucking god. So it's pointless that he wants to get revenge on the guy that killed his mother? The last remaining piece to his family without any remorse? I'm sorry, did we not watch the same fucking show tonight and for the past two seasons? Klaus took away his life, made him into his little slave and abused him time and time again by making him out to be this bad guy that his friends couldn't trust until he was unsired, to the guy that almost killed his girlfriend whom Klaus is so infatuated with because Klaus told him too - and yet, people are still upset at Tyler even though Klaus what, tried to kill Caroline twice? No wait, three times actually if you want to count season two for the sacrifice. But, whatever. I'm sorry, but what Klaus did to Tyler's mother, to… well hell lets just add Aunt Jenna into the mix was unforgivable. And yet after tonight's episode the only one that is still getting the most hate out of everyone is Tyler, whom deserves no hate in my opinion because he has his reasons for doing this, he has his reasons for doing what he did to Hayley - alright? And his reasons aren't pointless; jesus fucking christ, fandom.
No, but seriously - if Tyler is the one torturing Hayley, then the reasoning should be clear. She's carrying Klaus's child; Klaus killed his mother - and the only attachment that Klaus really has aside from his family is the baby. So, to get back at him without actually killing him - is to put the baby in danger, so he knows what it feels like to lose something, so he can feel the pain of loss that Tyler has dealt with for what, the past year? I mean, that's how I see it honestly and if Julie seriously didn't write that as the reasoning then she's a bigger dumbass than she has been for the past few years.


text:
This is a hodge-podge collection of shit I reblog. Fandoms galore. Sometimes the tags are entertaining. Sometimes maybe not so much.
Real talk time, I will be flailing over my ships about 99% of the time, so just be prepared for that. You have been warned.
Catching Elephant is a theme by Andy Taylor


text:
Albergue Anatot Reviews
- Info
- |
- Rates
- |
- Map & Directions
- |
- Reviews
- |
- Deals
- |
- Facilities
Reviews & Ratings Explained
The rating percentage is calculated from customers who booked within the last 12 months.
All ratings and reviews are based on the feedback and opinions of the customers who submitted them and do not express the opinions of Hostelworld.com. This way, you get an up-to-the-minute opinion of just how good a hostel really is.
Read our review guidelines »
It was a very nice stay. The plays is for everybody who search some peace and silence to relax and to avoid the touristic area and to see the true Gran Canaria. The food is very good and the stuff is lovely and helped us a lot. It was very helpful to have a car in this area. Thank you for everything.
- Novice Nomad
- Anonymous
- Germany
- Couple, 31-40
- (1 review)


text:
201 - Current
I. A congratulations and a welcome to new FS Instructor Laura Scarry
II. New study: "No fatal risk" in proning out violent resisters
III. New findings on obese subjects & prone positioning
IV. Latest news on OIS that occurred inside an accelerating van
V. FS faculty member trains feds to interview "Persons of Concern"
I. Once again, scientific probe challenges alleged danger of prone positioning and hog-tying
II. New study: Force & struggle don't affect sobriety test results
III. Study yields jury-friendly measure of stress caused by CEW deployment
I. "Looming": Important consideration when cops fire at moving cars
II. New survey: Vest wear up, but care problems a potential threat
III. "Heroes": Powerful new film of life and death on the thin blue line
IV. New stats on the growing threat of rapid mass murder
V. Array of free legal info available at "one-stop" website
I. When you don't see what's visible: The in-attentional blindness factor
II. Research findings mark the dismal toll of police stress
III. Coming to courtroom near you: more brain scans of violent suspects
I. Doubts raised about certain reaction-time training exercises…and more.
II. New free site offers case-by-case details of Taser court decisions
© 2014 Force Science Institute Ltd.


text:
Original post @ Happy Hunting!.
Happy Hunting's very own Hunt Reporter and Host Cinders Vale brings out gifts from the Sports Hunt, Around the Grid in 80 Days Hunt and an Anarchy Hunt fashion show. You can see a slide show of active hunt posters, as well as those accepting applications for the next few weeks.
Visit http://happyhuntingtv.wordpress.com/2014/08/29/80-days-with-sports-and-anarchy-at-happy-hunting/ for actual post date.


text:
Credits count. They help potential clients determine whether or not to hire a filmmaker, producer or studio. To be fair to them and those involved, I encourage you to practice what I call good "creditquette".Continue reading
Tag Archives: variable
Salomon Ligthelm on Crossing the 180 #96
This week I interview one of the most stylistic filmmakers on the DSLR scene today. You don't want to miss this one!Continue reading
Miller Mobley on Crossing the 180 #94
Photographer turned filmmaker Miller Mobley talks about his experience co-directing "Greatness is Within" in collaboration with Variable.Continue reading


text:
I don't know. But I want to be on wedding.
I haven't never seen Olympic Games.
I like watching a comedy. I prefer to watch films in cinemas. But I didn't have a cinema in my city. Recently they
Wash and cut vegetables. Mix everything and pour souce.
On the first photo I can see fruits. I love them. It is sweet, sometimes sour. Every fruit is delicious. And on t


text:
Alejandro Quesada wrote a question about Six Six One Evo Pressure Suit on July 12, 2010
Is this a d3O based suit?
Is this a d3O based suit?
Do you recommend this case for DH bikes? If not, what case do you recommend to travel with a DH bike (wheels included)?
Thank you!
0 Answers


text:
Here she is for the first time ... the spawn of Kim Kardashian and Kanye West.
Kanye revealed the photo of baby North West on Kris Jenner's talk show moments ago, a last ditch effort to boost ratings before Fox decides whether to pick the show up for a full series ... something Kim's mother is desperately hoping for.
As we reported, Kim and Kanye had initially debated using the baby's first images to raise money for charity ... but they decided Kris' show was a more worthy cause.
she is a cute baby...I give her that....
She's a cutie =)
Totally cute, looks like her mum!
Nice work Kim & Kanye. Props.
No denying she is adorable!
Wow, she really is a beautiful baby! Regardless of what anyone thinks of her parents, can't deny she's a cutie.
What a cute baby, please don't sell her to the media.
Enjoy your angel.
Haha she already has a moustache.
She is a cutie, but the people in Oklahoma has already seen here days ago!
they debated whether or not to sell the pics for charity???? No one offered the big money they wanted, and the charity would have been PMK church!! No one really cares about this kid....and their over inflated ego's are hurt!
She looks too old for a new born & ugly too.
a beautiful girl...looks like her mama. So glad that is over...now let the child have a normal life and stay out of it because ya'll are the only ones who love the "K" family.. Now on to real important stuff!
The baby is already holding her head up wow strong baby.


text:
Quarry House, High Street, Steeton - 3 bed - £239,950 - Green Partnership - Keighley
Property details
Quarry House, High Street, Steeton £239,950
Phone 01535 930603
Property details
Bedrooms: 3
VALUERS OPINION An attractive and deceptively spacious family-sized home, situated on the fringe of this sought after village, close to open countryside. The accommodation includes two reception rooms plus conservatory and dining kitchen, plus three good-sized bedrooms and spacious bathroom with four piece suite. Both central heating and double glazing are installed. Externally there are virtually level gardens to the rear and driveway to the side providing parking with access to the single garage. This family-sized detached property enjoys distant views and is most highly recommended for an internal inspection.
Entrance Porch with quarry tiled floor.
Lounge 14'6 x 12'0 (4.43m x 3.67m). 'Living flame' gas fire in feature traditional style surround with wood mantle and quarry tiled hearth. Windows to two aspects. Ceiling coving.
Sitting Room 14'7 x 8'11 (4.46m x 2.73m). Windows to two aspects. Ceiling coving.
Dining Kitchen 19'1 x 8'10 (5.83m x 2.71m). Range of base and wall units being tiled between, with worksurfaces incorporating inset sink and drainer. Range style cooker with five ring gas hob, oven and grill, plus additional electric oven. Hood over. Integrated refrigerator and freezer. Display unit. Laminate floor covering. Pantry off.
Conservatory 11'9 x 7'5 (3.58m x 2.27m). Views and access onto rear garden. Laminate floor covering.
Utility Room 'Belfast' sink in wood surround with drainer and cupboards below. Plumbing for automatic washing machine. Gas fired central heating boiler. Airing cupboard with radiator.
Cloakroom with low suite wc.
Landing Useful study area.
Bedroom One 14'7 x 15'6 (4.45m x 4.73m). Built-in wardrobes with cupboards over. Distant views from window. Ceiling coving. Windows to two aspects.
Bedroom Two 14'5 x 12'1 (4.41m x 3.69m). Windows to two aspects, one enjoying distant views. Ceiling coving.
Bedroom Three 11'10 x 8'9 (3.62m x 2.68m). Ceiling coving.
Spacious Bathroom 10'8 x 8'9 (3.27m x 2.68m) with four piece suite, comprising:- tiled shower cubicle, panelled bath, wash basin and wc. Tiling to walls. Recessed spotlights.
EXTERNALLY Gardens to front and rear. Driveway to side providing parking and access to single garage.
DIRECTIONS From the traffic lights in Steeton, proceed towards Airedale Hospital. After passing the pelican crossing turn first left into Mill Lane. At the 'T' junction turn left into High Street and continue up the hill. Towards the top there is a cross roads with an unmade road to the left and right. Turn right where Quarry House will be seen on the left-hand side.
VIEWING By appointment with our Silsden Office.
These particulars are believed to be correct, though their accuracy is not guaranteed and they do not form part of a contract. No person in the employment of The Green Partnership has authority to make any representation or warranty whatsoever in relation to the property. Fixtures and fittings not referred to in the text are specifically excluded. Where included, the heating system and kitchen appliances have not been tested. Measurements are approximate, usually to the nearest 6 inches (15cm) of a room's maximum dimension. Illustrations are for identification purposes only and are not to scale.
Local information for this property
Abbey Park Junior, Infant and Nursery School
Addingham Primary School
All Saints' CofE Primary School
Allerton Primary School
Ashfield Primary School
Ashlands Primary School
Askwith Community Primary School
Atlas Community Primary School
Baildon CofE Primary School
Barnoldswick Church of England Controlled Primary School
Ben Rhydding Primary School
Blakehill Primary School
Bradleys Both Community Primary School
Brooklands School
Burley and Woodhead CofE Primary School
Burley Oaks Primary School
Carleton Endowed CofE Primary School
Chellow Heights Special School
Christ Church Church of England Voluntary Controlled Primary School
Clayton CofE Primary School
Clayton Village Primary School
Coates Lane Primary School
Colne Christ Church Church of England Voluntary Aided Primary School
Colne Lord Street School
Cononley Community Primary School
Cottingley Village Primary School
Cowling Community Primary School
Crossflatts Primary School
Crossley Hall Primary School
Cullingworth Village Primary School
Denholme Primary School
Earby Springfield Primary School
East Morton CofE Primary School
Eastburn Junior and Infant School
Eldwick Primary School
Embsay Church of England Voluntary Controlled Primary School
Foulridge Saint Michael and All Angels CofE Voluntary Aided Primary School
Foxhill Primary School
Frizinghall Primary School
Gargrave Church of England Voluntary Controlled Primary School
Girlington Primary School
Glenaire Primary School
Glusburn Community Primary School
Green Lane Primary School
Harden Primary School
Hawksworth Church of England Primary School
Haworth Primary School
Heaton Primary School
Heaton St Barnabas' CofE Aided Primary School
High Crags Primary School
Hollingwood Primary School
Holycroft Primary School
Horton Grange Primary School
Hothfield Junior School
Hoyle Court Primary School
Idle CofE Primary School
Ingrow Primary School
Iqra Community Primary School
Keelham Primary School
Keighley St Andrew's CofE Primary School and Nursery
Kelbrook Primary School
Kildwick Church of England Voluntary Controlled Primary School
Laneshaw Bridge Primary
Laycock Primary School
Lees Primary School
Ley Top Primary School
Lidget Green Primary School & Children's Centre
Lilycroft Primary School
Lister Primary School
Long Lee Primary School
Lothersdale Community Primary School
Low Ash Primary School
Margaret McMillan Primary School
Menston Primary School
Merlin Top Primary School
Miriam Lord Community Primary School
Moorside Community Primary School
Myrtle Park Primary School
Nessfield Primary School
Oakworth Primary School
Oldfield Primary School
Our Lady of Victories Catholic School
Oxenhope CofE Primary School
Park Primary School
Parkwood Primary School
Poplars Farm Primary School
Priestthorpe Primary School
Princeville Primary School
Rainbow Primary School
Riddlesden St Mary's CofE Primary School
Russell Hall Primary School
Sacred Heart Roman Catholic Primary School, Colne
Saltaire Primary School
Salterforth Primary School
Sandal Primary School
Sandy Lane Primary School
Shibden Head Primary School
Shipley CofE Primary School
Skipton Parish Church Church of England Voluntary Controlled Primary School
Skipton, Greatwood Community Primary School
Compare all 143
Aireville School
Beckfoot School
Beechcliffe Special School
Belle Vue Boys' School
Belle Vue Girls' School
Bingley Grammar School
Bradford Christian School
Bradford Girls' Grammar School
Bradford Grammar School
Brooklands School
Colne Park High School
Dixons Allerton Academy
Ermysted's Grammar School
Guiseley School
Hanson School
Hazelbeck Special School
Ilkley Grammar School
Immanuel College
Jaamiatul Imaam Muhammad Zakaria
Kings Science Academy
M A Girls School
New Gables
Oakbank School
Oasis Academy Lister Park
One In A Million Free School
Parkside School
Queensbury School
Skipton Girls' High School
South Craven School
St Bede's Catholic Grammar School
St Catherine's Catholic High School
St Joseph's Catholic College
St Mary's Catholic Comprehensive School, Menston
The Alternative School
The Challenge College
The Holy Family Catholic School
The North Halifax Grammar School
The Samuel Lister Academy
Thornton Grammar School
Titus Salt School
University Academy Keighley
West Craven High Technology College
Compare all 42
Local information for this property
- Read full description
- See this house on a map
- Read local information
Local Advertisers


text:
Astrophysical theory is intellectually vibrant, and productivity is high: about 45 percent of published papers are on theory, and about one-third of publishing astronomers are pursuing theory (see Figure 4.9). Based on the recent record, there is a compelling case that investments in theory by the agencies will be amply repaid in the form of new mission and experiment concepts and enhanced scientific return from operating facilities. Astrophysical theory draws some of the world's best intellectual talent into the U.S. scientific enterprise. Because some of the most important theory contributions in the next decade will come from broadly based theory not specifically tied to large activities, the role of general individual investigator programs will continue to be as important as ever. These programs form the traditional base of theoretical astrophysics in which Ph.D. students are trained, new ideas arise, and future observational or experimental efforts are seeded.
Astrophysics and cosmology theory is supported through a number of programs at the federal agencies. At NSF, general astrophysics theory is funded through the AST Astronomy and Astrophysics Research Grants (AAG) program,5 as well as through the NSF Division of Physics (NSF-PHY) via its Frontier Centers and individual investigator grants in cosmology and particle physics theory. At NASA, the Astrophysics Theory Program (ATP) supports most general theory efforts. In addition, the Hubble, Spitzer, Chandra, and Fermi Observatories accept theoretical investigations as part of their guest investigator programs. Other critical support comes from NASA Prize Postdoctoral Fellowship programs (Einstein, Hubble, Sagan). The DOE's Office of High Energy Physics also supports theoretical and computational astrophysics efforts. Table 5.2 summarizes current funding levels.
As is the case with the grants programs in general, proposal success rates in theory have declined over the past decade. The recent success rate in NASA's ATP is only 15 to 20 percent, significantly lower than funding rates for theory within its Planetary Exploration program, for example. Given the central importance of theory to the enterprise, and the crucial role played by individual investigator grants, the committee recommends in Chapter 7 that the grants programs at both NSF and NASA be augmented.
The dramatic impact of computation on astronomy and astrophysics is manifested in many ways. Modern numerical codes are now being used to simulate and