Why is VIP 622 calling level3?

Ronald_Jeremy

SatelliteGuys Pro
Original poster
Jan 2, 2005
3,429
0
Rock Ridge!!!!!!!!!!!!
I turned on the logs in my router yesterday and my VIP 622 is phoning home frequently to 2 addresses. One is Echostar which is understandable. But it is also phoning home to level3.

Level3 is a major internet backbone provider.
 
Level 3 is also a co-location provider. It's very possible that E* has some stuff co-located off campus at a Level3 co-lo facility.

Or, they just never SWIP'ed the IP space.

Or, they never requested DNS delegation of that ip range from their upstream provider, which might be level3, who has default PTR records in place.

Lots of possibilities. If I had the IP I could do more homework, but I'm not going to sift through router logs. I don't even log with that much verbosity.
 
69.25.21.153

Belongs to logmein.com. DNS SOA for the zone is handled by ns2.3amlabs.com, which is a domain owned by logmein.com.

Must not be the same IP as I see no L3 in the mix. Everything to this IP appears go go through InterNAP (as10913).

Must not be the same IP the OP is talking about. If the 722's are calling home to that IP, it would be really bizarre.
 
Belongs to logmein.com. DNS SOA for the zone is handled by ns2.3amlabs.com, which is a domain owned by logmein.com.

Must not be the same IP as I see no L3 in the mix. Everything to this IP appears go go through InterNAP (as10913).

Must not be the same IP the OP is talking about. If the 722's are calling home to that IP, it would be really bizarre.

Oops:eek:. Wrong log.

Try 4.71.42.136
 
OrgName: Level 3 Communications, Inc.
OrgID: LVLT
Address: 1025 Eldorado Blvd.
City: Broomfield
StateProv: CO
PostalCode: 80021
Country: US
Note the state that it's located in. It's nothing more than a co-located server that E* is using.
 
Note the state that it's located in. It's nothing more than a co-located server that E* is using.
I looked up that address before I even posted the thread. That address is level3's HQ. Contact Us


If the DNS info hasn't been updated for the ip AND it is in fact an echostar server, why in the hell do they have it phoning home to two different places?
 
Redundancy. What if one of those machines go down ?
Then you just assign the ip address to the other machine. Which is the premise behind the TCP/IP protocol and the reason the internet was designed the way it was.

Even if that were the reason, it should still only contact one. It would only contact the second if the first were down. Kind of like primary and secondary DNS servers. I wish I had a way to log what was being sent.

I'll have to look into that.
 
Level3 offers services like a content delivery network (CDN) which is essentially local caching of data. It's comparable to Limelight.com and Akamai.com. Sometimes the Limelight and Akamai hosts appear with addresses of the ISP's data center that contains the CDN hosts.
More sophisticated customers of these CDNs have actual applications running on those local cache hosts, so it can be more than just caching, it can be data collecting and full-fledged web sites.
All so you can get your TV working quickly no matter how many people are trying to get that same Video-On-Demand content!
Most of the selection of which host you use is hidden behind DNS and smart routing technologies.
 
Then you just assign the ip address to the other machine. Which is the premise behind the TCP/IP protocol and the reason the internet was designed the way it was.
So what happens during the time when the 1st machine goes down and they re-assign it to a 2nd machine ? And if Dish has a 2nd machine sitting around doing nothing, just waiting for the 1st to possibly fail, why not hook it up and use it ?

Using your logic, and since you mentioned DNS, why do we have primary DNS, secondary DNS, tertiary, and so on ? Why not just wait for a machine to go down and "just assign the ip address to the other machine".
 
So what happens during the time when the 1st machine goes down and they re-assign it to a 2nd machine ? And if Dish has a 2nd machine sitting around doing nothing, just waiting for the 1st to possibly fail, why not hook it up and use it ?

Unused hardware is bad... I prefer setting up zones and having either taking over the other's load in the event of a failure. Kind of a poor man's active / passive cluster ;)

Using your logic, and since you mentioned DNS, why do we have primary DNS, secondary DNS, tertiary, and so on ?

