Re: BGP next-hop

From: Shane <shane_at_shanekillian.net>
Date: Thu, 26 Jul 2012 21:12:43 +0100

For what its worth, just happened to be lambing this when the mail came in.
The answer is no, you must use the next-hop-self command

Rack1R4(config-router)#neighbor 155.1.0.1 next-hop-self

Without next hop self -

Rack1R1#show ip bgp 112.0.0.0 255.0.0.0
BGP routing table entry for 112.0.0.0/8, version 24
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  54 50 60
    54.1.1.254 (metric 2195456) from 155.1.146.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal
  54 50 60
    204.12.1.254 (metric 307200) from 155.1.0.4 (150.1.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack1R1#
Rack1R1#
Rack1R1#
Rack1R1#show ip route 112.0.0.0
Routing entry for 112.0.0.0/8
  Known via "bgp 100", distance 200, metric 0
  Tag 54, type internal
  Last update from 204.12.1.254 00:03:42 ago
  Routing Descriptor Blocks:
  * 204.12.1.254, from 155.1.0.4, 00:03:42 ago
      Route metric is 0, traffic share count is 1
      AS Hops 3
      Route tag 54
      MPLS label: none
Rack1R1#
Rack1R1#
Rack1R1#
#### Recursion to get to next hop advertised ####
Rack1R1#show ip route 204.12.1.254
Routing entry for 204.12.1.0/24
  Known via "eigrp 100", distance 90, metric 307200, type internal
  Redistributing via eigrp 100
  Last update from 155.1.146.4 on Ethernet0/0, 00:04:49 ago
  Routing Descriptor Blocks:
  * 155.1.146.4, from 155.1.146.4, 00:04:49 ago, via Ethernet0/0
      Route metric is 307200, traffic share count is 1
      Total delay is 2000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
Rack1R1#

With Next hop self -

Rack1R1#show ip bgp 112.0.0.0 255.0.0.0
BGP routing table entry for 112.0.0.0/8, version 32
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  54 50 60
    54.1.1.254 (metric 2195456) from 155.1.146.6 (150.1.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal
  54 50 60
    155.1.0.4 from 155.1.0.4 (150.1.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack1R1#

Rack1R1#show ip route 112.0.0.0
Routing entry for 112.0.0.0/8
  Known via "bgp 100", distance 200, metric 0
  Tag 54, type internal
  Last update from 155.1.0.4 00:00:32 ago
  Routing Descriptor Blocks:
  * 155.1.0.4, from 155.1.0.4, 00:00:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 3
      Route tag 54
      MPLS label: none
Rack1R1#

On 26 Jul 2012, at 19:24, Ray wrote:

> When using iBGP, it is assumed that there will be an underlying IGP to
> control/forward advetsisments. iBGP has AD of 200 and will typically lose
> out ot other routing protocols by design. It was set up this way as a loop
> prevention mechanisim. Like stated above, a route learned from outside the
> Internetwork is assumed to be valid best. This is not the case when the
> same route is learned internal to the AS.
>
>
>
> So the above is default behavior. We can peer iBGP neighbors with the
> 'next-hop' self command or use a route-map attached to the neighborship
> that changes next hop. It depends on what is trying to be accomplished.
>
>
> /ray
>
>
> On Thu, Jul 26, 2012 at 5:10 PM, <mohd-mousa_at_hotmail.com> wrote:
>
>> Hi All,
>>
>> There is question for bgp next-hop, can we learn the next-hop through the
>> bgp
>> itself not through IGP ?
>>
>> Could anyone provide me with example why we can't do this, I tried to find
>> example but no luck !
>>
>>
>> Thanks Alot,
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Jul 26 2012 - 21:12:43 ART

This archive was generated by hypermail 2.2.0 : Wed Aug 01 2012 - 15:55:23 ART