[c-nsp] SoO causing 1-member update groups
bill fumerola
billf at mu.org
Tue Dec 16 16:37:46 EST 2008
i don't run any MPLS or anything like that, so i decided to steal the
SoO ext community for use as a generic "which colo was this route
originated from/learned in" community. the fact that it pretty printed
it on one line in the CLI had something to do with it.
anyways, after adding it on one of my routers, a previously 20 member
update group became 20 independent update groups all w/ the same SoO
community set. and that's my question: why would all of these become
independent update groups? is it because the loop protection changes the
outbound logic such that messages can't be replicated?
also, some of these displayed in the update-groups as:
Site-of-Origin is 0x0:0:0 (2 different update groups)
Site-of-Origin is 0xEF43:8653:1627824172 (5 different update groups)
Site-of-Origin is 0xD0D:3341:218959117 (4 different update groups)
when the only thing that was set was:
Site-of-Origin is SoO:36692:2
why does adding an external community to a route (via a route-map)
impact the neighbor itself? i realize in later versions of IOS this
command was added to the per-{neighbor,peer-group,peer-policy} stanzas.
i guess that's what i get for trying to steal a special-use community
for my own usage. i just didn't expect the update group madness (they
were all set to the same SoO) or the corruption.
i'm just curious about all of this, it didn't have any operational impact.
-- bill
p.s. just for kicks, i ran 'clear ip bgp update-group', which according to
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpdpg.html
"Clears BGP update membership and recalculates BGP update-groups."
but it actually reset all the neighbors themselves. yay docs.
More information about the cisco-nsp
mailing list