Re: What DNS Is Not

[Martin Hannigan]

On Mon, Nov 9, 2009 at 8:54 PM, Jorge Amodio  wrote:

> > A second issue is ownership.  I own my domain.
>
> Interesting statement, did you get a property title with your domain name ?
>
> Just curious
>
>
I'd take that question up with your IP attorney.

[ Summary: lots of lawyers and courts seem to think that domain names are
property ]

http://news.cnet.com/2100-1023-223597.html

http://www.domainnamenews.com/legal-issues/are-domain-names-considered-property-or-not/2917

http://newmedialaw.proskauer.com/2008/12/articles/domain-names/appellate-watch-are-domain-names-property-that-can-be-seized-under-state-forfeiture-laws/

http://www.law.duke.edu/journals/dltr/articles/2001dltr0032.html

http://pblog.bna.com/techlaw/2009/09/domain-name-deemed-tangible-property-web-pages-too-in-utah.html



-M<


-- 
Martin Hannigan   mar...@theicelandguy.com
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants

Re: What DNS Is Not

[Patrick W. Gilmore]

As someone just said to me privately: "I dislike the pedantic   
nerds pull sometimes."  (The "" is mine, not the original quote,  
so the Communications Committee doesn't send me a warning.)


On Nov 9, 2009, at 8:10 PM, bmann...@vacation.karoshi.com wrote:


good question - does patrick own the domain or has he paid for
the registration of mapping a string into a database? either? both?
neither?


The argument is silly at best.  I "own" the domain for the year I paid  
for it.  You call it "stewardship".  I won't argue if you want to play  
that game.


(BTW, I seriously considered putting the word "own" in quotes, but it  
would have required five extra keystrokes on the iPhone and I didn't  
think it was worth the effort.  Everyone - including Bill - knows  
exactly what I meant.  I mean, we're not newbies or idiots or    
Oh, right.  Teach me to be lazy.)


Let's use "stewardship", or any other string of characters that makes  
you happy.  The basic premise does not change.  My "stewardship" of ianai.net 
 (and it's not ".com" - one would think someone like you would  
realize the difference) is qualitatively different than the  
"stewardship" of the *TLDs.


For one thing, I have every right to point any hostname in my domain  
at any IP address I want.[*]  I could create a zone file with 36^N  
entries pointing them all at the same IP address.  No one would blink  
an eye.  It is not unexpected, inappropriate, or in any way "wrong".   
Putting "* IN A 1.2.3.4" has the exact same results for any hostname  
up to N letters.  Consider it shorthand.  Think of all the RAM I'll  
save!


Verisign putting a domain into .com that does not exist is not only  
unexpected, it is inappropriate, and Just Plain Wrong.  They do not  
"own" the zone, they have _no_right_ to put any entries in that zone  
that are not requested through the appropriate method.


If you do not (want to) see that, we will have to agree to disagree.


Also, you were so busy picking on my choice of words that you  
completely ignored the "choice" point.  Guess you couldn't come up  
with any feeble semantic arguments on that one?




not being able to resist the analogy


s/the/a really bad/


Its ok for me to practice indentured servitude in my home, yet when I
see my neighbor practicing it in their home - I call the cops on her
for practicing slavery.  and hope that no one notices me.


Honestly, Bill, don't you think that was a little pathetic?

Why don't you just compare me to Hitler and get it over with.

--
TTFN,
patrick

[*] I'm not going to explain things like "I shouldn't point hostnames  
at IP addresses I do not own" (er, "steward") because anyone who  
brings up that point is not worth talking to.  If your best counter  
argument is so stupid that anyone with more than three brain cells to  
rub together already knows, understands, and has gone right past, then  
please un-sub from NANOG, throw your laptop in a lake, and go get a  
job a HS drop out can do.  Because that's all you deserve.

Re: about interdomain multipath routing.

[Steven King]

Those are very good points Jack. We stopped using multihop for those
same reasons.

Jack Bates wrote:
> Matthew Petach wrote:
>>
>> I've outlawed the use of multihop eBGP for load-sharing here; when we
>> get
>> multiple links off the same router to a peer or upstream, they are
>> configured
>> with multipath.  We've got hundreds of BGP sessions across the network
>> configured with multipath on them.
>>
>
> Same here for my connections, though some of my customers are stuck
> with multihop eBGP in certain remote areas, but that's a completely
> different scenario (single link, but obsolete equipment) and out of my
> control.
>
> I much prefer multipath, especially given that the standard multihop
> config uses static routing and there are conditions that could cause
> the flap of the eBGP session during a single link outage. With
> Multipath, only the effected path goes down, as it should.
>
>
> Jack
>

-- 
Steve King

Network Engineer - Liquid Web, Inc.
Cisco Certified Network Associate
CompTIA Linux+ Certified Professional
CompTIA A+ Certified Professional

Re: about interdomain multipath routing.

[Kevin Loch]

Bin Dai wrote:

Hi:
These days, in the research, the interdomain multipath routing is pretty 
hot but i doubt its actually use in reality.
Does anyone tell me any use of interdomain multipath routing like 
multipath BGP in the real world?


"BGP multipath" is extremely common and used to load balance multiple
links to the same neighbor ASN.  As implemented by popular vendors it
requires most attributes (like as-path) to be identical.

Did you really mean this or something that uses different as-paths
in parallel?

- Kevin

Re: What DNS Is Not

[Jack Bates]

Andrew Cox wrote:
I think the issue is more that older apps would expect that if they can 
get a response then everything is ok.. perhaps this simply an outdated 
method and needs to be rethought.




The app is expecting a response of some kind. When it gets back bogus 
information that has it connecting to an IP that may not respond at all, 
the app will have to sit around waiting on a timeout.



Jack

Re: about interdomain multipath routing.

[Jack Bates]

Matthew Petach wrote:


I've outlawed the use of multihop eBGP for load-sharing here; when we get
multiple links off the same router to a peer or upstream, they are configured
with multipath.  We've got hundreds of BGP sessions across the network
configured with multipath on them.



Same here for my connections, though some of my customers are stuck with 
multihop eBGP in certain remote areas, but that's a completely different 
scenario (single link, but obsolete equipment) and out of my control.


I much prefer multipath, especially given that the standard multihop 
config uses static routing and there are conditions that could cause the 
flap of the eBGP session during a single link outage. With Multipath, 
only the effected path goes down, as it should.



Jack

Re: What DNS Is Not

[Andrew Cox]

Shouldn't such apps be checking the content they receive back from a 
server anyway?
Regardless of if they think they're getting to the right server (due to 
a bogus non-NXDOMAIN response) there should be some sort of validation 
in place.. otherwise you're open in any sort of man-in-the-middle attack.


I think the issue is more that older apps would expect that if they can 
get a response then everything is ok.. perhaps this simply an outdated 
method and needs to be rethought.


valdis.kletni...@vt.edu wrote:

On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said:

  

For instance, returning the IP address of your company's port-80 web
server instead of NXDOMAIN
not only breaks non-port-80-http applications



Remember this...

  

There is one special case for which I don't mind having DNS servers
lie about query results,
which is the phishing/malware protection service.  In that case, the
DNS response is redirecting you to
the IP address of a server that'll tell you
   "You really didn't want to visit PayPa11.com - it's a fake" or
   "You really didn't want to visit
dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware".
It's technically broken, but you really _didn't_ want to go there anyway.
It's a bit friendlier to administrators and security people if the
response page gives you the



Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.

  

Re: about interdomain multipath routing.

[Matthew Petach]

On Mon, Nov 9, 2009 at 5:56 PM, Bin Dai  wrote:
> Hi:
> These days, in the research, the interdomain multipath routing is pretty hot
> but i doubt its actually use in reality.
> Does anyone tell me any use of interdomain multipath routing like multipath
> BGP in the real world?

I've outlawed the use of multihop eBGP for load-sharing here; when we get
multiple links off the same router to a peer or upstream, they are configured
with multipath.  We've got hundreds of BGP sessions across the network
configured with multipath on them.

Matt

> Best,
> Daniel
>
>

Re: about interdomain multipath routing.

[Steven King]

We use eBGP multipath where I work. We usually get two or more
connections to each provider we have. Using multipath we are able to add
hardware redundancy with bandwidth balancing (to an extent) with this
method. There are some providers who will only allow multipath eBGP and
not even let you run multihop eBGP.

Bin Dai wrote:
> Hi:
> These days, in the research, the interdomain multipath routing is
> pretty hot but i doubt its actually use in reality.
> Does anyone tell me any use of interdomain multipath routing like
> multipath BGP in the real world?
>
> Best,
> Daniel
>

-- 
Steve King

Network Engineer - Liquid Web, Inc.
Cisco Certified Network Associate
CompTIA Linux+ Certified Professional
CompTIA A+ Certified Professional

Re: BGP Peer Selection Considerations

[Steve Bertrand]

a...@baklawasecrets.com wrote:
> Hi,
> 
> Thanks to everyone that replied to my post on failover configuration.  This 
> has lead me to this post.  I'm at a point now where I'm looking at 
> dual-homing with two BGP peers upstream.  Now what I am looking at doing is 
> as follows:
> 
> BGP Peer with Provider A who is multihomed to other providers.
> BGP Peer with Provider B who is not peered with provider A
> 
> I have an existing relationship with provider A, colo, cross connects etc.  
> Provider A has offered to get the PI space, ASN number, purchase the transit 
> for us with provider B and manage cross connects to provider B 

...I've likely missed something, but get the IP/ASN for yourself.

*ensure* that A & B will peer and provide transit for you.

> (they say they have a diverse "fibre backhaul network").  This is quite 
> attractive from a support and billing perspective.

...until you find out that the backhaul network is owned by Provider B,
or virtualized within an existing circuit to someplace else.

> Also suspect that provider A will be able to get more attractive pricing from 
> Provider B than I would be able to.

But at what cost?

