From: Steven Weber (itweber@xxxxxxxxxxxxx)
Date: Fri Jan 11 2002 - 12:13:49 GMT-3
why not just put them on 2 separate Vlans then ?
----- Original Message -----
From: <Richard.Westby-Nunn@engenoil.com>
To: <Kivas.Waters@Honeywell.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, January 11, 2002 9:38 AM
Subject: RE: Input Smac ACL not working??
> Hmmm, that poses a problem then. Maybe you can help here? This is the
> scenario:
>
> There is a remote division that has recently moved in with another
division,
> in other words they are sharing the same location and office physically.
> Both divisions use different LANs. To save costs they have decided to use
> one hub between both divisions, thus minimising cabling costs in the
> building, only one cabinet and hub needed, but they want to prevent the
> unauthorised users, from the other division, from logging onto our
network.
> Companies choice against all pleas from me, so I have to try and create a
> solution here! :-(
>
> Hence the idea of the Source MAC ACL! The devices use DHCP to get IP
> Addresses, and apart from using static addresses in the location, with the
> Layer 3 ACL, is there any way to prevent the unwanted users from getting
> onto the WAN??
>
> Difficult one I know!
>
> Richard
> -----Original Message-----
> From: Waters, Kivas (UK72) [mailto:Kivas.Waters@Honeywell.com]
> Sent: 11 January 2002 14:36
> To: Richard.Westby-Nunn@engenoil.com; ccielab@groupstudy.com
> Subject: RE: Input Smac ACL not working??
>
>
> Hi Richard As far as I know, access-expressions and MAC address lists are
> only applicable to bridged traffic! If you configure bridging of these
> devices to another LAN then by all means use your method of access
control.
> When routing however, you need to configure L3 ACL's, in your case
matching
> on host IP address.
>
> Hope I understand this correctly, please someone correct me if I'm wrong.
>
> regards
>
> Ki
>
> ex DD East London'er
>
>
> -----Original Message-----
> From: Richard.Westby-Nunn@engenoil.com
> [mailto:Richard.Westby-Nunn@engenoil.com]
> Sent: 11 January 2002 11:07
> To: ccielab@groupstudy.com
> Subject: Input Smac ACL not working??
>
>
> Maybe someone can explain this one??
>
> Have an Smac ACL to only allow certain devices to be able to be routed,
and
> then prevent all others from getting out of the LAN. LAN is going to be
> shared with another division, that is not to be allowed access to this
> network, or the WAN component at least!
> For some reason it doesn't seem to be working?? I am still seeing a device
> that is not in the ACL in my arp, and can ping it from outside of the LAN
> (0050.8bbb.910b).
> I am sure there is a problem with my config, but I can't see what it is.
>
> Any ideas?
>
> Config is as follows:
> -------------------------------------
> interface FastEthernet0
> ip address 10.17.40.254 255.255.255.0
> ip helper-address 10.1.15.205
> no ip directed-broadcast
> half-duplex
> access-expression input smac(700)
> !
> access-list 700 permit 0080.640d.b505 0000.0000.0000
> access-list 700 permit 0080.640d.b769 0000.0000.0000
> access-list 700 permit 0080.640d.c989 0000.0000.0000
> access-list 700 permit 0080.640d.b650 0000.0000.0000
> access-list 700 permit 0010.8343.4713 0000.0000.0000
> access-list 700 permit 0010.83f4.14d9 0000.0000.0000
> access-list 700 permit 0010.83f4.dfc8 0000.0000.0000
> access-list 700 permit 0080.640d.c9c2 0000.0000.0000
> access-list 700 permit 0090.f2b0.0fd6 0000.0000.0000
> access-list 700 permit 0050.7377.7c0e 0000.0000.0000
> access-list 700 permit 0090.f2b0.0d68 0000.0000.0000
> access-list 700 deny ffff.ffff.ffff 0000.0000.0000
>
> -------------------------------------
>
> sh access-lists
> Bridge address access list 700
> permit 0080.640d.b505 0000.0000.0000
> permit 0080.640d.b769 0000.0000.0000
> permit 0080.640d.c989 0000.0000.0000
> permit 0080.640d.b650 0000.0000.0000
> permit 0010.8343.4713 0000.0000.0000
> permit 0010.83f4.14d9 0000.0000.0000
> permit 0010.83f4.dfc8 0000.0000.0000
> permit 0080.640d.c9c2 0000.0000.0000
> permit 0090.f2b0.0fd6 0000.0000.0000
> permit 0050.7377.7c0e 0000.0000.0000
> permit 0090.f2b0.0d68 0000.0000.0000
> deny ffff.ffff.ffff 0000.0000.0000
> Extended IP access list 100
> permit ip any host 10.1.7.168
> permit ip any host 10.1.7.174
> permit ip any host 10.1.7.184
> permit ip any host 10.1.7.188
> Extended IP access list 102
> deny eigrp any any (16364 matches)
> permit ip any any (158 matches)
>
> -----------------------
> sh arp
> Protocol Address Age (min) Hardware Addr Type Interface
> Internet 10.17.40.55 53 0080.640d.c989 ARPA FastEthernet0
> Internet 10.17.40.52 53 0010.8343.4713 ARPA FastEthernet0
> Internet 10.17.40.59 53 0080.640d.b769 ARPA FastEthernet0
> Internet 10.17.40.58 53 0080.640d.b505 ARPA FastEthernet0
> Internet 10.17.40.56 53 0050.8bbb.910b ARPA FastEthernet0
> Internet 10.17.40.103 53 0010.83f4.14d9 ARPA FastEthernet0
> Internet 10.17.40.101 53 0010.83f4.dfc8 ARPA FastEthernet0
> Internet 10.17.40.90 53 0080.640d.c9c2 ARPA FastEthernet0
> Internet 10.17.40.250 53 0090.f2b0.0fd6 ARPA FastEthernet0
> Internet 10.17.40.254 - 0050.7377.7c0e ARPA FastEthernet0
> Internet 10.17.40.252 53 0090.f2b0.0d68 ARPA FastEthernet0
> -----------------------
>
> Richard Westby-Nunn
> Easy Going Guy ;-)
>
> Dimension Data Network Engineer
> Onsite @ Engen Petroleum
> +27 (0)83 44 44 66 5
> Richard.Westby-Nunn@engenoil.com
> Richard.Westby-Nunn@didata.co.za
>
> Men who live on the Edge of Sanity,
> Witness the Exhilaration as they Push the Limits!!
> ) - >
>
>
>
>
> Engen Petroleum Limited disclaim all liability for any loss, damage or
> expense however caused, arising from the sending, receipt, or use of this
> e-mail communication and on any reliance placed upon the information
> provided through this service and does not guarantee the completeness or
> accuracy of the information.
> Engen Petroleum Limited disclaim all liability for any loss, damage or
> expense however caused, arising from the sending, receipt, or use of this
> e-mail communication and on any reliance placed upon the information
> provided through this service and does not guarantee the completeness or
> accuracy of the information.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:25 GMT-3