Re: AS path not optimal

[joel jaeggli]

On 3/4/14, 3:16 AM, ku po wrote:
> One of my client has peering with nlayer and a provider from Asia. It seems
> from one  major ISP in US, the best path is through this Asia provider,
> instead of through nlayer which we want it to be.
> 
> It seems this major ISP does not have a direct peering with nlayer AS 4436
> is the cause of this problem.
> 
> What is the best way to address this problem?

For exit selection, tag the routes you want to influence with a
community and then apply a higher localpref to routes from that community.

if inbound is also coming from asia you should explore prepending
towards that provider via provider communities or in your advertisement
directly (the later obviously is gross)







signature.asc
Description: OpenPGP digital signature

Re: ISP inbound failover without BGP

[Hank Nussbacher]

Have them look at radware linkproof which is designed for small shops that 
don't want to do bgp and getting their own ASN and pi address space.  Been 
around since 1999.

http://www.radware.com/Products/LinkProof/

Hank

On Mar 4, 2014 3:11 AM, Eric A Louie  wrote:
>
> This may sound like dumb question, but... I'm used to asking those.
>
> Here's the scenario
>
> Another ISP, say AT&T, is the primary ISP for a customer.
>
> Customer has publicly accessible servers in their office, using the AT&T 
> address space.
>
> I am the customer's secondary ISP.
>
> Now, if AT&T link fails, I can provide the customer outbound Internet access 
> fairly easily.  So they can surf and get to the Internet.
>
> What about the publicly accessible servers that have AT&T addresses, though?
>
> One thought I had was having them use Dynamic DNS service. 
>
> Are there any other solutions, short of using BGP multihoming and having them 
> try to get their own ASN and IPv4 /24 block?
>
> It looks like a few router manufacturers have devices that might work, but it 
> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the 
> primary ISP fails, the secondary ISP address is advertised. 

Re: ISP inbound failover without BGP

[Jon Lewis]

On Mon, 3 Mar 2014, Justin M. Streiner wrote:

If they're not technically competent enough to handle BGP, they won't be 
technically competent enough to deal with solutions that play the short DNS 
TTL game.


As someone else mentioned in this thread - would colocating the servers be a 
workable solution for them?  Put the servers some place where the redundancy 
exists already.


My vote goes to the traditional BGP multihomed solution.  It's the right 
way to solve the problem and the easiest to manage.


If getting AT&T to do BGP and buying a BGP capable router (they don't even 
need full routes...so so anything that'll speak BGP, take a pair of 
default routes, and handle whatever their traffic level is will do) is too 
costly[1], another possible option I've not seen mentioned is VPN.  They 
could put one machine/router somewhere with decent redundancy and setup a 
VPN gateway at their office that connects to the colo'd device.


You might even offer this as a service.

Spammers have been doing this for years.  It makes moving their operations 
easier as their public facing servers get cancelled.  All they do is move 
the VPN server(s) and their systems that do all the "work" remain online 
and hidden.


[1] If only I had a dollar for every time a client said redundancy was too 
expensive to have, but when their non-redundant stuff went offline, 
they claimed to be losing millions of $ per small unit of time.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: AS path not optimal

[David Miller]

On 03/03/2014 10:16 PM, ku po wrote:
> One of my client has peering with nlayer and a provider from Asia. It seems
> from one  major ISP in US, the best path is through this Asia provider,
> instead of through nlayer which we want it to be.
> 
> It seems this major ISP does not have a direct peering with nlayer AS 4436
> is the cause of this problem.
> 
> What is the best way to address this problem?
> 


Add BGP communities to your client's announcements directing the Asia
provider to prepend their AS X times (whatever value of X works best for
you) on passing your client's prefixes to that major ISP in the US.

The Asia provider should be able to provide you a list of their BGP
control communities.

-DMM




signature.asc
Description: OpenPGP digital signature

Re: ISP inbound failover without BGP

[Seth Mattinen]

On 3/3/14, 7:20 PM, Randy Carpenter wrote:
> Is there some technical reason that BGP is not an option? You could allow 
> them to announce their AT&T space via you as a secondary.


