Metro E WAN Integration

tbrooks25 · ‎09-24-2007

Hello,

We have just started to integrate a new 3 point metro-e wan connection to our main school office. I have attached configurations from both the main and remote site as well as a basic diagram of how everything physically connects. The problem I am having is on the remote side. I can reach the remote catalyst from the main site, but I cannot reach the devices on the other side of the remote catalyst however the remote catalyst can see devices on it's side as well as devices at the main site.

If you have any questions or need further configuration data please let me know.

The previous connection was a T1 connection through a 2620 but this is not compatible with metro-e so we are trying to connect directly through the catalysts.

The other two connection points will be connecting through cisco routers that are compatible with metro-e so i don't think I'll have problems with those sites.

Joseph W. Doherty · ‎09-24-2007

Not enough information to be sure, but from your description where remote devices can only be reached from the remote Catalyst sounds like either they don't have a gateway or your routing is not advertising routes properly end-to-end (like the subnet those remotely unreachable devices reside on).

tbrooks25 · ‎09-25-2007

We are running eigrp across the board so if it's a routing problem either I have set the wrong statement or my eigrp statements are wrong.

Keep in mind all of this is live and working over our existing T1 but when we try to cut over to the metro-e, we get the problems I stated earlier. We have confirmed connection to/from the main site on metro-e from all of our locations.

Joseph W. Doherty · ‎09-25-2007

Been a long while since I've used EIGRP, so shooting a bit in the dark, but wonder why on "main" you have 10.100.171.1 defined both on FastEthernet3/20 and vlan1 as a secondary?

Also, why is "remote" GigabitEthernet3/3 defined 10/full while "main" FastEthernet3/20 is default (100/auto)? (This issue, if an issue, unlikely to have anything to do with your problem.)

Why does "remote" have "ip route 0.0.0.0 0.0.0.0 10.100.171.1" and "main" have "ip route 0.0.0.0 0.0.0.0 10.100.177.2"?

Why doesn't "main" have 10.100.171.0/24 in "router eigrp 100"? (Perhaps the assumption is "redistribute static" will pick it up? True with default?)

tbrooks25 · ‎09-25-2007

"why on "main" you have 10.100.171.1 defined both on FastEthernet3/20 and vlan1 as a secondary?"

Look again... Vlan 1 has 177.1 as a secondary not 171.1. 177.1 is a network at our main site.

"why is "remote" GigabitEthernet3/3 defined 10/full while "main" FastEthernet3/20 is default (100/auto)?"

The remote site's Embark cisco device port is set at 10/full so we have to set our catalyst port at 10/full in order for it to function correctly. The main site Embark cisco device is set at 100 auto hence why we have the main site port set at 100/auto.

"Why does "remote" have "ip route 0.0.0.0 0.0.0.0 10.100.171.1" and "main" have "ip route 0.0.0.0 0.0.0.0 10.100.177.2"?"

Remote has 171.1 as it's route because that is the IP on the port of the catalyst switch at main. The 177.2 address is our gateway to the internet. In other words all the sites tie to the main site then route to the internet from the main site.

"Why doesn't "main" have 10.100.171.0/24 in "router eigrp 100"?"

This is where I am a bit confused with eigrp. Shouldn't the statement on the remote site "redistribute connected" take care of this? I can connect to the remote site from the main site without an eigrp statement so what does that mean???

Joseph W. Doherty · ‎09-25-2007

Yup, misread .171. vs .177. for two of my questions, although using a default for the Internet path, believe you might be able to advertise it via EIGRP.

Just wondered about the speed mismatch. Your answer not unexpected.

On the last issue, again I'm very rusty with EIGRP, but I would expect it might need to be advertised from all routers that touch the subnet. Granted the "redistributed connected" should do so on "remote", but the question stands about "main". (Also some routing protocol treat redistribution into the protocol a bit differently vs. using network statements.)

As to your question about getting to the remote site from main, since remote shares a connected subnet with main, this would work (main to/from remote) by default even without routing. However, if you ping LAN side gateway addresses, or source pings from LAN side interface on either main or remote, you might find they fail.

One thing to check, do both 4500s see all the far side LAN side subnets in their route tables?