Új hozzászólás Aktív témák

• #524 Tsory tag tusi_ #510

  Új Válasz 2012-04-27 16:25:25 #524

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Tsory

  tag

  válasz tusi_ #510 üzenetére

  Én máshogy csoportosítanám őket: 2 telephely, több telephely multipoint, több telephely point-to-point. Az alapvető dolgok talán egy pont-pont kapcsolatnál érthetőek meg a legegyszerűbben, hiszen ilyenkor nem kavarnak be az alinterfészek, valamint nincs több DLCI egy porton. Először a DTE-DCE kapcsolatnak kell rendben lennie (helyi router--szolgáltató frame-relay switch), itt működik az LMI. Utána a DTE-DTE kapcsolatnak (router-router kapcsolat), itt lényeges a frame-relay encapsulation. Ezután rendben kell lennie a layer2-layer3 címek összerendelésének, ezt vagy az inverz ARP intézi, vagy mi kézzel veszük fel frame-relay map paranccsal. Ezek nem feltételnül múlnak azon, hogy Cisco eszközökből építkezünk, pl. a frame-relay enkapszulációnak meg kell egyeznie a két oldal között. Ha az egyik oldalon ietf van beállítva, akkor a másik oldalon is azt kell beállítani. Ha az inverz ARP ki van kapcsolva, akkor kézzel kell felvenni a frame-relay map-et, szintén függetlenül az eszköz gyártójától.

  Nézzünk egy egyszerű két telephelyes kapcsolatot:

  Budapest (192.168.1.1/24) -- DLCI 16 -- FRSW1..FRSW2 -- DLCI 20 -- Debrecen (192.168.1.2/24)

  Ha minden automatizmus működik, akkor a kapcsolat így épül fel pl. Budapest oldalról:

  Frame-relay encapsulation:
  A helyi routeren beállítjuk a soros interface-en a frame-relay enkapszulációt.

  LMI:
  Ha működik az automatikus LMI típus beállítás, akkor lekérjük az FRSW1-től az elérhető PVC-k DLCI-jét. LMI üzenetben megkajuk, hogy a DLCI 16 van számunkra fenntartva.

  Inverz ARP:
  A budapesti router kihirdeti jelenlétét a virtuális áramkörön a 192.168.1.1/24 címének kiküldésével, DLCI 16-al. Debrecen router fogadja ezt az információt és hozzárendeli a kapott 192.168.1.2 IP-címet a helyi DLCI 20 címéhez. Gyakorlatilag hozzá már úgy érkezik a csomag, hogy a 2. rétegbeli cím DLCI 20 lesz benne. Debrecen router is hirdeti saját IP-címét a virtuális áramkörön, vagyis 192.168.1.2/24, DLCI 20 lesz a csomagban. Budapest router ezt úgy kapja meg, hogy 192.168.1.2 IP és DLCI 16 lesz benne. Ezt felveszi a saját frame-relay map táblájába.

  Hibakeresés:

  Layer 1: kábel stb.

  Layer 2: Nem egyezik az LMI típusa a szolgáltató FR switchével. Ez pl. észrevehető a show frame-relay lmi parancsból. A Num Status Enq. Sent valamint Num Status msgs Rcvd mezőknek nagyjából együtt kell nőniük, valamint a timeouts értékeknek nem szabad nőniük.

  R1#show frame-relay lmi
  LMI Statistics for interface Serial0/0/0 (Frame Relay DTE) LMI TYPE = ANSI
  Invalid Unnumbered info 0 Invalid Prot Disc 0
  Invalid dummy Call Ref 0 Invalid Msg Type 0
  Invalid Status Message 0 Invalid Lock Shift 0
  Invalid Information ID 0 Invalid Report IE Len 0
  Invalid Report Request 0 Invalid Keep IE Len 0
  Num Status Enq. Sent 122 Num Status msgs Rcvd 122
  Num Update Status Rcvd 0 Num Status Timeouts 0
  Last Full Status Req 00:00:04 Last Full Status Rcvd 00:13:24

  Ilyenkor az interfacen kiadott frame-relay lmi-type [cisco | ansi | q933a] paranccsal kell beállítani az LMI típusát.

  PVC problémák

  A show frame-relay pvc parancs kimenetén látszik a PVC állapota. Ha a hibát a nem megfelelő frame-relay enkaszuláció okozza, akkor azt az encapsulation frame-relay [cisco | ietf] paranccsal változtathatjuk meg.

  Ha az inverz ARP nem működik (nem támogatja valamelyik eszköz, vagy ki van kapcsolva), akkor kézzel kell összerendelni a helyi DLCI-ket a távoli IP címekkel. Ez látszik a show frame-relay map kimenetén. A frame-relay map ip ip-cím dlci broadcast paranccsal korrigálhatjuk a problémát.

Új hozzászólás Aktív témák