IP Routing

[stevenamills]

Wednesday, I had a client that had ATT Uverse Installed. They had purchased the package with 8 IPs. In all fairness, I'm sure that the kids that installed it were doing POTS last week and didn't know a static Ip from a toilet!

When they left, the 2Wire router they installed was showing a totally different IP than it should and they said it would take a while to "pull" the right one. Didn't sound right, but maybe these worked differently. I should have known better. It was set up as dynamic and would never get the right IP.

That was easily fixed and I hooked the local DLink to it and we could browse - get email etc.

Yesterday, we discovered that you can't get to the box from outside. Everything dies at the Chicago NAP. Try to explain that to a rep!! I finally convinced someone in Dallas to enter a ticket. As I write this, the tables are still screwed.

All of this is rather basic, but as I'm thinking about it, I'm wondering why we can browse since the outside world can't find our IP. Is it because the return packets are only traversing a hop at a time or??

Any insights would be helpful Thanks.

 

[TimeCode]

Strange!!! I've never seen that. What do you get when you use "tracert"?

 

[stevenamills]

The more I work with this the more confused I become. I'm really missing something.

Their Gateway is assigned a public address ending in .190 - this you can't reach. You can however reach my DLink attached to it which I assigned .185. Using the DLink as the "gateway" seems to solve it.

I'm confused.....

Oh - Any tracert to the .190 dies at the Chicago NAP. .185 reaches the DLink.

 

[thecoldone06]

Shot in the dark here but the Chicago NAP might be configured to drop ICMP packets to itself. This would block pinging/tracert to itself but forward to your DLink. Thats my only guess.