1700 with WIC-1ENET behind DSL modem

[sross35]

I am trying to setup a 1700 router behind a dsl modem. If I have routing on I cannot ping beyond the gateway from the 1700. If you turn off routing and specify a default-gateway, I can ping anywhere. I assume the above is maybe because I am not running a protocol between my router and my provider.

Anyways, when I have routing off and everything works fine from the router; when I hook up a workstation off of the other ethernet interface with dhcp and nat I cannot get out with my workstation. The workstation is off of the Ethernet0 and the dsl modem is plugged into the FastEthernet0. DHCP works but NAT and routing doesn't seem to work. Any help would be appreciated. Thanks

Yes I have IP NAT INSIDE on the inside int., IP NAT OUTSIDE on the out int., and ip nat inside source list 1 int fa0 overload with access-l 1 permit 192.168.1.0 0.0.0.255

[thisisshanky]

Check this link

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a0080093fbf.shtml

I think the problem here is that DSL modem has no idea of the network 192.168.1.0 behind the e0 interface of 1720. Most DSL modems does not allow adding static routes or running a routing protocol. Best way to do this is to configure the DSL as a basic bridge between dsl and ethernet interface and let 1720 run a pppoe client in the IOS and get a public IP via PPPOE. 1720 will perform NAT as well. FOr inside clients on the E0 interface you can enable Cisco IOS DHCP server.

In most cases E0 (10baseT) is connected to the DSL modem while Fa0/0 goes to the inside switch or hub (network). Your configuration is flipped around.

[sross35]

How do I know if my provider is running pppoe and what if they are not?

[Richard Burts]

I think that the pppoe that Sankar suggests is one way to go at solving your issue. I think there is probably another approach - at least if I understood your original post correctly. When you say that with routing turned on it did not get outside but if you turn off routing and configure default-gateway, then I assume that the router did not have any default route when routing was turned on. So my suggestion is to turn on routing and to configure a default route with the DSL modem as the next hop.

HTH

Rick

[sross35]

Sorry for the delay, I figured this out late last week. It was not that I didn't have a default route statement in the configuration, it was that I am used to using the outbound interface as the destination and not the IP address of the next hop. Once I tried that it worked fine with routing. Just didn't understand why that is the case. I have always used the outbound interface.

Thanks for the responses anyway.

[thisisshanky]

If you do a debug ip packet (not recommended during business hours), when you have the default route configured as outbound interface (FE in your case) you would see "encapsulation failed".

When the router gets a packet for an unknown destination, it uses the default route to route the packet. It looks up the next hop and then looks up the arp cache for the mac-address of nexthop. If the next hop doesnt exist it sends an arp requests, resolves the ip address to mac-address, caches that info in the arp-cache and then routes the packet to the next-hop. Because you have your default route with no next-hop specified, the router wont be able to resolve the mac-address and therefore drop the packet. You can also see the encapsulation failed counter going up in sh ip traffic command output. The outbound interface type, default route will work very well with serial interfaces, as they are point-to-point networks. They dont work well with broadcast type interface such as Ethernet

HTH

[Richard Burts]

Scott

I am glad that you have figured out what the issue was. You have run into one of the subtle differences about static routes to outbound interfaces where the outbound interface is point to point (like most serial interfaces) or is multi-access (like Ethernet). Static routes (including default routes) to outbound point to point interfaces are simple and work well. Packets are sent to the outbound interface and are forwarded with no need to resolve a layer 2 address. But static routes to a multi-point interface are sent to the interface and must resolve the layer 2 address before they can be forwarded. To resolve the layer 2 address over Ethernet the router must ARP for the destination address. If it is a default route we are looking at then the router must ARP for EVERY remote address. If the provider router is configured to support proxy ARP then the provider router will respond to each ARP request. It is a sub-optimal solution but it works. However increasingly providers (and many enterprise networks) disable proxy ARP. If proxy ARP is disabled then your router will ARP for a remote destination, will not get an answer, will discard the packet. This is exactly what was happening in your case.

It is a best practice of configuring routers to configure static routes with next hop addresses when the outbound interface is a multi-access interface.

HTH

Rick