[c-nsp] BGP into OSPF

[Dario]

Thanks a lot for your answer Barry,

> > 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:
> > 

sorry, is the same router with two interfaces:

		       S0
                    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. 

it's one router (S0) and two interfaces (R1 and R2).


> > 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). 

I think we can use AS prepends as well as Local Preference; we're
not advertising private AS's to our 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".
> :)

jajajaja, you're sure, problems with my english ;)


> >                         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.

Ok, I'll check it.


> >                 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

Sure, more clear :)

 
> 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.  

My idea is to only pass C1 and C2 a default route
(default-originate), not full or partial routing.


> 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:

This is our idea, expand entire list for C1 and C2.


> > 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. 

But, if we only distribute default route from BGP to
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.

We're looking for the best solution taken into account 
minimal changes in the customer network.

We need to separate routes due multicast traffic, they 
need symmetrical paths to work fine.


> 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):

I hope it :)


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

I'll check this link.


Many thanks Barrie