[c-nsp] Options for customer prefix injection into iBGP at the edge
Mark Tinka
mtinka at globaltransit.net
Sat Sep 5 00:39:31 EDT 2009
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>
More information about the cisco-nsp
mailing list