[j-nsp] BGP origination

[dre]

On Wed, Jan 29, 2003 at 02:17:15AM -0500, Richard A Steenbergen wrote:
> For example, you have a customer with a /24 implemented as a .1/24
> address on an interface, and you need to announce that /24 for them.
> The interface route will override the static route because of
> preference, the route with the community tags attached will never
> get into the rib, and the route will never be announced. (or somewhat
> conversely say the /24 is used inside your network and redistributed
> via an IGP, the static would win and you would need to specify a
> working next-hop in your holddown route).

Don't mix customer prefixes with your own infrastructure addressing.
Always save at least a few infrastructure addresses for customers,
namely the preferrably /31 (but is often /30 due to code limitations)
ptp links, and one loopback per customer (e.g. for bgp router-id per
neighbor).  keep N for gre, hsrp/vrrp, and other off-one situations
(plan accordingly; N is often larger with a smaller customer base).

With proper address planning, you can easily avoid this situation.
A good policy would be to dictate that customers not implenting BGP
get static routes only (no customer addressing allowed in your IGP
ever), but directly to your outgoing interface, while still giving
them an infrastructure address on (from your perspective) far-end
interfaces.  You can then classify these customer static routes to
be redistributed into your IBGP.

Sorry to go to the competitor's documentation, and I would write
it in RPSL, but that would mean digressing a little further off-topic.
This is a very good reference on "access engineering" BGP4+CIDR best
practices:

ftp://ftp-eng.cisco.com:/cons/workshops/isp-workshop/StudentCD-Rev-E/Adv_BGP/a3-1up.PDF

dre