Re: Colo Vending Machine
> > The vending machine should use a card like an ATM/gift card, not accept cash. > You should be able to "charge" the card with some cash via a web portal and > keep the card in the facility in your space. If something is needed, one can > purchase it with the card. If there is no money on the card, a person can > add cash to the card via a web portal somewhere. Scenario: remote hands > guy arrives on site, needs an SFP, card doesn't have enough money on it, > calls me, I can add the cash to the card, he can purchase the SFP and leave > the card in the space for the next time it is needed. > > Actually pricing should be 8 bits, 16 bits, or maybe 32 bits for the really important stuff. George
Re: Level 3 - "legacy" Wiltel/Looking Glass bandwidth
As a Level 3 customer who had connectivity to some legacy Wiltel equipment I can also attest that service levels were pretty bad following that merger. We had a few memorable outages where escalations were necessary to get things resolved and folks familiar with the equipment were hard to find. In meeting with our account team we were able to get them to agree to roll us off the old gear which was really inadequate anyway for the purpose which happened to be an Option A MPLS NNI. It took them a long time to get that done but since then I would say that service levels have returned to the normal albeit somewhat less than desirable levels. We have had relatively few problems with our vanilla transit connections though. The same goes for some long haul that they inherited with the Broadwing acquisition. There were some glitches with some of the fiber grooming they did a while back but that seems to have passed. I also seem to be receiving less maintenance notifications overall from Level 3 as a general trend. Hope it continues. George
Re: PPPoE vs. Bridged ADSL
We like PPPoE on the edge because we can use RADIUS to apply policy to the subscribers for bandwidth management, class-of-service, SNPs, etc. You probably have some of these features via your DSLAM, but we found it easier to do via RADIUS with a web based GUI for our provisioning folks. So if we need to snip someone's Internet and leave voice or VPN packets alone due to an abuse issue for example, we can apply the policy that references the appropriate ACL. George smime.p7s Description: S/MIME cryptographic signature
Re: impossible circuit
A strange one indeed, especially if you have no connectivity to Sprint there. Since your fix was layer 2 you might be onto something. And you have the time it happened, and as we all know - somebody changed somethin' even if they won't fess up. I'm trying to think how you could cause something like that with a conventional DACS or one of the newer packet friendly types that might be more prone to a layer 2 bug since software is fairly new. Course it would make more sense if it was just crossed Ethernet rather than DS3 frames but who knows. There are plenty of carriers putting them in (including us). Shame it's not the kind of thing you can duplicate without being service affecting. George Jon Lewis wrote: After all the messages recently about how to fix DNS, I was seriously tempted to title this messsage "And now, for something completely different", but impossible circuit is more descriptive. Before you read further, I need everyone to put on their thinking WAY outside the box hats. I've heard from enough people already that I'm nuts and what I'm seeing can't happen, so it must not be happening...even though we see the results of it happening. I've got this private line DS3. It connects cisco 7206 routers in Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). According to the DLR, it's a real circuit, various portions of it ride varying sized OC circuits, and then it's handed off to us at each end the usual way (copper/coax) and plugged into PA-2T3 cards. Last Tuesday, at about 2:30PM, "something bad happened." We saw a serious jump in traffic to Ocala, and in particular we noticed one customer's connection (a group of load sharing T1s) was just totally full. We quickly assumed it was a DDoS aimed at that customer, but looking at the traffic, we couldn't pinpoint anything that wasn't expected flows. Then we noticed the really weird stuff. Pings to anything in Ocala responded with multiple dupes and ttl exceeded messages from a Level3 IP. Traceroutes to certain IPs in Ocala would get as far our Ocala router, then inexplicably hop onto Sprintlink's network, come back to us over our Level3 transit connection, get to Ocala, then hop over to Sprintlink again, repeating that loop as many times as max TTL would permit. Pings from router to router crossing just the DS3 would work, but we'd see 10 duplicate packets for every 1 expected packet. BTW, the cisco CLI hides dupes unless you turn on ip icmp debugging. I've seen some sort of similar things (though contained within an AS) with MPLS and routing misconfigurations, but traffic jumping off our network (to a network to which we're not directly connected) was seemingly impossible. We did all sorts of things to troubleshoot it (studied our router configs in rancid, temporarily shut every interface on the Ocala side other than the DS3, changed IOS versions, changed out the hardware, opened a ticket with cisco TAC) but then it occurred to me, that if traffic was actually jumping off our network and coming back in via Level3, I could see/block at least some of that using an ACL on our interface to Level3. How do you explain it, when you ping the remote end of a DS3 interface with a single echo request packet and see 5 copies of that echo request arrive at one of your transit provider interfaces? Here's a typical traceroute with the first few hops (from my home internet connection) removed. BTW, hop 9 is a customer router conveniently configured with no ip unreachables. 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms 56.154 ms 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 ms 56.196 ms 9 * * * 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms 81.821 ms 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 ms 77.128 ms 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms 53.200 ms 45.736 ms 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms 56.671 ms 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 ms 62.640 ms 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 ms 42.690 ms 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms 41.016 ms 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms 42.262 ms 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 ms 43.392 ms 22 * * * 23 sl-bb2
Re: PPP+RADIUS - routing subnets to end users - Framed-Route vs. Framed-IP-Netmask
We've always considered the WAN and LAN to be different objects so our history is to prefer the method you think is 'better.' Seems this model has been around since the dialin days. We also have customers with multiple routes so it seems a logical separation. Failover might be a bit more flexible too since you can control some parameters of the Framed Route. I know some people use RFC1918 addresses for WAN which might be a factor (we do not). Perhaps in some network strategies the lines between WAN and LAN may be a bit more blurred than ours. George On Mar 8, 2010, at 6:10 PM, Erik L wrote: > Scenario: with the help of RADIUS, routing subnets to end users connecting > via PPP. > > Discussion: pros/cons of using Framed-IP-Address+Framed-Route versus > Framed-IP-Address+Framed-IP-Netmask. > > We're talking here in generic terms, so as far as the behaviour of the LNS or > access concentrator or whatever else is receiving the Access-Accept and > terminating the ppp session, we're assuming more or less sane behaviour, > roughly as follows. In the first alternative, the IP address on the ppp link > is outside the subnet indicated by Framed-Route and one or more subnets are > routed via the link; one such subnet per Framed-Route attrib. In the second > alternative, the one subnet routed is that which contains the > Framed-IP-Address and is as large as the Framed-IP-Netmask indicates. > > I'm arguing to a colleague that the first alternative is "better", non-/32 > netmasks on a ppp link make no sense (since netmasks on point-to-point links > don't matter anyway), that the second alternative doesn't allow users to make > use of their allocated space as easily and effectively as the first > alternative, and that the second alternative is limited to routing one subnet > (though you might be able to mix Framed-IP-Netmask and Framed-Route > together?). > > Comments? How are others doing it and why? > > Erik > smime.p7s Description: S/MIME cryptographic signature
Looking for XO routing engineer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can someone from XO please contact me about this hijacked prefix: 72.44.152.0/24 I see it coming from AS35909 through AS2828. No luck getting anyone on the phone. Thanks George Carey -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) iEYEARECAAYFAk2x0jcACgkQJdlqYKAmD6FO2gCeJd6uToUghlKdjNd38JpAP2VZ SnwAoLQbpi9ygjIkCPDCU6TrnPOFc98r =OkTz -END PGP SIGNATURE-
