On 16/Feb/20 20:47, Baldur Norddahl wrote:
>
> This is for volumen however. Almost everything breaks if we loose the
> transits. It is not like you are 80% ok.
And this is an important point, as even if many of your on-net caches
would origin via a peering session with its owner, some origins
On 16/Feb/20 18:08, Baldur Norddahl wrote:
>
> From the perspective of someone just starting out being dual homed,
> this will be very different. You are not going to get 7 transits and
> you are not going to be able to peer 85% of the traffic. That is why I
> advocate that it is better to buy
ting-solutions>
>>> <https://twitter.com/ICSIL>
>>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>>> <https://www.facebook.com/mdwestix>
>>> <https://www.linkedin.com/company/midwest-internet-exchange>
>>> <https://twit
st-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswis
ttps://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> ----------
> *From: *"Baldur Norddahl"
> *To: *nanog@nanog.org
> *Sent: *Sunday, February 16, 2020 10:08:12 AM
> *Subject: *Re: Dual Homed BGP
>
>
>
> On Sun, Feb 16, 2020 at 12:45 PM Mar
:49 PM
To: Job Snijders
Cc: NANOG
Subject: Re: Dual Homed BGP
Dear Job and NANOG,
Just wondering, wouldn't any of you guys consider using full tables in this
case, for the ability to detect and avoid prefix hijacks (using RPKI/ROV or
other means)?
Of course, I'm focused on security
From: "Baldur Norddahl"
To: nanog@nanog.org
Sent: Sunday, February 16, 2020 10:08:12 AM
Subject: Re: Dual Homed BGP
On Sun, Feb 16, 2020 at 12:45 PM Mark Tinka < mark.ti...@seacom.mu > wrote:
On 25/Jan/20 02:49, Baldur Norddahl wrote:
>
>
>
> T
On Sun, Feb 16, 2020 at 12:45 PM Mark Tinka wrote:
>
>
> On 25/Jan/20 02:49, Baldur Norddahl wrote:
>
> >
> >
> >
> > The solution is to stay clear of tier 1 networks. Find a good local
> > tier 3. Whatever you are going to do, they will do better.
>
> So all our transit comes from the top 7
On 16/Feb/20 16:51, Saku Ytti wrote:
> I'd really like to hear more datapoints from different eyeballs on this, like
>
> 60% local caches, of remaining traffic, 70% peered
>
> so transit = 0.4*0.3 = 12%
>
> I think this might be reasonable, but perhaps it's even less transit
> for eyeballs
On Sun, 16 Feb 2020 at 14:02, Mark Tinka wrote:
> But that only accounts for about 15% of our overall traffic. The rest
> comes from peering.
I'd really like to hear more datapoints from different eyeballs on this, like
60% local caches, of remaining traffic, 70% peered
so transit = 0.4*0.3 =
On 25/Jan/20 02:49, Baldur Norddahl wrote:
>
>
>
> The solution is to stay clear of tier 1 networks. Find a good local
> tier 3. Whatever you are going to do, they will do better.
So all our transit comes from the top 7 "global" carriers. Yes,
including Cogent :-).
But that only accounts for
Dear Job and NANOG,
Just wondering, wouldn't any of you guys consider using full tables in this
case, for the ability to detect and avoid prefix hijacks (using RPKI/ROV
or other means)?
Of course, I'm focused on security, and I know this is often not a high
priority for a real network manager
Interesting discussion.
Besides the point about control which many people have made, I would like
to point - it also depends on your geography and peering in that geography.
Cannot generalise but typically in the US and Europe you will find
reasonably good peering across larger operators and
I’m listening to the advice of others and taking it in….
For my ISP, I’ve had 2 or 3 internet uplinks for about 12 years now for 50,000
subs, and have only learned a default route on them. It’s been good up to this
point.
-Aaron
lør. 25. jan. 2020 13.42 skrev Tore Anderson :
> * Baldur Norddahl
>
> > If you join any peering exchanges, full tables will be mandatory. Some
> parties will export prefixes and then expect a more specific prefix
> received from your transit to override a part of the space received via the
>
* Baldur Norddahl
> If you join any peering exchanges, full tables will be mandatory. Some
> parties will export prefixes and then expect a more specific prefix received
> from your transit to override a part of the space received via the peering.
That would be a fundamentally flawed
lør. 25. jan. 2020 00.40 skrev Jon Lewis :
> On Fri, 24 Jan 2020, Baldur Norddahl wrote:
>
> > Full tables will not make much noticeable difference if you are not
> peering. However you want to make sure both
> > links get used. It can be a 90%/10% split but 100%/0% is bad because
> then you may
On 1/23/20 6:01 PM, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual Home
ISP should have full tables. My understanding has always been that full
tables when dual homed allow much more control. Especially in helping to
prevent Async routes.
If you don't have
On Fri, 24 Jan 2020, Baldur Norddahl wrote:
Full tables will not make much noticeable difference if you are not peering.
However you want to make sure both
links get used. It can be a 90%/10% split but 100%/0% is bad because then you
may discover that the alternate path
is actually broken the
On 1/23/2020 6:01 PM, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual
Home ISP should have full tables. My understanding has always been
that full tables when dual homed allow much more control. Especially
in helping to prevent Async routes.
Brian, you're
Full tables will not make much noticeable difference if you are not
peering. However you want to make sure both links get used. It can be a
90%/10% split but 100%/0% is bad because then you may discover that the
alternate path is actually broken the moment the primary fail. If you
choose only
Don't forget to connect to peering exchanges and take their full routes too
if you can.
On 1/23/20 16:01, Brian wrote:
Hello all. I am having a hard time trying to articulate why a Dual Home
ISP should have full tables. My understanding has always been that full
tables when dual homed allow much more control. Especially in helping to
prevent Async routes.
If you're multi-homed
fre. 24. jan. 2020 18.23 skrev Job Snijders :
>
> On Fri, 24 Jan 2020 at 17:40, Brian wrote:
>
> Am I crazy?
>>
>
> I dropped out of university, never completed my psychology studies, I fear
> I am unqualified to answer this question. ;-)
>
Education shopping, it is called by some.
Chriztoffer
Dear Brian,
On Fri, 24 Jan 2020 at 17:40, Brian wrote:
> Hello all. I am having a hard time trying to articulate why a Dual Home
> ISP should have full tables. My understanding has always been that full
> tables when dual homed allow much more control. Especially in helping to
> prevent Async
We have full tables from 2 ISPs at just one datacenter, and it is nice in the
case of partial reachability issues—If one ISP loses access to routes to a
destination but the other one doesn’t, for example. For us, the decision to do
full tables was easy, as we are running 2 MX150s which can very
Honestly, this. Your only real choice is what of 2 pipes to chuck it out of.
Full tables vs partial and a default don’t make the process much more
intelligent for 1 site dual homed, and as mentioned routing policy will have
more influence.
-Ben
> On Jan 24, 2020, at 8:47 AM, Mel Beckman
It’s pretty pointless for a small ISP to get full routes, because the BGP
tables are so highly manipulated. It’s better to just get “company” routes for
each upstream, and then use your own traffic engineering via prepending and
static or policy routes to balance the outbound traffic the way
don't
need to do this that often.
Thoughts?
Ahmed
From: Max Pierson [mailto:nmaxpier...@gmail.com]
Sent: 18 January 2011 21:30
To: Jack Carrozzo
Cc: Jack Bates; ayousuf0...@gmail.com; nanog group
Subject: Re: Dual Homed BGP for failover
Me 3's commit confirmed ... maybe someone
On Wed, 19 Jan 2011 10:23:47 -, Ahmed Yousuf wrote
- Accept that we are never going to get an ideal
distribution of traffic and continue monitoring and adjusting local
pref/prepends etc. as and when we need to change the distribution of
traffic. Hopefully we don't need to do
of the
higher capacity link.
-Original Message-
From: Randy McAnally [mailto:r...@fast-serv.com]
Sent: 19 January 2011 14:00
To: Ahmed Yousuf; 'nanog group'
Subject: RE: Dual Homed BGP for failover
On Wed, 19 Jan 2011 10:23:47 -, Ahmed Yousuf wrote
- Accept that we are never
Simulators (Ryan Shea)
6. RE: Network Simulators (Gary Gladney)
7. RE: Dual Homed BGP for failover (Randy McAnally)
8. Re: Network Simulators (Carlos Martinez-Cagnazzo)
9. RE: Dual Homed BGP for failover (Ahmed Yousuf
On Wed, 19 Jan 2011 14:26:32 -, Ahmed Yousuf wrote
We're doing BGP to announce our PI space and make sure that our PI
space is reachable through both ISPs in case one link goes down.
This is the primary need to do the BGP here. Unfortunately my boss
has requested that we make use of
You can just accept directly-connected peers from each network (or within 2
AS's, etc) then point a default at each one with different preferences. You
can do with with two edges if you like also: iBGP between the edges, and
push default into OSPF from both.
WRT dynamic load balancing...
You really limit yourself when you just take a default from a provider. If
you take 2 default's (one from each provider) for whatever reason, once you
change the local pref on one of them, it's all your traffic outbound or
none.
I always request a full table + default, so you can filter to best
From: Ahmed Yousuf
Sent: Tuesday, January 18, 2011 10:32 AM
To: nanog@nanog.org
Subject: Dual Homed BGP for failover
- Is this really a good idea, as the BGP process won't care
what
the utilisation of the links are and you will see situations where the
lower
speed link
On Tue, Jan 18, 2011 at 1:32 PM, Ahmed Yousuf ayousuf0...@gmail.com wrote:
It
has now been requested to be able to distribute traffic across both links
rather than preference traffic to the higher speed link.
- Is this really a good idea, as the BGP process won't care what
the
On 1/18/2011 1:00 PM, William Herrin wrote:
IMO, that would be a mistake. Taking significantly less than a full
table severely limits your options for balancing traffic between the
links.
It should also be noted that taking a full table, doesn't mean you have
to use the full table. Apply
...@herrin.us
Subject: Re: Dual Homed BGP for failover
CC: ayousuf0...@gmail.com; nanog@nanog.org
On 1/18/2011 1:00 PM, William Herrin wrote:
IMO, that would be a mistake. Taking significantly less than a full
table severely limits your options for balancing traffic between the
links
-Original Message-
From: Brandon Kim
Sent: Tuesday, January 18, 2011 11:57 AM
To: jba...@brightok.net; b...@herrin.us
Cc: ayousuf0...@gmail.com; nanog group
Subject: RE: Dual Homed BGP for failover
Someone should advise him that if he wants to take in a full BGP
routing
On 1/18/2011 2:05 PM, George Bonser wrote:
One can take a full feed but filter so only a subset of the routes are
actually installed. For example, filter all routes that are more than
one AS away from the immediate upstream.
You should still be careful, as most processors keep a copy of
On Tue, Jan 18, 2011 at 3:57 PM, Jack Bates jba...@brightok.net wrote:
You should still be careful, as most processors keep a copy of filtered
routes as well, so while your forwarding table may not increase, your route
processor memory most likely will.
I don't think this is the case, on IOS
On 1/18/2011 3:03 PM, Jack Carrozzo wrote:
I don't think this is the case, on IOS at least. Some years ago I was
rocking some 7500s with $not_enough ram for multiple full tables, but
with a prefix list to accept le 23 they worked fine.
On JunOS, I know I can view pre and post filtered bgp
Yep, the great thing about IOS without 'commit confirmed' is when you remove
a bgp filter, it runs out of memory, reboots, brings up peers, runs out of
memory, reboots... meanwhile if you're trying to get in over a public
interface you're cursing John Chamber's very existence. Not that that's ever
Me 3's commit confirmed ... maybe someone from Cisco should be watching
:)
On Tue, Jan 18, 2011 at 3:21 PM, Jack Carrozzo j...@crepinc.com wrote:
Yep, the great thing about IOS without 'commit confirmed' is when you
remove
a bgp filter, it runs out of memory, reboots, brings up peers, runs
On Tue, Jan 18, 2011 at 12:05 PM, George Bonser gbon...@seven.com wrote:
-Original Message-
From: Brandon Kim
Sent: Tuesday, January 18, 2011 11:57 AM
To: jba...@brightok.net; b...@herrin.us
Cc: ayousuf0...@gmail.com; nanog group
Subject: RE: Dual Homed BGP for failover
One can take
46 matches
Mail list logo
