Re: BGP analyzing tool

[Kanagaraj Krishna]

Hi Doug,
 How about cisco? In juniper, 'show route detail' really helps. 
Thanks.

Regards,
Kana  
  - Original Message - 
  From: Doug Marschke 
  To: 'Kanagaraj Krishna' 
  Cc: nanog@merit.edu 
  Sent: Wednesday, November 22, 2006 2:08 PM
  Subject: RE: BGP analyzing tool


  I don't know of any tool, but it seems like you should be able to get a show 
route detail about, write a script to choose inactive reasons and sort based 
off that.

   

  Doug

   


--

  From: Kanagaraj Krishna [mailto:[EMAIL PROTECTED] 
  Sent: Tuesday, November 21, 2006 6:57 PM
  To: Doug Marschke
  Cc: nanog@merit.edu
  Subject: Re: BGP analyzing tool

   

  Using cli like "sh ip bgp xxx.xxx.xxx.xxx"[Cisco] or "sh route protocol bgp 
xxx.xxx.xxx.xxx detail" [Juniper] would be able to show me details for specific 
destinations. What i need is a software to get all the data from a routers 
routing table, analyze the best path and summarize the reason why its being 
chosen based on the BGP algorithm (local pref, no. of hops, MED, etc). That 
would show the big picture of why a certain upstream is more prefered than the 
other. Thanks.

   

  Regards,

  Kana 

- Original Message - 

From: Doug Marschke 

To: 'Kanagaraj Krishna' 

Sent: Wednesday, November 22, 2006 10:09 AM

Subject: RE: BGP analyzing tool

 

What kind of router?  A juniper will show you this with a show route detail.

Doug

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Kanagaraj Krishna
Sent: Tuesday, November 21, 2006 6:27 AM
To: nanog@merit.edu
Subject: Re: BGP analyzing tool


Hi,
   Are there any available BGP analyzing tool that can be used to identify 
details on best chosen path based on the BGP algorithm? NTOP can capture the

traffic info, but to analyze each destination to find the reason for
selection 
(local preference, no of AS hops, iBGP vs eBGP etc) would be hard. I need
this 
info to understand why a certain upstream is being more prefered than the 
others. Thanks.

Regards,
Kana

Re: OT: How to stop UltraDNS sales people calling

[Andy Davidson]

On Tue, 2006-11-28 at 16:44 +, Paul Vixie wrote:
> [EMAIL PROTECTED] (Andy Davidson) writes:
> > I am really fed up of calls from UltraDNS - we seem to get them every
> > few days.  We don't need their product.  
> every month or two somebody will ask me "does BIND really drop 20% of all
> queries it receives?"  and i say, "um, no, why do you ask?" and the answer
> is always "that's what the ultradns salesman told me."  i can't argue with
> their success, but i guess i am ready to quibble over their manners.

The volumes are different, but the message is the same when I am called,
there's a claim that we are dropping queries because we use bind, but
the people on the phone can't explain why.  

This is a problem when our CTO gets the sales call, as it generates
effort explaining that the company are employing scare tactics.


Thanks for the volume of offlist replies with some good suggestions,
too, everyone - many were very amusing.

Re: How to stop UltraDNS sales people calling

[Alexander Harrowell]

"Can I speak to so-and-so?"

"I'm sorry I can't help. I am a counter-terrorism officer monitoring
this line for reasons of national security."

On 11/29/06, William Yardley <[EMAIL PROTECTED]> wrote:


On Tue, Nov 28, 2006 at 05:48:55PM -0800, Joseph Jackson wrote:

> I had ultradns calling also but told them we weren't at a place to use
> their product and they said ok and let me be.   They were always
> professional on the phone.

One more on the side of "They call all the time and won't leave us the
@#$@ alone, no matter how direct we are".

Fortunately, they don't call me (yet), but they have been calling
several other folks at our office repeatedly for years, despite being
told pretty bluntly to knock it off.

w

Re: OT: How to stop UltraDNS sales people calling

[Jay Hennigan]

Jeremy Chadwick wrote:

On Tue, Nov 28, 2006 at 05:56:19PM -0600, Gadi Evron wrote:

Okay, this was fun and I am all for OT fun. But can we please stop putting
down a part of our community? Especially one which contributes to NANOG so
much?

We all have sale trolls to live with.


I both agree and disagree.  I agree that the put-downs are a bit
excessive (I laughed more than once :-) ), but I disagree with
the "sale trolls" comment.

UltraDNS's sales staff *does not* have to behave like this.


Agreed.  When I get such calls, the first question I ask is, "Is this a 
sales call?"  If I get an honest "Yes", I'm somewhat more inclined to 
continue the conversation.  If the first thing a salesperson tells me is 
a lie, game over.