I always thought it was a geek contest to see whose resolv.conf file is the longest :D

Why not just wait for a machine to go down and "just assign the ip address to the other machine".

What do you do with load balancers where the load balancer fails and it isn't redundant? Arrggh.
 
The idea of primary, secondary, tertiary DNS is just for DNS servers.
We're just talking about the host you're trying to reach.

It's a lot more sophisticated than you're making it.
Perhaps you can read more at Akamai.com for how they do it.
These systems, when they go down, don't affect anyone. It's really that good.
 
I can't even begin to discuss what's right and wrong in this thread thus far. :D

You can't just take an IP and assign it to another box on another network. The IP block that the address falls in must be re-routed to the new location. The Internet as we know it at a high level routes based on Antonymous System Number instead of IP address. Providers who are multi-homed run a protocol called BGP (Border Gateway Protocol) that basically announces to the entire Internet "This is my ASN, and these are the subnets I am aware of (either directly connected, statically routed, or learned via some type of igp such as ospf) within my ASN". Such announcements generally never have a prefix smaller than /24 (~252 addresses or less), and most providers will filter any announcements for prefixes smaller than /24. So, you won't see single IP addresses in the global routing table -- and if you do, they will almost unanimously be ignored.

Now, most major networks (and I'm sure that level 3 and E* both fall in this category) will be peered with two or more upstreams. This is transparent at the IP level, because those BGP announcements will tell "the rest of the world" about the paths available to get to the network.

Regardless of multiple paths being available, routers will insert only the best path into their routing tables. If this path becomes unavailable, the route will get replaced with the next best path. This is not completely instantaneous but it's pretty fast...

Now, this doesn't cover a number of scenarios. For example, what if the power goes out to the router that is announcing the networks, or the machine itself, or both. Now, of course, this is preventable by having multiple routers announcing the same ASN in different parts of the campus with different power feeds, running an IGP to handle changes/failures in the internal routing structure, having multiple segregated machines that can respond to the same IP, fault tolerant load balancers / traffic directors, etc etc...

But, being that you can pick up a 1/4 rack of co-location for dirt cheap nowadays, the cost/benefit ratio of building a massively redundant network versus putting boxes on two separate networks is fairly significant. It's generally easier and cheaper to have two boxes on two networks with two different providers on two different power grids with two different ip addresses, and have your STB's "call home" to two different IPs that exist in two completely different subnets.

They could do it through DNS by having a common hostname that they control with a short TTL, and change the IP within DNS. I've seen DNS records cached for hours or days even with a short TTL though, especially with large providers (i.e. the ones that lots of 722 owners would have at home, comcast, verizon, etc) ignoring short TTLs to save on outbound DNS traffic -- RAM is cheaper than bandwidth after all, so that's an easy enough option to rule out.

That's the short version. Redundancy of internet-facing services is a very, very complex subject. It's also a big part of my job and has been for most of my adult and part of my non-adult life.

The really short version -- most people usually do more than one thing to keep things redundant. No matter how much redundancy you have on your primary systems and within your network, the big guys almost always throw offsite boxes on a completely separate network.
 
Oops:eek:. Wrong log.

Try 4.71.42.136

Looks like E* definitely has "something" to do with the IP, as the last hop before the host is:

ECHOSTAR-SA.hsa2.Denver1.Level3.net.

The IP hasn't been SWIP'ed, it's just listed as part of a huge Level3 aggregate:

NetRange: 4.0.0.0 - 4.255.255.255
CIDR: 4.0.0.0/8
NetName: LVLT-ORG-4-8

Also, it doesn't look like Level3 has delegated DNS for the IP range to anyone, so there's not a lot to learn there either.

That gives us a little less information. We can tell that the host is most likely in/near Denver based on the DNS information of the next to last hop.

Since Level3 provides co-location and leased line services, I can't really tell if this is going to one of their co-lo facilities, or directly to the E* campus. My *guess* is that it's co-lo as there's no evidence of a point to point in there, but depending on what type of technology they use for the last mile, there won't always be such evidence.
 

Was this a bad install?

Yankees fan here!! How often can I move?

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)