- Test - lists.nanog.org

Re: AS Connectivity Lookup
by Hank Nussbacher 07 Mar '12

07 Mar '12

At 09:29 07/03/2012 -0800, Radke, Justin wrote: >How can I easily view the current peering relationship of a particular AS? >Assume the AS you are researching does not have a looking glass and you are >not going to do lookups from the top 10 providers route servers to get some >glimpse of their connectivity. In my particular search >bgplay.routeviews.org does >not have any information and as-rank.caida.org is out of date. In the past >there was a great website called webtrace.info but it is no longer online. > >Any suggestions? Try: http://www.fixedorbit.com/search.htm and do an ASN search. -Hank

2 1

VLAN Troubles
by Alan Bryant 07 Mar '12

07 Mar '12

I hope everyone is having a better workday so far than I am. I am trying to clean up the network for the Hospital I work for, and part of that is creating two VLAN's for two separate subnets on our network. Before, it was not separated by VLANs. We are also replacing our aged Juniper firewall with an ASA. I'm very new to VLAN's, so I am hoping this is something simple that you guys can help me out with. We have two switches that do not seem to be passing VLAN traffic. The two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco switch appears to be functioning fine, but the Dell switch is only passing traffic to the Cisco that is on the default untagged VLAN1. Our second VLAN is not getting passed to the Cisco at all, I am not seeing any packets tagged with the particular vlan in Wireshark. I have Port 1 on the Dell switch connected to port 29 on the Cisco switch, and port 1 on the Cisco switch connected to the ASA. I have the following config on the relevant ports on the Cisco switch: interface GigabitEthernet0/1 description ASA 5505 switchport trunk encapsulation dot1q switchport mode trunk interface GigabitEthernet0/29 description Radiology Switch switchport trunk encapsulation dot1q switchport mode trunk Here is the config for the Dell switch: interface ethernet g1 speed 1000 duplex full exit interface ethernet g2 speed 1000 duplex full exit interface ethernet g3 speed 1000 duplex full exit interface ethernet g4 speed 1000 duplex full exit interface ethernet g5 speed 1000 duplex full exit interface ethernet g7 speed 1000 duplex full exit interface ethernet g9 speed 1000 duplex full exit interface ethernet g10 speed 1000 duplex full exit interface ethernet g12 speed 1000 duplex full exit interface ethernet g14 speed 1000 duplex full exit interface ethernet g15 speed 1000 duplex full exit port jumbo-frame interface ethernet g1 switchport mode trunk exit interface ethernet g24 switchport mode trunk exit vlan database vlan 12,22 exit interface range ethernet g(2,4,7,12,14-15) switchport access vlan 12 exit interface vlan 12 name Radiology exit interface vlan 22 name Guest exit interface vlan 1 exit Anyone have any ideas or pointers? Is there more information that I need to provide? Vlan1 works just fine, of course. It is Vlan 12 that is not working. Everything on the Dell switch is communicating with each other just fine on the same subnet.

10 13

IETF - Overlapping IPv4 Address Support
by Guru NANOG 07 Mar '12

07 Mar '12

Adding four more bits to the Left of the Source Address and setting those bits to 1111 (0xF) can help to start the migration to "Regions" and more IPv4 Addresses - Using and Re-Using legacy spectrumhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-spa… 16 /8s for "Future use" - it looks like the "Future" has arrived 240/8 Future use 1981-09 RESERVED [15] 241/8 Future use 1981-09 RESERVED [15] 242/8 Future use ... 253/8 Future use 1981-09 RESERVED [15] 254/8 Future use 1981-09 RESERVED [15] 255/8 Future use 1981-09 RESERVED [15] http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13. Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the network into regions. Two regions may use overlap IPv4 address space. This is particularly important when the Internet is transitioning to IPv6. The Wi-Fi SP may not have enough unique public IPv4 addresses to globally address large number of Wi-Fi device.

9 8

L3 VPN Management
by Leigh Porter 07 Mar '12

07 Mar '12

