Re: BGP next-hop

Damn autocorrect :-)

On 26 Jul 2012, at 21:12, Shane wrote:

> 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:14:28 ART