Similarly, any company that spams me selling network equipment or 
connectivity is clearly way beyond stupid and not one with which I would 
ever consider doing business.


Yes, this thread is OT to a large extent, but we are network operators. 
Many of us have sales staff.  Educating our own sales people on what not 
to do is a step towards noise reduction, albeit out-of-band noise as far 
as this forum is concerned.


--
Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED]
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: How to stop UltraDNS sales people calling

[Jay Hennigan]

Alexander Harrowell wrote:


"Can I speak to so-and-so?"

"I'm sorry I can't help. I am a counter-terrorism officer monitoring
this line for reasons of national security."


"Can I speak to so-and-so?"

"I'm sorry, he's in prison.  He went on a shooting spree at a 
telemarketing call center."


--
Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED]
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Fwd: The IESG Approved the Expansion of the AS Number Registry

[Marshall Eubanks]

Seems relevant.

Begin forwarded message:


From: IESG Secretary <[EMAIL PROTECTED]>
Date: November 29, 2006 10:32:38 AM EST
To: IETF Announcement list 
Subject: The IESG Approved the Expansion of the AS Number Registry

 Original Message 
Subject: The IESG Approved the Expansion of the AS Number Registry
Date: Mon, 27 Nov 2006 09:56:13 -0500
From: IESG Secretary
To: IANA
CC: IESG

Dear IANA,

The IESG has approved the expansion of the size of the AS Number
registry described in draft-ietf-idr-as4bytes-12.txt before the  
approval

of the document. Please expand the AS Number space to include the
values 65536 through 4294967295, initially marked as "Held by IANA".

Allocations can be made to the RIRs prior to the publication of
this RFC.

Thank You,
The IESG

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

Increase in NANOG Meeting Attendance Fees

[Joe Abley]

[sent to nanog-futures@, bcc'ing nanog-announce@, apologies for  
duplicates]


During the past several community meetings, Merit have presented  
accounts for NANOG which show that revenue from membership fees and  
sponsorship are not sufficient to cover costs, despite substantial  
measures taken by Merit over the past several meetings to reduce the  
overhead involved in NANOG activities.


Recent efforts to plan ahead and arrange meeting venues up to 18  
months in the future have provided additional financial pressure,  
since hotels require substantial deposits. Extending the length of  
the meeting from Sunday-Tuesday to Sunday-Wednesday has also  
contributed to increased costs, as have the improvements in network  
infrastructure which have been evident at recent meetings. Revenue  
has not increased to offset these additional costs.


Merit and the SC are together working on changes to the sponsorship  
structure at NANOG meetings in order to increase the value to  
sponsors from participating with the goal of increasing meeting  
revenue. Changes will take some time to implement, however, and are  
by their nature somewhat speculative since the benefits of the  
changes will not be really apparent until they have been implemented.


At past community meetings, people have clearly expressed that modest  
increases in meeting fees would not present significant barriers to  
meeting attendance, so long as the other costs of attending (hotel  
block rates, travel, etc) were maintained at current levels. NANOG  
meeting fees are low when compared to other, similar events. The  
current meeting fee of $350 has been in place since NANOG 28 in June  
2003.


Both Merit and the SC are committed to finding a sustainable funding  
model which will ensure that NANOG continues to be a viable community  
resource for many years to come, and is predictably and reliably self- 
sustaining for the benefit of all participants.


In their meeting on Wednesday 2006-11-22 the Steering Committee  
approved an increase of NANOG meeting attendance fees from $350 to  
$450. This will be implemented for NANOG 39 in Toronto.


Further discussion of funding models and related topics is  
encouraged, and should take place on the nanog-futures mailing list.  
Please see  for subscription  
instructions.



Joe Abley
for the SC

Re: Fwd: The IESG Approved the Expansion of the AS Number Registry

[Deepak Jain]

Afraid so. I'm hoping to be out of the industry before calls for 128 bit 
AS#s come down the pipe and people (at that time) are laughing about how 
silly 32 bit AS#s seem.


Does anyone have a current projection of when AS# (16 bit) exhaust will 
occur?


Thanks,

Deepak

Marshall Eubanks wrote:


Seems relevant.

Begin forwarded message:


From: IESG Secretary <[EMAIL PROTECTED]>
Date: November 29, 2006 10:32:38 AM EST
To: IETF Announcement list 
Subject: The IESG Approved the Expansion of the AS Number Registry

 Original Message 
Subject: The IESG Approved the Expansion of the AS Number Registry
Date: Mon, 27 Nov 2006 09:56:13 -0500
From: IESG Secretary
To: IANA
CC: IESG

Dear IANA,

