Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Static Inter-VLAN Routing Difficulties

Status
Not open for further replies.

vbahuse

Technical User
Sep 20, 2007
33
0
0
CA
I've run into a problem regarding inter-VLAN routing which I need some help with. This switch (3560) is already in use in a system that I am not permitted to interrupt traffic on. I'm being asked to tighten up the routing such that only two clients be permitted to route across to the other vlan. Here is my attempted configuration:

Code:
ip routing

ip route 10.0.1.5 255.255.255.255 vlan2
ip route 10.0.1.6 255.255.255.255 vlan2
ip route 192.168.1.0 255.255.255.0 vlan1
ip route 0.0.0.0 0.0.0.0 null0

I thought that this would only permit 10.0.1.5 and 10.0.1.6 to communicate to vlan1, while all others would be dropped by the default route (null0).

This however doesn't seem to work as I would expect as anyone on the 10.0.1.x network is still able to communicate with anyone on the 192.168.1.x network. I'm wondering if this has something to do with the default vlan being used, vlan1?

 
Problem is these are directly connected networks, not next hop routers. To do this, you'll need to implement ACL(s) to allow those particular hosts and deny everything else.
 
cajuntank is right. If these are directly connected network, those ip route statements do absolutely nothing. You need access lists, not routing statements.
 
Yep, you'd need to get rid of you route statements above, then use an acl, something like:

conf t
ip access-list extended FUBAR
permit ip host 10.0.1.5 192.168.1.0 0.0.0.255
permit ip host 10.0.1.6 192.168.1.0 0.0.0.255
deny ip 10.0.1.0 0.0.0.255 192.168.1.0 0.0.0.255

then apply this acl inbound on your interface which is directly connected (or leads to) 10.0.1.0/24. If this is vlan1 for you, then:

conf t
int vlan1
ip access-group FUBAR in

Hope I got the masks and commands right, just typing this from hazy memory. This is all assuming your 3560 is the router between these two subnets


 
Hey guys,

I took a slightly different path as some of the clients that require access use dhcp and therefore don't always get the same ip. I tried using mac filtering inbound on the interface to the 10.0.1.0/24 network, which works great for the 10.0.1.0/24 subnet, but I still hit a glitch.

my config is something like:

Code:
conf t
mac access-list ext FUBAR
permit host 1234.1234.1234 any
permit host 4321.4321.4321 any
permit host abcd.abcd.acbd any
permit host dcba.dcba.dcba any
deny any any
exit
int gi0/1
mac access-group FUBAR in

The issue that I have run into is that the 10.0.1.0/24 network has other routers which forward messages from clients which are on other subnets (10.0.2.0/24, 10.0.3.0/24, etc) and their traffic is still allowed through? I checked the arp table on my 3560 and it doesn't show these devices that are still being permitted however it does show the address and mac of the router forwarding the messages to me.

Question: I thought that MAC addresses would flow through, i.e. be consistent across all networks, even through NATs? Obviously this assumption is incorrect so how do I filter (allow MACs from any of the 10.0.x.x networks only if I want them and deny the rest?)

any help would be appreciated,

vbahuse
 
Port security on the access-switchports of the vlan to be filtered.

Burt
 
Doesn't look like the Lock and Key (Dynamic) ACLs can meet my need. As far as I was able to find they only allow a predetermined ACL rule to be applied (i.e. doesn't seem to allow the specific host which just authenticated to be the host used in the dynamic rule).

Instead I have created a administrative task on the one dhcp computer to renew its IP everyday at a specific time, therefore extending the lease to ensure that it doesn't loose it.

Then on the 3560 I simply used an IP access-list for the three "almost" static IPs. This seems to work for now (we'll see if my assumption regarding extending the dhcp lease works).

vbahuse
 
I fyou need to make sure those three clients keep their IP's,,, why not just setup reservations for them in your DHCP scope?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top