- Test - lists.nanog.org

Avaya CNA 336 questions from other users.
by Drew Weaver 04 Jun '07

04 Jun '07

I have a hard time finding people who know what an Avaya converged network analyzer is in my social circle, so I turn to you folks to see if anyone has any experience with them. We have had one deployed at our edge for awhile and I wanted to compare notes on performance with other folks who also use this product. Any off-list contact would be appreciated. Thanks, Andrew

1 0

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
by Robert Bonomi 04 Jun '07

04 Jun '07

> From owner-nanog(a)merit.edu Mon Jun 4 13:54:55 2007 > Subject: Re: Security gain from NAT (was: Re: Cool IPv6 Stuff) > Date: Mon, 4 Jun 2007 14:47:06 -0400 > > On 4-Jun-2007, at 14:32, Jim Shankland wrote: > > > Shall I do the experiment again where I set up a Linux box > > at an RFC1918 address, behind a NAT device, publish the root > > password of the Linux box and its RFC1918 address, and invite > > all comers to prove me wrong by showing evidence that they've > > successfully logged into the Linux box? > > Perhaps you should run a corresponding experiment whereby you set up > a linux box with a globally-unique address, put it behind a firewall > which blocks all incoming traffic to that box, and issue a similar > invitation. > > Do you think the results will be different? Consider the possible *FAILURE* modes. e.g. (1) where somebody brings up _another_ path between the LAN that that box is onn, and the public internet, with no translations or other protections whatsoever. (2) where the 'protection box' "fails open" -- e.g. passes all traffic without modification. NAT/PAT is 'belt and suspenders', but it *does* provide an additional layer of protection, _if_the_primary_protection_fails_. That 'additional protection' may or may not be 'significant', depending on one's viewpoint.

1 0

NANOG40 agenda changes
by Steve Feldman 04 Jun '07

04 Jun '07

Since the first session went long, we are rearranging things a bit: - This morning's session will resume at 11:40 - Randy Bush's talk moves from today to Wednesday at 10:30, and the rest of the agenda shifts 15 minutes later that day. The complete updated agenda is at: http://www.nanog.org/mtg-0706/topics.html Steve

1 0

Re: NAT Multihoming
by Stephane Bortzmeyer 04 Jun '07

04 Jun '07

On Sun, Jun 03, 2007 at 07:33:45PM -0700, Stephen Satchell <list(a)satchell.net> wrote a message of 29 lines which said: > The last time I renumbered, I found that quite a few people were not > honoring the TTLs I put in my DNS zone files. [...] Custom customer > zone files hosted elsewhere? Do not forget that applications have their own caches, too, and they typically ignore completely the DNS TTL. A typical Web brower calls getaddrinfo() once and use the IP address as long as it is not restarted.

2 1

Re: NAT Multihoming
by Iljitsch van Beijnum 04 Jun '07

04 Jun '07

On 4-jun-2007, at 4:33, Stephen Satchell wrote: > The last time I renumbered, I found that quite a few people were > not honoring the TTLs I put in my DNS zone files. I would clone > the new address and monitor traffic to the old address -- and it > took up to seven days for the traffic to the old address to die > down enough that I could take it out. Are you sure this was the result of DNS servers increasing the TTL, not simply applications doing their own caching?

1 0

Re: Providers that carry IPv6
by Jeroen Massar 04 Jun '07

04 Jun '07

Antonio Querubin wrote: > On Mon, 4 Jun 2007, Jeroen Massar wrote: > >> Please at least honor: ip6.de.easynet.net/ipv6-minimum-peering.txt > > A typical trans-Pacific path is significantly longer than a typical > trans-Atlantic path. The < 40 ms policy recommendation in the above is > unrealistically small for those of us out here in the Pacific Ocean > where it takes roughly 50 ms just to reach only halfway across the > ocean. It also favors a system of short IPv6 paths through multiple > tunnels that add significant latency which is somewhat self-defeating. > Ideally you want an IPv6 path between point A and point B to be > reasonably close in latency to the IPv4 path. That is indeed the intention of that document, therefor that "<40ms policy" can be mostly ignored for that type of links. > In the absence of > ubiquitous, diverse, native IPv6 peering between Tier 1 providers, which > I suspect will still take a while to develop, currently the only > realistic way of keeping the latency delta minimized between an IPv4 > path and an IPv6 path is to have your own diverse set of tunnels, even > if it means tunnels that go halfway around the world. I don't see a real reason why one needs to tunnel around the world. Unless you are indeed in a very remote location where no transit provider is providing IPv6 yet. If that is still the case though I definitely would suggest that you start kicking your current IPv4 transits *VERY* hard in several naughty places to get them going and start providing it. At the very least they can do a tunnel over their own infrastructure and terminate you at their ends. > The alternative > is IPv6 connectivity that really stinks because packets have to bounce > through multiple tunnels unnecessarilly. Try to avoid that at all cost of course. But if that is the only way, then for the time being that is then the only solution. Of course document it properly and kick upstreams to fix it. Greets, Jeroen