The IESG has approved the expansion of the size of the AS Number
registry described in draft-ietf-idr-as4bytes-12.txt before the approval
of the document. Please expand the AS Number space to include the
values 65536 through 4294967295, initially marked as "Held by IANA".

Allocations can be made to the RIRs prior to the publication of
this RFC.

Thank You,
The IESG

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

comcast routing issue question

[Jim Popovitch]

Question:  What could cause the first trace below to succeed, but the
second trace to fail?

$ mtr 69.61.40.35
HOST: blueLoss%   Snt   Last   Avg  Best Wrst
  1. 192.168.3.1   0.0% 14.3   4.3   4.3   4.3
  2. 73.62.48.10.0% 1   10.6  10.6  10.6  10.6
  3. 68.86.108.25  0.0% 1   11.4  11.4  11.4  11.4
  4. 68.86.106.54  0.0% 19.8   9.8   9.8   9.8
  5. 68.86.106.9   0.0% 1   20.5  20.5  20.5  20.5
  6. 68.86.90.121  0.0% 1   11.3  11.3  11.3  11.3
  7. 68.86.84.70   0.0% 1   27.7  27.7  27.7  27.7
  8. 64.213.76.77  0.0% 1   24.5  24.5  24.5  24.5
  9. 208.50.254.1500.0% 1   39.4  39.4  39.4  39.4
 10. 208.49.83.237 0.0% 1   46.6  46.6  46.6  46.6
 11. 208.49.83.234 0.0% 1   40.7  40.7  40.7  40.7
 12. 69.61.40.35   0.0% 1   43.9  43.9  43.9  43.9

$ mtr 69.61.40.34
HOST: blueLoss%   Snt   Last   Avg  Best  Wrst
  1. 192.168.3.1   0.0% 11.1   1.1   1.1   1.1
  2. 73.62.48.10.0% 19.9   9.9   9.9   9.9
  3. 68.86.108.25  0.0% 19.3   9.3   9.3   9.3
  4. 68.86.106.54  0.0% 19.6   9.6   9.6   9.6
  5. 68.86.106.9   0.0% 19.0   9.0   9.0   9.0
  6. 68.86.90.121  0.0% 1   18.2  18.2  18.2  18.2
  7. 68.86.84.70   0.0% 1   23.9  23.9  23.9  23.9
  8. ???  100.0 10.0   0.0   0.0   0.0


Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.

Crazy.

-Jim P.

Re: comcast routing issue question

[Jim Popovitch]

On Thu, 2006-11-30 at 00:06 -0500, Jim Popovitch wrote:
> Question:  What could cause the first trace below to succeed, but the
> second trace to fail?
> 
> $ mtr 69.61.40.35
> HOST: blueLoss%   Snt   Last   Avg  Best Wrst
>   1. 192.168.3.1   0.0% 14.3   4.3   4.3   4.3
>   2. 73.62.48.10.0% 1   10.6  10.6  10.6  10.6
>   3. 68.86.108.25  0.0% 1   11.4  11.4  11.4  11.4
>   4. 68.86.106.54  0.0% 19.8   9.8   9.8   9.8
>   5. 68.86.106.9   0.0% 1   20.5  20.5  20.5  20.5
>   6. 68.86.90.121  0.0% 1   11.3  11.3  11.3  11.3
>   7. 68.86.84.70   0.0% 1   27.7  27.7  27.7  27.7
>   8. 64.213.76.77  0.0% 1   24.5  24.5  24.5  24.5
>   9. 208.50.254.1500.0% 1   39.4  39.4  39.4  39.4
>  10. 208.49.83.237 0.0% 1   46.6  46.6  46.6  46.6
>  11. 208.49.83.234 0.0% 1   40.7  40.7  40.7  40.7
>  12. 69.61.40.35   0.0% 1   43.9  43.9  43.9  43.9
> 
> $ mtr 69.61.40.34
> HOST: blueLoss%   Snt   Last   Avg  Best  Wrst
>   1. 192.168.3.1   0.0% 11.1   1.1   1.1   1.1
>   2. 73.62.48.10.0% 19.9   9.9   9.9   9.9
>   3. 68.86.108.25  0.0% 19.3   9.3   9.3   9.3
>   4. 68.86.106.54  0.0% 19.6   9.6   9.6   9.6
>   5. 68.86.106.9   0.0% 19.0   9.0   9.0   9.0
>   6. 68.86.90.121  0.0% 1   18.2  18.2  18.2  18.2
>   7. 68.86.84.70   0.0% 1   23.9  23.9  23.9  23.9
>   8. ???  100.0 10.0   0.0   0.0   0.0
> 
> 
> Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
> but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.
> 
> Crazy.

Btw, the problem has now been resolved, however I'm still curious as to
what scenario could have caused that.

-Jim P.

Re: comcast routing issue question

[Jordan Hazen]

