October 2009 - Test - lists.nanog.org

Network topology
by Colin Alston 15 Nov '13

15 Nov '13

Hi all I'm considering trying to come up with some means to automatically detect a networks topology and draw pretty pictures. This is somewhat boring though if a network isn't well arranged with VLANs and q-tag trunk routers and so on (It will just look like a big cloud of junk connected off an assumed switch). Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP?

9 12

Inventory and workflow management systems
by vijay gill 26 May '13

26 May '13

What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay

10 13

ISP port blocking practice
by Zhiyun Qian 13 Sep '10

13 Sep '10

Hi all, What is the common practice for enforcing port blocking policy (or what is the common practice for you and your ISP)? More specifically, when ISPs try to block certain outgoing port (port 25 for instance), they could do two rules: 1). For any outgoing traffic, if the destination port is 25, then drop the packets. 2). For any incoming traffic, if the source port is 25, then drop the packets. Note that either of the rule would be able to block outgoing port 25 traffic since each rule essentially represent one direction in a TCP flow. Of course, they could apply both rules. However, based on our measurement study, it looks like most of the ISPs are only using rule 1). Is there any particular reason why rule 1) instead of rule 2)? Or maybe both? Also, is it common that the rules are based on tcp flags (e.g. SYN, SYN-ACK)? One would think block SYN packet is good enough. Regards. -Zhiyun

52 121

Upstream BGP community support
by Andy B. 04 Jun '10

04 Jun '10

Hi, Quick question: Would you buy transit from someone who does not support BGP communities? Here is the story: My company is pushing several GBit/s through various upstream providers. We have reached the point where we rely on BGP communitiy support, especially communities that can be sent to the upstream to change the way he announces our prefixes to his peers/transits. While most decent upstream providers support this kind of traffic engineering, one of them refuses to send and accept BGP communities. I tried to contact my upstream several times through different channels to get some background as to why they would not be able to provide us this service, but all we get is tickets that get closed without an answer. Management itself does not seem to bother either. Is this normal or is it too much to ask for BGP communities from an upstream who has points of presence in the US, Europe and Asia? Andy

27 58

Wireless bridge
by Peter Boone 05 Apr '10

05 Apr '10

Hi NANOG, I'm looking for some equipment recommendations for a wireless bridge between two locations approximately 500-800 meters apart. The current setup for this company has been extremely unstable and slow. I don't have a lot of experience in this area so I was hoping someone could give me a few pointers. Currently, both locations are using Linksys WRT54GL's flashed with DD-WRT firmware (Yes, 802.11g. All extra bells and whistles are disabled in the firmware. They were set up for WDS so other wireless clients could connect to the same access point, with varying degrees of success. Not very important). They are connected to SmartAnt 2300-2500 MHz 14 dBi directional antenna mounted on the roof (extended pretty high for perfect line of sight). I'm not sure when they got these antenna exactly but I'm told it was when WiFi was very new. The network is very small so both locations share the same subnet (192.168.1.0/24). They have gone through numerous Linksys access points over the years. The wireless settings are tweaked as best as possible, and we have found the connection to be most stable when the TX is limited to 6-9 Mbps. We have explored other options as well. An internet connection at each location + VPN is out due to very slow upstream speeds (the buildings are in an industrial area, ADSL is the only option.) The max they offer on regular business accounts is 800 kbps up. T1 lines are even slower and even more expensive. They won't offer us any other solutions such as fibre. We have considered running fibre/coax but there is too much construction activity and other property in the way. I'm looking into RouterBOARD right now, considering a RB433AH and R52H wireless card, but I'm not sure this will actually solve the problem. It's difficult to determine if the issue is with the antennas or access points (for example, after a good thunderstorm, the wireless link will be down for at least 12 hours, but will fix itself eventually. Resetting either access point will keep the link down for at least 30 minutes. Using an airgun on the access points tends to make them more reliable, even if they are clean and dust free. From the admin interface, each access point will report seeing a very good and strong signal from the other, yet they refuse to communicate until they feel like it a few hours later.) Any suggestions welcome. I'm sure you can tell cost is a bit of a factor here but it will be easy for me to justify a higher price if I'm confident it will be effective. While I'm at it, I've been reading along on the list for over a year now; thanks everyone for sharing your real world experiences :) Peter

23 36

Voice Operators' Group: voiceops.org
by Hiers, David 12 Feb '10

12 Feb '10

Hi Everyone, I'm pleased to announce that the Voice Operators' Group has found an excellent home. Our web site, www.voiceops.org has a good home (thanks Scott!), while Jared, Daniel, and all the great folks over at nether.net are hosting our list server. If VoiceOps can do for voice anything close to what NANOG has done for IP, we'll all owe much to the people that are making this happen. email: voiceops-subscribe(a)voiceops.org web: https://puck.nether.net/mailman/listinfo/voiceops Thanks, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

26 39

Tucows vs Postini
by Paul Stewart 24 Nov '09

24 Nov '09

Hi folks... Anyone have much experience with outsourcing antispam/antivirus to Tucows? We use Postini today and are overall pleased. The Tucows pricing seems to be MUCH lower so curious on any feedback... Thanks, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."

5 5

IPv6 Deployment for the LAN
by Ray Soucy 23 Nov '09

23 Nov '09

Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/

42 140

Strip AS in BGP peer
by Sherwin Ang 21 Nov '09

21 Nov '09

Hello Nanog, am not sure if i should have placed this on the cisco-nsp or the juniper-nsp but someone may have a direct answer. well here it goes. we'll soon form a new internet exchange and i would like to suggest a model in the route-server wherein the route-server would strip out it's own AS and give the neighbors/peers the AS's of the members. I have seen this in Any2IX but i have no idea on how to implement it as if i am the Any2 route-server. if you could point me to the right direction or reading, i could take it from there. -Sherwin

5 4

Minimum IPv6 size
by Seth Mattinen 12 Nov '09

12 Nov '09

Since we're on the topic of what's commonly accepted in IPv4 land (a /24), what's the story in IPv6 land? It seems to me that a /32 is a fur sure thing, but others will accept down to a /48, too. ~Seth

8 11