1 0

Peering Personals@Peering BOF XV at NANOG 40 in Bellevue
by William B. Norton 04 Jun '07

04 Jun '07

[ If you are NOT ATTENDING this NANOG in Bellevue, please disregard ] We have some time at this Peering BOF XV for some Peering Coordinator introductions. This is a chance for Peering Coordinators to introduce themselves to the group before we break for beers. How does this work? We solicit Peering Coordinators (with this note), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Open" vs. "Selective" vs. "Restrictive" policies etc.). >From the answers we will select a set of ISP Peering Coordinators to share a short (2-3 minute) description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in the Peering Personals section of the Peering BOF, please reply to me (privately) with the answers the following 8 questions: ------------------------------ 1) Name: ____________________ 2) Title: ___________________ 3) Company: _________________ 4) AS#: _____________________ 5) Check which one best applies: ___ We are an ISP (sell access to the Internet) --OR-- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy --OR-- ___ We are Access-Heavy 6) Check whichever ones apply: ___ We are an "Open" peer (The answer to peering requests is YES) ___ We are a "Selective" peer (The answer to peering requests is YES but we may have a few 'objective and meetable' pre-requisites such as "three geographically diverse locations with 10Mbps on each coast") ___ We are a "Restrictive" peer (The answer to peering requests is generally NO) ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering 7) Current Peering Locations: _______________________ 8) Planned (3-6 mos) Peering Locations: _______________________________ Bill -- //------------------------------------------------ // William B. Norton <wbn at equinix.com> // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

1 0

IPv6 Training?
by Alex Rubenstein 03 Jun '07

03 Jun '07

Does anyone know of any good IPv6 training resources (classroom, or self-guided)? Looking to send several 1st and 2nd tier guys, for some platform/vendor-agnostic training. Any clues? Thanks.. -- Alex Rubenstein, AR97, K2AHR, alex(a)nac.net, latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net

17 20

NANOG40 PGP Key Signing
by Majdi Abbas 03 Jun '07

03 Jun '07

Just a reminder, The keysigning sessions are going to be during the morning breaks during the general session, Monday through Wednesday, in the Lake Sammamish room. If you haven't already done so and plan to participate, please add your key to the keyring at: http://biglumber.com/x/web?keyring=3816 Additional information is available on the NANOG website, at: http://www.nanog.org/mtg-0706/pgp.html Or follow the links from the agenda. If you have any further questions, feel free to contact me off-list. Thanks! --msa

1 0

Re: IPv6 Advertisements
by Iljitsch van Beijnum 02 Jun '07

02 Jun '07

On 2-jun-2007, at 17:25, Ross Vandegrift wrote: > Am I under some misconceptions about IPv6 routing policies here? There are no IPv6 routing policies. Everyone gets to decide which prefixes to accept and which to reject on their own. However, unlike IPv4, there are currently pretty much only two flavors: /32 and /48. So if you have a /32 and start announcing a bunch of /36s, or you have a /48 and start announcing /52s, it's likely that at least some people out there aren't going to accept those. (Nor /48s in blocks that are carved up as /32.) So I expect people who are in your position to start requesting blocks larger than /32 or /48 in order to be able to deaggregate, or even request multiple independent PI blocks. It will be interesting to see what this means for the number of PI requests and speed at which the global IPv6 routing table grows. It would be nice if rather than fight about how difficult it should be to occupy a slot in the routing table, with both "too difficult" and "too easy" having painful consequences, we could work something out using regional address blocks or something so it's not necessary for a router on one side of the globe to have all the more specifics that are only relevant on the opposite side of the globe. Obviously we don't want metro addressing with mandatory interconnection all over the place, but common sense suggests that there is some middle ground where it's possible to have address space that's at least portable within a certain region, but we get to prune the routing tables elsewhere.

2 1