[c-nsp] BGP Tunnel or other alternative

Brian Feeny signal at shreve.net
Mon Nov 1 21:35:11 EST 2004


I am going to be getting eBGP up between two routers that are not 
directly connected.  I wanted to run
this by the list to see if anyone can give some suggestions about 
possibilities I should consider
for accomplishing this goal.  R1 is in AS A and R2 is in AS B.  The 
diagram looks like this:

R1<-ether->Cat3550<-ether->Cat6500-1<-ATM->Cat6500-2<-ether->R2
=======AS A===================---------------==========AS B====

eBGP multihop will not directly work, since the Cat6500's in the middle 
are not
BGP speakers and will not know about all routes for which R1 and R2 are 
trying
to reach.  Single statics on the 6500's, redistributed into IGP's will 
allow R1 and R2
to establish BGP sessions, but the routes themselves will not have 
reachability.

1. The Cat6500's do not run BGP.  I have heard from others that 6500's 
can't
handle BGP well, and so have avoided it.  If someone has something to 
say
contrary to this, please let me know (perhaps an IOS version) so I can 
look into this
as running BGP on the 6500's is a solution.

2.  GRE Tunnel is an option, but that would probably lead to MTU 
problems.  The ether
interface off R1 goes to a switch so any change to the MTU on that 
interface would
require change to other members of the switch/segment........I don't 
want to have to change
MTU if I can avoid it.

3. PBR on the 6500's is an option but I am not sure if that is a clean 
solution for the above.
I could say any traffic sourced over this PVC, send to the neighboring 
6500.  The 6500's
each know about all routes within there own respective AS's (via IGP's) 
and and so once
you get to the next 6500 your home free.  I have never looked to PBR 
other than temporary
bandaid fixes, and not sure I like to think of it as a solution.

4. Terminating the ATM link directly on R1/R2 is a problem because we 
are pressed for
real estate on those routers.  Buying additional routers is of course 
an option, but you know
we are first looking to solve these types of things technically.


Thanks for any suggestions,

Brian

---------------------------------------------
Brian Feeny, CCIE #8036, CISSP
Network Engineer
ShreveNet Inc.



More information about the cisco-nsp mailing list