With the risk of starting holy war on how BGP works on dialup and that
providers should permit such, the OP has not specified what transport
methods is in play with AT&T which could limit such an option.

~Seth

Re: ISP inbound failover without BGP

[Justin M. Streiner]

On Mon, 3 Mar 2014, Eric A Louie wrote:

Honestly?  Because the end-customers are not technically competent 
enough to run dual-homed BGP, and we don't want to be their managed 
service providers on the IT side.  And announcing the AT&T space is fine 
until something goes wrong, and I have to troubleshoot the problem 
(Customer - "How come AT&T is down, and we're not getting inbound 
traffic to our servers?", and I discover L3 or CenturyLink isn't 
accepting my advertisement for some weird reason, but they won't fess up 
to it for a few frustrating hours)


If they're not technically competent enough to handle BGP, they won't be 
technically competent enough to deal with solutions that play the short 
DNS TTL game.


As someone else mentioned in this thread - would colocating the servers be 
a workable solution for them?  Put the servers some place where the 
redundancy exists already.


jms

Re: ISP inbound failover without BGP

[Faisal Imtiaz]

There are other elaborate solutions to accomplish this, however all of them 
would require a competent IT/Network Person to manage the network.

If we were the ISP, we would look at such a case an an opportunity, and become 
the managed service provider, for a fee (typically a premium), and provide the 
service.

As service providers, we all complain about the end-customer being a pain, but 
we often forget that it the the PITA end-customers that give us the ability to 
earn our daily bread! I think too many of us are overworked and providing 
highly under-paid services for peanuts, where we often overlook at 
opportunities to get premium value as a PITA, and not worth it...

:)

Just my personal two cents,.

Faisal Imtiaz
Snappy Internet & Telecom