> Am I missing things that I need to consider?

I think so. Long-term survival for one.

If you are budgeted for a diverse and redundant network, then I
recommend that you ensure one. My current understanding is that you can
negotiate terms with potential providers where there is competition.

Don't allow any of your ISPs to manage/dictate the use of your address
space. It will bite you, and cause undue frustration.

Steve

Re: What DNS Is Not

[Valdis . Kletnieks]

On Mon, 09 Nov 2009 15:04:06 PST, Bill Stewart said:

> For instance, returning the IP address of your company's port-80 web
> server instead of NXDOMAIN
> not only breaks non-port-80-http applications

Remember this...

> There is one special case for which I don't mind having DNS servers
> lie about query results,
> which is the phishing/malware protection service.  In that case, the
> DNS response is redirecting you to
> the IP address of a server that'll tell you
>"You really didn't want to visit PayPa11.com - it's a fake" or
>"You really didn't want to visit
> dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware".
> It's technically broken, but you really _didn't_ want to go there anyway.
> It's a bit friendlier to administrators and security people if the
> response page gives you the

Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.



pgpJo9eqAx0jr.pgp
Description: PGP signature

Re: What DNS Is Not

[bmanning]

On Mon, Nov 09, 2009 at 08:32:38PM -0500, Patrick W. Gilmore wrote:
> >   notbeing Paul, its rude of me to respond - yet you posted this
> >   to a public list ... so here goes.
> >
> >   Why do you find your behaviour in your domains acceptable and yet  
> >the
> >   same behaviour in others zones to be "a Bad Thing" and should be  
> >stopped?
> 
> Thought I was clear: Choice.
> 
> I believe there is a qualitative difference between a *TLD and a  
> second level domain.  /Especially/ for the GTLDs.

so you are making the arguement that as one navigates
the dns heirarchy, operational choices nearer the root
affect more people.

as may be. - yet we see ICANN under serious pressure to 
flatten out the root zone - to create the same amount of choice 
at the root as one might find in .COM

I will echo your original question to Paul, If its a "Bad Thing"
at the root or TLD, is it a "Bad Thing" in ianai.com?

I would say yes it is  -  looking for consistency in the stewardship
guidelines for any delegation.  personally, I take the path less
traveled and woudl suggest that a wildcard - at any delegation point -
can be a useful tool.

the unspoken compoent here is the diversity of expectation on what
one might do with a wildcard.  Is the wildcard in and of itself a
"Bad Thing" or has the wildcard been used in conjunction with other
heinous practice to unfairly exploit the gullible masses?

I don't think it fair to blame wildcards here - they are a symptom
but not the actual cause of "Bad Thing" - for that you need other
bits in play. 

--bill

about interdomain multipath routing.

[Bin Dai]

Hi:
These days, in the research, the interdomain multipath routing is  
pretty hot but i doubt its actually use in reality.
Does anyone tell me any use of interdomain multipath routing like  
multipath BGP in the real world?


Best,
Daniel

Re: What DNS Is Not

[Jorge Amodio]

> A second issue is ownership.  I own my domain.

Interesting statement, did you get a property title with your domain name ?

Just curious

Re: What DNS Is Not

[Patrick W. Gilmore]

Sent from my iPhone, please excuse any errors.


On Nov 9, 2009, at 19:32, bmann...@vacation.karoshi.com wrote:


On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote:

On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:


i loved the henry ford analogy -- but i think henry ford would have
said that
the automatic transmission was a huge step forward since he wanted
everybody
to have a car.  i can't think of anything that's happened in the
automobile
market that henry ford wouldn't've wished he'd thought of.

i knew that the "incoherent DNS" market would rise up on its hind
legs and
say all kinds of things in its defense against the ACM Queue
article, and i'm
not going to engage with every such speaker.


Paul: I completely agree with you that putting wildcards into the
roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.
Users have little (no?) choice on their TLDs.  Stopping those is a
Good Thing, IMHO.

However, I own a domain (or couple hundred :).  I have a wildcard on
my domain.  I point it where I want.  I feel not the slightest twinge
of guilt at this.  Do you think this is a Bad Thing, or should this  
be

allowed?



   notbeing Paul, its rude of me to respond - yet you posted this
   to a public list ... so here goes.

   Why do you find your behaviour in your domains acceptable and yet  
the
   same behaviour in others zones to be "a Bad Thing" and should be  
stopped?


Thought I was clear: Choice.

I believe there is a qualitative difference between a *TLD and a  
second level domain.  /Especially/ for the GTLDs.


I guess one could argue CCTLDs are different, but I disagree.  If you  
are in Germany, a .de is nearly as important as .com in the US.   
(Don't believe me?  Go to www.dtag.com.)


But no one has to use ianai.net.  Or aa.com.  Or 

A second issue is ownership.  I own my domain.  The .com domain is not  
owed by Verisign (despite what they may think :-).


Again, one could make an argument that the CCTLDs are different -  
"owned" by their host countries.  I personally disagree, but I admit  
that argument is less objective than the GTLDs.



Do you disagree wih my logic?   Do you believe Verisign should be  
allowed to do with .net the same things I should be allowed to do with ianai.net 
?


If so, please explain why.

If not, uh ... Why did you ask? =)

--
TTFN,
patrick
 

Re: What DNS Is Not

[bmanning]

On Mon, Nov 09, 2009 at 04:52:35PM -0800, Buhrmaster, Gary wrote:
> 
> 
> > -Original Message-
> > From: bmann...@vacation.karoshi.com
> > [mailto:bmann...@vacation.karoshi.com]
> > Sent: Monday, November 09, 2009 4:32 PM
> > To: Patrick W. Gilmore
> > Cc: NANOG list
> > Subject: Re: What DNS Is Not
> 
> ...
> 
> > notbeing Paul, its rude of me to respond - yet you posted this
> > to a public list ... so here goes.
> > 
> > Why do you find your behaviour in your domains acceptable and yet
> > the same behaviour in others zones to be "a Bad Thing" and should be
> > stopped?
> 
> Ok, devils advocate argument.  
> 
> Is there is a difference between being a domain "owner"
> (Patrick wanting to wildcard the domain he has paid for),
> and a domain "custodian" (Verisign for the .com example)
> in whether wildcards are ever acceptable in the DNS
> responses you provide?
> 

good question - does patrick own the domain or has he paid for
the registration of mapping a string into a database? either? both?
neither?

I'll lay out what I just did in private email a moment ago.

regardless of payment, ownership, or other considerations, we
all (who manage a delegation  point) are stewards of that delegation.
Patrick, as steward of a domain, feels certain behaviours are 
acceptable when he performs them within his stewardship, yet is
nonplused when another steward does the exact same thing in a different
delegation.

not being able to resist the analogy

Its ok for me to practice indentured servitude in my home, yet when I 
see my neighbor practicing it in their home - I call the cops on her
for practicing slavery.  and hope that no one notices me.

--bill

Re: What DNS Is Not

[David Andersen]

On Nov 9, 2009, at 7:52 PM, Buhrmaster, Gary wrote:



-Original Message-
From: bmann...@vacation.karoshi.com
[mailto:bmann...@vacation.karoshi.com]
Sent: Monday, November 09, 2009 4:32 PM
To: Patrick W. Gilmore
Cc: NANOG list
Subject: Re: What DNS Is Not


...


notbeing Paul, its rude of me to respond - yet you posted this
to a public list ... so here goes.

Why do you find your behaviour in your domains acceptable and yet
   the same behaviour in others zones to be "a Bad Thing" and  
should be

   stopped?


Ok, devils advocate argument.

Is there is a difference between being a domain "owner"
(Patrick wanting to wildcard the domain he has paid for),
and a domain "custodian" (Verisign for the .com example)
in whether wildcards are ever acceptable in the DNS
responses you provide?


I think this is spot on.

In particular:  Patrick, for some domains at least, can implement a  
wildcard with the full cooperation and agreement of all of the  
customers of sub-zones within his domain.  Particularly if he doesn't  
resell any subdomains within it.  Verisign cannot. [1]


[1]  As a customer of .com, my own disagreement on this is sufficient  
to prove that they don't have unanimous agreement. :-)


  -Dave

Re: What DNS Is Not

[Edward Lewis]

At 0:32 + 11/10/09, bmann...@vacation.karoshi.com wrote:


not being Paul, its rude of me to respond - yet you posted this
to a public list ... so here goes.

Why do you find your behaviour in your domains acceptable and yet the
same behaviour in others zones to be "a Bad Thing"...


Not being anyone who has posted on this thread on a public list...

I agree that the rules for what is acceptable in the operations of 
DNS zones vary from zone to zone.  This is because of the different 
relationships between the zone administrator and the entities 
represented in the zone and the different relationships between the 
zone administrator and the relying parties.


