Inter-Vlan Routing via multilayer switch

[Karim Elsadek]

Dear all ;

Kindly be informed that I have the following design 

- Configuration on Sw 04 :

interface gigabitethernet 0/2

no switchport

ip address 10.10.10.2 255.255.255.0

- Configuration on Sw 03 :

interface gigabitethernet 0/2

no switchport

ip address 10.10.10.1 255.255.255.0

ip routing

interface vlan 2

ip address 192.168.2.1 255.255.255.0

no shutdown

interface vlan 3

ip address 192.168.3.1 255.255.255.0

no shutdown

interface fastethernet 0/1

switchport mode trunk 

switch port encapssulation dot1q

interface fastethernet 0/2

switchport mode trunk 

switch port encapssulation dot1q

- Configuration on Sw 01

interface fastethernet 0/1

switchport mode trunk

interface fastethernet 0/2

switchport mode access

switch port access vlan 2

- Configuration on Sw 02

interface fastethernet 0/1

switchport mode trunk

interface fastethernet 0/2

switchport mode access

switch port access vlan 3

*************************************************

- ping from 192.168.2.2 to 192.168.3.2 (Replay).

- ping from 192.168.2.2 to 10.10.10.1 (Replay).

- Ping from 192.168.2.2 to 10.10.10.2 (Request time out)

i try to use static default route command on Sw 03 but ping still give time out.

i use packet tracer to study the case.

i hope some one help me

[Jon Marshall · Accepted solution]

Packet Tracer can sometimes be a bit buggy but you should just be able to add a default route to sw4 ie.

ip route 0.0.0.0 0.0.0.0 10.10.10.1

and obviously make sure IP routing is enabled.

Jon

[Karim Elsadek]

Thanks Jon , Ip routing already enabled 

but I configured Sw4 with static route to the other subnet and it work well.

[devils_advocate · Accepted solution]

Without seeing the full config on switch 4 I cannot be sure but I suspect if you were to look at the routing table on this device, it would not know about the 192.168.2.0 network.

If you think about it from the packet perspective, we know it can get to 10.10.10.1 which is SW3. The packets are likely reaching 10.10.10.2 but because SW4 has no route to reach the 192.168.2.0 network, the replies are failing to make it back to the source.

If you do a ' show ip route 192.168.2.0' command on SW4, you will probably see nothing listed in the routing table. The source ip address of the ICMP packets is going to be 192.168.2.2 so when SW4 receives these, it attempts to build the echo reply packet but has no idea where to send it as the next hop because it does not have an entry for 192.168.2.0 in its routing table.

That seems the likely cause to me anyway.

Add a static route on Sw4 to solve the issue:

#ip route 192.168.2.0 255.255.255.0 10.10.10.1

or a default route as Jon has suggested.

[Karim Elsadek]

Thanks for your  comment , I really missed this note.