Hi Dev,
It's not so much an "extended RT community" (not specific to the
route target community) but certainly another extended community with
a special purpose defined in RFC2547. My view is that the various
extended communities were defined to be interpreted by the routing
software in a way that isn't traditional, such as the traditional
method of setting a community outbound and matching with a route-map
inbound for filtering.
For the route origin community in IOS, we're configuring the feature
with the "ip vrf sitemap" command rather than using the traditional
route-map in / route-map out community filtering method. The same is
true for the other reserved community types: route target and OSPF
domain-id.
I would say that the original question and suggested answer is
absolutely correct. These communities are not for general use. The
only RFC I know of that specifies the use of the origin community are
those related to 2547 and those that updated this standard. In
production, I would say trying to use SOO for other purposes would be
like using some other reserved community for another purpose (such as
no-export). I would agree with your initial instinct. If we can
think of some good follow-up questions, I'm glad to forward them to
Yakov, since he co-authored the RFC and now works for Juniper. His
take on things is always very interesting and always educational.
On a side note, I have encountered a few large SPs that will not
configure SOO, or route origin, on their PE routers for L3VPN
customers. They suggest the utilization of regular community
filtering (like Bryan suggested) on the CE routers when running BGP as
the PE-CE protocol with back door links. (They expect the CE router
to set and match non-reserved communities such as CE-ASN:XXX instead
of origin:CE-ASN:XXX) Often, these service providers try to fully
manage the CE routers and this configuration would be under their
control anyway. Either way, I've been on some calls where my tier 2
service provider customers wanted SOO configured for L3VPN service
they were buying from a tier 1 service provider. In two cases we were
told that they don't wish to incorporate SOO into their standard PE
configuration and it wasn't open for discussion. It's funny that we
learn this stuff and some features get dropped to simplify
configurations.
HTHs,
Bill - JNCIE-M #119, CCIE# 7258
On Jun 10, 2009, at 11:14 AM, Bryan Bartik wrote:
Seems like it would only be useful for MPLS VPNs, but again it is
just another extended RT community. Have you tried using it on
normal BGP sessions, with a route-map (set on one end, match on the
other)? Before the soo neighbor option, that is how it was set.
On Wed, Jun 10, 2009 at 3:35 AM, Jared Scrivener <[email protected]
> wrote:
To the best of my knowledge the SOO extended community is only used
for MPLS VPNs.
On 6/10/09 4:05 AM, "devang patel" <[email protected]> wrote:
Hi Group,
I just want to make sure that SOO is only MPLS VPN property right?
it will not work for normal IPv4 routing protocols, I mean for SOO
to work interface should be the part of VRF and that prefix should
be advertised in appropriate routing protocol or need to used it
with neighbor command with BGP under IPv4 VRF address family; right?
regards,
Dev
Cheers,
Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
Sr. Technical Instructor - IPexpert, Inc.
URL: http://www.IPexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
Mailto: [email protected]
--
Bryan Bartik
CCIE #23707 (R&S), CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
