- Több tucat gyorsító összeköthetőségét kínálja az Instinct MI400 sorozat
- Imádja az alteregókat az új AMD Software
- Csak úgy szórja a dollár milliárdokat adatközpontokra az Amazon
- Mexikó tisztázta a Google-t a monopóliummal kapcsolatos vádak alól
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Bambu Lab 3D nyomtatók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen notebookot vegyek?
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- Milyen egeret válasszak?
- Milyen monitort vegyek?
- Házimozi belépő szinten
- Milyen belső merevlemezt vegyek?
- Samsung LCD és LED TV-k
- Milyen billentyűzetet vegyek?
-
PROHARDVER!
--- Még az új vizsgarendszer előtti információk, majd frissítjük! ---
Gyakran ismételt kérdések
Olvasd el a cikkeket itt.
Új hozzászólás Aktív témák
-
robesz87
tag
válasz
FecoGee
#1896
üzenetére
Nekem úgy sem működött, de kikockultam az issue-t.
Így nem működik:
line vty 0 4
login
line vty 5 15
password cisco
loginÉs a működő:
line vty 0 4
no login
line vty 5 15
password cisco
loginAzaz a line vty 0 4-hez be kellett írnom a NO LOGIN parancsot, ami letiltja a belépést 0-4-ig.
-
crok
Topikgazda
válasz
FecoGee
#1893
üzenetére
Így van, nincs login pw. Mikor telnetelsz a 0.-at nyitod meg először.
Ha a nulladikon ACL nem tilt de nem tudsz bejelentkezni, mert a login
password nincs beállítva (és nincs aaa..) akkor kizártad magad. Az
adminnak pl. úgy lehet garantált elérést biztosítani, hogy az utolsó login
vty-ra csak az admin IP-t engedélyezed, így azt más nem tudja lefoglalni,
bármennyien is vagytok bent (vagy bruteforce-al próbálkoznak..) de épp
ezért neked mindig fent lesz tartva. -
robesz87
tag
válasz
FecoGee
#1891
üzenetére
Ez a működő. Ha 5 15-re konfigulom nem megy. 2960 24TT switch, ha ez számít valamit és Packet Tracer
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname S1
!
enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0
!
!
spanning-tree mode pvst
!
interface FastEthernet0/1
!
.
.(kiszedtem a portokat, ne legyen hosszú a post)
.
interface FastEthernet0/23
switchport access vlan 99
switchport mode access
!
interface FastEthernet0/24
!
interface GigabitEthernet1/1
!
interface GigabitEthernet1/2
!
interface Vlan1
no ip address
shutdown
!
interface Vlan11
no ip address
!
interface Vlan99
ip address 192.168.99.254 255.255.255.0
!
interface Vlan101
no ip address
!
!
line con 0
password cisco
login
!
line vty 0 4
password cisco
login
line vty 5 15
login
!
!
end -
robesz87
tag
Sziasztok!
Telnetet próbálgattam Switch-en.
Minden ok volt, ugyanabban a Vlan-ban volt a PC, pingelni is tudtam...
- Amikor line vty 5 15 -re konfiguráltam fel a telnetet, nem tudtam csatlakozni.
- Ellenben line vty 0 4 -re konfigolva működik.Kétszer is felépítettem az elejétől, hátha esetleg csak elírtam valami parancsot, de ugyanerre jutottam.
//
PC>telnet 192.168.99.2
Trying 192.168.99.2 ...Open[Connection to 192.168.99.2 closed by foreign host]
Tehát a kérdésem az, hogy miért csak akkor működik a telnet, ha 0 4-re konfigolom?
-
jerry311
nagyúr
-
Tsory
tag
Én úgy tudom, hogy az automatikusan létrejövő VLAN-ok mellett alapból kétféleképpen lehet létrehozni VLAN-okat:
1. Global Configuration Mode
Switch# configure terminal
Switch(config)# vlan vlan_ID
Switch(config-vlan)# end2. VLAN Database Mode
Switch# vlan database
Switch(vlan)# vlan vlan_ID
Switch(vlan)# exitEbből a második módszer elvileg már elavult, hivatalosan az elsőt javasolják.
-
crok
Topikgazda
Igen, plusz egy metódus.
De ezek egyike se működik jól pl. 8xx routereken meg úgy alapvetően olyan
esetben, ha routert használsz switch modullal (mindegy, hogy fix vagy modu-
láris az eszköz): hiába mondod neki, hogy interface vlan xyz, hiába írja ki,
hogy okayrendbeneddignemvoltilyenvlandemostcsináltam, hiába mutatja a
sh ip int brie, hogy up/up.. akkor se nyikkannak meg az ilyen SVI-ok, pedig
kellene.. ám miután vlan database-ben hozzáadod, és az NVRAM-ban a vlan
database-be bekerültek azonnal működnek. Ez sokéves tapasztalat. Ezért
írtam, hogy ami minden esetben működik az a vlan database majd interface
vlan.. Ez minden esetben működik. Természetesen L3 switchen is lehet
választani azt a lehetőséget, hogy a csak átmenő VLAN-okat is interface
vlan <vlanID> -val csinálod meg, de kérdés: van értelme? Ott lesz a sh int
desc -ben, ott lesz a konfigban az üres SVI konfig is. Pedig mondjuk csak
access porton és/vagy az upstream trunk-on engeded, mert nem routeolod.
Na az ilyet nem tenném csak vlan database-be, mert csak ott kell meglennie.[Szerk.]
Ja és a kegyvesztett parancsok világ életemben wr -el mentettem konfigot..
pedig 12.2 után azt mondták, hogy ki fogják venni és csak a copy run start
marad meg.. nos 15.2 -nél járunk.. wr még mindig van! Ja az tudjátok miért
jött 15 a 12 után? -
crok
Topikgazda
válasz
robesz87
#1879
üzenetére
Ha jól értem a kérdésed:
@1:
vlan database
vlan <vlan ID>
Ezzel létrehoztad a VLAN-t a switch-en (routeren, ha a routerben SW
modul van). Ezzel kreáltál egy L2 VLAN-t, de még nem csináltál SVI-t
(lehet nem is csinálhatsz, mert L2 switchen dolgozol épp..).@2:
conf t
interface vlan <vlan ID>
Ezzel ha eddig nem volt ilyen VLAN akkor létrehozod és egyúttal az SVI-t
is létrehoztad, mostmár adhatsz neki IP címet meg amit akarsz. De nem
minden IOS tudja ezt megcsinálni valamint L2 switchen csak egy olyan
VLAN interface lehet, aminek van IP címe (ugye management).Ezért a az alap metódus az, hogy VLAN database-ben létrehozod és ha
kell SVI, akkor conf t + interface vlan <vlan ID> és ami még kell. -
-
Tsory
tag
válasz
zsolti.22
#1872
üzenetére
Take it easy! Nem mondtam, hogy te írtad be, csak meglepődtem, mert nálam nem jelent meg. Csak próbáltam rájönni, mi lehet a megoldás. Sunyijanika már felvilágosított engem, hogy ez így természetes.
Itthon újra megcsináltam a konfigot, itt is működik. Úgy látszik, tud ez konzekvensen is működni
. -
#1873
Tsory
tag
sunyijanika
#1871
Tsory
tag
válasz
sunyijanika
#1871
üzenetére
Köszi, ezt nem tudtam. Nálam csak projekt mentésekot majd visszatöltésekor generálta le a plusz bejegyzéseket.
-
#1871
sunyijanika
tag
Tsory
#1870
sunyijanika
tag
Nem, ennek így kell működnie, mivel az igaz, hogy amikor előállítod elég csak két paramétert beállítani (és nem is enged többet - fordítottját), de amint elindítod a FW switchet az legenerálja a maradékot, de ennek nem kéne semmi hibát okoznia.
Azonban, lehet időként a gns3 kavar a dologba , ha nyomsz neki egy reset-t és újra felveszed a DLCI-k menni fog ahogy nálam és Tsory-nál is
-
Tsory
tag
válasz
zsolti.22
#1869
üzenetére
Nézd meg az FR switch konfigját. Ha megnyitom a feltöltött project fájlodat, akkor nálam így néz ki a konfigja:
1:102 - 2:201
1:103 - 3:301
2:201 - 1:102
3:301 - 1:103Mintha duplázná a konfigot. Ilyet nekem nem is enged előállítani. Törölve az összerendeléseket, resetelve az FR switchet, majd felvéve:
1:102 - 2:201
1:103 - 3:301már rendesen működik nálam.
Enélkül azt kapja vissza R1, hogy nem is léteznek ilyen DLCI-k:
R1#sh frame-relay map
Serial0/0.1 (down): ip 10.0.0.2 dlci 102(0x66,0x1860), static,
broadcast,
CISCO, status deleted
Serial0/0.1 (down): ip 10.0.0.3 dlci 103(0x67,0x1870), static,
broadcast,
CISCO, status deleted -
#1869
zsolti.22
senior tag
sunyijanika
#1867
zsolti.22
senior tag
válasz
sunyijanika
#1867
üzenetére
Most főleg nem a két szpók mögötti hálózat érdekel, ezek a nyamvadtak még EIGRP-n sem fedezik fel egymást, deleted, inactive a frame-relay PVC, nem hogy még itt split-horizonozzak, addig se annak, se az auto summarynak egy deka értelme sincsen.
A GNS3 is up2date, csak lejáratom itt magam.
-
Tsory
tag
válasz
f_sanyee
#1865
üzenetére
Egyetértek, de jó lenne, ha megbízhatóbban működne. Frissítettem a legújabb verzióra, és sokkal jobb lett. A régiben a 3725-ben volt alapból 3 WIC1T, de nem működött, csak ha bementem a config fül alá, és változtatás nélkül leokéztam. Most az új verzióban nincs benne WIC kártya, de ha rámegyek az add a link seriallal, akkor belerak egyet automatikusan. Így ez a része már oké.
Ezzel össze tudtam rakni a 3 router 1 FR Switch multipoint konfigot, és működik is. Ha a hub routeren tiltom a split horizont, akkor a spoke routerek látják egymás hálózatait. Ha nem tiltom, akkor nem.
Egy vicces dolog van azért még vele: a project betöltésekor, amikor frissen indul minden eszköz, akkor úgy indul, hogy az EIGRP partnerség megszakad, holott addig nem is lehetett. Valamint kell neki vagy 5 perc, mire beáll a rendszer egy core i5-ön.
-
sunyijanika
tag
válasz
zsolti.22
#1849
üzenetére
Nézzük ezt a FR-t.
1. Nincs kiadva a (no auto-summary) - ahogy ezt már írták,
2. a hubra mindenféle kép kell a no split-horizon eigrp x parancs.
3. Ahogy látszik, néhány útvonalat ismer, néhányat nem a 2 spoke. Ha megnézed a frame-relay map-t akkor láthatod, hogy csak egy út van és az a "hub"-hoz vezet. a hubon kivan adva a no split parancs ezért ő szépen küldi az update-t mind2 irányba ezért látod a subneteket, de soha nem fogja elérni őket (no ping). Ezért mindenképp kell további map-ket hozzáadni.
R2 ---> frame-relay map ip 10.0.0.3 201 broadcast
R3 ---> frame-relay map ip 10.0.0.2 301 broadcast
Ezek után szépen működni fog a dolog!
- Az mind1, hogy a fizikai vagy multipoint-t konfigurálsz a spokekon mind2 egyaránt működik (bár nincs sok értelme)
-
zsolti.22
senior tag
válasz
f_sanyee
#1865
üzenetére
Nem kell túl nagy tervezés ahhoz, hogy összedobjon az ember egy EIGRP-s FR hálózatot, nincs 3 perc az egész. És 100%-ig meg vagyok győződve, hogy tegnap délután ugyanezen konfigurációval ment inverz ARP-vel, azonnal felismerték egymást FR-n keresztül az EIGRP szomszédok; tegnap estére már ugyanaz a konfiguráció nem működött inverz ARP-vel és kézi map paranccsal sem.
Tervezheted a topológiát, ahogy akarod, ha a GNS3 gondol egyet és nem akar úgy menni, ahogy szeretnéd. -
f_sanyee
senior tag
GNS3-nek vannak elonyei fizikai eszkozokkel szemben, pl annyi routert futtatsz amennyit a geped elbir. nem kell neki hely, aram. nincs hangja, akarmelyik kapcsolatra nyomhatsz wiresharkot (ami egy igazi kabel eseten nem tul egyszeru) ami eleg hasznos tud lenni. egyszerubb es gyorsabb felepiteni benne barmilyen topologiat mint a drotokkal szorakozni.
nekem a 3725-os routerek bevalltak, igaz vannak problemak, de ezeket el lehet kerulni, pl ha megtervezed rendesen mit akarsz osszekotni mivel es nem ossze vissza adogatod az wiceket meg torolgeted a kapcsolatokat, akkor fog menni rendesen. nalam kulon fut dynamips es minen uj topologia elott ujdainditom. -
Tsory
tag
válasz
zsolti.22
#1859
üzenetére
Hát ez nekem elég sztochasztikusan viselkedik. Van, hogy a pingek sem mennek, vagy akár az interface-eket sem mennek up/up állapotba.
A konfig nekem jónak tűnik, mondjuk a no auto-summary-t beállítanám az eigrp alá.
Hát erősen elgondolkoztam, hogy vagy nagyon alaposan ki kell választani a megfelő router/ios típust a GNS3-ban, vagy érdemes ezeket is fizikai eszközökön gyakorolni. Szerencsére a 26XX sorozathoz serial interface-el már elég olcsón hozzá lehet jutni, talán az is jó a tesztekhez. FR switchet is lehet belőlük csinálni.
-
Tsory
tag
válasz
zsolti.22
#1840
üzenetére
> teljesen vagy csak részlegesen, de ne legyen full mesh a PVC-k és routerek között <---ez nem tiszta.
Ha full mesh topológiát használsz, akkor minden router közvetlenül eléri a másikat, így a routing update-eket is közvetlenül megkapják. Így nem tud közbeszólni a spit horizon rule.
Ha nincs full mesh topológiád, akkor lesz olyan része a hálózatnak, ahol egy router a multipoint subinterface-en bejövő routing update-et nem fogja továbbítani ugyanazon subinterface-én lévő másik DLCI alatt elérhető másik routernek, így az nem fogja megkapni az update-et. Ebben az esetben vagy ki kell kapcsolni a split horizont, vagy point-to-point subinterface-t kell alkalmazni.
-
jerry311
nagyúr
-
zsolti.22
senior tag
Ma reggel ugyanarra a konfigra már a RARP se működött...ez a GNS böszmesége. Gyakran előfordul az, hogy ha előbb indítom el a routereket, minthogy adok nekik WIC-1T-t (persze nem menet közben), akkor megint nekiáll hülyeséget kiírni, hogy nem tudja a 0/32-es serial portra csatlakoztatni a kábelt.
-
Tsory
tag
válasz
robesz87
#1854
üzenetére
A native vagy defalt VLAN-t trunk port esetén értelmezzük. A trunk port az a port, amin több VLAN forgalma haladhat keresztül. Tipikusan switchek között van. Mivel több VLAN forgalma megy keresztül ezen a kapcsolaton, ezért szükség van valamilyen jelölésre, hogy a túloldal tudja, milyen VLAN-ba kell kerülnie a forgalomnak. Ezt cimkézéssel (tagging) oldják meg. Erre van legalább két módszer: ISL, 802.1q. Az ISL Cisco specifikus, a 802.1q IEEE szabvány.
Alapértelmezés szerint a default vagy más néven native VLAN forgalma cimke nélkül megy át a trunk porton. Hogy erre miért volt szükség, arra 3 indokot találtam:
1. SW1--HUB--SW2 esetén ha a hub-ra PC is csatlakozik, akkor az a forgalom tageletlen, így a switchek nem tudnák forgalmazni az innen jövő adatokat.
2. A tagelés késleltetést okoz a feldolgozásban, ezért lehetnek olyan protokollok, ahol ez számít, azokat jobb cimke nélkül forgalmazni.
3. kompatibilitási okokból.
Vagyis a native VLAN forgalma tageletlenül közlekedik alapból. A két szomszédos switchen be tudod állítani, hogy mi a default VLAN (nem feltétlenül a VLAN1 lesz az). Így az abba a VLAN-ba tartozó forgalom cimke nélkül közlekedik a két swith között a trunk porton. Értelemszerűen ugyannarra kell állítani a két szomszédos switch trunk portján, különben az egyik VLAN forgalma belefolyna a másikba.
Ha mégis tageled a natív VLAN forgalmát, akkor minden forgalom tagelve megy át a trunk porton a két switch között, és természetesen működik a kommunikáció így is.
Még valami: a tag alapból addig marad rajta a kereteken (qinq ill. dubble taggingel most nem foglalkozom), amíg át nem utaznak a trunk porton, után a switch leveszi róla, és úgy küldi őket az access portokra. Ha nincs trunk portod, akkor nem is taggelődik a forgalom (ok kivéve pl. voice VLAN, ami valójában akár trunk port is lehetne, de multi-VLAN access portnak hívják).
-
robesz87
tag
Visszamenőleg ismét lenne 2 natív vlan-os kérdésem.
1) A natív vlan csak a default vlan1-re tud belépni ( mert ahhoz nem kell tag )?
2) Tegyük fel, SwitchA-ból SwitchB-be érkezik a 99-es natív vlanon a tagged keret. Ez egyben a trunk port is. A natív vlanon a tag-et elhagyja? Így nem is éri el a célját az adat?
-
Tsory
tag
válasz
robesz87
#1847
üzenetére
Ha külön akarsz kezelni felhasználókat és hozzáférési szinteket, akkor legegyszerűbben a login local valamint a username username privilege-level level password password paranccsal teheted meg.
Pl.
username guest privilege 1 password guest
username admin privilege 15 password adminline vty 0 4
login localÖsszefoglalva:
The Cisco IOS thus supports the following local (non-AAA) authentication settings:
1. no login disables any authentication; anyone able to access the line (console or VTY through telnet or SSH) is logged in automatically (do not use outside of lab environment).
2. login enables simple password-based authentication. The password is specified per-line (console or VTY) with the password command (do not specify different passwords on different VTY lines or you'll create total confusion).
3. login local enables local username+password authentication
Ezen felül lehet még külső szerverrel (AAA) pl. tacacs vagy radius protokollal is authentikálni.
-
Tsory
tag
válasz
robesz87
#1847
üzenetére
Lehetni lehet. csak nem látom sok értelmét. Belépéskor nem tudsz vty vonalat választani, elvileg sorban kapod őket. Így az első 5 kapcsolatnál password1 kellene, majd utána a password2.
Azt viszont el lehet vele érni, hogy pl. max 2 konkurens kapcsolatod lehet, ha csak 2 vty vonalat engedélyezel.
-
crok
Topikgazda
válasz
zsolti.22
#1849
üzenetére
Ahogy látom R1-en van ugyan subinterface, de csak egy. Kíváncsi lennék
a konfigra. pastebin.com-ra is teheted. De ahogy látom Null0-ra mutat az
az EIGRP route amit kaptál.. az nem valami jó Egyébként az EIGRP
konfigban van no autosum? Ja és akkor a FR SW-ben csak 2 entry van? -
crok
Topikgazda
válasz
zsolti.22
#1844
üzenetére
Igen, csak a középsőn volt, de a split horizon csak azon játszhatott.. volna!
De mivel subint volt, gondolom 2, így az egyik egyfelé, másik másik felé
ment, így a split horizon miatt a subint már nem fogja meg a routing update-
eket, hiszen már másik interface-en megy a dolog -
crok
Topikgazda
válasz
zsolti.22
#1840
üzenetére
> teljesen vagy csak részlegesen, de ne legyen full mesh a PVC-k és
routerek között <---ez nem tiszta.Nem csodálom. A "teljesen" és a "full mesh" számomra ugyan az.
A 3 router összekötéséhez egy negyediket vagy Frame-relay switchet
használtál? Mi a konfigja? Akkor lenne baj, ha így nézne ki a kiépítés:LAN
_
|
R1
|
|
[] <- Frame-relay switch (lehet router is..)
||
/ \
/ \
R2 R3
| |
_ _
LAN LANEzen esetben, amint látod, R1 egyetlen interface-én 2 router lóg. Nyilván
más DLCI-vel éri el a másik 2 routert ám itt bizony bejön a képbe a split
horizon szivatás, hiszen egy interface-en át érsz el 2 eszközt, mind a
kettőtől kapsz utakat, de ugyan azon interface-en keresztül nem küldhet
ki a router routing információkat R1 ahonnan kapta.. tehát R1 megkapja
R2 és R3-tól a routing információkat ám nem küldheti ki az R2-től kapott
információkat R3-nak, hisz ugyan azon interface-en kellene kiküldeni,
mint amin kapta (még akkor is, ha más DLCI). Képet és konfigot adj,
akkor meg tudom nézni hogy miért megy máshogy, mint várod. -
-
Tsory
tag
válasz
zsolti.22
#1840
üzenetére
Ha subinterface-eket használtál, akkor a split horizon nem játszik:
Configuring Frame Relay subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces. This capability allows you to overcome split horizon rules so packets received on one virtual interface can be forwarded to another virtual interface, even if they are configured on the same physical interface.
-
Tsory
tag
válasz
robesz87
#1838
üzenetére
1. Alapvetően igen, de nem feltétlenül telnet, lehet pl. ssh is.
Ezt a vty-n kiadott transport input paranccsal lehet szabályozni.
2. Eszköz és IOS függő is, de minden aktív vty erőforrásokat használ, erre oda kell figyleni.
Nálam pl. 989 lehet egy Enterprise IOS-el 2811-en:
Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3)
Router(config)#line vty 0 ?
<1-988> Last Line number
<cr> -
zsolti.22
senior tag
Oké.
Csináltam olyat, hogy:LAN |== R1 =============== R2 =============== R3 ==| LAN
............S0/0 ...........................S0/0.1 multi ...................S0/0Sima mezei Frame Relay, az R2 multipointnak konfigolva. Mindegy, hogy RARP-pal vagy map ip-vel, de az íájdzsiárpí megy rajtuk és a split horizon valamiért nem, vagy nem úgy műxik, ahogy kéne, mert az R1 látja R3 hálózatát és viszont. Tudomásom szerint csak akkor kéne, ha kikapcsolom a split horizont. Épp most írom le DOCX-be a route könyv összefoglalóját és van ilyen, hogy 3 feltételnek kell teljesülnie, hogy gond legyen a Split Horizonnal, mégpedig:
> 3 vagy annál több router legyen a hálóban, amik egy alhálóban vannak
> legyen multipoint interfész konfigurálva
> teljesen vagy csak részlegesen, de ne legyen full mesh a PVC-k és routerek között <---ez nem tiszta. -
jerry311
nagyúr
-
crok
Topikgazda
válasz
zsolti.22
#1836
üzenetére
Gondolj úgy a stub-ra, mint olyan routerre, ami mögött már nincs más hálózat,
csak a saját LAN-ja.. Azért jó a stub EIGRP-nél, mert hub-and-spoke design
esetén például nem fog a hubtól EIGRP-n kérést kapni, hogy egy épp eltűnt
route nála megtalálható-e, ahogy más, normális esetben történne, mert a stub
router egy speciális EIGRP packet-el minden szomszédot értesít arról, hogy ő
csak egy stub - egy csonk a hálózaton, egy "végpont" EIGRP szempontból.
Ez nem csak emiatt jó, hogy a hub nem kérdez feleslegesen, de mivel a spoke
router egy stub - tehát nincs (vagy csekély számú..) másik WAN kapcsolata
van csak így nem kell a teljes hálózat routing tábláját megtanulni, a stub csak
elküldi a saját hálózatait és kap a hub(ok)tól egy default utat. Így erőforrást és
konvergenciaidőt spórolsz: a spoke (stub) router routing táblája kicsi, a hub(ok)
meg tudnak róla hogy a stub felől érkezett route-ok ha eltűnnek az EIGRP-ből
akkor azokat nemigen kell máshol keresni. Kicsit ASCII art-osan:Ilyen van, hogy:
LAN |==stub spoke == hub == stub spoke==| LAN..de olyan nincs hogy:
LAN |==stub spoke == hub == stub spoke==| LAN
|| ||
"======================="mert ekkor a stub már nem stub, nem egy "lezárt hálózat" mert van kapcsolata
egy másik spoke-al, így az egyik stub a másiknak a hálózatait nem csak a hub
routeren keresztül ismeri. A Cisco oldala tök jól leírja. -
zsolti.22
senior tag
Mai napig nem értem ezt az eigrp stubságot. Átfordítottam magyarra, de úgy se világos. Más szavakkal, mint ez, el tudja mondani valaki: A stub fogalma: egy olyan router, ami nem továbbít forgalmat két távoli EIGRP által tanult hálózat között.
Ez nekem túl egyszerűen van fogalmazva, hogy megértsem. -
Tsory
tag
Ha már így beindult a fórum, akkor itt egy kis hétvégi történet, remélem nem untatok vele senkit.
Amikor a konzol kábel és a csavarhúzó nem elég:
Egy 2811-est akartam kiporolni, de nem sikerült a rack fület leszedni róla, mert a csavarok egy része bele volt szorulva. A végén sikerült szétnyírnyi a csavarok fejét is. Mit lehet ilyenkor tenni? Le kellett fúrni a csavarok fejét. A rack fülek és a fedlap levétele után már szerencsére ki lehetett csavarni a fej nélküli csavarokat. Ebay-en néztem csavart, de csak aranyárban találtam. Szerencsére a csavarboltban volt M4X10 csillag süllyesztett fejű csavar, ami pont jó volt hozzá. 20 db. volt vagy 100 HUF.
Tervbe volt véve a flash bővítése is, de kisméretű CF kártyák csak aranyárban voltak hozzá. A Cisco oldalán azt írják, hogy 256 MB compact flash memory a maximum, amit tud kezelni. A fórumokon viszont azt írták, hogy 1 vagy 2 GB-ost is kezel. Én egy 1 GB-os mezei Transcend-et vettem. Javasolták a ROMMON frissítést a flash bővítés előtt, úgyhogy én is azzal kezdtem. Ehhez a 26XX routereken fizikailag ki kellett cserélni egy a romot, a 2811-nél szerencsére az IOS cseréhez hasonlóan egyszerűen lehet upgradelni. A folyamat: C2800NM_RM2.srec.124-13r.T11 letöltése és CF kártyára másolása, ROMMON upgrade
Router#upgrade rom-monitor file flash:C2800NM_RM2.srec.124-13r.T11
This command will result in a 'power-on reset' of the router!
Continue? [yes/no]: yes
ROMMON image upgrade in progress.
Erasing boot flash eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Programming boot flash pppppppppppEzután CF kártya csere, majd ROMMON-ból TFTP-vel az IOS letöltése a CF kártyára. A show flash kimenetén öröm volt látni a szabad helyet. Így már szűken elférek rajta
.A memóriáját is bővíteni akartam, de nem volt kéznél DDR SDRAM with ECC, így a kedvenc RAM boltomból rendeltem:
http://stores.ebay.com/Memoryk
Az MEM2811-512D 512MB DRAM MEMORY CISCO ROUTER 2821 2811 volt $14.50, $3.78-ért ki is szállítják. Remélem hamarosan megérkezik.
-
tusi_
addikt
válasz
zsolti.22
#1818
üzenetére
Igazából nem nehéz a switching anyag, ha ott tartasz majd, nem lesz problémád vele. Igy most, hogy másodjára is elolvastam a switchet - fejezetenként kilaborozva - , azt mondom, sokkal egyszerűbb, mint a route. Tegnap bele néztem a routingba és nyeltem nagyokat. Abban a 370. oldalnál tartok, de szvsz nehezebb, mint a switch. Ha azt megtanultad, akkor a switch sem lesz gond.
-
tusi_
addikt
Néha többször el kell olvasnom egy fejezetet, mert nem tudom vissza mondani magamban, illetve elakadok valahol és nem kapok választ a kérdéseimre, amik felmerülnek. Ilyenkor legvégső esetben jól jönnek a tapasztaltaktól a válaszok. Bár mint korábban irtam, jobb szeretek magamtól rájönni, mert azt tuti nem felejtem el.
-
tusi_
addikt
Kb erre gondoltam. Bazi nagy helyen van értelme, ahol sok roamingos csóka dolgozik és rohangálnak egyik zónából a másikba, de egy "kisebb" helyen, ahol max 100-200 - an dolgoznak, ott "felesleges".
Kicsit olyannak tűnik ez nekem mint a VTP. Kevés switchnél felesleges, csak biztonsági rés, de ahol van 200 switch, ott jól jön, hogy csak egy helyen kell álltgatni, majd dinamikusan átmegy mindenhova.
Többet tanulok itt, mint a könyből
-
crok
Topikgazda
Elterjedt, de csak nagy, úgy értem nagyon nagy számú AP esetén éri meg
egyáltalán.. van nálunk hely, ahol 160+ AP van.. na ott azért az autonómmal
szívni egyesével egy minden AP-t érintő változtatással.. nem okay, sőt, állati
nagy szívás. Plusz a WLC-nek vannak ám nagyon király funkciói: rogue AP
szűrés, lefedettség, áthallás, zavarás mutatása térképen (ha tettél fel alaprajzot
és betetted az AP-kat láthatod az AP terhelést, az interferenciákat.. egy több
emeletes, sok-sok AP-vel felszerelt épületben ez óriási segítség.. de felesleges
pénzkidobás ha csak pár AP van. IMHO. -
crok
Topikgazda
Korrekt. Legkönnyebben hardverrel, IP-telefon, PC, Switch (+SPAN port)
és PC meg Wireshark amivel ezt tényleg meg lehet figyelni..A telefonok egy érdekes és furcsa viselkedését írtam le egy hónapja itt.
Témába vág, érdemes elolvasni hogy startkor mit csinál néhány telefon és
milyen problémákat okozhat ez egy kis port-security -vel egybekötve -
Tsory
tag
Akkor végül nem vettél még IP telefont?
Elvileg ilyenkor be van állítva a porton a voice VLAN, amit CDP-n keresztül megkap a telefon. Így a voice forgalom már taggelve megy a portra, az adat forgalom meg taggeletlenül, ami bekerül abba a VLAN-ba, ami a porton be van állítva.
Pl.
switchport access vlan 63
switchport voice vlan 306Ilyenkor a Voice forgalom tagelve megy a 306-ba, az adat forgalom meg tageletlenül a 63-ba.
-
tusi_
addikt
Szupi.
Még a telefonnal kéne kipróbálnom ezt, mert ott is a nativ vlant IS használhatja a DATA stream, ha a telefonról van átfűzve a pc.
A NONE beáltás mellett megy ha jól emléxem VID-es vlanba a telo és a PC is, mig a dot1p, untagged és vlan_vlid beállitás mellett a pc adat mindig a nativba megy.
Mivel lehetne rendesen gyakorolni a telefon beállitást ? PT nem tudja sajnos. MLS qos-t még megeszi, de itt ki is fújt. (Nem várunk sokat tőle, hisz CCNA-s progi, de valamivel szeretnék elmerülni benne.)
-
Tsory
tag
Ezek szerint már legalább kétféleképpen lehet védekezni a VLAN hopping ellen (CCNP SWITCH 642-813 Official Certification Guide)
1. Native VLAN pruning:
a. Set the native VLAN of a trunk to a bogus or unused VLAN ID.
b. Prune the native VLAN off both ends of the trunk.Vannak olyan protokollok, amelyek mindenképpen a native VLAN-ban közlekednek, de benne van a doksiban (amit be is hivatkoztál), hogy ezek a forgalmak ekkor is átmennek (CDP, PAgP, DTP).
Érdekességképpen volt, aki megnézte, hol közlekednek ezek a protokollok, és azt találta, hogy a CDP, VTP, PAgP, UDLD mindig a VLAN1-ben közlekedik, amit nem is lehet prunolni. Így csak az STP és DTP lehet érdekes prunolt native VLAN esetében:
STP and DTP frames have no relation to VLAN, so are always transmited over Native VLAN. CDP/VTP/PAgP/UDLD are always transmited over VLAN 1, if Native VLAN is 1 then will be transmited in untagged form, if VLAN 1 is tagged (Native VLAN is other VLAN then 1), protocols will be tagged with 1.
http://www.netcontractor.pl/blog/?tag=native-vlan
2. Native VLAN tagging:
One alternative is to force all 802.1Q trunks to add tags to frames for the native VLAN, too. The double-tagged VLAN hopping attack won’t work because the switch won’t remove the first tag with the native VLAN ID (VLAN 10 in the example). Instead, that tag will remain on the spoofed frame as it enters the trunk. At the far end of the trunk, the same tag will be examined, and the frame will stay on the original access VLAN (VLAN 10). To force a switch to tag the native VLAN on all its 802.1Q trunks, you can use the following command:
Switch(config)# vlan dot1q tag native
-
tusi_
addikt
vlan dot1q tag native = Native vlan tagg
"Although maintenance protocols such as CDP, PAgP, and DTP normally are carried
over the native VLAN of a trunk, they will not be affected if the native VLAN is pruned
from the trunk. They still will be sent and received on the native VLAN as a special case
even if the native VLAN ID is not in the list of allowed VLANs." -
tusi_
addikt
Tudomásom szerint a nativ vlant szokták használni Managmentnek is, de nem a vl 1 , hanem egy véletlenszerűt. Legyen vl 666.
De olyat is olvastam, hogy a támadhatósága miatt - a switchek az untagged kereteket a nativ vlanba kapcsolja - ki szokták szedni a trunk interfészen a hirdetett vlanok közül, de a vtp infok akkor is átmennek rajta. -
-
crok
Topikgazda
Ez nem teljesen van így..
Igen, a natív VLAN-on nincs VLAN tag, de attól még egy L2 switchen
használhatsz más VLAN-t is mint a VLAN1.. sőt, ha mondjuk csinálsz
egy másik VLAN-t, teszem a 100-at és az interface-eken meghagyod
a VLAN1-et natívnak, de nem teszed be egyetlen trönkbe se a.. akkor
az állt elő, hogy a VLAN 100 a management, de van rajta VLAN tag.Ha értitek mire akarok kilyukadni.
Az hogy natív VLAN meg management VLAN az olyan mint az alma
meg a körte.. van közük egymáshoz, de van, hogy nem tudod össze-
hasonlítani őket.. mindkettő gyümölcs de nem tuti hogy salátába is
egybe tennéd őket.. lehet natív VLAN-ban a management interface,
de lehet a natív VLAN más mint a management. De egyébként igen,
ha mindenhol ugyan azt a natív VLAN-t használod, a trönkökön is
átviszed őket akkor L2 szinten egy broadcast tartomány lesz így az
ARP a címeket fel tudja oldani (ha egy L3 is ) és elérik egymást. -
tusi_
addikt
válasz
robesz87
#1802
üzenetére
A nativ a taggeletlen Vlan, nem kap VID-et.
Ezt használja a VTP is pl.A managment Vlan az a Vlan, amin sávon belüli elérést tudsz csinálni, és ssh-val, vagy - inkább ne - telnettel be tudsz jelentkezni a kütyükre. Minden l2 switchen addsz egy ip-t a nativ vlannak - ugyanabból a subnetből - és azon kersztül tudod elérni távolról.
. Mivel point-to-multipoint subinterface van a hub routeren a konfigban, így itt szerepet játszik a split horizon.
Új hozzászólás Aktív témák
Hirdetés
- Kérlek használd a keresőt, mielőtt kérdezel!
- Olvasd el a téma összefoglalót mielőtt kérdezel!
- A dumpok és a warez tiltott témának számítanak!
- Bomba Ár! Dell Latitude 3190 - Intel N4120 I 4GB I 128GB SSD I 11,6" HD I Cam I W11 I Garancia!
- Bomba Ár! Dell Latitude 3190 - Intel N4120 I 4GB I 64GB SSD I 11,6" HD I Cam I W11 I Garancia!
- Bomba ár! Dell Latitude E6520 - i7-2760QM I 8GB I 256SSD I Nvidia I HDMI I 15,6" HD+ I W10 I Gari!
- Bomba ár! Dell Latitude E7240 - i7-4GEN I 16GB I 256SSD I 12,5" HD I HDMI I Cam I W10 I Garancia!
- Bomba ár! Toshiba Satellite Pro R50-C - i3-6G I 4GB I 128GB SSD I 15,6" I HDMI I Cam I W10 I Gari!
- Veszünk: PS5 Fat/Slim/Digital/Pro konzolt, játékokat, Portalt stb. Kérj ajánlatot!
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
- BESZÁMÍTÁS! ASUS TUF Z390-PLUS GAMING alaplap garanciával hibátlan működéssel
- AKCIÓ! ASRock Z390 i7 8700K 32GB DDR4 500GB SSD RTX 3050 8GB Zalman i3 Edge Seasonic 650W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest