In a message written on Fri, Sep 30, 2011 at 10:51:58AM -0400, Christopher
Morrow wrote:
> the troubleshooting though with something like unique origin is
> 'simpler' for them: "Oh, as27 is NYC, as37 is WDC... why is Newark
> seeing WDC as the best path?"
I'm not sure I get it.
Unique origin ASN output (simplified)
10.1.2.3/32
65000
65001
* 65002 (Best)
65003 65001
So we know it's coming from site 65002.
Using the F-Root model, with an origin of 65999 for the Anycast routes:
10.1.2.3/32
65000 65999
65001 65999
* 65002 65999 (Best)
65003 65001 65999
We still know it's coming from site 65002 by just looking. I have a
hard time calling one "simpler" than the other, indeed I would call them
pretty darn equal.
But here's the difference, let's say I have 20 Anycasted routes for
different services, but I originate them all from 65999, I can see the
status of all 20 with:
show bgp ipv4 uni regexp _65999$
I'll get 20 lines, showing me how each virtual is routed.
With a unique origin ASN configuration, to get the same info for 20
routes I would need 20 lines like:
show bgp ipv4 uni 10.1.2.3/32
show bgp ipv4 uni 10.1.2.4/32
show bgp ipv4 uni 10.2.2.1/32
And so on, or have the discipline to keep them all in one netblock so:
show bgp ipv4 uni 10.1.2.3/24 longer-prefixes
produces useful output.
Thus I think I can make a good argument that having a consistent
origin ASN makes troubleshooting easier when you have multiple
Anycast routes, because you can select the entire set of routes by
origin ASN.
--
Leo Bicknell; E-mail: bickn...@isc.org, Phone: +1 650 423 1358
INOC*DBA *3357*592; Internet Systems Consortium, Inc. www.isc.org
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
