Routing through sub-interfaces fails

[Konstantin Minevskiy]

Hello,

I have a problem accessing my wireless router through VLAN sub-interface on my Cisco 1841 router.

My hardware:

Cisco Catalyst 2960 switch (192.168.100.4 /24)

Cisco Catalyst 3550 switch (192.168.100.6 /24)

Cisco 1841 router (192.168.100.7 /24)

Asus RT N66U wireless router (192.168.100.2 /24)

Here's my network topology:

I have two VLANs - 10 and 20.

2 DHCP pools are configured on 2 1841's interfaces - 192.168.1.0 /25 and 192.168.1.128/26 with default router sitting on 192.168.1.1 and 192.168.1.129 respectively. No issues with obtaining IP address from any of those pools.

Laptop connects to L3 3550 switch (switchport access vlan 10), which, in turn, connects to 1841 router through trunk (with VLANs 10 and 20 allowed).

3550 is connected to 2960 through trunk with VLANs 10 and 20 allowed.

Wireless router is connected to 2960.

I can successfully ping my wireless router and outside world from 1841 from fa0/1 interface, but not from fa0/1.10 or fa0/1.20 sub-interfaces -  all packets got dropped. My laptop can obtain IP from both pools (depending on port I connect it to), but can't ping my wireless router and anything beyond it. Could anyone please explain why?

I attach my configs:

Cisco Catalyst 3550:

interface FastEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport port-security mac-address sticky
 speed 100
!
interface FastEthernet0/2
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/3
 switchport access vlan 10
 switchport mode access
!
interface FastEthernet0/4
 switchport access vlan 20
 switchport mode access
!

Cisco 1841:

ip dhcp pool Vlan10DHCP
 network 192.168.1.0 255.255.255.128
 default-router 192.168.1.1 
 dns-server 208.67.220.220
 domain-name home.local
!
ip dhcp pool Vlan20DHCP
 network 192.168.1.128 255.255.255.192
 default-router 192.168.1.129 
 dns-server 208.67.220.220 
 lease 0 12
interface FastEthernet0/1
 ip address 192.168.100.7 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1.10
 description VLAN10 Sub Interface
 encapsulation dot1Q 10
 ip address 192.168.1.1 255.255.255.128
!
interface FastEthernet0/1.20
 description VLAN20 Sub Interface
 encapsulation dot1Q 20
 ip address 192.168.1.129 255.255.255.192
!

Routing table on 1841:

S*    0.0.0.0/0 [1/0] via 192.168.100.2
                is directly connected, FastEthernet0/1
      192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks
C        192.168.1.0/25 is directly connected, FastEthernet0/1.10
L        192.168.1.1/32 is directly connected, FastEthernet0/1.10
C        192.168.1.128/26 is directly connected, FastEthernet0/1.20
L        192.168.1.129/32 is directly connected, FastEthernet0/1.20
      192.168.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.100.0/24 is directly connected, FastEthernet0/1
L        192.168.100.7/32 is directly connected, FastEthernet0/1

Sorry if this all looks a bit messy - I've just started my preparation for CCENT and I still feel a little confused about several terms.

[Konstantin Minevskiy]

I typed 192.168.1.0 /26 by mistake; of course it is 192.168.1.128 /26 and that's exactly what I have on my wireless router.

Thank you for your suggestion about best practice.

[Richard Burts]

If the static route on the wireless router is correct then I do not see anything in the information in your post that would explain problems when doing ping to the Internet. Perhaps there is some additional testing that might help find the problem. If I am understanding correctly you can ping from the client PC to the router and to the wireless router with little or no problem. But ping from the client PC to the Internet suffers very high packet loss. Is this understanding correct?

If so I would suggest doing some testing from the 1841 to try to determine whether the problem is with a specific subnet, or perhaps is specific to the PC. I suggest doing a series of pings from the 1841 to compare some variables. I suggest doing ping to some Internet resource specifying its name and then ping to the same destination using its IP address rather than name to verify that there is not a problem with DNS. (I do not really think it is a DNS issue but would like to be able to eliminate this as a possible cause.) I would also suggest doing some pings with the default packet size and then doing some pings with a packet size that is larger (probably at least 1300 bytes) to see if there is any performance difference because of packet size. I would suggest doing a fairly large number of pings, perhaps 500 or 1000 of each type, so that we get a good observation.

By default ping from the 1841 will use the source address of the physical interface and these pings will help to establish a base line of how well ping works. Then I would like to suggest doing a similar set of ping specifying the address of vlan 10 as the source and then doing a similar set of ping specifying the address of vlan 20 as the source address.

Hopefully these tests will give us a better understanding of whether the problem is related to something on the PC or to something about the subnet from which the ping is coming.

HTH

Rick

[Konstantin Minevskiy]

Richard, sorry for wasting your time for so long. My own carelessness is the only answer to my earlier issue. Thank you for your patience.

[Richard Burts]

I am glad that you were able to identify the cause of this problem and that now things are working well.

HTH

Rick

[Konstantin Minevskiy]

OK, problem solved. Yesterday, when I was sleepy, I added additional default static route on 1841 - 0.0.0.0 0.0.0.0 FastEthernet 0/1, which obviously is the same as my current default route. I guess I didn't pay enough attention to my running config lines and that is why I usually had about half of my ICMP packets got "confused" and, eventually, dropped. Somehow I thought that every single route should be displayed upon "show ip route" command. It tought me to look at running config command as well

I'd like to thank everyone who was involved in this troubleshooting.