You'll probably find enough details here: http://wiki.nil.com/Multihomed_MPLS_VPN_sites_running_EIGRP
If that's not the case, let me know and I'll fix the article. Ivan http://www.ioshints.info/about http://blog.ioshints.info/ > -----Original Message----- > From: Derick Winkworth [mailto:[email protected]] > Sent: Sunday, July 12, 2009 9:38 PM > To: [email protected] > Subject: [c-nsp] EIGRP SoO question > > I'm trying to wrap my head around how this works. > > There is BGP SOO. This is where routes are tagged as they > are redistributed into BGP so that other PEs attached to the > same customer site do not push the routes back into the site. > This accounts for the PE -> CE direction. > > In the opposite direction, it seems there are actually two > different mechanisms. > > There is > > a) EIGRP SOO. This is an EIGRP extension/tag that the PE > uses so it does not re-introduce a route back into the PE > iBGP cloud. Routes are tagged going into a site, and if the > site is dual-homed and the route comes back to another PE > that is appropriately configured, this other PE will see the > tag and not re-advertise that route back into BGP. > > b) BGP cost community. This attribute carries the EIGRP > metric of the route that is being redistributed into BGP. At > another PE (presumable a PE attached to a multihomed site), > this attribute tells BGP to compare the EIGRP cost embedded > in the attribute directly to an EIGRP route learned from the > CE. This attribute is compared before any other BGP attribute. > > > So I guess why do we need both (a) and (b)? > > The documentation for this is shoddy. > > Derick Winkworth > CCIE #15672 > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
