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

• #844 Tsory tag zsolti.22 #843

  Új Válasz 2012-05-30 11:54:03 #844

  Ú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 zsolti.22 #843 üzenetére

  Akkor inkább Amazon.

  TShoot 39,99 USD
  Switch 37,79 USD
  CCNA Sec 29,99 USD

  Nekem eddig 3 könyvet 14-16 USD körül hoztak meg. Így 123,77 a 3 könyv. Cisco Press-szel számolva 30+30+25+45=130 USD, ha tényleg 45 USD a szállítási költség és a CCNA Sec-et odaadnák 25 USD-ért.

• #759 Tsory tag sunyijanika #757

  Új Válasz 2012-05-16 20:41:07 #759

  Ú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 sunyijanika #757 üzenetére

  Nem csak az update-ek, de a szomszédsági viszony kiépítéséhez szükséges hello csomagok is multicastban mennek ospf és eigrp esetében is, így itt is szükség lehet a broadcast kiegészítésre.

• #756 Tsory tag zsolti.22 #752

  Új Válasz 2012-05-16 20:26:13 #756

  Ú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 zsolti.22 #752 üzenetére

  Itt van még néhány példa és magyarázat:
  [link]

• #755 Tsory tag zsolti.22 #752

  Új Válasz 2012-05-16 20:15:19 #755

  Ú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 zsolti.22 #752 üzenetére

  Multipoint frame-relay esetén ahhoz, hogy a pingek menjenek, a spoke routereknek tudni kell pingetni egymást. Ehhez tudniuk kell, hogy az azonos alhálózatban lévő másik router merre van. Ehhez fel kell venni kézzel még egy frame-relay map parancsot a spoke routereken.

  Pl. R2 192.168.1.2/24 -- DLCI201 -- FRSW --DLCI102 ---- R1 192.168.1.1/24 --- DLCI103 -- FRSW --- DLCI301 --- R3 192.168.1.3/24

  Ilyenkor R2-n ki kell adni:

  frame-relay map ip 192.168.1.1 201 broadcast
  frame-relay map ip 192.168.1.3 201 broadcast

  R3-n:

  frame-relay map ip 192.168.1.1 301 broadcast
  frame-relay map ip 192.168.1.2 301 broadcast

  Így egy traceroute parancsnak érdekes kimenete lehet:

  R2#traceroute 192.168.1.3

  Type escape sequence to abort.
  Tracing the route to 192.168.1.3

  1 192.168.1.1 29 msec 28 msec 28 msec
  2 192.168.1.3 64 msec * 56msec

  Ekkor már a ping is meni fog.

  A routing update-ek általában broadcast vagy multicast forgalommal mennek. Ezt alapból a routerek nem továbbítják. A frame-relay map parancs végén kiadott broadcast kiegészítéssel azonban ezeket a forgalmak is továbbításre kerülnek, így elvileg kiépülhet a szomszédsági viszony is a spoke routerek között, habár ezt ki kellene próbálni.

• #711 Tsory tag BaziJoe00 #710

  Új Válasz 2012-05-11 13:11:19 #711

  Ú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 BaziJoe00 #710 üzenetére

  Mintha az egyik dollárban a másik meg fontban lenne. USA vs. GB. A book description-nél van ISBN szám az USA oldalon, a GB-nél a product details-nél.

• #623 Tsory tag zsolti.22 #610

  Új Válasz 2012-05-09 09:42:50 #623

  Ú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 zsolti.22 #610 üzenetére

  A packet tracer-rel ellentétben a GNS3 magát a hardvert emulálja, ebbe lehet valódi ios-t betölteni. Az emuláció miatt erőforrás igényesebb, de cserébe a hardver közeli parancsok kivételével az összes ios parancsot lehet használni. Pl. én megszoktam a w rövidítést a packet tracerben, és meglepődtem, hogy a GNS3-ban és valódi eszközön ez nem elég, hiszen sokkal több parancs elérhető, így w-vel is több kezdődik, így wr-t kell gépelni. A felhő emulátoron keresztül össze lehet kötni fizikai hardverekkel is.

  A GNS3-hoz érdemes az ios-t kitömöríteni pl. winrar-ral, mert így jobban fut vele. Ha betöltesz egy ios-t, akkor érdemes ellenőrizni a minimális követelményeit, amit az ios lapon elhelyezett linkkel könnyen meg tudsz tenni. Pl. Image Name c3745-adventerprisek9-mz.124-15.T14.bin DRAM / Min Flash 256 / 64. A 3700-as routereknél valamiért 16 MB a flash alapértelmezett értéke (legalábbis nálam), ezt át kell állítani legalább 64 MB-re, amit a router konfigurációjánál lehet megváltoztatni. Ezután már rendesen elindul a router. Az összekötéseknél ha manuális módot választasz, akkor meg lehet adni neki konkrétan, hogy melyik portot mivel akarod összekötni.

  Szerintem jóval kényelmetlenebb a kezelése a GNS3-nak, mint a packet tracernek, de mivel valódi IOS-t lehet betölteni, ezért több mindenre használható, mint a packet tracer. Az emuláció miatt sok eszköznél nem árt az erős PC alá.

