Based on the fact that we access ORION via one of our ISPs (3rd party, we
don't BGP/directly peer with ORION), I'm not sure if i can use this solution
here. I could do that for the routes learned from that ISP, but we receive
the entire internet routing table from them? I'd have to understand things
more before I went down that road. perhaps I shouldn't be accepting the
full table from them.
>the localpref is something I'll look at, thanks for that. I'm not a BGP
expert by any stretch, and our requirements here are "simple". we are not a
transit. I've only attempted to make the config safe, not efficient.
> i'd like to hear what you have to say about the original question, is
there good reason in this day and age to drop traffic as described in the
original post in your opinion?
It sounds like the target site has a possible misconfiguration if this is a
long term issue. If they're using the open internet to get back to you and not
ORION (when your packets arrived from ORION-based connection), then something
is misconfigured or down. The problem is a conflict in the way BGP works and
how people assume it works BGP is designed to get packets to where they
want to go, not drop them if they're going the wrong way.
The route back to you via ORION might not be available temporarily for a
legitimate reason (outtage, etc), or due to other unintentional side effects
of preference configurations. They are likely not seeing a route to you being
preferred via ORION. Try some traceroutes from your end and from their end and
compare. They're likely different paths. However, that shouldnt be suprising
- or a reason to filter traffic, really.
Symmetric routes across any chunk (big or small) of the internet are a
mythological thing of the past. Don't rely on that being the case at
As for your getting a full table from your upstream, you would likely
expect and want that. Mixed in would be ORION's prefixes, and if things
are working right, you are using an ORION path to get to your target. That's
up to the upstream's config preferences for packets destined to go through
ORION, so if you are the one using the open internet to get to the target
(check your traceroutes), then you need to talk to your upstream and get them
to fix their route preferences or whatever link or peering session is down.
As for dropping traffic, that's a strong fail-fast signal there. If you want
to ensure you are getting the intended bandwidth, say if you needed a 100mbps
path guaranteed that ORION can easily give you but the open internet/your
respective ISPs cant or wont (or you didnt pay for nor want to), then having
it fail immediately instead of using a slow backup path might be what you
want. There's a balance to be struck between failing fast thus generating
sufficient complaints that pressure to fix the best (and only) path that has
the required capacity is done ASAP, but then you are also left with no
alternate connectivity to the target in the meantime. Which scenario you
prefer is up to you and dependant on your organizations' needs.
An alternative is to generate sufficient alarms on the best connection's
failure, fail over to slower alternates, alert users to the degraded quality
(and modify their expectations and behaviour), and have your respective tech
teams respond promptly. This all requires awareness, training and a more
sophisticated failure-handling system. (How do you automatically alert all
users that the alternate degraded path is in use for eg? Email? Pager?) Having
alternate connectivity tends to dilute responce urgency from my experience. A
question of discipline/(dis)incentives.
As for using an outtage as a security measure, yes you will reduce the
opportunities for the open internet to be a source of spoofed packets from
other 'semi-trusted' entities that you expect to only go across ORION for.
However, it sounds like you have no opportunity to determine such packets'
arrivals/departures, as it all goes through your upstream(s). The other end
however seems to have a firewall system that does determine this disparity of
paths. This is a minor security benefit, IMHO, which may be worth it to you,
depending on how important some connectivity is vs the increased risk of
spoofed packets from the general internet during the primary link via ORION's
downtime. And, it seems this is the other org's decision to make, not yours,
since you dont directly control your own ORION peering, and you are getting a
full routing table from your upstream.
If you wanted to control your ORION traffic, you would likely get a second BGP
feed and link from your upstream if you cant connect to ORION directly somehow.
Are you not on TORIX? If so you could connect to ORION directly as we at Heavy