imaš 2 access-liste (ako nisi slučajno pogrešio u kucanju)

access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
ova access lista ima implict deny na kraju i blokira sve

access-list 100 permit ip any any
ova access lista ne radi ništa, dozvoljava sve, pa onda je isto kao da nisi ni stavio access listu

ako hoćeš da ti bude blokiran ping, ali dozvoljen ping reply možeš dodati

access-list 110 permit icmp any any echo-reply
access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31
access-list 110 permit ip any any

bas suprotno, ACL 100 je veoma bitna, barem u realnom zivotu xD, jer prvi, tj gornji redovi bivaju deny statement, pa posle njih moras pustiti sve sto ti treba da prodje kroz ruter, ili kao sto je gore napisano, acess-list 100 permit ip any any, ovo se radi zbog jer na kraju svake liste deny ip any any... paketi koji se budu podudarali sa ACL 110, nece ni stici do 100 xD

a) svi paketi se podudaraju sa ACL 110 zbog implicit deny
b) u realnom životu 2 access liste se ne mogu staviti na interface u out pravcu

Slučajno je napisano 110 i 100...

U svakom slučaju, hvala.

grrr, ja sam pogresio, mislio sam da su 100 i 110 redovi u jednoj istoj ACL, mislio sam da se podrazumeva da je to jedna te ista ACL, bas iz razloga sto ide jedna ACL na jednom interfejsu u jednom pravcu....:)

ICMP se ne koristi samo za ping (echo/echo-reply), vec i za mnoge druge stvari. Izmedju ostalog i za PMTUD, koji ako ne radi kako valja cesto pravi glavobolje. Ja bih radije to uradio ovako:

access-list 110 deny icmp 192.168.0.0 0.0.0.63 192.168.0.64 0.0.0.31 echo
access-list 110 permit ip any any

Time se onemogucava ICMP Echo (Type=8, Code=0), ali se dozvoljava Echo Reply (Type=0, Code=0), kao i sve ostale ICMP poruke.

Beri, jel moze malo vise o PMTUD procesu?

Svako moze da procita na wiki-ju, ali bih voleo da procitam tvoje objasnjenje.

Kao sto si i sam rekao, klasicnu pricu mozes da nadjes na gomili sajtova ili da procitas RFC 1191. Ukratko, su source (S) i destination (D) host povezani nizom rutera na sledeci nacin:

S --- R1 --- R2 --- R3 --- ... ---- Rn --- D

i ako je na S hostu aktiviran PMTUD (Linux: /proc/sys/net/ipv4/ip_no_pmtu_disc = 0) tada ce on smatrati da su ruteri R1 ... Rn sposobni da bez fragmentacije prenesu IP pakete od S ka D, odnosno da u mrezi izmedju S i D nema nijednog linka ciji je MTU manji od MTU na linku S-R1. Stoga, umesto da S salje IP pakete sa resetovanim DF bitom (DF=0) i prepusti ruterima R1 ... Rn da se sami snalaze i fragmentiraju paket kako im je volja, S ce postaviti DF=1 i pokusace da posalje paket ka D. Ako iz bilo kog razloga neki od rutera R1 ... Rn ne moze da dalje prosledi takav paket (npr. ako je MTU (R2,R3) < MTU (S,R1)), taj ruter (u primeru: R2) ce o tome obavestiti izvorisni host (S) ICMP porukom Destination Unreachable - Fragmentation Needed and DF Set (Type=3, Code=4); u "unused" polje ICMP poruke ruter ce kopirati MTU interfejsa koji pravi problem (u primeru R2-R3). Kada primi ICMP poruku, host S ce pokusati da posalje pakete ponovo, ali uz MTU koji odgovara vrednosti koju je dobio u ICMP poruci od rutera R2. Postupak se ponavlja sve dok se nijedan ruter R1 ... Rn vise ne buni, ili dok se ne dostigne minimalni standardni MTU (576 bajtova).

Dok je kod IPv4 uvek moguce iskljuciti PMTUD i prepustiti ruterima da fragmentiraju pakete, kod IPv6 to nije moguce - PMTUD je obavezan, ruteri ne vrse fragmentaciju IPv6 paketa. Osim PMTUD, ICMPv6 se koristi i za ND (ekvivalent ARP u IPv6). Zbog toga je blokiranje ICMPv6 poruka prilicno nezgodna stvar, koja moze da dovede i do totalnog prekida komunikacije.

Problem kod PMTUD nastaje kada host S nije u stanju da prima ICMP poruke od rutera iz bilo kog razloga (firewall/acl negde na putu, gubitak ICMP paketa usled opterecenja linkova itd.) i ako TCP implementacija nije dovoljno inteligentna da prepozna tu situaciju. U tom slucaju, narocito kod starijih uredjaja i OS cesto se desasvalo da TCP nastavi sa retransmisijama dok ne istekne timeout i sesija puca. Tipican efekat koji su korisnici cesto primecivali su nepotpune web stranice, slike ucitane do pola itd. Vecina novijih TCP implementacija koristi PLPMTUD (RFC4821) - mehanizam koji omogucava TCP-u da na pocetku veze posalje par proba i ustanovi end-to-end MTU, oslanjajuci se na retransmisije. Na Linuxu se ova opcija moze da ukljuci sa "echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing".

Srodan problem, danas nazalost veoma cest, je vezan za mreze gde se koristi MPLS, gde ponekad moze da dodje do ovakve situacije:

S === PE1 === P1 --- P2 --- ... --- Pn --- PE2 --- D

Na ovoj slicici MTU na linku S-PE1 i PE1-P je veci od MTU u ostatku mreze. Primera radi, neka je MTU(S,PE1) = 2000 bajtova, MTU (PE1,P) = 4470, a u ostatku mreze 1500. Ono sto se tu desava je da source host (S) smatra da je MTU cele mreze 2000 bajtova i pokusava da posalje paket te duzine preko rutera PE1. Ruter PE1 "vidi" sledeci ruter u nizu (P) preko linka sa MTU=4470 bajtova i salje paket ka tom ruteru. Medjutim, kada PE1 ruter posalje paket on mu dodaje MPLS labelu i od tog trenutka P ruteri na putu izmedju PE1 i PE2 manipulisu samo MPLS labelama. ICMP poruke sa P rutera ne stizu nigde. P1 ce detektovati MTU problem na linku P1-P2 i poslace ICMP poruku ka hostu S, ali ta poruka nece stici nigde, jer P ruteri nemaju rute niti su u stanju da formiraju MPLS paket - oni samo vrse zamenu labele drugom labelom. Zbog toga je veoma bitno da se u MPLS mrezama ujednace MTU vrednosti na svim linkovima gde god je to moguce.

Ok, hvala, jasno kao dan. Svidja mi se ovaj PLPMTUD.

Tekst koji sam ja nasao i cini mi se da vredi procitati:

http://conferences.sigcomm.org/imc/2010/papers/p102.pdf