On Thu, Nov 30, 2006 at 12:28:30AM -0500, Jim Popovitch wrote:
> 
> On Thu, 2006-11-30 at 00:06 -0500, Jim Popovitch wrote:
> > Question:  What could cause the first trace below to succeed, but the
> > second trace to fail?
> > 
[snip]
> > Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
> > but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.
> > 
> > Crazy.
> 
> Btw, the problem has now been resolved, however I'm still curious as to
> what scenario could have caused that.

Perhaps CEF-style load balancing over multiple paths, with one of them
down and not properly failing over?  Per-flow balancing would decide
which path to use based on source & target IP.

> -Jim P.
> 

-- 
Jordan.

Re: comcast routing issue question

[Jeremy Chadwick]

On Thu, Nov 30, 2006 at 12:06:29AM -0500, Jim Popovitch wrote:
> $ mtr 69.61.40.34
> HOST: blueLoss%   Snt   Last   Avg  Best  Wrst
>   1. 192.168.3.1   0.0% 11.1   1.1   1.1   1.1
>   2. 73.62.48.10.0% 19.9   9.9   9.9   9.9
>   3. 68.86.108.25  0.0% 19.3   9.3   9.3   9.3
>   4. 68.86.106.54  0.0% 19.6   9.6   9.6   9.6
>   5. 68.86.106.9   0.0% 19.0   9.0   9.0   9.0
>   6. 68.86.90.121  0.0% 1   18.2  18.2  18.2  18.2
>   7. 68.86.84.70   0.0% 1   23.9  23.9  23.9  23.9
>   8. ???  100.0 10.0   0.0   0.0   0.0
> 
> 
> Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
> but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.

You're not the only one who noticed this.

http://www.dslreports.com/forum/remark,17368208

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

Re: Fwd: The IESG Approved the Expansion of the AS Number Registry

[Chris L. Morrow]

On Wed, 29 Nov 2006, Deepak Jain wrote:

>
>
> Afraid so. I'm hoping to be out of the industry before calls for 128 bit
> AS#s come down the pipe and people (at that time) are laughing about how
> silly 32 bit AS#s seem.
>
> Does anyone have a current projection of when AS# (16 bit) exhaust will
> occur?

anyone have a swag at the number of things that this (32bit asn) touches?

netflow
bgp (duh!)
provisioning databases/systems
web-pages (really the backend parts like routeviews query/search tools)


yeesh :(

Re: comcast routing issue question

[Jamie Dahl]

Comcast broke themselves doing a maintenance..


On Thu, November 30, 2006 01:59, Jeremy Chadwick wrote:
>
> On Thu, Nov 30, 2006 at 12:06:29AM -0500, Jim Popovitch wrote:
>> $ mtr 69.61.40.34
>> HOST: blueLoss%   Snt   Last   Avg  Best  Wrst
>>   1. 192.168.3.1   0.0% 11.1   1.1   1.1   1.1
>>   2. 73.62.48.10.0% 19.9   9.9   9.9   9.9
>>   3. 68.86.108.25  0.0% 19.3   9.3   9.3   9.3
>>   4. 68.86.106.54  0.0% 19.6   9.6   9.6   9.6
>>   5. 68.86.106.9   0.0% 19.0   9.0   9.0   9.0
>>   6. 68.86.90.121  0.0% 1   18.2  18.2  18.2  18.2
>>   7. 68.86.84.70   0.0% 1   23.9  23.9  23.9  23.9
>>   8. ???  100.0 10.0   0.0   0.0   0.0
>>
>>
>> Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
>> but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.
>
> You're not the only one who noticed this.
>
> http://www.dslreports.com/forum/remark,17368208
>
> --
> | Jeremy Chadwick jdc at parodius.com |
> | Parodius Networkinghttp://www.parodius.com/ |
> | UNIX Systems Administrator   Mountain View, CA, USA |
> | Making life hard for others since 1977.   PGP: 4BD6C0CB |
>
>


-- 
Jamie Dahl

"Thousands of tired, nerve-shaken, over-civilized people are beginning to
find out that going to the mountains is going home; that wilderness is a
necessity; and that mountain parks and reservations are useful not only as
fountains of timber and irrigating rivers, but as fountains of life."
--John Muir

Re: comcast routing issue question

[Adrian Chadd]

On Wed, Nov 29, 2006, Jeremy Chadwick wrote:

> > 
> > Taking the 69.61.40.33/28 subnet a bit further, .36 drops at 68.86.84.70
> > but .37 - .39 make it.  .40 drops at 68.86.84.70, but .41 makes it.
> 
> You're not the only one who noticed this.

Not that its probably it; but i've seen some crappy etherchannel links
with IP path selection exhibit this whacky behaviour.



Adrian