I will definitely look into some of the resources you mentioned. Again,
thanks to all who responded.
~-----Original Message-----
~From: Peter van Oene [mailto:pvo@xxxxxxxxxxxx]
~Sent: Thursday, July 11, 2002 10:16 AM
~To: Lupi, Guy; cisco@xxxxxxxxxxxxxx
~Subject: RE: Route Reflection with Multiple POPs [7:48509]
~
~
~Not really :) Howard's is one of the few SP oriented books on
~the market
~though admittedly I haven't picked it up yet (very broke :)
~
~The ISP resources at NANOG are helpful and contain some
~valuable links and
~one can glean some valuable information by looking at some of the
~historical design oriented presentations that many have given over the
~years. Cisco also has a document (and recently a book based on the
~document) from Phillip Smith which deals with ISP design tips (called
~something like IOS Essentials: Design tips every ISP should know --
~something similar to that) Some quick tips would include:
~
~IGPs:
~- install only link/loopback addresses (ie no redistribution
~into the IGP
~of static/connected/or otherwise)
~- tune metrics for optimal SPF(usually to link delay - ie 70ms
~= 70) - see
~latest nanog for netflow/lots of math based method which seems cool! :)
~- pre allocate contiguous IP space to non-backbone areas such that
~summarization _could_ take place
~- keep in mind summarization when multiple exits from an area
~exist can
~cause sub-optimal routing in normal states and blackholes in
~some failure
~states
~- if you _really_ need to put externals in your IGP (say you
~have a bunch
~of dial routers and marketing gave some customers static IP's that are
~radius assigned (shame on you marketing), use a separate
~instance of the
~IGP or use NSSA with no type 7/5 conversion or full external
~filtering at
~L1L2 border in ISIS and advertise a BGP aggregate from the
~related ABR's.
~- authentication can't hurt
~- hard code RIDs
~
~
~BGP
~- peer on lookbacks
~- hard code RIDs
~- use recognizable /32 space for loopbacks for easy router
~identification
~- use bgp-deterministic-med (to reduce some potential for med oriented
~oscillation) (lots of ietf chat on this on IDR group as howard
~points out
~from time to time)
~- build resilient RR clusters (ie two RR servers per group of clients)
~- one cluster ID per RR server (subject to some memory vs
~potential for bad
~routing debate) (also cisco default)
~- use communities and do community based advertisements
~- wrt to advertising to transit providers/peers, use an
~explicit accept /
~default reject style policy for safety (ie when you mess it
~up, you don't
~send anything vs messing it up and advertising transit)
~- authenticate IBGP and possibly EBGP where appropriate
~- use next-hop-self vs passive interface (helps hook mpls into
~forwarding
~plane if you decide to deploy it and keeps IGP smaller)
~- don't dynamically redistribute anything in bgp - ie only
~redist statics
~routes for aggregation
~- try not to leak too much junk to your transit providers (ie
~aggregate
~where you can without too much TE loss)
~- filter customer prefix advertisements - IRR based would be
~ideal, but
~manual is cool too
~- local pref customer routes over peer routes over transit routes
~- either use meds or zero them in and out (better to know what
~is going to
~happen than learn :)
~
~Lots of more stuff out there likely to cover, but thats my 10
~minute off
~the top of my head while my soup cooks :) Likely lots there
~to debate as
~well! Building networks generally involves a lot of personal design
~philosophy which makes for healthy debate.
~
~Pete
~
~
~At 09:20 AM 7/11/2002 -0400, you wrote:
~>This is where my thinking went wrong then, Phil also said
~basically the same
~>thing. It seems that I have a basic misunderstanding of how larger
~>providers carry their routing information. Where would I be
~able to get
~>information about proper addressing structures and routing protocol
~>implementation in large/service provider networks? Are there
~any books that
~>go into detail on these particular topics, take you step by
~step from a
~>customer through to the core?
~>
~>-----Original Message-----
~>From: Peter van Oene
~>To: Lupi, Guy; cisco@xxxxxxxxxxxxxx
~>Sent: 7/11/2002 8:18 AM
~>Subject: RE: Route Reflection with Multiple POPs [7:48509]
~>
~>Hi Guy,
~>
~>As others have pointed out, it is not necessary, nor usually
~desirable,
~>to
~>run separate IGPs in your AS assuming you use your IGP properly. A
~>properly utilized ISP IGP should carry only link and loopback
~addresses
~>and
~>thus be reasonably small. Use of hierarchy can also help
~larger domains
~>
~>scale, though modern IGP implementations on reasonably powered routers
~>should be able to handle rather large single areas.
~>
~>BGP never runs entirely on its own as one always requires
~some method of
~>
~>resolving BGP Next-Hops to forwarding next hops. Static
~routes can work
~>
~>here to connect otherwise disconnected IGP domains, or, separate IGP
~>domains can be used for this purpose as well.
~>
~>At 06:19 PM 7/10/2002 -0400, Lupi, Guy wrote:
~> >I know that you can run confederations and reflectors, and seperate
~>levels
~> >of reflection, which Cisco refers to as "nested reflection". Now my
~> >question is, how would you set up your bgp peering? Due to
~financial
~> >constraints I would imagine that the best thing to do would
~be to have
~>one
~> >circuit from POP router 1 to core router 1, and another circuit from
~>POP
~> >router 2 to core router 2. Assuming that you are only
~running BGP in
~>the
~> >core, and that the clients have to have a session with each
~reflector,
~>how
~> >would you communicate the loopback addresses of all the
~routers to each
~> >other? Are static routes used in this situation? Thanks
~to all of the
~> >people who responded by the way, I appreciate the
~direction. Ever feel
~>like
~> >you know so much, only to read a book and find out that you know so
~>little
~> >:)?
~> >
~> >*-----Original Message-----
~> >*From: Peter van Oene [mailto:pvo@xxxxxxxxxxxx]
~> >*Sent: Wednesday, July 10, 2002 3:00 PM
~> >*To: cisco@xxxxxxxxxxxxxx
~> >*Subject: Re: Route Reflection with Multiple POPs [7:48509]
~> >*
~> >*
~> >*Couple thoughts. First off, one can confederate and reflect
~> >*at the same
~> >*time (ie rr clusters inside sub-as's). Also, keep in mind
~that these
~> >*techniques deal with control, not forwarding and thus it is
~> >*possible, and
~> >*somewhat common, to have a RR hierarchy that does not map
~> >*directly to the
~> >*physical topology. I tend to see an arbitrary set of core
~> >*routers (from
~> >*2-20ish) that form the central IBGP mesh with the second
~level of the
~> >*hierarchy being formed by lead major pop routers, or
~dedicated route
~> >*servers (ie one armed routers that simply reflect routes). I
~> >*personally
~> >*try to keep the topology as flat as possible (ie less than 4
~> >*levels in the
~> >*hierarchy) but I don't have any particular technical driver
~> >*for that other
~> >*than to minimize complexity and aid troubleshooting.
~> >*
~> >*Of note, this assumes you are reflecting full routes
~throughout your
~> >*backbone. I've seen providers try and reflect partial routes
~> >*to areas of
~> >*their backbone to allow for smaller routers where RR
~> >*topologies can lead to
~> >*blackholes. In general, if you are reflecting all routes, you
~> >*shouldn't run
~> >*into issues here.
~> >*
~> >*I
~> >*
~> >*
~> >*
~> >*At 04:42 PM 7/10/2002 +0000, Lupi, Guy wrote:
~> >*>Let me preface this by saying that I am trying to learn more
~> >*about large
~> >*>scale BGP design and operation. This question is on route
~> >*reflectors when
~> >*>you have multiple POPs in seperate IGP domains. If you
~> >*currently have one
~> >*>POP and are going to move to 2 within the same AS, you can
~> >*either run full
~> >*>mesh (doesn't scale), reflectors, or confederations.
~> >*Assuming you don't
~> >*>currently have a central core that the POPs connect back to,
~> >*how well does
~> >*>reflection scale? I was reading Building Service
~Provider Networks
~> >*>[Berkowitz], and it states that iBGP doesn't scale well once
~> >*you go above
~> >*>15-20 sessions per router. It also states that most ISPs run
~> >*reflectors
~> >*>instead of confederations, but I believe that statement is
~> >*being made under
~> >*>the assumption that the ISP will have a central core to which
~> >*the POPs will
~> >*>connect. This would indicate to me that assuming you don't
~> >*have a central
~> >*>core, one could only connect 6 or 7 POPs (dual reflectors for
~> >*redundancy)
~> >*>together using reflection before you would have to either
~> >*create a central
~> >*>core to reduce the amount of iBGP sessions, or turn to
~>confederations.
~> >*>Perhaps the best way to accomplish this would be to establish
~> >*a "core" in
~> >*>one of the POPs and run reflection from there, which is also
~> >*presented as a
~> >*>solution in the book? Any opinions? I have made an
~attempt at ASCII
~> >*>drawing below, to me the central core solution makes more sense.
~> >*>
~> >*> First Scenario, no central core
~> >*>
~> >*> POP 1 POP 2
~> >*> Cluster Cluster
~> >*> o---------------o
~> >*> Full Mesh Between Reflectors
~> >*> o---------------o
~> >*>
~> >*> Second Scenario, central core establised at one of the POPs
~> >*>
~> >*> POP 1 POP 2
~> >*> Core Reflectors
~> >*> Clients o----- -----o Clients
~> >*> o----- \ / -----o
~> >*> o o
~> >*> POP 3 / \ POP 4
~> >*> Clients o----- -----o Clients
~> >*> o----- -----o
~> >*>
~> >*>
~> >*>Guy H. Lupi
~> >*>CCIE No. 9275
~> >*
~> >*
~> >*
~> >*
~abuse@xxxxxxxxxxxxxx
~
~
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=48590&t=48509
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx
