Karl O. Pinc wrote:
If you can't justify that, then get a /24 of PA space from a provider
that *will* allow you to reannounce that /24 via an additional
transit and *will* provide you with an LOA that you can provide to
that additional transit operator.
I may have to go that way if nothing better is available.
It's not the end of the world. I've been in that position several times
(years ago) and been pleased with the result, at least technically
speaking. The problem is finding an ISP that will do that. Look to small
ISPs that really want your money, and don't expect to get it if you're
only buying a T1/E1 ...
The number of networks that filter prefixes smaller than /22 don't
appear to be that numerous IMHO, but if they do, your /24 will still
be reachable as they'll see the larger /19 or whatever from your
provider that it's carved out of.
But not from the 2nd provider, which defeats the purpose:
having a reliable Internet connection no matter what.
I disagree.
"Having a reliable Internet connection no matter what" fails (in my
experience) much more frequently for other reasons than not being able
to reach the small portions of the world that filter "le 22" ... like
power failure, split-brain load balancers, human error, etc.
On one of my routers (pulling down a full table), I see
284266 IPv4 routes
but after reconfiguring that router to only accept prefixes equal to or
larger a /23 and then reloading it I see
$ bgpctl sho ip bgp inet | wc -l
134167
Draw whatever conclusions you wish.
Hmm, let's see if we can see the DNS root servers from this router if we
leave it filtering "le 23" ...
$ host g.root-servers.net
g.root-servers.net has address 192.112.36.4
g.root-servers.net mail is handled by 10 nic.mil.
$ bgpctl sho ip bgp 192.112.36.4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
$ sudo vi /etc/bgpd.conf ### REVERT BACK TO PREVIOUS "le 24"
config ...
$ sudo bgpctl reload
reload request sent.
request processed
$ bgpctl sho ip bgp 192.112.36.4
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
*> 192.112.36.0/24 64.62.180.89 100 0 6939 4323 27066
5927 5927 i
That should be enough of an answer, I think. YMMV.
IP resources are scarce and people are
wasteful and greedy.
Yes.
Most offices don't need BGP multihoming, or any sort of inbound
multihoming at all-- just outbound which is easily done without the
assistance of the ISPs themselves or ARIN by using NAT and
upstream-failover features commonly found in most routers.
In this case the requirement is to have Internet service that
reaches everywhere, all the time. Upstream failover features
involving pinging the link endpoint and such won't cut it.
Then use a better test than just pinging the link endpoint.
If somebody removes one of the lower floors of the building
that will cut the risers and we'll be out of Internet; but
then we'll have other problems anyway.
True.
Any other sort of
outage, it does not matter if the problem's in a router
half way around the world, and it's my head on the block.
That's the world of I.T.
You can spend tons of money [and time] chasing after potential problems
that could occur on the other side of the world, and trying to add more
theoretical "9's" to your availability, but in my experience keeping
clueful people around and solving the most common failure modes first
and adding decent monitoring/logging tools pays off much better.
Even the "problem on the other side of the world" issues tend to be
relatively easy to work around:
a) Tier 1 de-peering. solution, don't buy transit from a single tier-1
operator, or from a tier-1 operator at all.
b) weird BGP bugs, like the confederation-in-AS4 bug that spread from
some small ISP in the Ukraine and affected a bunch of machines around
the world. solution, have a fall-back default route on at least one of
your BGP speakers and/or have at least one BGP speaker be a router that
uses a completely-different BGP stack and hope that one bug won't affect
every implementation.
Regardless, you'll probably be bitten much more often by common problems
before you see these sorts of issues being the limiting factors in your
environments overall availability. Especially since it doesn't sound
like you're a datacenter.
(We've tried other physical links, radio and such, with no luck.)
BGP seems the appropriate technology to use in this
circumstance. The question becomes how to best deploy it.
The 2 router/2 bgpd hack seemed to me to fall within BGPs
design parameters,
The devil's in the details. What you propose doesn't appear very exotic
at all. I've operated/installed similar topologies a number of times
before and been pleased with the results.
in that it does not seem to be something
that will simply stop working one day. But that's what
it seems to me; you folks know a lot more and have a lot
more experience than I do which is why I'm writing and
listening. Is the two router approach really a bodge or
a legitimate hack?
This should work fine if configured sanely. If your head is really on a
chopping block, it might be wise to either undertake massive testing of
your configurations and/or contract an engineer to set up your routers
initially and then turn over maintenance to you.
Cheers,
-Tico
Thanks for the help.
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