- Original Message -
> From: "Eric A Louie" 
> To: "Randy Carpenter" 
> Cc: "NANOG" 
> Sent: Monday, March 3, 2014 11:49:21 PM
> Subject: Re: ISP inbound failover without BGP
> 
> Honestly?  Because the end-customers are not technically competent enough to
> run dual-homed BGP, and we don't want to be their managed service providers
> on the IT side.  And announcing the AT&T space is fine until something goes
> wrong, and I have to troubleshoot the problem (Customer - "How come AT&T is
> down, and we're not getting inbound traffic to our servers?", and I discover
> L3 or CenturyLink isn't accepting my advertisement for some weird reason,
> but they won't fess up to it for a few frustrating hours)
> 
> 
> 
> 
> 
> >
> > From: Randy Carpenter 
> >To: Eric A Louie 
> >Cc: NANOG 
> >Sent: Monday, March 3, 2014 7:20 PM
> >Subject: Re: ISP inbound failover without BGP
> > 
> >
> >
> >Is there some technical reason that BGP is not an option? You could allow
> >them to announce their AT&T space via you as a secondary.
> >
> >-Randy
> >
> >- Original Message -
> >> This may sound like dumb question, but... I'm used to asking those.
> >> 
> >> Here's the scenario
> >> 
> >> Another ISP, say AT&T, is the primary ISP for a customer.
> >> 
> >> Customer has publicly accessible servers in their office, using the AT&T
> >> address space.
> >> 
> >> I am the customer's secondary ISP.
> >> 
> >> Now, if AT&T link fails, I can provide the customer outbound Internet
> >> access
> >> fairly easily.  So they can surf and get to the Internet.
> >> 
> >> What about the publicly accessible servers that have AT&T addresses,
> >> though?
> >> 
> >> One thought I had was having them use Dynamic DNS service.
> >> 
> >> Are there any other solutions, short of using BGP multihoming and having
> >> them
> >> try to get their own ASN and IPv4 /24 block?
> >> 
> >> 
> >> It looks like a few router manufacturers have devices that might work, but
> >> it
> >> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the
> >> primary ISP fails, the secondary ISP address is advertised.
> >> 
> >> 
> >
> >
> >
>

Re: ISP inbound failover without BGP

[Justin M. Streiner]

On Mon, 3 Mar 2014, Eric A Louie wrote:

Are there any other solutions, short of using BGP multihoming and 
having them try to get their own ASN and IPv4 /24 block?


For what it sounds like the customer wants to do, this really is the right 
solution.  Most everything else has some level of 'ugly hack' attached to 
it, that can cause reliability/reachability problems at inopportune times 
(as opposed to problems that happen at opportune times).


If the customer is just looking for failover capabilities, they can take 
default via BGP from both providers, prefer one over the other, and use 
some other bits to prefer one provider over for inbound connectivity. 
They would not need very beefy routers for this.


That will get you basic service redundancy.  Add a second router, and they 
can have some protection in the event of a router failure.


It all really boils down to what the customer wants and is willing to pay 
for.  If they have services that need to be reliably reachable, then using 
a time-tested design is a prudent decision.


jms

Re: ISP inbound failover without BGP

[Eric A Louie]

Honestly?  Because the end-customers are not technically competent enough to 
run dual-homed BGP, and we don't want to be their managed service providers on 
the IT side.  And announcing the AT&T space is fine until something goes wrong, 
and I have to troubleshoot the problem (Customer - "How come AT&T is down, and 
we're not getting inbound traffic to our servers?", and I discover L3 or 
CenturyLink isn't accepting my advertisement for some weird reason, but they 
won't fess up to it for a few frustrating hours)





>
> From: Randy Carpenter 
>To: Eric A Louie  
>Cc: NANOG  
>Sent: Monday, March 3, 2014 7:20 PM
>Subject: Re: ISP inbound failover without BGP
> 
>
>
>Is there some technical reason that BGP is not an option? You could allow them 
>to announce their AT&T space via you as a secondary.
>
>-Randy
>
>- Original Message -
>> This may sound like dumb question, but... I'm used to asking those.
>> 
>> Here's the scenario
>> 
>> Another ISP, say AT&T, is the primary ISP for a customer.
>> 
>> Customer has publicly accessible servers in their office, using the AT&T
>> address space.
>> 
>> I am the customer's secondary ISP.
>> 
>> Now, if AT&T link fails, I can provide the customer outbound Internet access
>> fairly easily.  So they can surf and get to the Internet.
>> 
>> What about the publicly accessible servers that have AT&T addresses, though?
>> 
>> One thought I had was having them use Dynamic DNS service.
>> 
>> Are there any other solutions, short of using BGP multihoming and having them
>> try to get their own ASN and IPv4 /24 block?
>> 
>> 
>> It looks like a few router manufacturers have devices that might work, but it
>> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the
>> primary ISP fails, the secondary ISP address is advertised.
>> 
>> 
>
>
>

Re: ISP inbound failover without BGP

[Joe Greco]

> Depending on their business=2C using dynamic DNS providers could be a reall=
> y bad idea. If they deal only with home users who won't even know=2C it'll =
> probably work. If their customers are security-aware businesses=2C they pro=
> bably block all sites hosted with dynamic DNS systems.


Where do dynamic DNS /providers/ enter the picture?

You update *your own* DNS records.  Those could conceivably be hosted
with a dynamic DNS provider, but why not just use the API for whatever
system you currently use for DNS?


... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: ISP inbound failover without BGP

[Arturo Servin]

On Mon, Mar 3, 2014 at 7:20 PM, Randy Carpenter wrote:

> Is there some technical reason that BGP is not an option? You could allow
> them to announce their AT&T space via you as a secondary.


unless it is a /26, /25 or something shorter.

Even with a /24 things may get messy.

IPv4 is coming to an end, but it is not possible for the customer to get
their own space and use BGP?

Regards,
as

Re: ISP inbound failover without BGP

[William Herrin]

On Mon, Mar 3, 2014 at 8:11 PM, Eric A Louie  wrote:
> One thought I had was having them use Dynamic DNS service.
>
> Are there any other solutions, short of using BGP multihoming
> and having them try to get their own ASN and IPv4 /24 block?

Hi Eric,

I went through this a couple years ago with continuity of operations
planning. The bottom line is: with the notable exception of
low-activity electronic mail, switching the address record in the DNS
entry will generally not work as expected. For folks serious about
reliable access to their servers, BGP isn't just the best way, it's
the only way.

Reasons why dynamic DNS fails to perform as expected include:

* Web browser DNS pinning can result in a customer's web browser
holding the old IP address indefinitely.

* Host-level caching of looked up names which discards the TTL.
Remember: your desktop or laptop performs lookups against multiple
name services, e.g. DNS, /etc/hosts, lmhosts, NIS+. DNS TTL is no
longer in scope once the name to address map enters the generic host
lookup mechanism. Most OSes have a fixed timeout of one sort or
another, some old ones as long as 24 hours.

* Custom applications with either IP addresses hardcoded into the
configuration or with getaddrinfo() called only once and the resulting
IP address held for the lifetime of the application.

* Anti-spam systems block IP addresses when receiving large quantities
of email from formerly-quiescent IP addresses. This is a problem if
your mail server sends a lot of email and suddenly switches to a new
sending IP address.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: ISP inbound failover without BGP

[Eric A Louie]

That's a good point Ray - thank you.




>
> From: Ray 
>To: Matthew Crocker ; Eric A Louie 
> 
>Cc: NANOG  
>Sent: Monday, March 3, 2014 6:31 PM
>Subject: RE: ISP inbound failover without BGP
> 
>
>
> 
>Depending on their business, using dynamic DNS providers could be a really bad 
>idea. If they deal only with home users who won't even know, it'll probably 
>work. If their customers are security-aware businesses, they probably block 
>all sites hosted with dynamic DNS systems.
>
>Ray
>
>
>> Subject: Re: ISP inbound failover without BGP
>> From: matt...@corp.crocker.com
>> Date: Mon, 3 Mar 2014 20:50:26 -0500
>> To: elo...@yahoo.com
>> CC: nanog@nanog.org
>> 
>> 
>> 
>> Depends on the application, 
>> 
>> SIP, VPN, SMTP, etc just setup both IPs and let the end-user application 
>> figure it out (SIP-UA register to both IPs for example)
>> 
>> HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend 
>> the requests. Then it can load balance traffic over both IPs.
>> 
>> DNS TTL ‘tricks’ are just that, they work ‘kinda’
>> 
>> Fatpipe?   Crazy expensive IMHO but I hear they work ok.
>> 
>> -Matt
>> 
>> --
>> Matthew S. Crocker
>> President
>> Crocker Communications, Inc.
>> PO BOX 710
>> Greenfield, MA 01302-0710
>> 
>> E: matt...@crocker.com
>> P: (413) 746-2760
>> F: (413) 746-3704
>> W: http://www.crocker.com
>> 
>> 
>> 
>> On Mar 3, 2014, at 8:11 PM, Eric A Louie  wrote:
>> 
>> > This may sound like dumb question, but... I'm used to asking those.
>> > 
>> > Here's the scenario
>> > 
>> > Another ISP, say AT&T, is the primary ISP for a customer.
>> > 
>> > Customer has publicly accessible servers in their office, using the AT&T 
>> > address space.
>> > 
>> > I am the customer's secondary ISP.
>> > 
>> > Now, if AT&T link fails, I can provide the customer outbound Internet 
>> > access fairly easily.  So they can surf and get to the Internet.
>> > 
>> > What about the publicly accessible servers that have AT&T addresses, 
>> > though?
>> > 
>> > One thought I had was having them use Dynamic DNS service. 
>> > 
>> > Are there any other solutions, short of using BGP multihoming and having 
>> > them try to get their own ASN and IPv4 /24 block?
>> > 
>> > 
>> > It looks like a few router manufacturers have devices that might work, but 
>> > it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the 
>> > primary ISP fails, the secondary ISP address is advertised.
>> > 
>> 
>> 
>
>
>

Re: ISP inbound failover without BGP

[Randy Carpenter]

Is there some technical reason that BGP is not an option? You could allow them 
to announce their AT&T space via you as a secondary.

-Randy

- Original Message -
> This may sound like dumb question, but... I'm used to asking those.
> 
> Here's the scenario
> 
> Another ISP, say AT&T, is the primary ISP for a customer.
> 
> Customer has publicly accessible servers in their office, using the AT&T
> address space.
> 
> I am the customer's secondary ISP.
> 
> Now, if AT&T link fails, I can provide the customer outbound Internet access
> fairly easily.  So they can surf and get to the Internet.
> 
> What about the publicly accessible servers that have AT&T addresses, though?
> 
> One thought I had was having them use Dynamic DNS service.
> 
> Are there any other solutions, short of using BGP multihoming and having them
> try to get their own ASN and IPv4 /24 block?
> 
> 
> It looks like a few router manufacturers have devices that might work, but it
> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the
> primary ISP fails, the secondary ISP address is advertised.
> 
> 

AS path not optimal

[ku po]

One of my client has peering with nlayer and a provider from Asia. It seems
from one  major ISP in US, the best path is through this Asia provider,
instead of through nlayer which we want it to be.

It seems this major ISP does not have a direct peering with nlayer AS 4436
is the cause of this problem.

What is the best way to address this problem?

RE: ISP inbound failover without BGP

[Ray]

Depending on their business, using dynamic DNS providers could be a really bad 
idea. If they deal only with home users who won't even know, it'll probably 
work. If their customers are security-aware businesses, they probably block all 
sites hosted with dynamic DNS systems.

Ray

> Subject: Re: ISP inbound failover without BGP
> From: matt...@corp.crocker.com
> Date: Mon, 3 Mar 2014 20:50:26 -0500
> To: elo...@yahoo.com
> CC: nanog@nanog.org
> 
> 
> 
> Depends on the application,  
> 
> SIP, VPN, SMTP, etc just setup both IPs and let the end-user application 
> figure it out (SIP-UA register to both IPs for example)
> 
> HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend the 
> requests. Then it can load balance traffic over both IPs.
> 
> DNS TTL ‘tricks’ are just that, they work ‘kinda’
> 
> Fatpipe?   Crazy expensive IMHO but I hear they work ok.
> 
> -Matt
> 
> --
> Matthew S. Crocker
> President
> Crocker Communications, Inc.
> PO BOX 710
> Greenfield, MA 01302-0710
> 
> E: matt...@crocker.com
> P: (413) 746-2760
> F: (413) 746-3704
> W: http://www.crocker.com
> 
> 
> 
> On Mar 3, 2014, at 8:11 PM, Eric A Louie  wrote:
> 
> > This may sound like dumb question, but... I'm used to asking those.
> > 
> > Here's the scenario
> > 
> > Another ISP, say AT&T, is the primary ISP for a customer.
> > 
> > Customer has publicly accessible servers in their office, using the AT&T 
> > address space.
> > 
> > I am the customer's secondary ISP.
> > 
> > Now, if AT&T link fails, I can provide the customer outbound Internet 
> > access fairly easily.  So they can surf and get to the Internet.
> > 
> > What about the publicly accessible servers that have AT&T addresses, though?
> > 
> > One thought I had was having them use Dynamic DNS service.  
> > 
> > Are there any other solutions, short of using BGP multihoming and having 
> > them try to get their own ASN and IPv4 /24 block?
> > 
> > 
> > It looks like a few router manufacturers have devices that might work, but 
> > it looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the 
> > primary ISP fails, the secondary ISP address is advertised.
> > 
> 
> 
  

Re: DSLAM

[Eric]

I can do it. 

Sent from my iPhone

> On Mar 3, 2014, at 12:40 PM, "Nick Olsen"  wrote:
> 
> Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. 
> And I need it by tomorrow.
> 
> Normal channels seem to be impacted by weather. Not to mention we've been 
> pretty unhappy with our current models (Versa, And Planet).
> 
> Any options? Unicast is acceptable.
> 
> Nick Olsen
> Network Operations  (855) FLSPEED  x106
> 
> 

Re: ISP inbound failover without BGP

[Matthew Crocker]

Depends on the application,  

SIP, VPN, SMTP, etc just setup both IPs and let the end-user application figure 
it out (SIP-UA register to both IPs for example)

HTTP/HTTPS setup a proxy server in a colo that is multi-homed to frontend the 
requests. Then it can load balance traffic over both IPs.

DNS TTL ‘tricks’ are just that, they work ‘kinda’

Fatpipe?   Crazy expensive IMHO but I hear they work ok.

-Matt

--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710

E: matt...@crocker.com
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com



On Mar 3, 2014, at 8:11 PM, Eric A Louie  wrote:

> This may sound like dumb question, but... I'm used to asking those.
> 
> Here's the scenario
> 
> Another ISP, say AT&T, is the primary ISP for a customer.
> 
> Customer has publicly accessible servers in their office, using the AT&T 
> address space.
> 
> I am the customer's secondary ISP.
> 
> Now, if AT&T link fails, I can provide the customer outbound Internet access 
> fairly easily.  So they can surf and get to the Internet.
> 
> What about the publicly accessible servers that have AT&T addresses, though?
> 
> One thought I had was having them use Dynamic DNS service.  
> 
> Are there any other solutions, short of using BGP multihoming and having them 
> try to get their own ASN and IPv4 /24 block?
> 
> 
> It looks like a few router manufacturers have devices that might work, but it 
> looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the 
> primary ISP fails, the secondary ISP address is advertised.
> 

Re: ISP inbound failover without BGP

[Joe Greco]

> This may sound like dumb question, but... I'm used to asking those.=0A=0AHe=
> re's the scenario=0A=0AAnother ISP, say AT&T, is the primary ISP for a cust=
> omer.=0A=0ACustomer has publicly accessible servers in their office, using =
> the AT&T address space.=0A=0AI am the customer's secondary ISP.=0A=0ANow, i=
> f AT&T link fails, I can provide the customer outbound Internet access fair=
> ly easily.=A0 So they can surf and get to the Internet.=0A=0AWhat about the=
>  publicly accessible servers that have AT&T addresses, though?=0A=0AOne tho=
> ught I had was having them use Dynamic DNS service.=A0 =0A=0AAre there any =
> other solutions, short of using BGP multihoming and having them try to get =
> their own ASN and IPv4 /24 block?=0A=0A=0AIt looks like a few router manufa=
> cturers have devices that might work, but it looks like a short DNS TTL (or=
>  Dynamic DNS) needs to be set so when the primary ISP fails, the secondary =
> ISP address is advertised.

The usual solution is to get the public servers stuck in a colo that's
multihomed.

Most of the other solutions tend to be a bit dodgy.  If your gear is
sufficiently competent, you can hack up a solution with multiple 
addresses for each of the servers (one on each ISP) and then use a
short TTL to fail over, but this has more of "fail" than "fail over"
about it, because there are a bunch of issues that typically result.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

ISP inbound failover without BGP

[Eric A Louie]

This may sound like dumb question, but... I'm used to asking those.

Here's the scenario

Another ISP, say AT&T, is the primary ISP for a customer.

Customer has publicly accessible servers in their office, using the AT&T 
address space.

I am the customer's secondary ISP.

Now, if AT&T link fails, I can provide the customer outbound Internet access 
fairly easily.  So they can surf and get to the Internet.

What about the publicly accessible servers that have AT&T addresses, though?

One thought I had was having them use Dynamic DNS service.  

Are there any other solutions, short of using BGP multihoming and having them 
try to get their own ASN and IPv4 /24 block?


It looks like a few router manufacturers have devices that might work, but it 
looks like a short DNS TTL (or Dynamic DNS) needs to be set so when the primary 
ISP fails, the secondary ISP address is advertised.

re: DSLAM

[Nick Olsen]

Thanks to all that replied. Specially Eric @ Luma Optics.
  
 We've reached the cut off date for day. We're working on fixing the DSLAM 
we have on hand for use.
  
 I appreciate all the replies.
  
 Nick Olsen
Network Operations  (855) FLSPEED  x106

  


 From: "Nick Olsen" 
Sent: Monday, March 03, 2014 3:40 PM
To: nanog@nanog.org
Subject: DSLAM   
 Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) 
DSLAM. And I need it by tomorrow.

   Normal channels seem to be impacted by weather. Not to mention we've 
been pretty unhappy with our current models (Versa, And Planet).

   Any options? Unicast is acceptable.

   Nick Olsen
Network Operations   (855) FLSPEED  x106

Re: DSLAM

[Nick Olsen]

Cocoa, Florida. Sorry.
  
 Nick Olsen
Network Operations  (855) FLSPEED  x106

  


 From: valdis.kletni...@vt.edu
Sent: Monday, March 03, 2014 4:05 PM
To: n...@flhsi.com
Cc: nanog@nanog.org
Subject: Re: DSLAM   
On Mon, 03 Mar 2014 15:40:35 -0500, "Nick Olsen" said:
> Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) 
DSLAM.
> And I need it by tomorrow.