Folks, I have a number of L3 MPLS VPNs. For example, there is the WiFi management VPN (WiFi management interface). There is th systems VPN where things like RADIUS servers, Databases talk. There is a VPN for LTE OAM. There are alsomseparate VPNs for other LTE functions. All OK. Then are various sites I have a cluster of ops servers, syslogs, things that go ping, instances of cacti and our various vendors management systems. They all sit behind a firewall. What's the nicest way of allowing the ops servers all talk to each VPN instance? At the moment I just us pretty normal L3VPN techniques so that every VPN sees routes tagged with the ops VPN target community and so that the ops VPN sees all the other VPN routes but the division between VPNs is maintained. Or, would it be nicer to have the firewall have a foot in each VPN, advertise routes to ops systems to each VPN instance and receive routes from all the other VPNs? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

3 2

FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
by David Swafford 07 Mar '12

07 Mar '12

Hi Everyone! I had several requests for more feedback on our FCoE experience, based on my comments from a thread last week, so I'm writing here with a bit more background on our project in hopes that it saves some pain for others :-). I'm with a sizable health insurance provider in the mid-west, and we've typically focused on technology vs. headcount as an overal strategy. Based on that, we upgrade much more often than some of our peers in the industry because techology is still cheaper than long-term staffing costs. Last fall, we were faced with an issue of both power and rack capacity constraints in our primary datacenter, which is just three years old now. As various ideas were on the table, which included taking out a section of IT cubes to expand the DC, the most appealing idea was to consolidate our server and network infrastructure into what was coined our "High Density Row". We transitioned from Cat6500s as access to a Nexus 5K deployment, using 5Ks as both distribution and access for the new HD row. We didn't like how oversubscription is handled on 2K FEXs when it comes to 10G links, so for the situation here all 5Ks made the most sense. Our capacity needs couldn't justify 7Ks and while they would have been cool to have, we didn't want to blow money just because. Our SAN is an EMC Symmetrix with Cisco MDS switches in between it and the hosts (Fiber Channel). In the new row, we deployed all hosts with CNAs (converged net adapters), which combine both FCoE storage and network in a single 10Gb connection. Since FCoE was new to all of us, we use a phased approach that the Nexus offered where we brough straight fiber channel connections into our distibution layer 5Ks and used the Nexus' FCoE proxy functionality to convert between true FC to FCoE. >From the host perpsective, it was only aware of FCoE connectivity to the Nexus. VSANs had to be created on the Nexus to map back to the FC VSANs on the MDS side, Virtual Fiber Channel (VFC) interfaces were created on the Nexus side, and a few other settings had to be configured. Overall though, the config wasn't huge, but the biggest hurdle for was that as the network guys, we had to learn the storage side to be able to properly set this up. So new terms like WWN (world wide name), floggy database, VSAN (a VLAN for storage), etc. Also, on the Nexus side, you have to enable the feature of FCOE, as Nexus OS is very modulular and leaves most options disabled during the initial setup. The painful part, which is probably what might be of most interest here, is that we hit a very strange and catrastrophic issue specific to QLogic's 8242 Copper-based (twinax) CNA adapter. As part of the burn-in testing, we were working with our server team to simulate the loss of a link/card/switch (all hosts were dual-connected with dual-CNAs to separate 5Ks). We were using the Cisco branded twinax cabling and QLogic's 8242 card (brand new HP DL580s in this case, new card, new 5K, new cabling). When a single link was dropped/diconnected PHYSICALLY (a shut/no shut is not the same here), the host's throughput on BOTH storage and network went to crap. Our baseline was showing nearly 400MB/s on storage (raw disk IO) tests prior to a link drop and 1-8 MB/s after! This siutation would not recover until you fully rebooted/power cycled the server. We had the same results accross every HP DL 580 tested, which was 5-6 of them I belive. We replaced CNAs, cables, and even moved ports across 5Ks. It didn't matter which cable, 5K, port, of card we used, all reacted the same! The hosts were all Windows 2008 Datacenter, simliar hardware, Nexus 5K on current code, twinax cabling. This situation led to a sev 2 w/ Cisco, the equivalant w/ HP, EMC, and QLogic. We used both the straight QLogic 8242 and the HP OEM'd version and the results were identical. QLogic acknowledged the issue but could not resolve it due not being able to grab a hardware level trace of the connection (required some type of test equipment that they couldn't provide and we didn't have). As part of our trail/error testing, we had our re-seller ship us the fiber versions of the same QLogic cards, becuase we eventually got down to a gut instinct of this being a copper/electrical anomoly. That instict was dead-on. Switching to the fiber versions, with fiber SFPs on the 5K side resolved the situation entirely. We are now able to drop a link with NO noticable degradation, back and forth, and eveyrthing is consistent again. We originally went the twinax route because it was signifiantly cheaper than the fiber, but in retrospect, as a whole, the danger posed was not worth it. You might ask, well... why would you intentially drop the cable? Think about a situation of doing a code upgrade on the 5K, since it's not a dual-sup box, you physcailly go through a reboot to upgrade it. That reboot right htere would have hosed our entire environment (keep in mind, the HD row's intent was to replace a signifiant portion of our production environment). You could also have a HW failure on a 5K. It kind of defeats the point of all this redundancy if your throuhput goes to hell when loosing a single path. As our storage guys best put it "i'd rather loose a path than have bad performance through it....based on how things alert, I'd know right away if a path were down, but not if it were severaly degraded." Btw, we've been rock solid on the fiber-connected CNAs ever since. We're still using copper on our connections to HP blade chassis though, which go to FLEX Fabric cards, as we couldn't produce the problem on those. For those wondering, we did rebuild several of the DL580s from scratch (all of this was a new deployment, thankfully!), we also went through many iterations of driver updates/changes/etc. Lots of head-banging and teamwork eventually got us squared away! This situation is a good example of why network guys NEED to have a great relationship with both server and storage guys (we're all really close where I'm at). Had there been tension/etc between the teams, this would have been signifiantky harder to resolve. Hope this helps, sorry for the long winded email :-), but I think those interested will find it beneficial. David.