(I"m just going to pick on one "reason.")

For the root zone or aTLD (which themselves have differences) the 
relationships tend to be global, multilingual, etc.  Stability and 
coherence here are vital for operations, because as you know being in 
"operations" really means "handling outages." Once a problem pops up, 
it might take a while (hours, days) to go from report to root cause 
analysis to long-term fix.  If the root and TLDs have lots of "bells 
and whistles" then, well, this is hard, so the root and TLDs are kept 
simple.


For a zone "lower in the stack" assumptions are different.  Generally 
speaking, the zone represents a single entity (a government agency, 
store, school) who will have a varying degree of active management of 
what is in the zone.  They may even be able to "roll back" to some 
point in time and see what is in the zone.  On-the-fly response 
generation is even acceptable because they can see what mislead 
someone, etc. (if they zone is properly run).  And by on-the-fly I am 
including wildcards generated answers, calculated answers or answers 
based on source of the request, etc., and other demographics or 
current load measures.


As far as relying parties, think about "who do I call?" when I can't 
get through.  They have two obvious choices - their ISP or the 
organization they want to reach.  Calls will end up with the ISP if 
the issue is high up in the zone, calls might get to the organization 
if the problems are lower in the tree.   (Because perhaps they got to 
the main web page but not to the department page.)


This is just one reason why it's reasonable to manage different DNS 
zones differently, why the "rules" don't apply the same everywhere. 
There are many other reasons.  But this is a public list.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

RE: What DNS Is Not

[Buhrmaster, Gary]

> -Original Message-
> From: bmann...@vacation.karoshi.com
> [mailto:bmann...@vacation.karoshi.com]
> Sent: Monday, November 09, 2009 4:32 PM
> To: Patrick W. Gilmore
> Cc: NANOG list
> Subject: Re: What DNS Is Not

...

>   notbeing Paul, its rude of me to respond - yet you posted this
>   to a public list ... so here goes.
> 
>   Why do you find your behaviour in your domains acceptable and yet
> the same behaviour in others zones to be "a Bad Thing" and should be
> stopped?

Ok, devils advocate argument.  

Is there is a difference between being a domain "owner"
(Patrick wanting to wildcard the domain he has paid for),
and a domain "custodian" (Verisign for the .com example)
in whether wildcards are ever acceptable in the DNS
responses you provide?

Re: What DNS Is Not

[bmanning]

On Mon, Nov 09, 2009 at 06:24:52PM -0500, Patrick W. Gilmore wrote:
> On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
> 
> >i loved the henry ford analogy -- but i think henry ford would have  
> >said that
> >the automatic transmission was a huge step forward since he wanted  
> >everybody
> >to have a car.  i can't think of anything that's happened in the  
> >automobile
> >market that henry ford wouldn't've wished he'd thought of.
> >
> >i knew that the "incoherent DNS" market would rise up on its hind  
> >legs and
> >say all kinds of things in its defense against the ACM Queue  
> >article, and i'm
> >not going to engage with every such speaker.
> 
> Paul: I completely agree with you that putting wildcards into the  
> roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.   
> Users have little (no?) choice on their TLDs.  Stopping those is a  
> Good Thing, IMHO.
> 
> However, I own a domain (or couple hundred :).  I have a wildcard on  
> my domain.  I point it where I want.  I feel not the slightest twinge  
> of guilt at this.  Do you think this is a Bad Thing, or should this be  
> allowed?
> 

notbeing Paul, its rude of me to respond - yet you posted this
to a public list ... so here goes.

Why do you find your behaviour in your domains acceptable and yet the
same behaviour in others zones to be "a Bad Thing" and should be 
stopped?


--bill

Re: What DNS Is Not

[Andrew Cox]

David Ulevitch wrote:

On 11/9/09 6:06 PM, Alex Balashov wrote:


Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why
this could possibly be controversial.


Because some people want the ability and choice to block DNS responses 
they don't like; just as they have the ability and choice to reject 
email they don't want to accept.


When the conficker worms phones home to one of the 50,000 potential 
domains names it computes each day, there are a lot of IT folks out 
there that wish their local resolver would simply reject those DNS 
requests so that infected machines in their network fail to phone home.
Dealing with 10k~ uni students who like to spread new viruses faster 
than STD's I often make light of the fact that we can use OpenDNS to a) 
keep tabs on who's infected at what sites and b) prevent them from 
possibly doing more damage by phoning home with info or to collect 
instructions.


To use your language, I don't understand how or why this could 
possibly be controversial.  --  Apparently it is.


-David

It's as David says, there are a lot of us who would rather have the 
choice than not have it.
If that's not acceptable to some then that's their decision however as a 
part of our network this DNS 'tomfoolery' is something that both we and 
the end user see benefits from so I don't see it going away anytime soon.


Regards,
Andrew Cox
AccessPlus HNA

Re: What DNS Is Not

[Kevin Oberman]

> From: "Patrick W. Gilmore" 
> Date: Mon, 9 Nov 2009 18:24:52 -0500
> 
> On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:
> 
> > i loved the henry ford analogy -- but i think henry ford would have  
> > said that
> > the automatic transmission was a huge step forward since he wanted  
> > everybody
> > to have a car.  i can't think of anything that's happened in the  
> > automobile
> > market that henry ford wouldn't've wished he'd thought of.
> >
> > i knew that the "incoherent DNS" market would rise up on its hind  
> > legs and
> > say all kinds of things in its defense against the ACM Queue  
> > article, and i'm
> > not going to engage with every such speaker.
> 
> Paul: I completely agree with you that putting wildcards into the  
> roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.   
> Users have little (no?) choice on their TLDs.  Stopping those is a  
> Good Thing, IMHO.
> 
> However, I own a domain (or couple hundred :).  I have a wildcard on  
> my domain.  I point it where I want.  I feel not the slightest twinge  
> of guilt at this.  Do you think this is a Bad Thing, or should this be  
> allowed?
> 
> Also, why are you upset at OpenDNS.  People _intentionally_ select to  
> use OpenDNS, which is clear in its terms of service, and even allows  
> users to turn off the bits that annoy you.  Exactly what is the issue?
> 
> And lastly, DNS is not "truth".  DNS is the Domain Name System, it is  
> what people configure it to be.  You yourself have argued things like  
> responding with "192.0.2.1"  for DNSBLs that are being shut down.   
> That is clearly NOT "truth".

I find it mildly amusing that my first contact with Paul was about 25
years ago when he was at DEC and I objected to his use of a wildcard for
dec.com. The situations are not parallel and the Internet was a
very different animal in those days (and DEC was mostly DECnet), but
still I managed to maintain a full set of MX records for all of our
DECnet systems.

That said, I really, really get annoyed by the abuse of the DNS system.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Re: What DNS Is Not

[Jack Bates]

Alex Balashov wrote:
When I write applications that make DNS queries, I expect the request to 
turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but 
especially non-HTTP.




Actually, the one I hate is when they return NXDOMAIN for any RR type 
other than A, breaking DNS. Most common is  to return NXDOMAIN, 
which immediately has the effect of breaking the ability to fallback to 
A (why query for another RR, when the domain doesn't exist?). Several 
high end load balancers have the ability to do this according to the 
content providers I have addressed the matter with.


As a side note, any IPv6 capable stack which has determined there is 
IPv6 connectivity (through 6to4, native, teredo, etc) cannot access 
these sites. For an example (an ongoing issue) see www.txu.com. Responds 
to A, gives NXDOMAIN to .


I will not shame the high profile websites that have fixed their 
loadbalancers/DNS servers, but everyone on this list knows and has 
probably used them.



Jack

Re: What DNS Is Not

[Patrick W. Gilmore]

On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:

i loved the henry ford analogy -- but i think henry ford would have  
said that
the automatic transmission was a huge step forward since he wanted  
everybody
to have a car.  i can't think of anything that's happened in the  
automobile

market that henry ford wouldn't've wished he'd thought of.

i knew that the "incoherent DNS" market would rise up on its hind  
legs and
say all kinds of things in its defense against the ACM Queue  
article, and i'm

not going to engage with every such speaker.


Paul: I completely agree with you that putting wildcards into the  
roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.   
Users have little (no?) choice on their TLDs.  Stopping those is a  
Good Thing, IMHO.


However, I own a domain (or couple hundred :).  I have a wildcard on  
my domain.  I point it where I want.  I feel not the slightest twinge  
of guilt at this.  Do you think this is a Bad Thing, or should this be  
allowed?


Also, why are you upset at OpenDNS.  People _intentionally_ select to  
use OpenDNS, which is clear in its terms of service, and even allows  
users to turn off the bits that annoy you.  Exactly what is the issue?


And lastly, DNS is not "truth".  DNS is the Domain Name System, it is  
what people configure it to be.  You yourself have argued things like  
responding with "192.0.2.1"  for DNSBLs that are being shut down.   
That is clearly NOT "truth".


--
TTFN,
patrick

P.S. Yes, I am intentionally ignoring the CDN side of things.  Find me  
in private, preferably with a shot of single-malt, if you want my  
opinion.




there three more-specific replies below.

Dave Temkin  writes:


Alex Balashov wrote:


For example, perhaps in the case of CDNs geographic optimisation  
should

be in the province of routing (e.g. anycast) and not DNS?


In most cases it already is.  He completely fails to address the  
concept
of Anycast DNS and assumes people are using statically mapped  
resolvers.


"anycast DNS" appears to mean different things to different people.   
i didn't
mention it because to me anycast dns is a bgp level construct  
whereby the
same (coherent) answer is available from many servers having the  
same IP
address but not actually being the same server.  see for example how  
several
root name servers are distributed.  .   
if you
are using "anycast DNS" to mean carefully crafted (noncoherent)  
responses
from a similarly distributed/advertised set of servers, then i did  
address

your topic in the ACM Queue article.

David Andersen  writes:


This myth ... was debunked years ago:

"DNS Performance and the Effectiveness of Caching"
Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris
http://pdos.csail.mit.edu/papers/dns:ton.pdf


my reason for completely dismissing that paper at the time it came  
out was
that it tried to predict the system level impact of DNS caching  
while only
looking at the resolver side and only from one client population  
having a
small and uniform user base.  show me a "trace driven simulation" of  
the
whole system, that takes into account significant authority servers  
(which

would include root, tld, and amazon and google) as well as significant
caching servers (which would not include MIT's or any university's but
which would definitely include comcast's and cox's and att's), and  
i'll
read it with high hopes.  note that ISC SIE (see http://sie.isc.org/  
may
yet grow into a possible data source for this kind of study, which  
is one

of the reasons we created it.)

Simon Lyall  writes:


I heard some anti-spam people use DNS to distribute big databases of
information. I bet Vixie would have nasty things to say to the guy  
who

first thought that up.


someone made this same comment in the slashdot thread.  my response  
there
and here is: the MAPS RBL has always delivered coherent responses  
where the
answer is an expressed fact, not kerned in any way based on the  
identity of
the querier.  perhaps my language in the ACM Queue article was  
imprecise
("delivering facts rather than policy") and i should have stuck with  
the
longer formulation ("incoherent responses crafted based on the  
identity of

the querier rather than on the authoritative data").
--
Paul Vixie
KI6YSY

Re: What DNS Is Not

[David Ulevitch]

On 11/9/09 6:06 PM, Alex Balashov wrote:


Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why
this could possibly be controversial.


Because some people want the ability and choice to block DNS responses 
they don't like; just as they have the ability and choice to reject 
email they don't want to accept.


When the conficker worms phones home to one of the 50,000 potential 
domains names it computes each day, there are a lot of IT folks out 
there that wish their local resolver would simply reject those DNS 
requests so that infected machines in their network fail to phone home.


To use your language, I don't understand how or why this could possibly 
be controversial.  --  Apparently it is.


-David

Re: What DNS Is Not

[Alex Balashov]

When I write applications that make DNS queries, I expect the request 
to turn NXDOMAIN if the host does not exist - HTTP as well as 
non-HTTP, but especially non-HTTP.


Anything else is COMPLETELY UNACCEPTABLE.  I don't understand how or 
why this could possibly be controversial.


--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

Re: What DNS Is Not

[Bill Stewart]

Hi, Paul - I share your dislike of DNS services that break the DNS
model for profit in ways that break applications.
For instance, returning the IP address of your company's port-80 web
server instead of NXDOMAIN
not only breaks non-port-80-http applications, it also breaks the
behaviour that browsers such as
IE and Firefox expect, which is that if a domain isn't found, they'll
do something that the user chooses,
such as sending another query to the user's favorite search engine.

There is one special case for which I don't mind having DNS servers
lie about query results,
which is the phishing/malware protection service.  In that case, the
DNS response is redirecting you to
the IP address of a server that'll tell you
   "You really didn't want to visit PayPa11.com - it's a fake" or
   "You really didn't want to visit
dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware".
It's technically broken, but you really _didn't_ want to go there anyway.
It's a bit friendlier to administrators and security people if the
response page gives you the
IP address that the query would have otherwise returned, though
obviously you don't want it to be
a clickable hyperlink.

However, I disagree with your objections to CDN, and load balancers in
general - returning the
address of the server that example.com thinks will give you the best
performance is reasonable.
(I'll leave the question of whether DNS queries are any good at
determining that to the vendors.)
Maintaining a cachable ns.example.com record in the process is
friendly to everybody;
maintaining cachable A records is less important.
If reality is changing rapidly, then the directory that points to the
reality can reasonably change also.


On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie  wrote:
> i loved the henry ford analogy -- but i think henry ford would have said that
> the automatic transmission was a huge step forward since he wanted everybody
> to have a car.  i can't think of anything that's happened in the automobile
> market that henry ford wouldn't've wished he'd thought of.

Well, there's the built-in GPS navigation system that tells you to go
drive off the dock into the water,
because it wasn't smart enough to know that the route the map database
showed in dotted lines was a ferryboat...

-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

Re: AT&T Admin

[Seth Mattinen]

Aaron Wendel wrote:
> Ok, guess we'll see if this really works or not.
> 
> Would an AT&T mail admin contact me offlist?  I have an issue I need to
> start moving up the chain since I'm getting nowhere fast with normal
> channels.
> 

FYI replying and changing the subject keeps your message under the same
thread. You should start a new message.

~Seth

Re: What DNS Is Not

[Paul Vixie]

i loved the henry ford analogy -- but i think henry ford would have said that
the automatic transmission was a huge step forward since he wanted everybody
to have a car.  i can't think of anything that's happened in the automobile
market that henry ford wouldn't've wished he'd thought of.

i knew that the "incoherent DNS" market would rise up on its hind legs and
say all kinds of things in its defense against the ACM Queue article, and i'm
not going to engage with every such speaker.

there three more-specific replies below.

Dave Temkin  writes:

> Alex Balashov wrote:
>>
>> For example, perhaps in the case of CDNs geographic optimisation should
>> be in the province of routing (e.g. anycast) and not DNS?
>
> In most cases it already is.  He completely fails to address the concept
> of Anycast DNS and assumes people are using statically mapped resolvers.

"anycast DNS" appears to mean different things to different people.  i didn't
mention it because to me anycast dns is a bgp level construct whereby the
same (coherent) answer is available from many servers having the same IP
address but not actually being the same server.  see for example how several
root name servers are distributed.  .  if you
are using "anycast DNS" to mean carefully crafted (noncoherent) responses
from a similarly distributed/advertised set of servers, then i did address
your topic in the ACM Queue article.

David Andersen  writes:

> This myth ... was debunked years ago:
>
> "DNS Performance and the Effectiveness of Caching"
> Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris
> http://pdos.csail.mit.edu/papers/dns:ton.pdf

my reason for completely dismissing that paper at the time it came out was
that it tried to predict the system level impact of DNS caching while only
looking at the resolver side and only from one client population having a
small and uniform user base.  show me a "trace driven simulation" of the
whole system, that takes into account significant authority servers (which
would include root, tld, and amazon and google) as well as significant
caching servers (which would not include MIT's or any university's but
which would definitely include comcast's and cox's and att's), and i'll
read it with high hopes.  note that ISC SIE (see http://sie.isc.org/ may
yet grow into a possible data source for this kind of study, which is one
of the reasons we created it.)

Simon Lyall  writes:

> I heard some anti-spam people use DNS to distribute big databases of
> information. I bet Vixie would have nasty things to say to the guy who
> first thought that up.

someone made this same comment in the slashdot thread.  my response there
and here is: the MAPS RBL has always delivered coherent responses where the
answer is an expressed fact, not kerned in any way based on the identity of
the querier.  perhaps my language in the ACM Queue article was imprecise 
("delivering facts rather than policy") and i should have stuck with the
longer formulation ("incoherent responses crafted based on the identity of
the querier rather than on the authoritative data").
-- 
Paul Vixie
KI6YSY

AT&T Admin

[Aaron Wendel]

Ok, guess we'll see if this really works or not.

Would an AT&T mail admin contact me offlist?  I have an issue I need to
start moving up the chain since I'm getting nowhere fast with normal
channels.

Thanks,

Aaron

Re: BGP Peer Selection Considerations

[Seth Mattinen]

William Herrin wrote:
> 
> Be aware that provider A's diverse network for provider A's service is
> the same diverse network they'll use to connect you to provider B. As
> a result, many or most of the outages which impact provider A will
> also impact your connectivity to provider B, defeating the central
> purpose of having a provider B.
> 


I'll just add to the OP: you want them independent *to you* not
internally diverse between themselves. How would that help your site be
independent? I'm sure the billing/support sounds attractive (and they
get to upsell you), but you won't gain provider independence, only a
larger bill.

~Seth

Re: BGP Peer Selection Considerations

[Joe Greco]

> Don't let them cross connect over their network. Bring it in to your
> site separate from A, otherwise there's no point in the multihoming
> exercise.

s/no point/less benefit/

... 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: Failover how much complexity will it add?

[Joe Greco]

> Most purpose-built routing "appliances" use ternary content 
> addressable memory (TCAM) in order to accomplish deterministic, 
> hardware-based, longest-prefix lookups in large routing tables, 
> such as a full Internet BGP feed. TCAM is used to replace 
> software-based table lookup algorithms which have been 
> empirically shown to lack scalability as the number of routes 
> in the routing table increases, and as the line rate in/out of 
> the routers increases. Current TCAM hardware-based routing 
> engines scale to 10 Gbps, and beyond. Much research has been 
> done in this area in the last 15 years. 
> 
> I don't think general purpose BSD/Linux systems meet the 
> scalability requirement for deterministic network design. 
> Nothing political about that. 

Whoa.  How'd you manage to get it completely inverted?

It's the TCAM based platforms that are a scaling problem.  You have
to do a forklift upgrade of them every now and then in order to 
assure yourself of being able to continue to hold a full table.

Put another way:  

Software-based lookup tables do tend to perform more slowly as the
number of routes grows.  However, a Linux or BSD router that was
operational in 1999 will still be functional today, able to route
a full table today.  It will suffer a mild degradation in 
forwarding capabilities as the route table grows, but this is mild.

Hardware-based lookup tables have a really bad failure mode:  they
fill.  When they fill, generally speaking, parts of the Internet
may vanish.  It is great to be able to forward at line speed up to
the table capacity of the box, but you can do the same thing on a
software-based platform... to get line rate simply means you need
to ensure you've got sufficient excess resources.

Software-based platforms are finicky at high PPS rates, but these
days it'd be kinda hard to come up with a platform that *couldn't*
route 1Gbps.  We're talking a fraction of that for this guy who has
a few 100Mbps links.

Now, of course, if he plans to scale that few 100Mbps links up to a
few 10Gbps links in the next few years, then there is definitely a
question about the suitability of a software-based platform, but it
is also the case that any inexpensive TCAM-based platform that might
be selected will also need to be upgraded ... at significant 
expense.

I would have thought that this lesson would still be fresh in the
minds of people, as we just passed 256K routes a little while ago
and broke a whole bunch of Catalyst 6500/7600 SUP720-3B's (etc).
I guess the pain isn't as memorable as I thought.

... 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: BGP Peer Selection Considerations

[William Herrin]

On Mon, Nov 9, 2009 at 12:40 PM,   wrote:
> I have an existing relationship with provider A, colo, cross connects
> etc.  Provider A has offered to get the PI space, ASN number,
> purchase the transit for us with provider B and manage cross
> connects to provider B (they say they have a diverse "fibre
> backhaul network").  This is quite attractive from a support
> and billing perspective.  Also suspect that provider A will be
> able to get more attractive pricing from Provider B than I
> would be able to.
>
> Am I missing things that I need to consider?

What happens when provider A is bought by provider C and you want to
dump provider C but keep provider B? You'll have created a conflict of
interest for provider B in any negotiation you have with them.

Be aware that provider A's diverse network for provider A's service is
the same diverse network they'll use to connect you to provider B. As
a result, many or most of the outages which impact provider A will
also impact your connectivity to provider B, defeating the central
purpose of having a provider B.

Regards,
Bill Herrin


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

Re: BGP Peer Selection Considerations

[Seth Mattinen]

a...@baklawasecrets.com wrote:
> Hi,
> 
> Thanks to everyone that replied to my post on failover configuration.  This 
> has lead me to this post.  I'm at a point now where I'm looking at 
> dual-homing with two BGP peers upstream.  Now what I am looking at doing is 
> as follows:
> 
> BGP Peer with Provider A who is multihomed to other providers.
> BGP Peer with Provider B who is not peered with provider A
> 
> I have an existing relationship with provider A, colo, cross connects etc.  
> Provider A has offered to get the PI space, ASN number, purchase the transit 
> for us with provider B and manage cross connects to provider B (they say they 
> have a diverse "fibre backhaul network").  This is quite attractive from a 
> support and billing perspective.  Also suspect that provider A will be able 
> to get more attractive pricing from Provider B than I would be able to.
> 
> Am I missing things that I need to consider?
> 

Don't let them cross connect over their network. Bring it in to your
site separate from A, otherwise there's no point in the multihoming
exercise.

~Seth

RE: Failover how much complexity will it add?

[Holmes,David A]

Most purpose-built routing "appliances" use ternary content addressable memory 
(TCAM) in order to accomplish deterministic, hardware-based, longest-prefix 
lookups in large routing tables, such as a full Internet BGP feed. TCAM is used 
to replace software-based table lookup algorithms which have been empirically 
shown to lack scalability as the number of routes in the routing table 
increases, and as the line rate in/out of the routers increases. Current TCAM 
hardware-based routing engines scale to 10 Gbps, and beyond. Much research has 
been done in this area in the last 15 years. 

I don't think general purpose BSD/Linux systems meet the scalability 
requirement for deterministic network design. Nothing political about that. 

-Original Message-
From: a...@baklawasecrets.com [mailto:a...@baklawasecrets.com] 
Sent: Monday, November 09, 2009 8:36 AM
To: nanog@nanog.org
Subject: Re: Failover how much complexity will it add?

Hi Joe,

I agree with most of what you say below regarding linux sysadmin, BSD etc.  I'm 
quite happy and actually would prefer building a linux solution on our own 
hardware.  However, politically I think this is going to be difficult.  I just 
feel that they will be more comfortable with embedded network boxes as a pose 
to a linux solution.  I guess what I'm saying is this is partially a political 
thing.

Adel




On Mon   3:20 PM , Joe Greco  wrote:

> > 
> > Thanks,
> > 
> > I've taken your advice and decided to reconsider my requirement for a
> full 
> > routing table. I believe I'm being greedy and a partial table will be 
> > sufficient. With regards to Linux/BSD, its not the CLI of quagga that
> will 
> > be an issue, rather the sysadmin and lack of supporting infrastructure
> for 
> > Linux boxes within the organisation. So things like package management,
> 
> 
> You don't need to run Apache on your router.
> 
> > syslog servers, 
> 
> If you didn't have syslog servers for the Cisco, you don't need one for 
> the Quagga.
> 
> > monitoring,
> 
> If you didn't monitor the Cisco, you don't need to monitor the Quagga.
> 
> > understanding of security issues etc.
> 
> What security issues?
> 
> The thing is, people get all tied up over this idea that it is some major
> ongoing burden to support a Linux based device.
> 
> I have a shocker for you. The CPE your residential broadband relies on
> may
> well run Linux, and you didn't even know it. The wifi router you use may
> run
> Linux. There are thousands of embedded uses for Linux. I highly doubt
> that
> the average TiVo user has a degree in Linux. Many different things you
> use
> in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly
> without any
> need of someone to handhold them on security issues.
> 
> Of course, security issues do come up. But they do with Cisco as well. 
> 
> A proper Linux router doesn't have ports open, aside from bgp and ssh,
> and
> those can be firewalled appropriately. This makes it very difficult to
> have
> any meaningful "security problems" relating to the platform...
> 
> You can expect the occasional issue. Just like anything else. But trying
> to
> compare it to security issues on a general Linux platform is only
> meaningful
> if you're trying to argue against the solution.
> 
> (I'm a BSD guy myself, but I don't see any reason for undue Linux
> paranoia)
> 
> > I don't want to leave them with a linux/bsd solution that they won't be
> 
> > able to maintain/manage effectively when I am gone.
> 
> If they're unable to maintain something as straightforward as BSD or
> Linux 
> when you're gone, this raises alarm bells as to whether or not BGP is 
> really suited for them. BGP is *much* more arcane, relatively speaking.
> You can go to your local bookstore and pick up a ton of Linux or BSD
> sysadm
> books, but you'll be lucky to find a book on BGP.
> 
> > Thanks for your comments. Look forward to hearing which solutions come 
> > back into the mix having dropped the full routing table requirement.
> 
> There's a whole plethora of BGP-capable gear that becomes possible once 
> you make that call. Cisco and Juniper both make good gear. A variety
> of other mfrs do as well. Something as old as an Ascend GRF 400 (fast
> ethernet, line speed, 150K routes, ~1998?) is perfectly capable of
> dealing
> with the load, though I mention this primarily to make the point that
> there
> is a lot of equipment within the last decade that can support this.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> [1]
> "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.
> 
> 
> 
> Links:
> --
> [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
> 
> 

Re: Failover how much complexity will it add?

[Charles Wyble]

On Nov 8, 2009, at 2:39 PM, a...@baklawasecrets.com wrote:



So if my requirements are as follows:

- BGP router capable of holding full Internet routing table.   
(whether I go for partial or full, I think I want something with  
full capability).


- Capable of pushing 100meg plus of mixed traffic.

What are my options?  I want to exclude openbsd, or linux with quagga.


Why is that?

BGP Peer Selection Considerations

[adel]

Hi,

Thanks to everyone that replied to my post on failover configuration.  This has 
lead me to this post.  I'm at a point now where I'm looking at dual-homing with 
two BGP peers upstream.  Now what I am looking at doing is as follows:

BGP Peer with Provider A who is multihomed to other providers.
BGP Peer with Provider B who is not peered with provider A

I have an existing relationship with provider A, colo, cross connects etc.  
Provider A has offered to get the PI space, ASN number, purchase the transit 
for us with provider B and manage cross connects to provider B (they say they 
have a diverse "fibre backhaul network").  This is quite attractive from a 
support and billing perspective.  Also suspect that provider A will be able to 
get more attractive pricing from Provider B than I would be able to.

Am I missing things that I need to consider?

Re: Failover how much complexity will it add?

[Valdis . Kletnieks]

On Mon, 09 Nov 2009 13:39:34 GMT, Adam Armstrong said:
> Sure, if you want to hand over your entire profit margin to a 3rd party. 
> Do you really want to give away the keys to your business, and rely 
> entirely upon a third party organisation? Better to acquire the skills 
> which are vital to your organisation yourself.

Umm.. You did that *anyhow* the instant you paid somebody else to run the
cables to your location rather than dig your own ditches.  Similarly for
electricity and everything else you don't create yourself.

> > NOTE: I am not an employee, or paid affiliate of packet exchange... I
> > have used them for services and am promoting them due to my own good
> > experiences with their services.
> >   
> I used to work for them. Then as now, I honestly can see little purpose 
> in their productset.

There's little purpose if you're an ISP that's supposed to be good at BGP
yourself.  If however, your business is running a /24 worth of webservers that
sells your company's product, and Best Practices says you should be multi-homed
but the in-house skill set runs more to Apache than BGP, a well-designed BGP
appliance can be a ghodsend.

(I admit I missed the OP's statement of what business line they were in).



pgpNkXzugtzja.pgp
Description: PGP signature

Re: Failover how much complexity will it add?

[Seth Mattinen]

a...@baklawasecrets.com wrote:
> Actually thinking about this, I still need to understand the implications of 
> not taking a full routing table to my setup.  So what is the likely impact 
> going to be if I take partial instead of full routing table.  Would 
> appreciate any feedback on this.  My organisation is only looking at using 
> BGP as a means of failover between two separate upstream ISPs.  We are not an 
> ISP.
> 


Some Cisco L3 switches should support this fine. A 3560 or 3750 can
speak BGP and route at line rate as long as your total number of routes
will fit in its TCAM space. Ask your upstreams how big a partial feed
from them is.

 "desktop routing" template:
 The selected template optimizes the resources in
 the switch to support this level of features for
 8 routed interfaces and 1024 VLANs.

  number of unicast mac addresses:  3K
  number of IPv4 IGMP groups + multicast routes:1K
  number of IPv4 unicast routes:11K
number of directly-connected IPv4 hosts:3K
number of indirect IPv4 routes: 8K
  number of IPv4 policy based routing aces: 0.5K
  number of IPv4/MAC qos aces:  0.5K
  number of IPv4/MAC security aces: 1K


If you ever need IPv6 it gets smaller:

  number of unicast mac addresses:  2K
  number of IPv4 IGMP groups + multicast routes:1K
  number of IPv4 unicast routes:3K
number of directly-connected IPv4 hosts:2K
number of indirect IPv4 routes: 1K
  number of IPv6 multicast groups:  1.125k
  number of directly-connected IPv6 addresses:  2K
  number of indirect IPv6 unicast routes:   1K
  number of IPv4 policy based routing aces: 0
  number of IPv4/MAC qos aces:  0.5K
  number of IPv4/MAC security aces: 1K
  number of IPv6 policy based routing aces: 0
  number of IPv6 qos aces:  0.625k
  number of IPv6 security aces: 0.5K


Anything in Cisco land that can hold two full tables in hardware and can
do line rate is going to be hideously expensive.

~Seth

Cisco Security Advisory: Transport Layer Security Renegotiation Vulnerability

[Cisco Systems Product Security Incident Response Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cisco Security Advisory: Transport Layer Security Renegotiation
Vulnerability

Advisory ID: cisco-sa-20091109-tls

http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml

Revision 1.0

For Public Release 2009 November 9 1600 UTC (GMT)

Summary
===

An industry-wide vulnerability exists in the Transport Layer Security
(TLS) protocol that could impact any Cisco product that uses any version
of TLS and SSL. The vulnerability exists in how the protocol handles
session renegotiation and exposes users to a potential man-in-the-middle
attack.

This advisory is posted at
http://www.cisco.com/warp/public/707/cisco-sa-20091109-tls.shtml.

Affected Products
=

Cisco is currently evaluating products for possible exposure to these
TLS issues. Products will only be listed in the Vulnerable Products or
Products Confirmed Not Vulnerable sections of this advisory when a final
determination about product exposure is made. Products that are not
listed in either of these two sections are still being evaluated.

Vulnerable Products
- ---

This section will be updated when more information is available.

Products Confirmed Not Vulnerable
- -

The following products are confirmed not vulnerable:

  * Cisco AnyConnect VPN Client

This section will be updated when more information is available.

Details
===

TLS and its predecessor, SSL, are cryptographic protocols that provide
security for communications over IP data networks such as the Internet.
An industry-wide vulnerability exists in the TLS protocol that could
impact any Cisco product that uses any version of TLS and SSL. The
vulnerability exists in how the protocol handles session renegotiation
and exposes users to a potential man-in-the-middle attack.

The following Cisco Bug IDs are being used to track potential exposure
to the SSL and TLS issues. The bugs listed below do not confirm
that a product is vulnerable, but rather that the product is under
investigation by the appropriate product teams.

Registered Cisco customers can view these bugs via Cisco's Bug Toolkit:
http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl

++
|  Product   |Bug ID |
|+---|
| Cisco Adaptive Security| CSCtd01491|
| Device Manager (ASDM)  |   |
|+---|
| Cisco AON Software | CSCtd01646|
||   |
|+---|
| Cisco AON Healthcare for   | CSCtd01652|
| HIPAA and ePrescription|   |
|+---|
| Cisco Application and  | CSCtd01529|
| Content Networking System  |   |
| (ACNS) Software|   |
|+---|
| Cisco Application  | CSCtd01480|
| Networking Manager |   |
|+---|
| Cisco ASA 5500 Series  | CSCtd00697|
| Adaptive Security  |   |
| Appliances |   |
|+---|
| Cisco ASA Advanced |   |
| Inspection and Prevention  | CSCtd01539|
| (AIP) Security Services|   |
| Module |   |
|+---|
| Cisco AVS 3100 Series  | CSCtd01566|
| Application Velocity   |   |
| System |   |
|+---|
| Cisco Catalyst 6500 Series | CSCtd06389|
| SSL Services Module|   |
|+---|
| Firewall Services Module   | CSCtd04061|
| FWSM   |   |
|+---|
| Cisco CSS 11000 Series | CSCtd01636|
| Content Services Switches  |   |
|+---|
| Cisco Unified SIP Phones   | CSCtd

Re: Failover how much complexity will it add?

[adel]

Hi Joe,

I agree with most of what you say below regarding linux sysadmin, BSD etc.  I'm 
quite happy and actually would prefer building a linux solution on our own 
hardware.  However, politically I think this is going to be difficult.  I just 
feel that they will be more comfortable with embedded network boxes as a pose 
to a linux solution.  I guess what I'm saying is this is partially a political 
thing.

Adel




On Mon   3:20 PM , Joe Greco  wrote:

> > 
> > Thanks,
> > 
> > I've taken your advice and decided to reconsider my requirement for a
> full 
> > routing table. I believe I'm being greedy and a partial table will be 
> > sufficient. With regards to Linux/BSD, its not the CLI of quagga that
> will 
> > be an issue, rather the sysadmin and lack of supporting infrastructure
> for 
> > Linux boxes within the organisation. So things like package management,
> 
> 
> You don't need to run Apache on your router.
> 
> > syslog servers, 
> 
> If you didn't have syslog servers for the Cisco, you don't need one for 
> the Quagga.
> 
> > monitoring,
> 
> If you didn't monitor the Cisco, you don't need to monitor the Quagga.
> 
> > understanding of security issues etc.
> 
> What security issues?
> 
> The thing is, people get all tied up over this idea that it is some major
> ongoing burden to support a Linux based device.
> 
> I have a shocker for you. The CPE your residential broadband relies on
> may
> well run Linux, and you didn't even know it. The wifi router you use may
> run
> Linux. There are thousands of embedded uses for Linux. I highly doubt
> that
> the average TiVo user has a degree in Linux. Many different things you
> use
> in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly
> without any
> need of someone to handhold them on security issues.
> 
> Of course, security issues do come up. But they do with Cisco as well. 
> 
> A proper Linux router doesn't have ports open, aside from bgp and ssh,
> and
> those can be firewalled appropriately. This makes it very difficult to
> have
> any meaningful "security problems" relating to the platform...
> 
> You can expect the occasional issue. Just like anything else. But trying
> to
> compare it to security issues on a general Linux platform is only
> meaningful
> if you're trying to argue against the solution.
> 
> (I'm a BSD guy myself, but I don't see any reason for undue Linux
> paranoia)
> 
> > I don't want to leave them with a linux/bsd solution that they won't be
> 
> > able to maintain/manage effectively when I am gone.
> 
> If they're unable to maintain something as straightforward as BSD or
> Linux 
> when you're gone, this raises alarm bells as to whether or not BGP is 
> really suited for them. BGP is *much* more arcane, relatively speaking.
> You can go to your local bookstore and pick up a ton of Linux or BSD
> sysadm
> books, but you'll be lucky to find a book on BGP.
> 
> > Thanks for your comments. Look forward to hearing which solutions come 
> > back into the mix having dropped the full routing table requirement.
> 
> There's a whole plethora of BGP-capable gear that becomes possible once 
> you make that call. Cisco and Juniper both make good gear. A variety
> of other mfrs do as well. Something as old as an Ascend GRF 400 (fast
> ethernet, line speed, 150K routes, ~1998?) is perfectly capable of
> dealing
> with the load, though I mention this primarily to make the point that
> there
> is a lot of equipment within the last decade that can support this.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> [1]
> "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.
> 
> 
> 
> Links:
> --
> [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
> 
> 

Re: What DNS Is Not

[Jack Bates]

Alex Balashov wrote:

Thought-provoking article by Paul Vixie:

http://queue.acm.org/detail.cfm?id=1647302



Bah, many of the CDN's I've dealt with don't seed geographical responses 
based on DNS, but rather use many out of band methods for determining 
what response they will hand out. The primary reason for short cutting 
cache is to limit failures in case the system a requestor is going to 
goes down.


And different CDN's behave differently, depending on how they deliver 
content, support provider interconnects, etc. I'd hardly call many of 
them DNS lies, as they do resolve you to the appropriate IP, and if that 
IP disappears, try and quickly get you to another appropriate IP.


The rest of the article was informative,though.


Jack

Re: Failover how much complexity will it add?

[Joe Greco]

> 
> Thanks,
> 
> I've taken your advice and decided to reconsider my requirement for a full 
> routing table.  I believe I'm being greedy and a partial table will be 
> sufficient.  With regards to Linux/BSD, its not the CLI of quagga that will 
> be an issue, rather the sysadmin and lack of supporting infrastructure for 
> Linux boxes within the organisation.  So things like package management, 

You don't need to run Apache on your router.

> syslog servers, 

If you didn't have syslog servers for the Cisco, you don't need one for 
the Quagga.

> monitoring,

If you didn't monitor the Cisco, you don't need to monitor the Quagga.

> understanding of security issues etc.

What security issues?

The thing is, people get all tied up over this idea that it is some major
ongoing burden to support a Linux based device.

I have a shocker for you.  The CPE your residential broadband relies on may
well run Linux, and you didn't even know it.  The wifi router you use may run
Linux.  There are thousands of embedded uses for Linux.  I highly doubt that
the average TiVo user has a degree in Linux.  Many different things you use
in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly without any
need of someone to handhold them on security issues.

Of course, security issues do come up.  But they do with Cisco as well. 

A proper Linux router doesn't have ports open, aside from bgp and ssh, and
those can be firewalled appropriately.  This makes it very difficult to have
any meaningful "security problems" relating to the platform...

You can expect the occasional issue.  Just like anything else.  But trying to
compare it to security issues on a general Linux platform is only meaningful
if you're trying to argue against the solution.

(I'm a BSD guy myself, but I don't see any reason for undue Linux paranoia)

> I don't want to leave them with a linux/bsd solution that they won't be 
> able to maintain/manage effectively when I am gone.

If they're unable to maintain something as straightforward as BSD or Linux 
when you're gone, this raises alarm bells as to whether or not BGP is 
really suited for them.  BGP is *much* more arcane, relatively speaking.
You can go to your local bookstore and pick up a ton of Linux or BSD sysadm
books, but you'll be lucky to find a book on BGP.

> Thanks for your comments.  Look forward to hearing which solutions come 
> back into the mix having dropped the full routing table requirement.

There's a whole plethora of BGP-capable gear that becomes possible once 
you make that call.  Cisco and Juniper both make good gear.  A variety
of other mfrs do as well.  Something as old as an Ascend GRF 400 (fast
ethernet, line speed, 150K routes, ~1998?) is perfectly capable of dealing
with the load, though I mention this primarily to make the point that there
is a lot of equipment within the last decade that can support this.

... 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: Failover how much complexity will it add?

[adel]

Actually thinking about this, I still need to understand the implications of 
not taking a full routing table to my setup.  So what is the likely impact 
going to be if I take partial instead of full routing table.  Would appreciate 
any feedback on this.  My organisation is only looking at using BGP as a means 
of failover between two separate upstream ISPs.  We are not an ISP.

Thanks

Adel



On Mon   1:32 PM , a...@baklawasecrets.com wrote:

> Thanks,
> 
> I've taken your advice and decided to reconsider my requirement for a
> full routing table. I believe I'm being greedy and a partial table will be
> sufficient. With regards to Linux/BSD, its not the CLI of quagga that will
> be an issue, rather the sysadmin and lack of supporting infrastructure for
> Linux boxes within the organisation. So things like package management,
> syslog servers, monitoring, understanding of security issues etc. I don't
> want to leave them with a linux/bsd solution that they won't be able to
> maintain/manage effectively when I am gone.
> 
> Thanks for your comments. Look forward to hearing which solutions come
> back into the mix having dropped the full routing table requirement.
> 
> Regards,
> 
> Adel
> 
> On Mon 11:45 AM , Joe Greco  wrote:
> 
> > > > > Basically the organisation that I'm working for will not have the
> > skills
> > > > > in house to support a linux or bsd box. They will have trouble
> > > > > with supporting the BGP configuration, however I don't think they
> > will be
> > > > > happy with me if I leave them with a linux box when they
> > > > > don't have linux/unix resource internally. At least with a Cisco
> or
> > > > > Juniper they are familiar with IOS and it won't be too foreign to
> > them.
> > 
> > > > On Sun 11:47 PM , Dale Rumph wrote:
> > > > 
> > > > What does your budget look like? A pair of Cisco 7246vxr's with
> G1's
> > > > sitting on the edge of the network would be very effective and
> still
> > allow
> > > > expansion. Or you could go up to the 7609. However this gear may be
> > > > slightly overkill. You might be ok with a 3660 enterprise and a ton
> > of
> > > > ram. I have done single sessions on them but not with the level of
> HA
> > your
> > > > looking for.
> > > > 
> > > > Just my 2c
> > 
> > > You will laugh, but the budget at the moment looks like £13k. 
> > > Impossible? Do only linux and openbsd solutions remain in the mix 
> > > for this pittance?
> > 
> > No, you have the buy-it-off-eBay solutions as well. "Beware the
> > fakes."
> > 
> > If they're familiar with IOS, then they can be familiar with Quagga
> > about as easily as they could be familiar with a switch or other 
> > network gizmo that had a Ciscoesque CLI but wasn't actually Cisco.
> > 
> > You've painted yourself into a corner. I have a word for you:
> > 
> > Reconsider.
> > 
> > I don't care what you reconsider, but reconsider something. You can
> > reconsider taking BGP with a full table. You can reconsider Quagga.
> > Or you can reconsider your budget. This is the end result of the
> > "pick any two" problem.
> > 
> > Most end user organizations have no need of full routes in BGP. To
> > try to take them dooms TCAM-based equipment at some future point,
> > though if you have a lot of money to throw at it, you can make that
> > point be years in the future. It is essentially planned obsolescence.
> > If you discard the requirement for full routes, you open up a bunch
> > of reasonably-priced possibilities.
> > 
> > Finding someone knowledgeable in BSD or Linux isn't that rough. 
> > Unlike a Cisco 76xx router, the hardest part of a Quagga-based 
> > solution is finding the right mix of hardware and software at the
> > beginning. PC hardware has a lot going for AND against it. There is
> > no reason you can't make a good router out of a PC. If you buy the
> > Cisco software-based routers, you're essentially buying a prepackaged
> > version, except that it'll be specced to avoid any real competition 
> > with their low-end TCAM-based offerings. A contemporary PC can 
> > easily route gigabits. Vyatta makes what I hear is a fantastic
> > canned solution of some sort, for a reasonable cost, and they will
> > sell just software or software/hardware. If you really can't put
> > it together yourself, there's someone to do it for you.
> > 
> > Reconsidering your budget is probably the most painful thing to do,
> > but also opens up the "just buy big Cisco" option. I think my point
> > here would have to be that what you're looking for would have needed
> > big Cisco... ten years ago. Now, dealing with a few hundred megs of
> > traffic, that's not that big a deal, the thing that's killing you is
> > the BGP table size.
> > 
> > Your best option may be to see if you can settle for partial routes
> > plus a default.
> > 
> > ... JG
> > -- 
> > Joe Greco - sol.net Network Services - Milwaukee, WI -
> http://www.sol.net [1]
> > [1]
> > "We call it the 'one bite at the apple' rule. Give me one chance [and]
> > then 

Re: Failover how much complexity will it add?

[Adam Armstrong]

Ken Gilmour wrote:

Hi Adel

There are companies like packet exchange (www.packetexchange.net)
(whom i have personally used) who will do all of the legwork for you,
such as applying for the ASN, address space, transit agreements, and
get the tail connections directly to your building. You just need to
pay them and buy the equipment (which they can also provide). Probably
easier in the long run.
  
Sure, if you want to hand over your entire profit margin to a 3rd party. 
Do you really want to give away the keys to your business, and rely 
entirely upon a third party organisation? Better to acquire the skills 
which are vital to your organisation yourself.

NOTE: I am not an employee, or paid affiliate of packet exchange... I
have used them for services and am promoting them due to my own good
experiences with their services.
  
I used to work for them. Then as now, I honestly can see little purpose 
in their productset.


adam.

2009/11/8  :
  

Thanks Seth and James,

Things are getting a lot clearer.  The BGP multihoming solution sounds like 
exactly what I want.  I have more questions :-)

Now I suppose I would get my allocation from RIPE as I am UK based?

Do I also need to apply for an AS number?

As the IP block is "mine", it is ISP independent.  i.e. I can take it with me 
when I decide to use two completely different ISPs?

Is the obtaining of this IP block, what is referred to as PI space?

Of course internally I split the /24 up however I want - /28 for untrust range 
and maybe a routed DMZ block etc.?

Assuming I apply for IP block and AS number, whats involved and how long does 
it take to get these babies?

I know the SSG550's have BGP capabilites.  As I have two of these in HA mode, 
does it make sense to do the BGP on these, or should I get dedicated BGP 
routers?

Fixing the internal routing policy so traffic is directed at the active BGP 
connection.  Whats involved here, preferring one BGP link over the other?

Thanks again, I obviously need to do some reading of my own, but all the 
suggestions so far have been very valuable and definitely seem to be pointing 
in some
fruitful directions.

Adel



On Sun   6:31 PM , "James Hess" mysi...@gmail.com sent:


On Sun, Nov 8, 2009 at 11:34 AM,   wrote:[..]
  

connections from different providers I would


still have issues.  So> I guess that if my primary Internet goes down I
lose connectivity> to all the publicly addressed devices on that
connection. Like> dmz hosts and so on.  I would be interested
to hear how this> can be avoided if at all or do I have to use the
same provider.
You assign multi-homed IP address space to your publicly addressed
devices,which are not specific to either ISP. You announce to both ISPs,  and
you accept some routes from both ISPs.

You get multi-homed IPs, either by having an existing ARIN allocation,
or getting a /22 from ARIN  (special allocation available for
multi-homing), or  ask for a /24 from  ISP A or ISP B  for
multihoming.


If  Link A fails, the BGP session eventually times out and dies: ISP
A's  BGP routers withdraw the routes,  the IP addresses are then
associated only with provider B.

And you design your internal routing policy  to  direct  traffic
within your network to the router with an active BGP session.

Link A's failure is _not_ a total non-event,  but a 3-5 minute partial
disruption, while the BGP session times out and updates occur in other
people's routers, is minimal compared to  a  3 day outage, if serious
repairs to upstream fiber are required.


--
-J



  





  

Re: Failover how much complexity will it add?

[adel]

Thanks,

I've taken your advice and decided to reconsider my requirement for a full 
routing table.  I believe I'm being greedy and a partial table will be 
sufficient.  With regards to Linux/BSD, its not the CLI of quagga that will be 
an issue, rather the sysadmin and lack of supporting infrastructure for Linux 
boxes within the organisation.  So things like package management, syslog 
servers, monitoring, understanding of security issues etc.  I don't want to 
leave them with a linux/bsd solution that they won't be able to maintain/manage 
effectively when I am gone.

Thanks for your comments.  Look forward to hearing which solutions come back 
into the mix having dropped the full routing table requirement.

Regards,

Adel



On Mon  11:45 AM , Joe Greco  wrote:

> > > > Basically the organisation that I'm working for will not have the
> skills
> > > > in house to support a linux or bsd box. They will have trouble
> > > > with supporting the BGP configuration, however I don't think they
> will be
> > > > happy with me if I leave them with a linux box when they
> > > > don't have linux/unix resource internally. At least with a Cisco or
> > > > Juniper they are familiar with IOS and it won't be too foreign to
> them.
> 
> > > On Sun 11:47 PM , Dale Rumph  wrote:
> > > 
> > > What does your budget look like? A pair of Cisco 7246vxr's with G1's
> > > sitting on the edge of the network would be very effective and still
> allow
> > > expansion. Or you could go up to the 7609. However this gear may be
> > > slightly overkill. You might be ok with a 3660 enterprise and a ton
> of
> > > ram. I have done single sessions on them but not with the level of HA
> your
> > > looking for.
> > > 
> > > Just my 2c
> 
> > You will laugh, but the budget at the moment looks like £13k. 
> > Impossible? Do only linux and openbsd solutions remain in the mix 
> > for this pittance?
> 
> No, you have the buy-it-off-eBay solutions as well. "Beware the
> fakes."
> 
> If they're familiar with IOS, then they can be familiar with Quagga
> about as easily as they could be familiar with a switch or other 
> network gizmo that had a Ciscoesque CLI but wasn't actually Cisco.
> 
> You've painted yourself into a corner. I have a word for you:
> 
> Reconsider.
> 
> I don't care what you reconsider, but reconsider something. You can
> reconsider taking BGP with a full table. You can reconsider Quagga.
> Or you can reconsider your budget. This is the end result of the
> "pick any two" problem.
> 
> Most end user organizations have no need of full routes in BGP. To
> try to take them dooms TCAM-based equipment at some future point,
> though if you have a lot of money to throw at it, you can make that
> point be years in the future. It is essentially planned obsolescence.
> If you discard the requirement for full routes, you open up a bunch
> of reasonably-priced possibilities.
> 
> Finding someone knowledgeable in BSD or Linux isn't that rough. 
> Unlike a Cisco 76xx router, the hardest part of a Quagga-based 
> solution is finding the right mix of hardware and software at the
> beginning. PC hardware has a lot going for AND against it. There is
> no reason you can't make a good router out of a PC. If you buy the
> Cisco software-based routers, you're essentially buying a prepackaged
> version, except that it'll be specced to avoid any real competition 
> with their low-end TCAM-based offerings. A contemporary PC can 
> easily route gigabits. Vyatta makes what I hear is a fantastic
> canned solution of some sort, for a reasonable cost, and they will
> sell just software or software/hardware. If you really can't put
> it together yourself, there's someone to do it for you.
> 
> Reconsidering your budget is probably the most painful thing to do,
> but also opens up the "just buy big Cisco" option. I think my point
> here would have to be that what you're looking for would have needed
> big Cisco... ten years ago. Now, dealing with a few hundred megs of
> traffic, that's not that big a deal, the thing that's killing you is
> the BGP table size.
> 
> Your best option may be to see if you can settle for partial routes
> plus a default.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> [1]
> "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.
> 
> 
> 
> Links:
> --
> [1] http://webmail.123-reg.co.uk/parse.php?redirect=http://www.sol.net
> 
> 

Re: Failover how much complexity will it add?

[adel]

Thanks,

Their offering certainly looks appealing.  Will be interested to hear user 
experiences of the Vyatta BGP router range.  Having said that
I will still be examining the Cisco offering, just because of the support, 
larger user community and skills base issue.  However if I can't
meet the price point using Cisco, obviously other solutions are going to come 
into the picture.

Adel




On Mon  11:39 AM , Arnold Nipper  wrote:

> On 09.11.2009 11:53 a...@baklawasecrets.com wrote
> 
> > You will laugh, but the budget at the moment looks like £13k.
> > Impossible? Do only linux and openbsd solutions remain in the mix
> > for this pittance?
> > 
> 
> Do you know Vyatta (http://www.vyatta.com/)? [1] CLI and config is
> Cisco-ish. Prices e.g.
> 
> Vyatta Appliance, Vyatta 2502, Enterprise Subscription, Basic Warranty,
> 1 Year (ships with US Power Cord as standard) (Typically ships in 10-12
> business days)
> Price: $2,997.00
> 
> Best regards,
> Arnold
> -- 
> Arnold Nipper / nIPper consulting, Sandhausen, Germany
> email: arn...@nipper.de phone: +49 6224 9259 299
> mobile: +49 172 2650958 fax: +49 6224 9259 333
> 
> 
> 
> Links:
> --
> [1]
> http://webmail.123-reg.co.uk/parse.php?redirect=http://www.vyatta.com/%29%3
> F
> 

Re: Failover how much complexity will it add?

[Joe Greco]

> > > Basically the organisation that I'm working for will not have the skills
> > > in house to support a linux or bsd box. They will have trouble
> > > with supporting the BGP configuration, however I don't think they will be
> > > happy with me if I leave them with a linux box when they
> > > don't have linux/unix resource internally. At least with a Cisco or
> > > Juniper they are familiar with IOS and it won't be too foreign to them.

> > On Sun  11:47 PM , Dale Rumph  wrote:
> > 
> > What does your budget look like? A pair of Cisco 7246vxr's with G1's
> > sitting on the edge of the network would be very effective and still allow
> > expansion. Or you could go up to the 7609. However this gear may be
> > slightly overkill. You might be ok with a 3660 enterprise and a ton of
> > ram. I have done single sessions on them but not with the level of HA your
> > looking for.
> > 
> > Just my 2c

> You will laugh, but the budget at the moment looks like £13k.  
> Impossible?  Do only linux and openbsd solutions remain in the mix 
> for this pittance?

No, you have the buy-it-off-eBay solutions as well.  "Beware the
fakes."

If they're familiar with IOS, then they can be familiar with Quagga
about as easily as they could be familiar with a switch or other 
network gizmo that had a Ciscoesque CLI but wasn't actually Cisco.

You've painted yourself into a corner.  I have a word for you:

Reconsider.

I don't care what you reconsider, but reconsider something.  You can
reconsider taking BGP with a full table.  You can reconsider Quagga.
Or you can reconsider your budget.  This is the end result of the
"pick any two" problem.

Most end user organizations have no need of full routes in BGP.  To
try to take them dooms TCAM-based equipment at some future point,
though if you have a lot of money to throw at it, you can make that
point be years in the future.  It is essentially planned obsolescence.
If you discard the requirement for full routes, you open up a bunch
of reasonably-priced possibilities.

Finding someone knowledgeable in BSD or Linux isn't that rough.  
Unlike a Cisco 76xx router, the hardest part of a Quagga-based 
solution is finding the right mix of hardware and software at the
beginning.  PC hardware has a lot going for AND against it.  There is
no reason you can't make a good router out of a PC.  If you buy the
Cisco software-based routers, you're essentially buying a prepackaged
version, except that it'll be specced to avoid any real competition 
with their low-end TCAM-based offerings.  A contemporary PC can 
easily route gigabits.  Vyatta makes what I hear is a fantastic
canned solution of some sort, for a reasonable cost, and they will
sell just software or software/hardware.  If you really can't put
it together yourself, there's someone to do it for you.

Reconsidering your budget is probably the most painful thing to do,
but also opens up the "just buy big Cisco" option.  I think my point
here would have to be that what you're looking for would have needed
big Cisco... ten years ago.  Now, dealing with a few hundred megs of
traffic, that's not that big a deal, the thing that's killing you is
the BGP table size.

Your best option may be to see if you can settle for partial routes
plus a default.

... 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: Failover how much complexity will it add?

[adel]

Looking at two 100Mbit/s BGP connections, so I think I want something that will 
do more than 100 but nowhere close to a gig.  So full routing table capability
with throughput of mixed traffic around 200Mbit/s.  If that makes sense.  Do 
the 2850s fall into that sort of price point?

Adel


On Mon  11:13 AM , Joe Abley  wrote:

> On 2009-11-09, at 19:53, a...@baklawasecrets.com wrote:
> 
> > You will laugh, but the budget at the moment looks like £13k. 
> > Impossible? Do only linux and openbsd solutions remain in the mix 
> > for this pittance?
> 
> I don't see an indication of the traffic you need to push (maybe I 
> deleted a message too enthusiastically) but check the 2800 series from 
> cisco. The 2850 will take full tables and has gigabit interfaces, but 
> don't expect them to do wire speed. Other 2800s suffer from reduced 
> RAM, but perhaps you don't need full tables.
> 
> Also look at Juniper J-series boxes, and maybe Force10 S-series boxes.
> 
> There's a healthy market in used cisco gear in most places I have ever 
> visited, if you don't need new.
> 
> Joe
> 
> 
> 

Re: Failover how much complexity will it add?

[adel]

You will laugh, but the budget at the moment looks like £13k.  Impossible?  Do 
only linux and openbsd solutions remain in the mix for this pittance?



On Sun  11:47 PM , Dale Rumph  wrote:

> What does your budget look like? A pair of Cisco 7246vxr's with G1's
> sitting on the edge of the network would be very effective and still allow
> expansion. Or you could go up to the 7609. However this gear may be
> slightly overkill. You might be ok with a 3660 enterprise and a ton of
> ram. I have done single sessions on them but not with the level of HA your
> looking for.
> 
> Just my 2c
> 
> - Original Message -
> From: a...@baklawasecrets.com 
> To: nanog@nanog.org 
> Sent: Sun Nov 08 18:36:31 2009
> Subject: Re: Failover how much complexity will it add?
> 
> Basically the organisation that I'm working for will not have the skills
> in house to support a linux or bsd box. They will have trouble
> with supporting the BGP configuration, however I don't think they will be
> happy with me if I leave them with a linux box when they
> don't have linux/unix resource internally. At least with a Cisco or
> Juniper they are familiar with IOS and it won't be too foreign to them.
> 
> On Sun 11:30 PM , "Renato Frederick"  wrote:
> 
> > There are any problems with quagga+BSD/Linux that you know or something
> 
> > like that?
> > 
> > Or in your scenario a "cisco/juniper box" is a requirement?
> > 
> > I'm asking this because I'm always running BGP with upstreams providers
> 
> > using quagga on BSD and everything is fine until now.
> > 
> > --
> > From: 
> > Sent: Sunday, November 08, 2009 8:39 PM
> > To: 
> > Subject: Re: Failover how much complexity will it add?
> > 
> > >
> > > So if my requirements are as follows:
> > >
> > > - BGP router capable of holding full Internet routing table. (whether
> I
> > 
> > > go for partial or full, I think I want something with full
> capability).
> > >
> > > - Capable of pushing 100meg plus of mixed traffic.
> > >
> > > What are my options? I want to exclude openbsd, or linux with quagga.
> 
> > > Probably looking at Cisco or Juniper products, but interested
> > > in any other alternatives people suggest. I realise this is quite a
> > broad 
> > > question, but hoping this will provide a starting point. Oh and
> > > if I have missed any specs I should have included above, please let
> me 
> > > know.
> > >
> > > Thanks
> > >
> > > Adel
> > 
> > 
> > 
> 
> 
>