> ""Howard C. Berkowitz"" wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Two more things (going back to more original topics I want
to cover again).
> > The first key question to ask here: what is the broad routing
> > paradigm? Cold potato/closest exit or hot potato/best exit?
>
> For a "peering routes" example, yes best-exit/closest-exist problems
> are super high on the agenda. However, that seems to be more of
> an IGP problem, and that's where regular knowledge of say, OSPF,
> is taken to a whole new level. And one that is never taught in any
> course or material in any classroom or even online. You learn that
> on the job at an ISP (does anybody else have any resources for this?).
>
> > >Many ISP's may want to inject their IGP into their BGP for
> > >customer static routes (using a route-map to filter out all the junk).
> >
> > With considerable aggregation, yes. Alternatively, though,
> > redistributing blackhole statics for their allocations is common
> > enough.
>
> Reversal routing concepts are common in the workplace and unheard
> of in any labs/certification courses.
>
> > We've been learning a lot about that IGP metric direct translation to
> > MED can be dangerous, and produce persistent oscillation. Those route
> > maps may be the better way to set MED.
>
> Where is there information available in-print/online about the MED's
> topic? Another one completely skipped over. Most people are using
> IGP metrics alone these days, no need to try to translate. At least in
> the environments I've seen. This is a part of that whole closest-/best-
> exit argument above. I've never really seen any configs or designs for
> translating IGP metrics to MED, something like that would interesting
> to see - even if it produces oscillatory routing. Do you know why this
> happens? Can you try to explain the problems more effectively?
So we've covered the "how" with MED's and IGP costing... now let's
discuss the "why".
There is no broad paradigm for shortest-/best- exit routing. This is
because somebody loses either way. One ISP is going to have to
take the "big" content traffic, and the other ISP is going to have to
take the "small" user traffic (on an asymmetrical path). This equation
gets worse when more ISP's get involved. This equation gets even
more worse when longer fiber routes are involved (across states,
across coast-to-coast, across *oceans*, etc). Who is going to
take the bulk of the traffic the longest distance?
Somebody got the short end of the stick here, and it was clearly
the access providers (should i say, Tier 2's? or would that be bad?).
Content providers, and content-heavy ISP's made it out big-time
during the whole period that the shortest-exit routing paradigm was
king. Now, you have access providers desparately looking to peer
with content providers and skipping the middlemen pointing their
shortest-exit at them. However, they aren't getting anywhere when
those same middlemen don't explain to the content providers how
to be "Internet" correct, when they can make tons of money. They
would rather sell transit to content providers at sub $100/Mbps per
month (outbound only even) instead of lose that traffic ratio that's
putting their competitors out of business.
Look at this another way, and see that content providers aren't going
to bother peering when they get these super-low prices. And content
providers (and therefore their upstreams even moreso) control the
whole flow of the Internet because local_pref *trumps*. It's not only
better to give than to receive according to your original statement --
it keeps you in business and puts your competitors and the Internet
access providers (whatever really happened to ExciteAtHome?) and
really, when it comes down to it -- the end-user *consumers* in the
same situation as the rest of corporate america -- a big fat short end
of the stick.
Just to make matters worse, as a content provider... or content-heavy
ISP -- you can actually *force* that competitor/access-provider/user-
heavy community (the eyeballs of the Internet) to use their *most*
expensive bandwidth (by resonable interpretation or corporate
espionage, social engineering, etc). Now *that* is truly scary.
Sorry for the conspiracy theories, but maybe this will allow some readers
to understand the whole shortest-/best- exit routing concepts better (or
it just might confuse them, hhehehe).
> But you can "sort of" find out what's changed and what hasn't changed.
One
> way to look at the churn is to do a "show ip route | i , 00:00" every
minute
> (shows you routes that have converged in the past minute). Another would
> be to collect dumps of the routing table and/or BGP table in intervals and
> compare them Unix "diff"-style. You can then make comparisons against
> the rest of the BGP table (like AS-paths) and/or SNMP IF-MIB-like data
> to find out what changed where (and possibly why).
Another thought I wanted to add in here. 7 areas of study I find
interesting
in this space:
1) Netsys (Cisco bought em. Cisco EOL'd it.)
2) WANDL IPAT (and competitors like Netmaker, OPNET ITG, et al)
3) Caimis/IXIA NetOps (and SDSC/CAIDA)
4) Yahoo TUNDRA Zebra/NetFlow analysis (and NetVMG, RouteScience, Sockeye,
Adlex, Proficient, et al)
5) Cisco MPLS/CEF TE with tmstats (and TE-MIB, et al)
6) Making RPSL work with anything above (and the Merit and/or RIPE
associated tools)
7) OSPF E1/E2 and how ISIS would do something similar (basically any
additive or multiplicitive routing concepts
apply here, including matching on additive communities and setting
something like local_pref)
I have a lot of expertise in 4-7, but not so much in 1-3 (probably because
they're bloat, but I'm not going to make any assumptions never having used
those products before). I want more experience in all those areas, and I'm
trying to build on that. Any input would be highly appreciated.
-dre
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=44796&t=44778
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
