To: Peter, Ahmed and Groupstudy
First, thanks to everyone for their help.
Second, here is what I learned...
The problem was a configuration error on my part but not with BGP. As Peter stated, a
router
will not install a route where it cannot find the route for the next hop. So, with my
example
in my original email, we should not have seen the 33.33.33.0 route because there was
not a
route for the next hop which was 192.1.1.1.
The problem was I looked for a route for the 192.1.1.0 network in my tables and I
overlooked
the default route that was configured in a previous lab. While I did not have a
specific
route for the 192.1.1.0 network, I did have a less specific route (ie 0.0.0.0)
configured.
Once I removed the default route, the 33.33.33.0 route was no longer in my routing
table.
Again, thanks to everyone for your input...
Scott Chapin
> Couple comments inserted below
>
> *********** REPLY SEPARATOR ***********
>
> On 2/20/2001 at 11:55 AM Ahmed Aden wrote:
>
> >Scott,
> >
> >I think the problem is with you putting 'no synchronization' in
> >router1. I would also say that if you did a ping to 33.33.33.1 from
> >router2 it would work because the 192 net is reachable from router2. When
> >you issue a 'no synchronization' you are saying that if this route is
> >being announced to me via an IBGP peer, I will install it into the
> >routing
> >table regardless. Keep in mind it will go into the routing
> >table without any
> >knowledge of whether the next-hop address is reachable.
>
> This last sentence is actually not true. A BGP router will never install a prefix
>into the routing table that it cannot resolve a route to the next_hop for. There is
>no way to turn this feature off as doing so would very likely create huge black holes.
>
> >From RFC 1771
> "If the NEXT_HOP attribute of a BGP route depicts an address to which
> the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
> route SHOULD be excluded from the Phase 2 decision function."
>
> Note: Phase two involves route selection and routes that do not meet phase two
>criteria are dropped.
>
> Synchronization in my opinion seems often misunderstood. Essentially, this feature
>is relevant when a transit AS (one that passes traffic for which it is neither the
>source nor destination) chooses not to use a full iBGP mesh. Hence, if routers
>a,b,c, and d were connected in series, consider that only A and D are IBGP peers and
>are providing transit between multiple ISPs. For this to work, an IGP would have to
>have full prefix awareness, or said another way, the IGP table and the BGP tables
>would need to contain the same routes. Hence, it could be said that the tables would
>need to be synchronized. For protection, the BGP routers will not advertise a prefix
>outbound via EBGP to other AS's until their internal IGP table has the prefix
>installed. This means that likely the other IGP routers in the domain also have the
>prefix and thus traffic will not be black holed.
>
> In practise, no one does this! Redistributing 100k routes into an IGP is not a good
>thing :) All transit provides fully mesh with IBGP (with the exception of traffic
>engineered cores over MPLS) Synchronization is thus always turned off. In fact,
>Juniper does not even offer a synchronization nob.
>
> You would need an
> >IGP or static routes to ensure that all next-hop
> >addresses are reachable from all IBGP peers. It's your responsibility to
> >verify that a next-hop route exists for every bgp route.
>
> In practise, the next_hop self method, or adding the external links as passive
>OSPF/IS-IS interfaces are the common methods for this procedure. Statics simply
>involve too much work.
>
> >
> >> This is my confusion: I was under the impression that routes do not
> >> get installed into routing tables if there is no route for the next-hop
> >> address. Specifically, since R1 does not know how to get to
> >> 192.1.1.1, the 33.33.33.0 route should not get installed.
> >
> >You have described the normal behavior, but you have also overridden this
> >behavior with 'no synchronization'.
>
> Again, this is not the case. As far as the problem goes, lets see the full routing
>table on R2 and R1 along with the BGP summaries.. This would help. Somehow, R1 is
>finding a route to 192.1.1.1.
>
> -pete
>
> >hope this helps,
> >
> >
> >On Tue, 20 Feb 2001, scott wrote:
> >
> >> Hello all - I may have been working on this too long. Take a look
> >> at the following network.
> >>
> >> AS100 iBGP AS100
> >> 22.22.22.0 11.11.11.0
> >> R2-173.4.175.19------173.4.175.17-R1 <synchronization turned
> >>
> >>
> >> 192.1.1.2
> >> off on R1 and R2
> >> |
> >> |
> >> | eBGP
> >> |
> >> |
> >> |
> >> 192.1.1.1
> >> R3
> >> AS300
> >> |
> >> 33.33.33.0
> >>
>
> _________________________________
> FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
