From: Hobbs (deadheadblues@gmail.com)
Date: Wed Feb 18 2009 - 13:38:59 ARST
Hehe :)
On Tue, Feb 17, 2009 at 5:51 PM, Ravi Singh <way2ccie@googlemail.com> wrote:
> Damn .. < slaps himself > . I seriously missed that one.
>
> Thanks Hobbs.
>
> Ravi
>
>
> On Wed, Feb 18, 2009 at 12:45 AM, Hobbs <deadheadblues@gmail.com> wrote:
>
>> What's the more preferred attribute?
>>
>>
>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml
>>
>> Step 10 vs 11....
>>
>> On Tue, Feb 17, 2009 at 5:33 PM, Ravi Singh <way2ccie@googlemail.com>wrote:
>>
>>> Hi Group,
>>>
>>> I think I might have to go back to basics here. Suppose R1 in AS-1 is
>>> learning a prefix (2.0.0.0/8) from R2 in AS-2 and R-3 also in AS-2 is
>>> connected to R1 & R2 both as in the diagram below
>>>
>>> R1 <----->R2
>>> \ |
>>> \ |
>>> \ |
>>> \ |
>>> R3
>>>
>>> R1 forms an eBGP peer with R2 & R3 and R2 & R3 form iBGP amongst
>>> themselves. R1 now receives the same prefix(2.0.0.0/8) from R3 as well
>>> and
>>> since everything else is same the comparison is made based on router-id &
>>> R2
>>> having a lower id (2.2.2.2) wins. Now, if on R1, I shut the BGP
>>> relationship
>>> towards R2 the only path will be from R3 as the best path. I turn the BGP
>>> neighbor on again and R1 still shows the path from R3 as the best path
>>> even
>>> though R2 peering is up and R2 has a lower router-id.
>>>
>>> It stays this way untill I hard reset the BGP peering on R1(or R3). Even
>>> a
>>> soft reset serves no good. My question is , is this the expected
>>> behaviour
>>> and if yes why so ? I mean shouldn't the protocol be intelligent enough
>>> to
>>> recalculate its decisions on receiving prefixes with more preferred
>>> attributes.
>>>
>>>
>>> Thanks,
>>> Ravi
>>>
>>>
>>> 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
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:11 ARST