Bonus points if you tell us what continent/timezone you need this in. 
Getting
said device to 60 Hudson and to Nowhere Island, Tahiti are 2 very 
different
things...
 

Re: DSLAM

[Valdis . Kletnieks]

On Mon, 03 Mar 2014 15:40:35 -0500, "Nick Olsen" said:
> Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM.
> And I need it by tomorrow.

Bonus points if you tell us what continent/timezone you need this in.  Getting
said device to 60 Hudson and to Nowhere Island, Tahiti are 2 very different
things...


pgpT7CE7kCgFo.pgp
Description: PGP signature

DSLAM

[Nick Olsen]

Hey Guys, I need a 24 port ADSL (2, +, It's all the same in my book) DSLAM. 
And I need it by tomorrow.
  
 Normal channels seem to be impacted by weather. Not to mention we've been 
pretty unhappy with our current models (Versa, And Planet).
  
 Any options? Unicast is acceptable.
  
 Nick Olsen
Network Operations  (855) FLSPEED  x106

New AS Number Blocks allocated to the RIPE NCC

[Andrea Cima]

Dear Colleagues,

The RIPE NCC has received the following AS Number Blocks from the IANA 
in February 2014.


200192-201215
201216-202239

You may want to update your records accordingly.

Best regards,

Andrea Cima
Registration Services Manager
RIPE NCC

RE: Filter on IXP

[Vitkovský Adam]

> - the IXP participants keep their IRRDB information fully up-to-date
Geez anything else but the fully up-to-date IRRDB please. That just won't fly. 
That's why I said that an up to date IRRDB would have been a nice side effect 
of IXP filtering. 

> - the IXP operators put in mechanisms to stop both route-leakages 
> and incorrect IRRDB as-set additions from causing things to explode. 
Yes this is a valid point

I think the technicalities of how to implement this kind of filtering at the 
IXP equipment is out of scope for this discussion. 

Anyways I believe IXPs should not be responsible for this mess and that BCP38 
should be implemented by the participants of an IXP. 
As Saku Ytti mentioned several times Tier2 ISPs are in the best position for a 
successful BCP38 filtering at their network boundaries. 



adam
-Original Message-
From: Nick Hilliard [mailto:n...@foobar.org] 
Sent: Sunday, March 02, 2014 2:01 PM
To: Vitkovský Adam; Jérôme Nicolle; nanog@nanog.org
Subject: Re: Filter on IXP

On 02/03/2014 12:45, Vitkovský Adam wrote:
>> On the other hand, if a member provides transit, he will add its 
>> customer prefixes to RaDB / RIPEdb with appropriate route objects and 
>> the ACL will be updated accordingly. Shouldn't break there.
> 
> And that's a really nice side effect.

and it only works for leaf networks.  The moment your ixp supports larger 
networks, it will break things horribly.

It also assumes that:

- all your IXP members use route servers (not generally true)

- the IXP kit can filter layer 3 traffic on all supported port configurations 
(including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS 
(not generally true)

- the IXP port ASICs can handle large L2 access lists (not generally true)

- there is an automatic mechanism in place to take RS prefixes and installed 
them on edge L2 ports (troublesome to implement and maintain)

- there is a fail-safe mechanism to prevent this from causing breakage 
(difficult to implement)

- the IXP participants keep their IRRDB information fully up-to-date (not 
generally true)

- the IXP operators put in mechanisms to stop both route-leakages and incorrect 
IRRDB as-set additions from causing things to explode.

Last but not least:

- there is a mandate from the ixp community to get the IXP operators into the 
business of filtering layer 3 data (not generally the case)

There are many places where automated RPF makes a lot of sense.  An IXP is not 
one of them.

Nick