- NANOG - lists.nanog.org

Radius & Tacacs+ Clients
by John Souvestre 16 Jan '09

16 Jan '09

Hi all. Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Thanks, John John Souvestre - Integrated Data Systems - (504) 355-0609

5 4

Approach to allocating netblocks
by Frank Bulk 16 Jan '09

16 Jan '09

For the first time we have our own ARIN-assigned netblocks that we can now split out and divide to our customers. What's the best approach to handing out /30's, /29's, etc. that is efficient as possible but allows for customers to expand their allocation to a neighboring block? I was thinking of having one /24 for each block size, and then do the divide and conquer approach by allocating the first /30, for example, as 0 and 128, then next two at 64 and 192, etc. Once there's only one /30 free between each allocation, I would start using another /24. Of course, that would mean 50% (or less) utilization. Ideas? Frank

7 9

What ISP's looking for in a BGP Security Solution?
by Akmal Shahbaz 16 Jan '09

16 Jan '09

Respected AllI would like to discuss some of the questions related to BGP Security which might be quite helpful in my research.1.What are you using now for BGP Security problems like Prefix hijacking,Path Spoofing,etc?2.What you would be looking for in any BGP Security Solution?3.Are solutions like BGPMon,PHAS,PGBGP are implemented anywhere?4.Are there some new issues related to BGP Security than widely discussed in research/conference/forums?5.Any other points you want to share.Thank You.Akmal Khan

1 0

Which is more efficient?
by Murphy, Jay, DOH 15 Jan '09

15 Jan '09

All, In your humble opinion, which transmission method is more efficient, packet or cell? Granted a cell is a fixed length packet and an IP packet is variable length....would this necessarily only relate to a specific protocol, namely, cell in ATM, and IP in Ethernet or other types of domains....feedback highly welcomed. Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fé, New México 87502 Bus. Ph.: 505.827.2851 "We move the information that moves your world." Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.

5 4

Re: Anyone notice strange announcements for 174.128.31.0/24
by deleskie＠gmail.com 15 Jan '09

15 Jan '09

This was a test using unassigned IP block, unless I'm reading it wrong. If a noc alerted on this it should have still be a low priority issue. I don't see any issues with the way this was carried out at all. -jim ------Original Message------ From: Michienne Dixon To: NANOG list Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Sent: Jan 12, 2009 6:55 PM But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, January 12, 2009 4:47 PM To: Paul Stewart Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 07:42, Paul Stewart wrote: > For us, it was annoying - we look for prefix hijackings or what appear > to be. i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy Sent from my BlackBerry device on the Rogers Wireless Network

21 34

Cogent Haiku v2.0
by neal rauhauser 14 Jan '09

14 Jan '09

Cogent makes a mess My phone rings and rings Unfornicate this!

21 30

Re: Which is more efficient?
by Josh Potter 14 Jan '09

14 Jan '09

What type of traffic are you looking at sending? As Scott said smaller payloads that need to be sent quickly work out well in fixed cells but larger payloads would be better off in variable sized packets. Also are you looking at simple data transmission rates or are you wanting to factor in hardware load, backplane load, cpu efficiency etc? On Wed, Jan 14, 2009 at 4:59 PM, Scott Berkman <scott.berkman(a)reignmaker.net > wrote: > Packets can have a max size as well based on the path MTU, such as 1500 > bytes in an Ethernet (10/100) link. I think there are a lot of other > variables here such as are you billed per data unit, bandwidth and control > factors on the links, and what type of data is being sent. > > If your data can always fit in a smaller N-byte cell, that can be quite > efficient since you have minimal overhead or wasted space and all the > benefits of the fixed length data unit from a processing standpoint. > > If you are constantly fragmenting and then having to reassemble data due > to the small cell size, you would be better off with a variable length > packet, especially when bandwidth is less in demand than processing power. > > -Scott > > -----Original Message----- > From: Murphy, Jay, DOH [mailto:Jay.Murphy@state.nm.us] > Sent: Wednesday, January 14, 2009 3:56 PM > To: nanog(a)nanog.org > Subject: Which is more efficient? > > > All, > > In your humble opinion, which transmission method is more efficient, > packet or cell? Granted a cell is a fixed length packet and an IP packet > is variable length....would this necessarily only relate to a specific > protocol, namely, cell in ATM, and IP in Ethernet or other types of > domains....feedback highly welcomed. Trying to make a decision on the > transport mode for cost, delay, jitter, ROI, etcetera. > > > Jay Murphy > IP Network Specialist > NM Department of Health > ITSD - IP Network Operations > Santa Fé, New México 87502 > Bus. Ph.: 505.827.2851 > > "We move the information that moves your world." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Confidentiality Notice: This e-mail, including all attachments is for the > sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited unless specifically provided under the New > Mexico Inspection of Public Records Act. If you are not the intended > recipient, please contact the sender and destroy all copies of this > message. -- This email has been scanned by the Sybari - Antigen Email > System. > > > > > -- Josh Potter

1 0

Anyone notice strange announcements for 174.128.31.0/24
by Michienne Dixon 14 Jan '09

14 Jan '09

I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24? I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0 This was from this AM around 10 AM CST: telnet@MLX4AP3#sho ip bgp route 174.128.31.0/24 Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 11911 Last update to IP routing table: 2h24m33s, 1 path(s) installed: This was from this AM around 11:30 AM CST: Number of BGP Routes matching display condition : 1 Prefix Next Hop Metric LocPrf Weight Status 1 174.128.31.0/24 160.81.151.109 88 200 100 BE AS_PATH: 1239 2914 3130 12083 Last update to IP routing table: 0h0m43s, 1 path(s) installed: - Michienne Dixon liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990

30 67

flattengraph.pl
by Gregory Edigarov 14 Jan '09

14 Jan '09

Hello, I have some problems with peaks on my mrtg, therefore I went to list archives on mrtg,org, and saw what's available. Then I found out that there is some script called flattengraph.pl, which I believe could help me with the situation. However this program is not available anymore and I cannot find and download it anywhere. So if some good soul will give me a link, or send me the file, I will be really grateful. Thanks a lot in advance. -- With best regards, Gregory Edigarov

3 4

Re: Approach to allocating netblocks
by Aidan Whyte 14 Jan '09

14 Jan '09

I guess it might depend on the general profile of your customers' requirements, but I'd imagine that non-contiguous blocks will be far more efficient in the long run, with the added benefit of no need for customers to pursue a renumbering plan every N years which should nearly always be avoided in any case imho. Obviously, the smaller the average block size the less efficient it becomes. If the customers are honest in their expected future ip address requirements it shouldn't be that often that they'll need more address space in any case. Aidan 2009/1/14 Frank Bulk <frnkblk(a)iname.com>: > Secondary IPs, additional documentation and confusion, and less efficient > use of address space, are just a few negatives of assigning more netblocks. > > Frank > > -----Original Message----- > From: Aidan Whyte [mailto:aidanwhyte@gmail.com] > Sent: Wednesday, January 14, 2009 10:35 AM > To: frnkblk(a)iname.com > Subject: Re: Approach to allocating netblocks > > Perhaps I'm missing something, but I've never seen much of a problem > with non-contiguous blocks for customer address space expansion..

1 0