I wouldn't call that product marketing.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: "Scott Weeks"
To: nanog@nanog.org
Sent: Tuesday, June 2, 2015 6:00:38 PM
Subject: Re: BGP Multihoming 2 providers
but I don't do email like that
why is it hard to read?
it's really hard to read email this way.
because it's out of order
umm, ok. I fixed it for you
-
You've obviously never been hounded by sales folks scraping
this list that believe they should never
customers.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: "Scott Weeks"
To: nanog@nanog.org
Sent: Monday, June 1, 2015 8:44:41 PM
Subject: Re: BGP Multihoming 2 providers full or partial?
- Original Message -
- Original Message -
From: "Scott Weeks"
--- n...@border6.com wrote:
From: Pawel Rybczyk
platform where we included new feature called
That might be interesting for you.
---
This might be interesting for you.
https://www.nanog.org/list
On Jun 01, 2015, at 17:46 , William Herrin wrote:
> On Mon, Jun 1, 2015 at 5:13 PM, Baldur Norddahl
> wrote:
>> This is only a problem if you use so called tier 1 transit providers.
>>
>> The smaller fish in the pond have multiple transits themselves and will
>> there by always have an alternat
On Mon, Jun 1, 2015 at 5:13 PM, Baldur Norddahl
wrote:
> This is only a problem if you use so called tier 1 transit providers.
>
> The smaller fish in the pond have multiple transits themselves and will
> there by always have an alternative route available.
Hi Baldur,
Cogent is not a tier 1 (not
On Mon, Jun 1, 2015 at 5:05 PM, Blake Hudson wrote:
> After studying failure modes and attempting to optimize BGP using partial
> routing tables, I am of the opinion that BGP with a full routing table to
> directly connected devices is by far the best way to gain the availability
> benefits of BGP
This is only a problem if you use so called tier 1 transit providers.
The smaller fish in the pond have multiple transits themselves and will
there by always have an alternative route available.
Regards
Baldur
Den 01/06/2015 22.32 skrev "William Herrin" :
> On Mon, Jun 1, 2015 at 2:40 PM, Blake
William Herrin wrote on 6/1/2015 3:28 PM:
On Mon, Jun 1, 2015 at 2:40 PM, Blake Hudson wrote:
A gateway of last resort, also called a backup default route, will take care
of partitions
No, Blake, it won't. A partition means one of your ISPs has no route
to the destination. Route the packet to
On Mon, Jun 1, 2015 at 2:40 PM, Blake Hudson wrote:
> A gateway of last resort, also called a backup default route, will take care
> of partitions
No, Blake, it won't. A partition means one of your ISPs has no route
to the destination. Route the packet to that ISP via a default route
and it gets
ic routes on the
BGP routers seems counter intuitive on the face of it.
From: NANOG on behalf of Baldur Norddahl
Sent: 01 June 2015 16:49
To: nanog@nanog.org
Subject: Re: BGP Multihoming 2 providers full or partial?
On 1 June 2015 at 15:29, Blake Hudson wrote:
Something to point out: Sometimes t
face of it.
From: NANOG on behalf of Baldur Norddahl
Sent: 01 June 2015 16:49
To: nanog@nanog.org
Subject: Re: BGP Multihoming 2 providers full or partial?
On 1 June 2015 at 15:29, Blake Hudson wrote:
Something to point out: Sometimes the device you c
___
From: NANOG on behalf of Baldur Norddahl
Sent: 01 June 2015 16:49
To: nanog@nanog.org
Subject: Re: BGP Multihoming 2 providers full or partial?
On 1 June 2015 at 15:29, Blake Hudson wrote:
> Something to point out: Sometimes the device you connect to is up, but has
&
On 1 June 2015 at 15:29, Blake Hudson wrote:
> Something to point out: Sometimes the device you connect to is up, but has
> no reachability to the rest of the world. Using static routes is.. well..
> static. There are a few cases (such as the one mentioned) where a static
> route can be somewhat
Hammett
Intelligent Computing Solutions
http://www.ics-il.com
- Original Message -
From: "Scott Weeks"
To: nanog@nanog.org
Sent: Monday, June 1, 2015 3:36:46 AM
Subject: Re: BGP Multihoming 2 providers full or partial?
--- n...@border6.com wrote:
From: Pawel Rybczyk
Baldur Norddahl wrote on 5/31/2015 1:13 PM:
Remember this:
1) for inbound traffic there will be no difference at all.
2) routers will ignore a static route if the link is down. If you can get
BFD from the providers then even better.
So you can emulate 99% of what you get with full routes by lo
--- n...@border6.com wrote:
From: Pawel Rybczyk
platform where we included new feature called
That might be interesting for you.
---
This might be interesting for you.
https://www.nanog.org/list
Please read #5 before going further.
Product Eva
Hi,
We've have recently published new version of our BGP routing
optimization platform where we included new feature called: vRouter.
That might be interesting for you.
The vRouter provides route summarization support to BGP routers whose
TCAM is unable to hold the entire actual feed of Internet
If your traffic is small, you could setup a VyOS box. You can still get
redundancy by having two switches, each one connected to an upstream
provider receiving a default route. Then hookup your VyOS router to
each switch and receive full routes to that. You will need a /29 subnet
from your p
Remember this:
1) for inbound traffic there will be no difference at all.
2) routers will ignore a static route if the link is down. If you can get
BFD from the providers then even better.
So you can emulate 99% of what you get with full routes by loading in
static routes. A simple example would
Well, we´re using 2x Cisco 3560X switches for simple inbound/outbound
load sharing with our provider for years
(http://wiki.nil.com/EBGP_load_sharing). There´s no need for us going
full routes...
Regards,
Michael
On Fri, May 29, 2015 at 4:36 AM, Maqbool Hashim wrote:
> We are an enterprise that are eBGP multihoming to two ISPs. We wish to load
> balance in inbound and outbound traffic thereby using our capacity as
> efficiently as possible. My current feeling is that it would be crazy for us
> to take a
On 31/May/15 14:09, Maqbool Hashim wrote:
>
> I am just not sure of exactly how to define the "partial" routing table
> criteria to our two providers. Should we just take routes for each provider
> and their peers and a default from both?
Since you can't take a full feed from either upstream,
there are other reasons or needs, that
can sway the decision in one direction or the other).
:)
Faisal Imtiaz
Snappy Internet & Telecom
- Original Message -
> From: "Maqbool Hashim"
> To: "Joseph Jackson" , nanog@nanog.org
> Sent: Sunday, May 31, 2015 8:09:
Just for the hardware and the planning required for migrating to new hardware
human resource etc.
-Original Message-
From: Faisal Imtiaz [mailto:fai...@snappytelecom.net]
Sent: 31 May 2015 14:01
To: Maqbool Hashim
Cc: nanog@nanog.org
Subject: Re: BGP Multihoming 2 providers full or
supp...@snappytelecom.net
- Original Message -
> From: "Maqbool Hashim"
> To: "Faisal Imtiaz"
> Cc: nanog@nanog.org
> Sent: Sunday, May 31, 2015 8:10:51 AM
> Subject: RE: BGP Multihoming 2 providers full or partial?
>
> Thanks,
>
> So we just ne
@nanog.org
Subject: Re: BGP Multihoming 2 providers full or partial?
If you wish to do outbound traffic engineering, and want to take advantage of
best paths to different networks (outbound), then you have to take full routes.
Or putting it another way Taking full routes offers the most
st/inconvenience
of upgrading existing hardware.
Thanks
-Original Message-
From: Joseph Jackson [mailto:jjack...@aninetworks.net]
Sent: 31 May 2015 12:41
To: Maqbool Hashim; nanog@nanog.org
Subject: RE: BGP Multihoming 2 providers full or partial?
Can your devices support a full ta
ashim"
> To: nanog@nanog.org
> Sent: Friday, May 29, 2015 4:36:34 AM
> Subject: BGP Multihoming 2 providers full or partial?
>
> Hi,
>
>
> We are an enterprise that are eBGP multihoming to two ISPs. We wish to load
> balance in inbound and outbound traffic th
vider.
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Maqbool Hashim
Sent: Friday, May 29, 2015 3:37 AM
To: nanog@nanog.org
Subject: BGP Multihoming 2 providers full or partial?
Hi,
We are an enterprise that are eBGP multihoming to two ISPs. We wish to load
balan
Hi,
We are an enterprise that are eBGP multihoming to two ISPs. We wish to load
balance in inbound and outbound traffic thereby using our capacity as
efficiently as possible. My current feeling is that it would be crazy for us to
take a full Internet routing table from either ISP. I have read
* Tore Anderson
> * Baldur Norddahl
>
>> Is assigning a /24 from my own PA space for the purpose of BGP
>> multihoming considered sufficient "need"?
>
> Not with current policies, no
That was then. With current policies: yes.
To elaborate a bit, the RIPE Com
On Wed, Jan 29, 2014 at 3:45 PM, Michael Braun (michbrau)
wrote:
> Does
> that cause any problems where address space is being advertised from a
> non-assigned AS?
how do you mean 'non-assigned' ?
perhaps you have an example in the routing system today you could point at?
IR on
your customer's behalf, for a reasonable fee.)
> Is assigning a /24 from my own PA space for the purpose of BGP
> multihoming considered sufficient "need"?
Not with current policies, no, as the multihoming clause only applied
specifically to PI assignments, not pA. However, i
I. Which appears to be
>impossible as RIPE does no longer assign PI space and PI can not be
>reassigned and thus be bought.
>
>Is assigning a /24 from my own PA space for the purpose of BGP multihoming
>considered sufficient "need"?
>
>Could he get some PI from
e for the purpose of BGP multihoming
considered sufficient "need"?
I haven't looked at RIPE policies in a while, but I would imagine that
assigning a customer a /24 of your space because they need to multihome is
considered a justifiable use.
Could he get some PI from another
for multihoming as everyone are going to ignore his route.
I would then need to help him with acquiring a /24 PI. Which appears to be
impossible as RIPE does no longer assign PI space and PI can not be
reassigned and thus be bought.
Is assigning a /24 from my own PA space for the purpose of BGP
Le 29/01/2014 20:34, Owen DeLong a écrit :
>> This sort of local-pref default seems to be a common practice with
>> backbones. It's very annoying. I wish they'd stop.
> Most of their customers would actually be very unhappy if they stopped. This
> local-pref default prevents many many problems and
> This sort of local-pref default seems to be a common practice with
> backbones. It's very annoying. I wish they'd stop.
Most of their customers would actually be very unhappy if they stopped. This
local-pref default prevents many many problems and in the vast majority of
cases provides the des
On Wed, Jan 29, 2014 at 6:32 AM, Joseph Jenkins
wrote:
> I am seeking some feedback/help with my BGP configuration.
> I am peering with two providers level3 and tw. Unfortunately all of
> my address spaces are preferring the route over tw rather than level3.
Hi Joe,
I had a situation like this
According to telnet://route-server.twtelecom.net and
http://lookingglass.level3.net/bgp/lg_bgp_main.php BGP is working as
designed. Your single prepend on one prefix with TWTC causes a slight
preference for LVL3. Add another prepend if you want to further balance
your ingress load away from TWTC.
It is likely that level3 is aggregating your route, but tw can't. Longest match
wins.
--
Jakob Heitz.
> Date: Wed, 29 Jan 2014 03:32:17 -0800
> From: Joseph Jenkins
>
> I am seeking some feedback/help with my BGP configuration. I am peering with
> two providers level3 and tw. Unfortunately
day, January 29, 2014 9:20:32 AM
> Subject: RE: BGP multihoming with two address spaces
>
> Perhaps L3 is preferring the routes it hears from TW over the ones it hears
> from you. Perhaps there is a community string you can attach to your
> announcements to one or both providers
Jenkins [mailto:j...@breathe-underwater.com]
Sent: Wednesday, January 29, 2014 7:45 AM
Cc: nanog@nanog.org
Subject: Re: BGP multihoming with two address spaces
I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0.
Joe
On Jan 29, 2014, at 4:21 AM, Sasa Ristic wrote:
> How are
I am announcing two separate /24s. 8.37.93.0 and 207.114.212.0.
Joe
On Jan 29, 2014, at 4:21 AM, Sasa Ristic wrote:
> How are you announcing your address space now?
>
> On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins
> wrote:
>> I am seeking some feedback/help with my BGP configuration. I
How are you announcing your address space now?
On Wed, Jan 29, 2014 at 12:32 PM, Joseph Jenkins
wrote:
> I am seeking some feedback/help with my BGP configuration. I am peering with
> two providers level3 and tw. Unfortunately all of my address spaces are
> preferring the route over tw rather
I am seeking some feedback/help with my BGP configuration. I am peering with
two providers level3 and tw. Unfortunately all of my address spaces are
preferring the route over tw rather than level3. I have tried Prepending my AS
and the carriers AS to the path on the tw side and I see those up
"George Bonser" writes:
>> -Original Message-
>> From: Bret Clark
>> Sent: Friday, December 10, 2010 7:08 AM
>> To: nanog@nanog.org
>> Subject: Re: BGP multihoming question.
>>
>> On 12/10/2010 10:01 AM, Dylan Ebner wrote:
>>
> -Original Message-
> From: Bret Clark
> Sent: Friday, December 10, 2010 7:08 AM
> To: nanog@nanog.org
> Subject: Re: BGP multihoming question.
>
> On 12/10/2010 10:01 AM, Dylan Ebner wrote:
> > 3. You cannot trust the second isp to advertise the SWIP block
On 12/10/2010 10:01 AM, Dylan Ebner wrote:
3. You cannot trust the second isp to advertise the SWIP block correctly if
they are not a tier 1. Even though they may advertise it for you to their
upstream, they don't always have the appropriate procedures in place to get the
LOAs to the upstream
Ebner
-Original Message-
From: b2 [mailto:b...@playtime.bg]
Sent: Thursday, December 09, 2010 5:32 AM
To: North American Network Operators Group
Subject: BGP multihoming question.
Hi , first sorry for lame question but i'm new to BGP.
In my ISP I have two full BGP sessions with my two transit
On 12/9/2010 5:32 AM, b2 wrote:
Hi , first sorry for lame question but i'm new to BGP.
In my ISP I have two full BGP sessions with my two transit providers (X
and Y), and for every provider i have assigned PA (Provider
Aggregatable) networks. Is it possible (if there are no filters on other
side)
2010/12/9 b2 :
> Hi , first sorry for lame question but i'm new to BGP.
> In my ISP I have two full BGP sessions with my two transit providers (X
> and Y), and for every provider i have assigned PA (Provider
> Aggregatable) networks. Is it possible (if there are no filters on other
> side) to adver
On Thu, 09 Dec 2010 13:32:26 +0200
b2 wrote:
> Hi , first sorry for lame question but i'm new to BGP.
> In my ISP I have two full BGP sessions with my two transit providers
> (X and Y), and for every provider i have assigned PA (Provider
> Aggregatable) networks. Is it possible (if there are no f
Hi , first sorry for lame question but i'm new to BGP.
In my ISP I have two full BGP sessions with my two transit providers (X
and Y), and for every provider i have assigned PA (Provider
Aggregatable) networks. Is it possible (if there are no filters on other
side) to advertise X networks to Y and
Most providers will give you just their on net prefixes. This is useful if
multihomed but you do not really need full tables.
Then you can default or similar for the rest of the net.
Jared Mauch
On Jun 14, 2010, at 11:30 AM, James Smallacombe wrote:
>
> I know this topic must have been cov
On Jun 14, 2010, at 12:08 PM, Fred Baker wrote:
> upstream, full routes are generally not as useful as one might expect. You're
> at least as well off with default routes for your upstreams plus what we call
> "Optimized Edge Routing", which allows you to identify (dynamically, for each
> pref
On Jun 14, 2010, at 11:30 AM, James Smallacombe wrote:
> Cisco's position these days seems to be "you don't need to carry full views
> unless you like tinkering with optimizig paths and such."
Not sure why Cisco's position is relevant, but let me restate it.
Cisco will happily sell you all the
I know this topic must have been covered before, but I can find no search
tool for the NANOG archives. I did google and reference Halabi's book as
well as Avi's howto, but I still don't feel I fully understand the pros
and cons of Full vs. Partial routes in a dual/multihomed network.
Cisco'
on issues like this :
[1] JFGI
-> if fail :
[2] man smartnet
-> if fail :
[3] go back to studying to get that A+ and consider perhaps a yob in redmond
On Fri, May 22, 2009 at 4:01 AM, Raymond Dijkxhoorn wrote:
> Hi!
>
> Yes, i can get sample of configuration via Google search.
>>
Hi!
Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.
Then post your suggested config and ask for comments.
...on a suitable list, dedicated to Cisco gear..
Sorry, yes. :-) Plenty of Cisco lists there to answer 'ques
Subject: Re: Local Peering and Transit - BGP multihoming Date: Fri, May 22,
2009 at 10:55:14AM +0200 Quoting Raymond Dijkxhoorn (raym...@prolocation.net):
> Hi!
>
>> Yes, i can get sample of configuration via Google search.
>> but i am looking for best practices and from
Hi!
Yes, i can get sample of configuration via Google search.
but i am looking for best practices and from experience people.
Then post your suggested config and ask for comments.
Bye,
Raymond.
nd Transit - BGP multihoming
Google BGP Cisco... Should give you 90% of this.
--Original Message--
From: ty chan
To: nanog@nanog.org
Subject: Local Peering and Transit - BGP multihoming
Sent: May 22, 2009 2:23 AM
Dear all,
In my lab, i manage two ASN (100,200). ASN100 has one transit to
Google BGP Cisco... Should give you 90% of this.
--Original Message--
From: ty chan
To: nanog@nanog.org
Subject: Local Peering and Transit - BGP multihoming
Sent: May 22, 2009 2:23 AM
Dear all,
In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and
local peering to
ty chan wrote:
> Dear all,
>
> In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and
> local peering to ASN500.
> ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some
> policies are required as below:
> 1. ASN100 customer can only use ASN300 for trans
Dear all,
In my lab, i manage two ASN (100,200). ASN100 has one transit to ASN300 and
local peering to ASN500.
ASN200 has one transit to ASN400. ASN100 do private peering to ASN200. Some
policies are required as below:
1. ASN100 customer can only use ASN300 for transit
2. ASN200 customer can onl
67 matches
Mail list logo