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 t
/twitter.com/mdwestix>
>>> The Brothers WISP <http://www.thebrotherswisp.com/>
>>> <https://www.facebook.com/thebrotherswisp>
>>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>>> --
>>> *From: *&
midwest-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/thebrothe
<https://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 P
: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 o
age -
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:
>
>
>
&
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 "glo
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 toda
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 wh
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 hence
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
> peer
* 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 expectati
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 d
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 ful
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 cor
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 defau
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 y
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 ro
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 wrot
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 you
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.
Am I crazy?
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 o
hghi availability and load balancer solution
> (InterNetX - J?rgen Gotteswinter)
> 5. Re: Network Simulators (Ryan Shea)
> 6. RE: Network Simulators (Gary Gladney)
> 7. RE: Dual Homed BGP for failover (Randy McA
f 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
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
ly we 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 "comm
On Tue, Jan 18, 2011 at 12:05 PM, George Bonser 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 Hom
Me <3's "commit confirmed" ... maybe someone from Cisco should be watching
:)
On Tue, Jan 18, 2011 at 3:21 PM, Jack Carrozzo 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 out of
> memo
I would be hesitant to do full tables on an SRX210, particularly if you only
have an SRX210B with 512MB of RAM. I'm not sure what filtering would do in
terms of memory usage, because I have not tried it. I generally put a separate
edge device in to handle the upstream and BGP, and use the SRX p
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
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 u
On Tue, Jan 18, 2011 at 3:57 PM, Jack Bates 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 at least. Some
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 filte
> -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
gt; To: b...@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 op
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 fi
On Tue, Jan 18, 2011 at 1:32 PM, Ahmed Yousuf 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 utilisation of the lin
> 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 wi
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 su
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... generally
Hi,
I'm looking at a setup where we use BGP to announce PI space to two upstream
ISPs. ISP A provides a 30Mb/s connection and ISP B provides a 10Mb/s.
Originally the plan was to use ISP B's link as a backup and local pref
traffic outbound via ISP A and pref inbound using AS prepend via ISP A.
49 matches
Mail list logo