[c-nsp] BGP into OSPF

[Barrie Jones Cook]

Hi Dario and everyone,

Please excuse me for quoting the entire reference
email, but it's been several days since it was written
and I'm guessing my reply won't stick to the thread
anyway (I get the digests and can't reply directly). 
I can't find any other replies to this, so I'm going
to go ahead and take a stab at it.

> We need to implement some special network.
> 
> Our customer has a link with us (statically routed)
and inside his network he's running OSPF.
> Due to traffic increase we need one more link and we
think to implement BGP to balance traffic.
> 
> This is the final plot:
> 
>             R1   R2 
>             |     |                        (AS766)
> --------------------------- eBGP
>        |               |                 (AS65xxx) 
>       C1-----iBGP-----C2
>        |               |
>       ------------------
>         OSPF cloud
> 
> Some customer networks (C1-nets) need to be routed
via C1 and the others (C2-nets) via C2 
> (and allways same way due to multicast issues). When
link C1-S0 fails all traffic will go via 
> C2-S0 and vice versa.

When I see S0, I think "Serial0".  I'm assuming,
therefore, that this is a Serial0 interface on each of
two different routers in AS 766.  As such, I'll change
the above diagram to say "R1" and "R2" instead,
because it helps me to see them as two separate
entities. If, however, this is actually one router
with two interfaces (and a BGP session to each of the
two customer routers), then please correct me.  I
think the config wouldn't change much anyway.
 
> 
> To obtain this we think to use AS-PATH attribute:
customer announces C1-nets and C2-nets 
> to S0 in the two BGP sessions, but C1-nets with
lower AS-PATH than C2-nets in C1-SO session
> (and C2-nets with lower AS-PATH than C1-nets in
C2-S0 session).
> 

I guess this will work, although I can't guarantee it,
having never tried it in a customer configuration like
this.  I've really only ever seen prepending used in a
kludge situation when you're trying to influence the
choice of a route across several ASes.  For this, I
would just use local-preference instead, that way I
know how it will behave, although it probably wouldn't
matter anyway because the routes will not leave your
AS as such (at least, I hope you're not advertising
private ASes to your peers).

> We announce defaul route from S0 to C1 and C2; then
C1 receives default route via S0 and 
> C2 but prefers S0 (eBGP Vs iBGP), idem C2.
> 
> Configuration:
> 
>         C1: (C2 is almost the same)
> 
>                 router bgp 65xxx
>                         no synchronization
>                         network C1-nets
>                         network C2-nets

don't forget that Cisco makes you spell it "neighbor".
:)

>                         neighbour S0 remote-as 766
>                         neighbour S0 route-map C1-S0
out
>                         neighbour C2 remote-as 65xxx
>                         neighbour C2 next-hop-self
>                         maximum-paths 2
>                         no auto-summary
>                 access-list 1 permit C1-nets
>                 access-list 2 permit C2-nets

According to Cisco, you get better performance if you
use prefix-lists instead of access-lists.  

http://cio.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cbgp.htm#wp7487

Also, I find they are easier to read in a config.

>                 route-map C1-S0 permit 10
>                         match ip address 1
>                 route-map C1-S0 permit 20
>                         match ip address 2
>                         set as-path prepend 65xxx
> 
>         S0:

Or R1/R2:
> 
>                 router bgp 766
>                         no synchronization
>                         neighbour C1 remote-as 65xxx
>                         neighbour C1
default-originate

You probably want to add "neighbor C1 prefix-list NULL
out" here, so you don't overwhelm C1 with a full
routing table (or even a partial one, when they
weren't getting it before):

 neighbor C1 prefix-list NULL out

ip prefix-list NULL description NULL route prefix-list
ip prefix-list NULL seq 5 deny 0.0.0.0/0 le 32

Ditto for C2 below.  

Also you probably want to have a prefix-list in on C1
and C2 neighbors (OK, you definitely want it, because
the rest of the internet community wants you to have
it so you don't accept just any random route from your
customer).  Of course, <C1-nets> should be expanded to
include the entire list of networks announced by C1:

 neighbor C1 prefix-list CUST-IN in
!
ip prefix-list CUST-IN description accept only C1 and
C2 nets
ip prefix-list CUST-IN seq 5 permit <C1-nets>
ip prefix-list CUST-IN seq 10 permit <C2-nets>

Again, the same for C2 below.

>                         neighbour C2 remote-as 65xxx
>                         neighbour C2
default-originate
>                         no auto-summary
> 
> Anyone finds an error in our proposal configuration?
Any unexpected bad-functioning?
> Is needed any BGP distribution over OSPF in the
customer network? defaul-route?

It's hard to tell, because I don't know what's in the
"OSPF cloud".  But, I'm going to take a guess here and
say that you probably need to have iBGP running on
*all* the routers in that "cloud" (in either a full
mesh, or using a route-reflector scheme or
confederations), in order to be able to turn off
synchronization and not have to redistribute BGP into
OSPF.  It shouldn't be too hard, however, to extend
your C1 and C2 iBGP configs to the rest of the routers
to get a full ibgp mesh, especially if you set up peer
groups.

Again, not knowing in more detail what is really there
in your network, it's hard to say with complete
confidence what you should do, but you can check out
some best practices (at least what Cisco
recommends--maybe others have some suggestions for
other BGP BCPs):

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_white_paper09186a008020b51d.shtml#wp1001898

> 
> 
> Best regards and many thanks in advance,
> 
>       Dario Donsion

Good luck,
Barrie