du musst di acl dann auch an einem interface und in die richtige richtung binden, ping geht dann natürlich weiterhin, du blockst ja tcp.
in deinem fall musst du dann noch die acl etwas aufsplitten, durchs subnetting ist das so und du hast in der acl source/destination verdreht..
also ich würde das so machen:
access-list 100 deny ip host 172.30.10.71 172.16.3.60 255.255.255.252
access-list 100 deny ip host 172.30.10.71 host 172.16.3.64
access-list 100 deny ip 172.30.10.72 255.255.255.252 172.16.3.60 255.255.255.252
access-list 100 deny ip 172.30.10.72 255.255.255.252 host 172.16.3.64
usw usf
(access-list 100 permit ip any any)
dann bindest du dise acl wo das 172.30.10/x netz landet INBOUND. Je nachdem welches Plattform/welches IOS sind vielleicht auch object-groups vorhanden, das wäre praktischer als das über zib ACEs zu machen.Was auch noch zu beachten wäre, handelt es sich um einen reinen Router ? n Switch ? Ist da ein Firewallfeature aktiv ? nich timmer alles aus der Nase ziehen lassen -.-
es handelt sich hier um den Coreswitch,
es gibt sonst kein access gruppen, nur ein paar standard access-listen.
Das sind auch die einzigsten 2 Netzte in unserem Rechenzentrum. (werden nicht über die Firewall geroutet)
Alle anderen Netze von anderen Standorte werden über unsere Checkpoint Firewall geroutet/gemanged.
ich habe das jetzt rausgefunden mit einem testrechner,
funktioniert so
conf t
access-list 101 deny ip host 172.16.1.5 172.30.10.132 0.0.0.0
access-list 101 permit ip any any
int Gi3/0/21
ip access-group 101 in
exit
in der produktivumgebung hängen die ip´s 172.30.10.x an einem Portchannel, bzw. das sind Bladeserver.
Frage:
muss ich jetzt die access-gruppe (ip access-group 101 in )an den physikalischen Interfaces erstellen oder an dem Po Interface?