9 Comments

  1. pun in shut pe R2 interfata catre R3;
    meserie.

  2. Liviu
    Author

    Alin, din pacate lucrurile sunt un pic mai complicate decat atat. Daca pui in SHUT interfata de pe R2 catre R3, R1 nu o sa primeasca [SYN, ACK] de la nimeni cand face telnet pe R3 si dupa cateva secunde tot o sa-ti intoarca mesajul setat cu comanda “busy-message”. Multumesc pentru raspuns, intrebarea insa ramane deschisa.

  3. ma gandeam sa schimb ip lo0 r2 cu lo0 r3, astfel r2 trimite SYN si nu mai apare mesajul “busy-message”

  4. Liviu
    Author

    Ionut, intr-un fel solutia ta “face match” pe cerintele problemei … adica NU te conectezi la R3 (pentru ca practic te conectezi la R2 daca schimbi IP-ul) dar nici nu primesti mesajul setat cu comanda “busy-message”. Din pacate ai “trunchiat” un pic ipoteza, pentru ca pe tine nici nu te mai intereseaza practic daca pe R3 toate “VTY lines” sunt ocupate.
    Incearca sa te gandesti la o modalitate prin care R1 sa primeasca un [SYN, ACK] de la loopback-ul lui R3 fara ca sesiunea TCP dintre R1 si R3 sa se poata stabili. In felul asta NU primesti nici “bussy-message” si nici nu te poti conecta pe R3.

  5. Daca R1 primeste [syn, ack] dar sesiunea tcp nu se stabileste atunci ne aflam in cazul unei sesiuni tcp half-open, R1 trimite syn, R3 trimite [syn,ack] insa R1 nu trimite catre R3 ack, sau trimite dar ack-ul nu ajunge.
    Daca nu exista un vty disponibil, R3 trimte direct [ack,rst], iar daca acest mesaj ajunge la R1, sau nimic nu ajunge, busy-message tot va fi afisat

  6. Liviu
    Author

    Daca incerci sa sugerezi ca nu exista solutie la problema, atunci concluzia la care ai ajuns este gresita desi rationamentul tau din observatia anterioara este foarte corect (pana la concluzie). Intrebarea ramane deschisa !

  7. initial am incercat pe R2 cu un named extended acl input pe interfata inspre R3:

    ip access-list extended filter
    deny tcp any eq telnet any match-all +ack +rst
    permit ip any any

    astfel R1 trimitea syn catre R3, iar [rst,ack] dinspre R3 nu mai ajungea la R1, dar dupa un timp desigur conexiunea tcp expira si mesajul busy-message aparea.

    atunci am inteles ca R2 trebuie sa faca mai mult decat sa forwardeze pachetele dintre R1 si R3 si trebuie sa intermedieze sesiunea tcp/23 dintre R1 si R3, astfel pe R2 am configurat:

    access-list 101 permit tcp any host 3.3.3.3 eq telnet
    ip tcp intercept list 101
    ip tcp intercept mode intercept (default in 12.4(24)T1, nu apare la show run)

    acum R2 intercepteaza syn pentru sesiunea tcp care face match pe acl 101. R2 va incerca cate o noua conexiune, atat pe server cat si pe client, jucand pe rand rolul clientului si al server-ului. la final R2 “leaga” cele doua conexiuni astfel incat R1 sa poata comunica direct cu R3.

    dupa “no ip route-cache” pe interfetele R2 (pentru a vedea pck tcp transit), facem “debug ip tcp intercept”:

    *May 27 15:25:36.079: INTERCEPT: new connection (192.168.0.1:37621 SYN -> 3.3.3.3:23)
    *May 27 15:25:36.087: INTERCEPT(*): (192.168.0.1:37621 3.3.3.3:23)
    *May 27 15:25:36.135: INTERCEPT(*): (192.168.0.1:37621 SYN -> 3.3.3.3:23)
    *May 27 15:25:36.151: INTERCEPT: in synsent (192.168.0.1:37621 <- RST 3.3.3.3:23)
    *May 27 15:25:36.155: INTERCEPT(*): (192.168.0.1:37621 <- RST 3.3.3.3:23)

    ce este important pentru noi este ca R1 va primi [ack,syn] de la R2, insa cu adresa ip a R3:

    *May 27 15:33:39.431: IP: s=3.3.3.3 (GigabitEthernet1/0), d=192.168.0.1, len 40, TCP src=23, dst=18632, seq=247175282, ack=4126048114, win=0 ACK SYN
    si astfel nu va mai afisa busy-message

  8. Liviu
    Author

    aceasta este raspunsul corect, felicitari !

  9. in sfarsit, m-a tinut pe jar de azi dimineata 😀 felicitari pentru intrebare, pentru mine a fost cea mai interesanta de pana acum!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.