5 6

Fwd: VLAN Troubles
by david peahi 06 Mar '12

06 Mar '12

---------- Forwarded message ---------- From: david peahi <davidpeahi(a)gmail.com> Date: Tue, Mar 6, 2012 at 9:47 AM Subject: Re: VLAN Troubles To: Alan Bryant <alan(a)alanbryant.com> Why don't you replace the Dell switches with Cisco 3560s, and that way you are working with a single implementation of the IEEE 802.1q trunking standard? I think the very existence of this email thread proves that much time and effort is wasted in the attempt to seamlessly interoperate devices from multiple vendors. In this email thread alone I counted 2 CLI's to be learned, 2 tech support organizations to call, and 2 hardware types to spare. David On Tue, Mar 6, 2012 at 8:07 AM, Alan Bryant <alan(a)alanbryant.com> wrote: > I hope everyone is having a better workday so far than I am. > > I am trying to clean up the network for the Hospital I work for, and > part of that is creating two VLAN's for two separate subnets on our > network. Before, it was not separated by VLANs. We are also replacing > our aged Juniper firewall with an ASA. > > I'm very new to VLAN's, so I am hoping this is something simple that > you guys can help me out with. > > We have two switches that do not seem to be passing VLAN traffic. The > two switches are a Dell Powerconnect 5324 & a Cisco 3560G. The Cisco > switch appears to be functioning fine, but the Dell switch is only > passing traffic to the Cisco that is on the default untagged VLAN1. > Our second VLAN is not getting passed to the Cisco at all, I am not > seeing any packets tagged with the particular vlan in Wireshark. > > I have Port 1 on the Dell switch connected to port 29 on the Cisco > switch, and port 1 on the Cisco switch connected to the ASA. > > I have the following config on the relevant ports on the Cisco switch: > > interface GigabitEthernet0/1 > description ASA 5505 > switchport trunk encapsulation dot1q > switchport mode trunk > > interface GigabitEthernet0/29 > description Radiology Switch > switchport trunk encapsulation dot1q > switchport mode trunk > > Here is the config for the Dell switch: > > interface ethernet g1 > speed 1000 > duplex full > exit > interface ethernet g2 > speed 1000 > duplex full > exit > interface ethernet g3 > speed 1000 > duplex full > exit > interface ethernet g4 > speed 1000 > duplex full > exit > interface ethernet g5 > speed 1000 > duplex full > exit > interface ethernet g7 > speed 1000 > duplex full > exit > interface ethernet g9 > speed 1000 > duplex full > exit > interface ethernet g10 > speed 1000 > duplex full > exit > interface ethernet g12 > speed 1000 > duplex full > exit > interface ethernet g14 > speed 1000 > duplex full > exit > interface ethernet g15 > speed 1000 > duplex full > exit > port jumbo-frame > interface ethernet g1 > switchport mode trunk > exit > interface ethernet g24 > switchport mode trunk > exit > vlan database > vlan 12,22 > exit > interface range ethernet g(2,4,7,12,14-15) > switchport access vlan 12 > exit > interface vlan 12 > name Radiology > exit > interface vlan 22 > name Guest > exit > interface vlan 1 > exit > > Anyone have any ideas or pointers? Is there more information that I > need to provide? Vlan1 works just fine, of course. It is Vlan 12 that > is not working. Everything on the Dell switch is communicating with > each other just fine on the same subnet. > >

