[c-nsp] eBGP peering traversing non-BGP routers

[Robert Blayzor]

Huizinga, Rene wrote:
> To make a long story short, the lab-answer for this with the limited info
> given would be either a tunnel or C1/C2/D1 in IBGP. Redistribution into OSPF
> is possible, but I'm probably thinking too practical again now to even
> consider that as an option, assuming that the BGP-table would be too big to
> end up with a manageable OSPF-setup :) When more info's known you may
> quickly wander in the direction of a default/summary-route mix.


I'm not really overly concerned about D1 & D2 and how they get their
routes, etc.  D1 & D2 would be a customer setup, and if they have to run
IBGP or do a lot of interior routing protocol fudge to get their stuff
to do what they want, so be it.

I'm thinking I could just include C1 and C2 in IBGP with route
filter-lists to eliminate all of the upstream routes from AS100 and
AS200 and just keep the routes exchanged from the local AS and say AS400
(or other peers).

If D2 (AS400) needs to see a full routing table, I could still have them
 do a multi-hop session from B1 or B2, if not, they could probably just
peer with C2.  At least then I'd have the routes being learned
internally by BGP route distribution and the routes announced from D2
would make their way home.   Of course IBGP is the easy answer....

Normally we just have our border/edge routers in IBGP while the network
core uses OSPF for everything internal.  Seems pretty common, but just
the way this one customer has to connect, my only option at this point
is a non-BGP router. (bummer)

-- 
Robert Blayzor, BOFH
INOC, LLC
rblayzor\@(inoc.net|gmail.com)
PGP: 0x66F90BFC @ http://pgp.mit.edu
Key fingerprint = 6296 F715 038B 44C1 2720  292A 8580 500E 66F9 0BFC

telnet: Unable to connect to remote host: Connection refused