Multi-homing with multiple ASNs
mysidia at gmail.com
Mon Nov 24 00:49:29 UTC 2014
On Fri, Nov 21, 2014 at 8:49 AM, Curtis L. Parish
<Curtis.Parish at mtsu.edu> wrote:
> I believe the state will modify their advertisements to add our ASN to the path
> but changes to advertising via the state network has to go through a design
> and change management process and then be scheduled into maintenance
> windows. Any attempts to balance the traffic via prepending will take weeks.
In other words, you are in effect not in control of the advertisement
of your prefix,
therefore you practically don't actually have an autonomous system,
you have the number technically, but not the administrative division
that is intended to exist.
An appropriate amount of time to push out any change needed to an
announcement should be no more than 1 business day, but less than 2
hours in an emergency, to add extra impending or pull an announcement.
I would call a change management process that requires any longer
unacceptable, or not reflecting the reality of the importance of
well-maintained optimal properly functioning network connectivity.
You have what seems to be something very fragile, and you have very
low configuration agility, since you cannot change your announcements
as needed out through the state as you need them to.
A stateful firewall, has no correct place outside the border of a
multihomed network; by definition, to have a stateful firewall, there
must be a single point of failure (on the stateful firewall element)
at least for each unique load-balancing tuple.
So I would call (in this case), the origination of your prefix by
multiple ASes a bad thing.
The protocol allows this, but the other constraints related to the
situation are serious impediments that make the solidity multihoming
seem improper or potentially precarious, in terms of the true
originating AS' ability to function as an AS and manage their network
More information about the NANOG