3 2

Re: VLAN Troubles
by Alan Bryant 06 Mar '12

06 Mar '12

Thank you for the suggestions, unfortunately none of them are working. I have tried with the uplink in general & trunk mode. I have allowed all vlans and allowed only the specific vlans I am using tagged and untagged, but it is still not passing vlan 12.

4 3

WW: Colo Vending Machine
by Jay Ashworth 06 Mar '12

06 Mar '12

Please post your top 3 favorite components/parts you'd like to see in a vending machine at your colo; please be as specific as possible; don't let vendor specificity scare you off. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

74 145

Centralized NOC Monitoring Solutions
by Eric Cables 06 Mar '12

06 Mar '12

I am evaluating outsourced NOC solutions, where all of the device monitoring and pro-active response is handled by a centralized NOC (NaaS? :-)). The goal is to reduce the day-to-day overhead of calling carriers to troubleshoot circuit problems, basic network troubleshooting when congestion occurs, pro-active response and notification when critical systems go down during off hours, etc. The focus is network related to start, but could branch out into servers in the future. Any feedback on: companies used, what to look for, and general thoughts on a centralized NOC approach would be appreciated. -- Eric Cables

2 1

Spread Spectrum NANOG Operational Alert - Source Addresses with 240 to 255
by Guru NANOG 06 Mar '12

06 Mar '12

Adding four more bits to the Left of the Source Address and setting those bits to 1111 (0xF) can help to start the migration to "Regions" and more IPv4 Addresses - Using and Re-Using legacy spectrum <spectrumhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-spa…>. The real Source Address is shifted 4 bits to the Right. The bits shifted off are placed in the Deprecated TOS field in the DDDD bits. The new TOS field has the SSSS.DDDD for the CPE. If a router attempts to reply or return to the Source Address it will hit one of the Regional Hubs. There are 16 of those. Agile CPE can reply in other ways to the Agile CPE that sent the Source Address with the 1111 bits. NANOG operators may want to study the evolution of 6to4 (2002:IPv4:0000) to 6RD (IPv4:IPv4) which tunnels using Re-Used legacy 32-bit addresses. The Legacy 32-bit Address Space will likely be around a long long time and be reused in many ways. That may increase the market value of /8s. Brokers are now selling /8s on the open market. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt <spectrumhttp://www.iana.org/assignments/ipv4-address-space/ipv4-address-spa…> 16 /8s for "Future use" - it looks like the "Future" has arrived 240/8 Future use 1981-09 RESERVED [15] ... 255/8 Future use 1981-09 RESERVED [15] http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs <http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13.> 014.13. <http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs-014.13.> Overlapping IPv4 Address Support Wi-Fi Service Provider may segment the network into regions. Two regions may use overlap IPv4 address space. This is particularly important when the Internet is transitioning to IPv6. The Wi-Fi SP may not have enough unique public IPv4 addresses to globally address large number of Wi-Fi device.

2 1