From: Jongsoo.Kim@Intelsat.com
Date: Wed Sep 15 2004 - 12:43:52 GMT-3
James
BGP protocol will choose which next hop to use for a BGP route.
But still it is IGP's decision which interface to use to reach the next hop.
Nexthop 10.90.90.1 for 2.2.2.0/29 is selected on R6 by iBGP process learned
from R1.
However, which interface R6 to use to reach 10.90.90.1 is based on IGP
process ( OSPF in this case).
So R6 will forward any packet of 2.2.2.0/29 to R4 via F/R interface.
In the same way, R4 learned 2.2.2.0/29 from two eBGP connections from R1 and
R6.
But it chooses R6's peer address as nexthop as you said higher IP address
(unless bgp loadbalance is enable.)
To determine which interface to use to reach 10.6.6.6, R4 will check IGP and
forward to F/R interface going to R6.
If you make bgp nexthop unchanged on R1 so that R4 choose 10.90.90.1 as
nexthop for 2.2.2.0/29, then still R4 will rely on IGP to select the proper
interface to forward.
Most likely, this kind of issue won't happen in real Lab test.
Regards
JK
-----Original Message-----
From: James [mailto:james@towardex.com]
Sent: Wednesday, 15 September, 2004 11:18 AM
To: Kim, Jongsoo
Cc: ziutek@mac.com; ccielab@groupstudy.com
Subject: Re: BGP reachability issues Lab 2 Cisco Press
Hi Jongsoo,
On Wed, Sep 15, 2004 at 10:17:58AM -0400, Jongsoo.Kim@Intelsat.com wrote:
> James
>
>
> As I didn't do any routing protocol in this lab, I am not sure why R6
> chooses R4 for next hop 10.90.90.1.
Because 10.90 is greator than 10.6? :)
> In my quick glance, OSPF topology among R1,R4, and R6 seems like the
source
> of this routing loop.
No.. It is BGP routing loop. IGP is fine, as long as you have it configured
correctly in the OSPF, et al sections prior.
HTH,
-J
> R1 and R6 don't have direct connection but it is connected via R4.
> So if 10.90.90.0/28 network is redistributed from EIGRP 30 to OSPF, R6
will
> learn it from R4, which is reason why R6 chooses R4 for 10.90.90.1.
>
> I agree with your work-around solution.
>
>
> JK
>
>
>
> -----Original Message-----
> From: James [mailto:james@towardex.com]
> Sent: Wednesday, 15 September, 2004 12:41 AM
> To: Joseph Rothstein
> Cc: ccielab@groupstudy.com
> Subject: Re: BGP reachability issues Lab 2 Cisco Press
>
>
> On Wed, Sep 15, 2004 at 05:19:03AM +0200, Joseph Rothstein wrote:
> > Greetings to all.
> >
> > Has anyone else had reachability issues with the BGP part of Lab 2 int
eh
> new Cisco Press book? I ahve a strange situation on R4 which prevents
> pinging the loopback 2.2.2.2 on R2:
>
> The problem is because R4 thinks to get to 2.2.2.0/29, R6 is the best
path.
> Now unfortunately, R6 obviously says R4 is the path, aka routing loop.
> Reading forward..
>
> >
> > R4#sipb
> > BGP table version is 5, local router ID is 10.4.4.4
> > Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
> > r RIB-failure, S Stale
> > Origin codes: i - IGP, e - EGP, ? - incomplete
> >
> > Network Next Hop Metric LocPrf Weight Path
> > *> 2.2.2.0/29 10.6.6.6 0 61555 62555
i
> > * 10.1.1.1 0 61555 62555
i
> > *> 4.4.4.0/24 0.0.0.0 0 32768 i
> > *> 5.5.5.0/27 10.6.6.6 0 61555 64555
i
> > * 10.1.1.1 0 61555 64555
i
> > *> 8.8.8.0/28 10.6.6.6 0 61555 63555
i
> > * 10.1.1.1 0 61555 63555
i
> >
> > This basically causes packets to bounce back and forth between R6 and R4
> since R6's BGP table uses 10.90.90.1 as it's next hop for 2.2.2.2, which
> goes through R4. So once the packet gets to R4 on its way to 10.90.90.1,
it
> just goes right back to R6.
> >
> > This seems like a pretty big problem, although the text does not state
> that IP addresses under BGP have to be reachable.
>
> Yep. Unfortunately, the labs 1 thru 3 are deliberately made to be very
> vague,
> assuming the student to understand the gotcha's. Since anything is a fair
> game
> in the real lab, vauge questions like these could potentially show up in
> real
> lab too I think... But anyway..
>
> In terms of fixing your problem here. The reason why R4 prefers R6 is
> because
> the nexthop address in the prefix arriving from R6 is higher.
>
> So in order to get around this, on the R1 router: go to bgp routing
> configuration area, then go to neighbor statement for peering with R4.
> Then type 'next-hop-unchanged' on peering configuration to R4.
>
> This will make R1 to pass nexthop to R4 unchanged, sending the prefix with
> 10.90.90.1 as the nexthop, which is higher than 10.6.6.6 delieverd from
> R6. So R4 now prefers R1 as its best path, eliminating the routing loop.
>
> Of course, as obvious as it may sound, if your IGP is broken and
10.90.90.x
> is not in your IGP table, then recursive route failure will occur and you
> may see RIB-failure error or otherwise BGP route not being installed due
> to martian next-hop.
>
> HTH,
> -J
>
>
> --
> James Jun TowardEX
Technologies,
> Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com , noc:
> www.twdx.net
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ############################################################
>
> Building on 40 Years of Leadership - As a global communications leader
with 40 years of experience, Intelsat helps service providers,
> broadcasters, corporations and governments deliver information and
entertainment anywhere in the world, instantly, securely and reliably.
>
> ############################################################
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and
> destroy all copies of the original message. Any views
> expressed in this message are those of the individual
> sender, except where the sender specifically states them
> to be the views of Intelsat, Ltd. and its subsidiaries.
> ############################################################
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net############################################################
Building on 40 Years of Leadership - As a global communications leader with 40 years of experience, Intelsat helps service providers, broadcasters, corporations and governments deliver information and entertainment anywhere in the world, instantly, securely and reliably.
############################################################ This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Intelsat, Ltd. and its subsidiaries. ############################################################
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:44 GMT-3