Re: EIGRP backdoor link on MPLS VPN and multiple SoO values

You're absolutely correct. With the cost community feature, SoO is
redundant for EIGRP.
On Feb 15, 2012 10:48 PM, "Pierre-Alex Guanel" <paguanel_at_gmail.com> wrote:

> Sorry, did not hit REPLY ALL so resending - with the typo correction.
> _________
>
> Hi Yuri,
>>
>> Thank you for the hints. I spent quite a bit of time labing based on your
>> input.
>>
>> Indeed, the SoO attribute is propagated in the EIGRP packets as you
>> mentioned. Also, as indicated, a CE can filter EIGRP updates based on the
>> SoO information.
>>
>> A question remains however as to the usefulness of SoO filtering. Here is
>> why:
>>
>>
>> - 1. I added a switch to CE1 and advertised a loopback in EIGRP.
>>
>> - 2. When SoO is configured on CE1 on the backdoor interface, the update
>> sent by CE2 is NOT recorded in the the EIGRP topology ( as expected)
>>
>> - 3. When SoO is NOT configured on CE1 on the backdoor interface, the
>> update sent by CE2 is recorded in the EIGRP topology database ( as
>> expected)
>>
>> - 4. In either case, CE1 never advertises any update back to PE1 because
>> the CE2 is not a feasible successor (basic EIGRP rules)
>>
>> - 5. I tried many things over the past two days (playing with offsets,
>> delays and variance throughout the topology) to make CE2 a feasible
>> successor but I never was able to make this happen.
>>
>> Finally I reasoned myself that if it was mathematically possible to
>> adjust the metrics so that CE2 was indeed a feasible successor, then this
>> could lead to a massive routing loop.
>>
>> Thus my doubt as to the usefulness of this feature:
>>
>> If there can't never be a routing loop in a back door topology (because
>> of the feasibility condition), what really is the point of the EIGRP SoO
>> filtering mechanism?
>>
>> Is it just some kind of paranoid filtering ..or am I mistaken in
>> thinking that CE2 cannot be made a feasible successor ????
>>
>> Thank you
>>
>
>
> On Tue, Feb 14, 2012 at 4:47 AM, Yuri Bank <yuribank_at_gmail.com> wrote:
>
>> The CE can inspect the EIGRP updates coming from the backdoor link. You
>> configure a sitemap to do this. The CE does not have to be running BGP!
>>
>> Check your packet capture again. Wireshark will not recognize the SoO
>> attribute included in the EIGRP packet. Look for "Type Unknown 0x0104" The
>> last 6 bytes of this field is the SoO! So just convert the HEX to Decimal
>> :-)
>>
>> Cheers
>>
>> -Yuri
>>
>> On Mon, Feb 13, 2012 at 5:10 AM, Pierre-Alex Guanel <paguanel_at_gmail.com>wrote:
>>
>>> According to paragraph 2) on page 2545 of INE CCIE R&S Lab Workbook
>>> Volume
>>> 1 (CCIEv4.0), when configuring PE routers of a multi-homed sites with
>>> different SoO values, an additional SoO interface should be configured on
>>> the CE routers with the backdoor links " to prevent routing loops.
>>>
>>> Diagram:
>>>
>>>
>>> PE1 -------------P--------P------------------PE2
>>> | |
>>> | |
>>> SoO=100:1 SoO=100:2
>>> | |
>>> | |
>>> CE1--SoO=100:1----------SoO=100:2-CE2
>>>
>>>
>>>
>>> Questions:
>>>
>>> How can a CE (acting as a backdoor) filter updates based on the site of
>>> origin since the CE is not running
>>> MBGP ?
>>>
>>> I have taken a network capture of traffic on the backdoor link, I do not
>>> see any extension in EIGRP carrying the SoO attribute ...
>>>
>>> Any input welcome.
>>>
>>> Thanks
>>>
>>> Pierre-Alex
>>>
>>>
>>> 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 Feb 16 2012 - 18:24:09 ART