CCIE.pl

Dokladnie tak jak mowisz. Ale ruch badajacy osiagalnosc hosta w sla jest juz generowany przez router wiec jesli mialbys np. taka sytuacje: ip route 0.0.0.0 0.0.0.0 192.168.1.1 ip route 0.0.0.0 0.0.0.0 192.168.2.2 200 przy czym obie trasy wychodza przez rozne interfejsy i mialbys potrzebe zbadac osia...

pokaz sh run z rutera ...

A lan'y sa fizycznie odseparowane (np. osobne switch'e) czy nie - wpiete do tego samego switcha?

Zgadza sie proxy-arp zareagowal poprawnie, po prostu braklo tutaj komunikacji w L3, w tym przypadku akurat ze wzgledu na ip bedacym adresem sieci, ale podobnie by sie to zachowalo gdyby wyslac icmp na poprawny adres ale nie istniejacy w sieci.

Wiesz co jak dla mnie dzialo sie tak dlatego ze R2 zobaczyl ze arp odnosi sie do jednej z podsieci do ktorych jest podlaczony wiec zgodnie z zalorzeniem proxy-arp odpowiedzial za docelowego hosta jednak potem stwierdzil ze adres jest jego adresem sieci przez co nie dostal replay od docelowego hosta ...

Nie ma sprawy dzwigu - najwazniejsze ze dziala

Hmm wiesz co nie mam tej ksiazki fizycznie ale znalazlem ja w necie i tam zaden ip interfejsu nie jest adresem podsieci routera laczacego oba lany - twierdzisz ze router ma odpowiedziec na arp dla adresu sieci jednego ze swoich interfejsow?

Spoko spoko jest OK dopisalem w poprzednim poscie ze wbiles sie z adresami na R1 i R3 w adresy sieci dla R2 wiec on nie bardzo wie co z tym zrobic jak pozamieniasz te IP to bedzie ok bez jakich kolwiek dodatkowych wpisow w tablicy - nie spojrzalem na poczatku na te IP.

Sprobuj jeszcze pokazac R3 i R1 ze zdalne sieci - czyli dla R1 siec podpieta na R3 i odwrotnie - moze osiagnac przez interfejs lokalny czyli ten do R2 ale nie przez ip R2 i wtedy powinno dzialac, czyli cos takiego: ip route zdalna_siec zdalna_maska interfejs_do_r2 uzupelnioenie bo przeciez mamy ip i...

Nie do konca, chodzi o zmiane stanu obiektu jesli jest icmp wiec przy brak replay dostanie unreachable obiekt zmieni stan na down a chyba o taka informacje chodzi.

Czy sytuacja jest taka sama jesli zmienisz reachability na state w track object?

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
access-list 101 deny ip any any

ostatnia regula jest tylko pro forma bo acl zawiera ja default'owo. taka acl zapinasz na odpowiednim interfejsie (np. na input gdzie jest podsiec 192.168.1.0)

PBR powinien byc robiony przy pomocy acl i wszystko bedzie dzialalo, poniewaz wybierasz IP z pakietow.
prefix-list'y sa wykorzystywane do filtrowania prefixow przy routingu dynamicznym (np. bgp) gdzie w update sa rozglaszane caly prefix (network/netmask).

zobacz co siedzi w tablicy translacji
sh ip nat translation

i sprobuj ja wyczyscic teraz powinno byc ok.

pewnie nie mozesz reloadowac routera ... ale jesli niema na nim duzego ruchu to popatrz jeszcze co leci w
debug ip nat

Przywroc poczatkowa konfiguraje + nowa route mapa dla static nat. I wyczysc tablice translacji clear ip nat translation * mozesz tez potrzebowac zrobic to w odwrotnej kolejnosci aby nie bylo problemu z czyszczeniem konfiguracji. Tutaj takie male howto http://www.cisco.com/en/US/tech/tk648/tk361/tech...