A default route, aka a route of last resort. For BGP, route to the next hope must be explicitly in the routing table. This is one of the pre-reqs for BGP to advertise its own routes as well (unless you have synchronisation turned off).
In my deployments of BPG, we alway suse the loopbak interface for iBGP peers as this is already distributed using our IGP, and then use the interface address of the peering routing for eBGP, with a atatic route to that IP. Good old bgp :). Right now lets spark of some discussion about the security of BGP peering :) Brian Dennis wrote: > > Jim, > The default route as you've seen won't work but this will: > > Rack4R2#conf t > Enter configuration commands, one per line. End with CNTL/Z. > Rack4R2(config)#ip route 0.0.0.0 128.0.0.0 192.168.33.2 > Rack4R2(config)#ip route 128.0.0.0 128.0.0.0 192.168.33.2 > Rack4R2(config)#^Z > Rack4R2#show ip route static > S 0.0.0.0/1 [1/0] via 192.168.33.2 > S 128.0.0.0/1 [1/0] via 192.168.33.2 > Rack4R2# > > It's the next best thing to a default route ;-) > > Brian Dennis, CCIE #2210 (R&S/ISP Dial/Security) > [EMAIL PROTECTED] > http://www.labforge.com > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of > Jim Devane > Sent: Thursday, March 20, 2003 9:28 AM > To: [EMAIL PROTECTED] > Subject: Re: eBGP Multi-hop [7:65823] > > Thanks for the replies so far... > Hmm, Well, actually becuase BGP uses TCP 179 is can traverse > non-BGP > speakers to a router that does speak BGP ( Just like TFTP'ing > to another > router) > I put the config I was testing below. The config works, BGP runs > everyone is > happy when I have a specific route to the opposite side peer's > Loopback > address. > > ip route 172.16.10.1 255.255.255.255 192.168.33.2 > > but if I remove that and install > > ip route 0.0.0.0 0.0.0.0 192.168.33.2 > > then BGP breaks. I don't understand why. There is no IGP. Both > routes > point > to exactly the same place. > > conf t > router bgp 65500 > no synchronization > bgp log-neighbor-changes > network 192.168.47.0 > network 192.168.55.0 > aggregate-address 192.168.0.0 255.255.0.0 > neighbor 172.16.10.1 remote-as 65555 > neighbor 172.16.10.1 ebgp-multihop5 > neighbor 172.16.10.1 update-source Loopback0 > neighbor 172.16.10.1 version 4 > neighbor 172.16.10.1 soft-reconfiguration inbound > neighbor 172.16.10.1 password 7 140705191C117B3821 > neighbor 172.16.10.1 filter-list 3 in > neighbor 172.16.10.1 filter-list 4 out > > > ----- Original Message ----- > From: "Carroll Kong" > To: > Sent: Thursday, March 20, 2003 6:54 AM > Subject: Re: eBGP Multi-hop [7:65823] > > > > I guess I am kind of just going to a quick stab. Do you have > "no > > synchronization" under the BGP configuration? > > > > > hello all, > > > > > > (Re-post...not sure if original msg made it our not) > > > > > > playing around again and have a question. eBGP multi-hop > cannot come > up > if > > > the peer is known through a default route. > > > Is there a reason why? > > > I mean, what is the point of a static route that causes a > recursive > lookup > > > or a static route that simply points to the same next hop > as a > default > > route? > > > For that matter, I can't see it being a matter of proximity > either. > If > > > convergence time were not an issue, what is really wrong > with having > a > 10 > > > hop or even 50 hop BGP session? (I know it is unlikely and > there are > > > cetainly better ways to handle it (GRE or IPSec tunnel)) > but for the > sake > > of > > > argument... > > > > > > Just curious, not able to find much on WHY it is like > this... > > > > > > thanks, > > > Jim > > -Carroll Kong > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65913&t=65823 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
