cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2241
Views
0
Helpful
32
Replies

cannot route between VLANs on 6509 switch

gflorescu
Level 1
Level 1

I have just installed a new Cisco 6509 switch and I have 2 VLANs:

VLAN 2

VLAN 3

I setup 2 interfaces on it:

int vlan 2

ip address 192.168.6.4

int vlan 3

ip address 192.168.7.1

I verified they're in no shutdown mode. I can ping both ip addresses when logged into the switch but I cannot ping between 2 hosts on the different subnets.

I have a default static route going to 192.168.6.1

(i.e. ip route 0.0.0.0 0.0.0.0 192.168.6.1 )

If I do sho ip route, it shows the 2 vlans that are directly connected and it shows the static route as well.

I want the 6509 to do the layer 3 routing between the VLANs.

32 Replies 32

Exactly. That's what I thought. You were just making a recommendation so that a suggested PING test would work. But adding that route also fixed his inter-vlan routing problem.

So, although adding a route to the 7.0 subnet on the PIX "fixed" his inter-vlan routing, he should not have had to do that, unless he has proxy arp enabled on the FW's interface.

So, I think adding the static route to the FW is really a band-aid to fix a misconfiguration. Unless, of course, for some operational reason that we are not privy to, proxy arp MUST be turned on the PIX interface. Otherwise, it should probably be turned off.

Victor

Guys,

Adding a static route on the PIX to get to the 192.168.7.0 network wouldn't fix the problem. PIX, by default, doesn't route traffic out the same interface it received the traffic on. Though, if the code supports it there's some additional configuration that can be used to get this to work.

HTH

Sundar

My guess is (again, I'm guessing), the OP created another subnet and wanted this subnet to traverse the PIX for internet/outside connectivity.

That subnet wasn't working and he posted his question here but forgot to introduce the PIX into the equation until he was pressed to provide more information.

For the PIX to serve a subnet other than its own, a route add must be entered and once the OP did, everything worked as designed.

Again, I guess we should let the OP answer your inquiries as I'm just replying to you out of courtesy.

My goal was identifying the inter-vlan configuration was properly done in the switch. Since he brought up another device into the equation (PIX), I had him test against that. My goal on that reply was never intended to fix his workstation issues, but it did. It's unknown up to this point how he was testing but it now works...

Gotta run, have a 2pm, adios ..

""For the PIX to serve a subnet other than its own, a route add must be entered and once the OP did, everything worked as designed.""

Even if your guess is correct, in a PIX you need more than just adding a route to forward traffic between interfaces. You would need an access rule + nat configuration if nat control is enabled etc..

You don't have to respond to this but just highlighting something PIX needs in addition to the route.

However, I agree with you the OP would have to provide more information to really know what the underlying problem was.

HTH

Sundar

Glad to hear your issue is resolved :-)

Are you saying you had to add a route on the PC for the other VLAN. If the PC's default gateway was pointing to the switch's VLAN interface IP then you shouldn't require a specific route in the PC.

The default route, aka gateway of last resort in the switch, is pointing to the PIX. I have seen problems on a few occasions, with a similar setup like yours, when a LAN host sends traffic to it's gateway (router) and it uses another router or firewall in the same LAN segment as it gateway the router would send an ICMP redirect packet to the PC. The PC could then accept that packet and start sending future communications to that remote network via the redirected gateway. We don't know if your issue was caused by the ICMP redirect or some route misconfiguration in the PC itself.

sundar:

Are you saying you had to add a route on the PC for the other VLAN. If the PC's default gateway was pointing to the switch's VLAN interface IP then you shouldn't require a specific route in the PC.

He added a route on the PIX, not the PC. But he shouldn;t have had to do that either.

Scroll up and see my comments to Edison.

Victor

Victor,

Our posts crossed each other. I responded to your query about adding a route to the PIX. By default, PIX doesn't route traffic out the same interface it received the traffic on.

HTH

Sundar

Gilbert

The config that you posted seems reasonable straightforward. I do not see any serious issue (other than that the static route p route 192.168.7.0 255.255.255.0 192.168.6.1 is incorrect since 192.168.7.0 is a connected subnet on VLAN 3 you can not route it to VLAN 2 address).

