[c-nsp] Options for customer prefix injection into iBGP at the edge

[Mark Tinka]

On Friday 04 September 2009 03:31:10 am Justin Shore wrote:

> loops.  The downside is that I hate using redistribution.
>  I'm not a big fan of it.  I've been bit too many times
> to consider redistribution a good method of doing
> anything. It will also result in higher CPU load as the
> RIB is frequently parsed for statics and processed with
> the route-map if I'm not mistaken. Correct?

We find redistribution useful with l3vpn's, because the NLRI 
is only limited to the VRF in question.

Aside from that, no, we don't like to use it either 
(although one might argue that Route Leaking in IS-IS is a 
form of redistribution, between levels).

The other place where we've used redistribution is when we 
need to announce the management IP address of a switch that 
doesn't support IS-IS through via router it's connected to.

But moving on to your issue...

> What methods do my SP colleagues prefer to use when
> managing the injection of customer routes into iBGP?

So there's three kinds of scenarios we typically look at:

a) customers who are assigned address space from our
   allocation.

b) customers who have their own allocation but don't run BGP
   and have us announce it for them.

c) customers who have their own allocation and run BGP with
   us.


1. For customers that use our address space, each router is
   is assigned a /24 (more or less) from which customers'
   point-to-point addresses are derived. This is announced
   as a single route from that edge router.

   In addition, customers may be assigned additional address
   space for their LAN, e.t.c., which we announce to the
   network via:

	- static pull-up route
	- BGP network statement (Cisco)
	- route-filter entry (Juniper)

   We have a routing policy from each edge router to our
   route reflectors that sets the LOCAL_PREF and community
   values as necessary for all our aggregates + longer. This
   ensures any prefixes that belong to us which we assign to
   our customers maintain a consistent routing policy. This
   routing policy references a generic prefix list (Cisco)
   or route filter (Juniper).


2. For customers who have their own address space but don't
   run BGP with us, the point-to-point address policy as in
   1), above, applies.

   We also have a routing policy from each edge router to
   our route reflectors that sets the LOCAL_PREF and
   community values as necessary for these types of
   customers. This routing policy also references a generic
   prefix list (Cisco) or route filter (Juniper).


3. For customers who have their own allocation and run BGP
   with us, we have a standard outbound policy depending on
   whether customers want full, partial, customized or
   default routes. This policy also references a generic
   prefix list (Cisco) or route filter (Juniper).

   The inbound policy is either generic for non-kinky,
   standard eBGP turn-ups, or customized if customers
   require more specific policies. This policy also
   references a customized prefix list (Cisco) or route
   filter (Juniper). These lists are aptly named, making
   troubleshooting easier for the NOC.


In the case of 2), above, admittedly on an on-going 
operational basis, it is easier to inject customer prefixes 
into iBGP with Juniper because it's a 2-step process which 
also achieves filtering, rather than in Cisco where it's a 
3-step process with filtering.

In Juniper, all you do is:

a) write a pull-up static route.

b) write a route filter which is referenced by an iBGP
   export routing policy.


In Cisco, you achieve the same with one extra step:

a) write a pull-up static route.

b) write a prefix list which is reference by an iBGP
   route map.

c) write a 'network' statement in BGP.


However, the extra step with Cisco is not a big deal.

For the case of 3), above, the Cisco portion is just a two-
step process as in the Juniper case (with only a) and b) 
steps being required), as the customer routes are being 
generated by, well, the customer.

Hope this helps.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090905/a29ed59f/attachment.bin>