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

Thanks for confirming

Pierre-Alex

On Friday, February 17, 2012, Yuri Bank <yuribank_at_gmail.com> wrote:
> 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 Sat Feb 18 2012 - 00:17:16 ART