• #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.

• #519 Tsory tag zsolti.22 #518

  Új Válasz 2012-04-26 16:23:27 #519

  Ú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 zsolti.22 #518 üzenetére

  Az LMI type ezek közül lehet valamelyik, IETF nem:

  R2(config-if)#frame-relay lmi-type ?
  cisco
  ansi
  q933a

  A 11.2-es vagy nagyobb verziójú IOS eszközöknél az LMI autosense-es, vagyis megpróbálja automatikusan detektálni a router az FR switch LMI típusát.

  Az end-to-end kapcsolatnál érdekes a frame-relay encapsulation típusa. Ez alapból cisco, habár ilyen opció nem látszik a helpben. Ha nem cisco router van a túloldalon, akkor ezt kell ietf-re állítani:

  R2(config-if)#encapsulation frame-relay ?
  MFR Multilink Frame Relay bundle interface
  ietf Use RFC1490/RFC2427 encapsulation
  <cr>

  Ts

• #512 Tsory tag tusi_ #508

  Új Válasz 2012-04-25 23:57:54 #512

  Ú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_ #508 üzenetére

  Jó lesz az a könyv. Az ábrán FR global címek vannak feltüntetve. Néhány oldallal előrébb el is magyarázzák a különbséget. Vagyis a local DLCI-k vannak úgy beállítva, hogy a túloldal global DLCI-vel egyezzen meg.

  "Frame Relay Global Addressing (DLCIs)

  The previous section discusses how Frame Relay addressing really works with local addressing.

  If you happened to come to this section on global addressing, and have not yet understood local addressing, stop now, and go back! Global addressing only makes sense if you have a good understanding of local addressing.

  Global addressing, or global DLCIs, is a convention service providers may use when choosing local DLCIs. By using the global addressing convention, documentation becomes easier, adding new sites becomes more predictable, and the DLCIs appear to be more like MAC addressing, with one DLCI per router.

  NOTE The use of global Frame Relay addressing does not change how Frame Relay uses local addresses, or the DLCIs in the frames as they pass over the network, and most importantly, routers still only configure and see local DLCIs."

  Ts

• #506 Tsory tag tusi_ #503

  Új Válasz 2012-04-25 22:32:55 #506

  Ú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_ #503 üzenetére

  Ez az ábra ne annyira jó . Melyik könyvből van? A DLCI értékek layer 2-es címek, gondolj úgy rájuk, minha MAC címek lennének. A hozzád legközelebb eső FR switchet címzed vele. Az FR hálózaton több ilyen switch is lehet, így a DLCI érték állandóan változik, míg a layer 3 cím nem (hasonlóan Ethernet hálózat esetében hop-ról hop-ra változik a forrás és cél MAC cím, míg az IP változatlan marad).

  

  Ts

• #500 Tsory tag tusi_ #499

  Új Válasz 2012-04-25 21:32:55 #500

  Ú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_ #499 üzenetére

  Az ábrán látszik, hogy statikus DLCI IP összerendelés történt. A távoli IP-t kell a lokális DLCI-vel összerendelni. Attalla esetében már az IP is problémás, mert a saját interface IP-je van beállítva, nem a távoli IP. A státusz jelentései:

  ACTIVE: sikeres end-to-end kapcsolat.
  INACTIVE: Sikeres kapcsolat a frame-relay switch-ig, de a PVC túlsó vége nem válaszol. Valószínűleg rosszul van konfigurálva a switch.
  DELETED: Olyan DLCI van konfigurálva, amit a switch nem fogad el ezen az interface-en. Vagyis valószínűleg rosszul van konfigurálva a DLCI érték.

  Így a C válasz a jó. Az E a statikus összerendelés miatt nem jó, ebben az esetben automatikusan kikapcsol az inverse ARP.

  "When static mapping is configured on an interface for a protocol and a specific DLCI, the router automatically disables dynamic Inverse ARP for the protocol and the specific DLCI on the interface."

  Ts

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