I know that you have said that the PCs are configured with correct gateways. But if the switch can successfully ping the PC with a standard ping but can not ping the PC with extended ping (which is what I believe you are describing) then it sure sounds like there is a problem with the gateway on the PC. Or perhaps that the PC is configured with a route that points somewhere else.

It would be really helpful if you would post the output of ipconfig and of route print from the PCs.

HTH

Rick

HTH

Rick

Hi:

Check the workstations, as recommended.

I am also wondering if proxy arp should be disabled on the FW's interface (192.168.6.1).

As far as I can remember, proxy arp is enabled by default on the PIX, so you would need to apply the sysopt noproxyarp command to the interface to disable proxy arp.

If that is indeed the problem, when you do an arp -a on a workstation in vlan 2 (192.168.6.0/24 subnet), you will see the MAC address for the FW's interface bound to IP addresses on the 192.168.6.0/24 subnet, instead of the router's vlan 2 interface.

HTH

Victor

Guys,

Unless I am missing something in the post, since it's quite a long thread, this should work without having to add a static route to the PC.

OP indicated he has the following 2 VLANs in his switch. His PCs on both VLANs are using these addresses as their default gateway. Real simple - this should have worked under normal circumstances without additional configuration in the PC or PIX.

nt vlan 2

ip address 192.168.6.4

int vlan 3

ip address 192.168.7.1

HTH

Sundar

""For the PIX to serve a subnet other than its own, a route add must be entered and once the OP did, everything worked as designed.""

Even if your guess is correct, in a PIX you need more than just adding a route to forward traffic between interfaces. You would need an access rule + nat configuration if nat control is enabled etc..

However, I agree with you the OP would have to provide more information to really know what the underlying problem was.

HTH

Sundar

Sundar:

Just to set things straight, since there was so much back and forth going on...

1.) I think I can speak for Edison (since I already clarified it with him) when I say that he only recommended adding the route to the 7.0 subnet on the PIX, not the PC, so that a suggested PING test between the switch and the PIX would work. It wasn't to address the inter-vlan routing issue between vlans 2 and 3.

2.) Upon adding the static route to the 7.0 subnet on the PIX, inter-vlan routing started working.

3.) I think we all agree that that should NOT have fixed the inter-vlan routing problem, and that if it did, it's because it is acting as a band-aid. I think we all agree that the traffic should have stayed local to the L3 switch and the PIX should have had nothing to do with routing between 2 vlans that are configured locally on the switch.

To that, I say that the FW was receiving traffic bound for the 7.0 subnet from hosts on the 6.0 subnet -- and I think that the reason for that is that proxy arp on the PIX interface is enabled.

If it is, the PIX will respond to all ARP requests that are broadcast on the 6.0 subnet for destinations on the 7.0 subnet, making hosts on the 6.0 subnet think that they should forward their traffic to the PIX. However, without a route to the 7.0 subnet, the PIX was dropping the traffic -- that is, until the OP added the static route to the PIX for the 7.0 subnet.

Anyway, I hate rehashing entire conversations, but this problem is a real good one "for the books," so IMHO, it's worth understanding exactly what is wrong and what fixed the problem.

Thanks

Victor

Victor,

""To that, I say that the FW was receiving raffic from hosts on the 6.0 subnet and I think that the reason for that is that proxy arp on the PIX interface is enabled. If it is enabled, but doesnt have to be for some other operational reason, it should be disabled.""

I thought about it too. But, when the PC ARPed for the gateway (switch) address had the PIX responded (proxyARP) then the OP wouldn't have been able to ping the PC from the switch itself. It's only when traffic was sourced from a remote network the pings were failing. Hence, it looks like for whatever reason the PC was sending the traffic to the PIX, ip redirects/proxy ARP etc, to get to the 7.0 network instead of sending it to the switch.

I responded a few times, probably too many, about the PIX and a static route alone wouldn't have addressed the issues if the PIX had been routing the traffic between the VLANs.

I totally agree with you we don't have all the facts to make an accurate determination as to what caused the problem to begin with.

:-)

HTH

Sundar

I think the PIX is handling the layer 3 routing for that subnet 192.168.6.x and the switch is handling layer 3 routing for the 192.168.7.x subnet.

The workstations in the 6.x subnet are configured like this:

192.168.6.10

255.255.255.0

192.168.6.1 <--default gatewa

I did notice that on the PIX there's a route for the 6.x subnet pointing to 192.168.6.1

They should point to 6.4 (The L3 switch).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: