Hirdetés
- Milyen egeret válasszak?
- Azonnali alaplapos kérdések órája
- HiFi műszaki szemmel - sztereó hangrendszerek
- AMD Navi Radeon™ RX 7xxx sorozat
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Nvidia GPU-k jövője - amit tudni vélünk
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- CPU léghűtés kibeszélő
- Dell notebook topic
-
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
-
-
crok
Topikgazda
válasz
FecoGee
#2413
üzenetére
A Syslog network traffic-et nem monitoroz, log-ot gyűjt.
Erre való a Netflow és a Netflow kollektor- és feldolgozó.
Bekonfigolod a router hogy gyűjtsön adatot aztán flow-export.
Vannak nagyon jó (nem ingyenes) megoldások: Isarflow, Netqos, SolarWinds.
Vannak jó és ingyenesek is, mint pl. Cacti (van pluginje).
Cisco.com link.
Ha ez nem hát' nem tom mire gondolsz monitorozás alatt..
SPAN port switchen + Wireshark? Vagy routeren is van lehetőség traffic export-ra..[ Szerkesztve ]
-
crok
Topikgazda
válasz
jerry311
#2405
üzenetére
A virtuális host-on a weboldalak megjelenítése megy?
Mert pl. QEmu-val az ICMP nem megy, maga a működése
akadályozza meg ezt :/ Szóval csak a ping nem megy
vagy semmi se megy? A host ARP táblájában a def.gw.
benne van? A routeren nincs valami ACL ami tiltja a
forgalmat (esetleg IP Inspection, ZBFW)? -
crok
Topikgazda
Attól függ mit használsz, ennél azért bonyolultabb a helyzet.
A VoIP nem egy, hanem 2 session egyszerre. Egy voice signaling
és egy voice. Signaling: H323 (TCP 1720, de kellhet a gateway-ek
komminukációjához a 1718 és 1719 is (RAS)), Cisco Skinny protocol
(TCP/UDP 2000), SIP (TCP 5060 vagy TCP 5061 ha TLS), MGCP
(UDP 2427,2428) Voice: A telefonok megállapodnak, hogy milyen
portokon kommunikálnak, ezt a control protocollon keresztül teszik
meg, ha NAT-olva lenne valahol azt STUN csomagokkal megoldja
(TC/UPD 3478). A voice stream portszámok alakulása 16348-32768
UDP portokon történik (ezt a forgalmat hívják voice bearer data-nak).[Szerk.]
Further reading:
TCP and UDP Ports Used by Cisco CallManager 3.3
PIX/ASA 7.x: Enable VoIP (SIP, MGCP, H323, SCCP) Services Configuration Example
CCIE Voice notes[ Szerkesztve ]
-
crok
Topikgazda
-
crok
Topikgazda
"és a routernél hogy állítom be, hogy a 2 lábán 2-2 vlan legyen?"
Ez egy hülye router-on-a-stick háló.. olyan, amilyennel
talán az életben sose fogsz találkozni
Csinálsz subinterface-eket a router egyes lefelé menő interface-ein,
encap dot1q <megfelelő vlan>, adsz neki IP-t a megfelelő subnetből.. -
-
crok
Topikgazda
A "jobb oldali" részre:
interface FastEthernet x/y
switchport access vlan 4
switchport mode access
switchport port-security
switchport port-security maximum 2
switchport port-security mac-address stickyTovábbiakban a trönk okozhat talán gondot, talán erre gondolsz:
Switch0 és Switch1 közti interface-ekre:
interface FastEthernet x/y
switchport trunk allowed vlan 2-3
switchport mode trunkSwitch2 és Switch3 közti interface-ekre:
interface FastEthernet x/y
switchport trunk allowed vlan 1-4
switchport mode trunkSwitch0 és Switch2 közti interface-ekre valamint a Switch1 és
Switch3 közti interface-ekre nincs megszorítás írva (plusz a
redundancia miatt okosabb is mind a 4 vagy az összes VLAN-t
engedni). Erre gondoltál? -
crok
Topikgazda
válasz
zsolti.22
#2326
üzenetére
Egyik phy interface-en sincs no shut a konfig szerint
Az alapvető probléma az, hogy nincs visszaút..
EDGE-ROUTER
router eigrp 65001
no autosum
router bgp 65001
! Ez mindenképp hiányzik
red eig 65001ENTERPRISE_FOS
router eigrp 65001
no autosumValamint ami felesleges: pl az összes static route a Null0-ra,
egyáltalán nem értem mi volt a céljuk. -
crok
Topikgazda
válasz
zsolti.22
#2323
üzenetére
Először is: mi az észlelt hiba?
Nem nézném át/raknám össze ha nem muszáj.. De első blikkre: R1 nem tanulja meg R3 prefix-eit és RIB failure van a BGP táblában? eBGP-t csak akkor futtatunk loopback-ek közt ha extra szükséges design kérés, egyéb esetben mindig direct IP-k közt van eBGP peering. Meg pl. R3-on vannak loopback-ek meg static utak a Null-ra. Miért? A network parancsok mellett nincs subnet.[ Szerkesztve ]
-
crok
Topikgazda
Több ponton is zavaros, hogy mit is akarsz pontosan :/
interface Tunnel10
ip address 20.0.0.1 255.255.255.252
tunnel source FastEthernet0/0
tunnel destination 40.0.0.2Ez alapján GRE tunnel a 30.0.0.2 és a 40.0.0.2 közt lenne.
Ez a Wireshark alapján látszik is.
Ha az ISAKMP konfig mind a két oldalon jó valamint az
IPSec transformset is szimmetrikus akkor az IPSecnek
nincs akadája, hogy kiépüljön. sh crypto isa sa.. DE!
access-list 100 permit ip 192.168.0.0 0.0.1.255 172.16.0.0 0.0.1.255
E szerint csak az lesz crypt-elve, ami ebbe beleesik, ebbe
meg csak loopback címek esnek bele. Permit gre any any -vel
meg azért mehet, mert akkor EIGRP neighborship az kiépül
és lesz routing a tunnelen keresztül.Na. Pontosan mit szeretnél elérni? Mi a hálózat, amin
ezt kivitelezni szeretnéd? Pingelnél A-ból B-be? Honnan
hová, milyen source-destination kellene, hogy menjen?
EIGRP kell, hogy menjen? Nem derül ki, hogy pontosan
mit akarsz crypt-elni: azt, ami a tunnelben megy, vagy
csak megadsz valamit a map-ben, amit szeretnél crypt-
elve áttolni? Mert mind a kettő dolognak megvan a fele.Van lehetőség tunnel nélkül is crypt-elni, ez a legegyszerűbb:
Az ilyeneket pedig nem szabad ám csinálni, kivéve, ha
arra valami jó okod van:
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
Ilyenkor ki lesz a next hop? Ilyenkor a route ugyan static
de a láttad, mi az admin distance egy ilyen route-nál?
Nincs next-hop -> innentől ha nem egy hálózatba esik egy
packet destination-je meg a kimenő interface, akkor hova
megy a csomag? ARP biztos nem lesz.. ez nem jó. -
crok
Topikgazda
IMHO pont annyira 10..15 év kell ehhez mint egy jobb HDD-nek
Ez nekem nem számít.Aki emiatt nem vált SSD-re az nem használt még SSD-t. Ha
adattárolásra akarnám használni, akkor drága.. nem vagyok
Apple fan, de nem hülyék, hidd el. Ha azt akarom, hogy valami
meglegyen vagy kiírom (ami szintén megadhatja magát, mint az
SSD..) vagy egy másik HDD-n tartom, mondjuk USB tokban..
ahogy teszem is! És egyszerre egy helyen tárolt adat nem adat
-> ha valamit tényleg nagyon meg akarok tartani -> kombinálom
még ezeket cloud tárolással -- moundjuk Ubuntu One, ahogy
csinálom is
Az SSD-k rééégen nem azok a megbízhatatlan
vackok, mint mikor indultak mondjuk az első netbookokban..
Szóval ez nálam nem érv! Nekem többet ér az, ha a gépem
20 sec alatt boot-ol és dolgozhatom is. Minden hónapban van
legalább egy Clonezilla mentés is (vagy ha valami nagyobb
változtatás/update van) így nem aggódom egy reinstalltól HW
hiba miatt. Én így csinálom[ Szerkesztve ]
-
-
crok
Topikgazda
válasz
FecoGee
#2237
üzenetére
Legegyszerűbben így mondanám el:
Alaphelyzet: R1 Fa0/0<=>Fa0/0 R2
R1(config)#do sh run | s router|prefix|^int.*Fa.*0/0
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
R2(config)#do sh run | s router|prefix|^int.*Fa.*0/0
interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
duplex auto
speed auto
router ospf 1
network 10.0.0.0 0.0.0.255 area 0Ekkor ezt teszed:
R2
router ospf 1
redistribute static subnets
ip route 0.0.0.0 0.0.0.0 10.0.0.1..akkor R1 megkapja a default route LSA-t, de nincs routing bit:
R1#sh ip ospf data external 0.0.0.0
OSPF Router with ID (10.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 8
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 10.0.0.2
LS Seq Number: 80000005
Checksum: 0xA3EA
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 10
Forward Address: 10.0.0.1
External Route Tag: 1Azért nincs, mert az LSA-ban levő route nem tehető be a routing
táblába (saját maga lenne a next hop..).Ám ha ezt teszem:
R2
router ospf 1
redistribute static subnets
no ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route 0.0.0.0 0.0.0.0 10.0.0.3Akkor R1 megkapja az LSA-t és boldogan teszi be a routing bitet:
a route betehető a routing táblába (a next hop connected hálóban van).
R1#sh ip ospf data external 0.0.0.0
OSPF Router with ID (10.0.0.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 3
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 10.0.0.2
LS Seq Number: 80000001
Checksum: 0xC7C8
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 10
Forward Address: 10.0.0.3
External Route Tag: 1Egyszóval: ha az OSFP processz szerint a route bekerülhetne a routing
táblába mert szabály szerint bekerülhet ("sanity check") akkor megérdemli
a routing bit-et, így ezzel az LSA-val számol az SPF algoritmus. Ebbe a
szabályban még nincs benne az, hogy valamilyen eszközzel manupuláljuk
az LSA-kból a route-ok bekerülését a routing táblába (pl distribute-list), csak
a nyilvánvalóan OSPF-ben részt nem vehető LSA-kat szűrjük (mint a példa:
olyan LSA, amiben saját magunk vagyunk a next hop egy hálózathoz (ami
még csak nem is connected, teljesen ismeretlen számunkra..) ).FIXME de én így tudom.
-
crok
Topikgazda
válasz
Funthomi
#2221
üzenetére
OSPF-nél a sync kötelező -> LSA-t tiltani nem lehet.
Azt viszont meg lehet akadályozni, hogy a tanult út bekerülhessen a routing táblába:R2 Fa0/0<=>Fa0/0 R3
R2(config)#do sh run | s router|prefix|^int.*Fa.*0/0
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
distribute-list prefix deny_default_route in
ip prefix-list deny_default_route seq 5 deny 0.0.0.0/32
R3(config)#do sh run | s router|prefix|^int.*Fa.*0/0
interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
duplex auto
speed auto
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
default-information originate always
OSPF database-ben benne van:
R2(config)#do sh ip ospf data
OSPF Router with ID (10.0.0.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 156 0x80000002 0x007685 1
10.0.0.2 10.0.0.2 136 0x80000003 0x00787D 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.0.2 10.0.0.2 157 0x80000001 0x007991
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.0.0.2 136 0x80000001 0x00D4D1 1
A routing táblába nem kerül be:
R2(config)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0[ Szerkesztve ]
-
crok
Topikgazda
Újabb IOS van a routereden, mint amire a könyvet írták, a CCNA is 12.3
és ez előtti IOS-ekre van megírva (nem vicc..).IP SLA - itt is írja, hogy az IP SLA szintaxis változott (és változik) az idők
folyamán. Sokszor megszívtam már routercserekor, hogy a kedves supplier
nem azt az IOS-t vitte ki amit kértem és az IP SLA nem ment fel.. persze hogy
nem mentek a hozzá kapcsolódó dolgok :/ Nézni kell a Feature Navigator-t. -
crok
Topikgazda
válasz
jerry311
#2179
üzenetére
Az MLS QoS pl. teljesen hasznavehetetlenül leírt és nagyon rosszul
dokumentált a könyvek alapján, ezt bizton állíthatom..
A switch CoS/QoS eléggé elnagyolt, de az MQC konfigurálása elég
jól le van írva (mellesleg a byte-to-byte működésére 2 hetet kellett
szánnom, hogy az egyes classok kihasználtsága egymáshoz képest
hogy alakul, főleg ha van queue limit is), bár régi-régi IOS bugok meg
sincsenek említve a könyvben
Pl. hogyha több serial interface MFR-
be rendezve van és ha service-policy-ben olyan beállítást kap, hogy
nem %-ban hanem konkrét értékekben vannak megadva a class-ok
sávszélértékei és a bundle-ből ha csak egy is kiesik - akkor bizony
az MFR "ledobja" magáról a service-policy-t egy log bejegyzéssel,
miszerint nincs elég sávszélesség.. és ha valaki nem veszi észre,
és mondjuk csinál a rotueren valamit és ráment a konfigra már el is
mentette az interface konfigot service-policy nélkül :/ Szívás.. de van
workaround: használj ilyen esetben %-os értékeket.. by Cisco..[ Szerkesztve ]
-
crok
Topikgazda
Port lement IOS frissítéskor (restart), STP frissített, aztán mikor a switch vissza-
tért, akkor az is küldött BPDU-t, hiszen akkor még saját magát tekinthette root-
nak, namost ezzel azt hiszem meg is sértettük a portfast-ot. Bár egy kis diagram
sokat segítene, hogy melyik switchen mi meg hogy történt[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#2086
üzenetére
Nem voltam elég pontos, elnézést
R7 LSDB-ben benne kell lennie, ha van egyáltalán olyan út, ami LSA7,
de ahhoz R7-nek lennie kell külső útjának (static vagy connected redist.).
Szóval ne az EIGRP utat keresd az R7-en, mert az area 2 az stub, az a
külső EIGRP út meg LSA5, amit stub nem kaphat meg.LSA7 csak az NSSA-ban van. R3 ezt majd LSA5-re alakítja.
Azt hiszem az LSA-k mozgásának iránya az, ami megkavart.[ Szerkesztve ]
-
crok
Topikgazda
válasz
zsolti.22
#2084
üzenetére
Na várjál.. Azt hiszem megvan. LSA7 az az út lenne az R3-on R7-től az
R4 felé, amit R7 hirdet, mint külső utat az R3 felé (mondjuk egy loopback
hirdetve a redistribute connected-el). Nem R7-en lesznek LSA7 utak./--! Jobb oldalt van NSSA és az LSA7 hogy honnan hová hogyan halad.
[ Szerkesztve ]
-
#2056
crok
Topikgazda
sunyijanika
#2055
crok
Topikgazda
-
crok
Topikgazda
válasz
robesz87
#2052
üzenetére
A megoldás az IP Inspection vagy esetleg ACL established opcióval.
Ezekkel tudsz olyat csinálni, amit el akarsz érni: egyik hálóból menjenek
csomagok a másikba és legyen válasz is, de a másik háló ne tudjon
kezdeményezni kapcsolatot visszafelé (megintcsak: SOHO routerek
Internetmegosztása és SPI tűzfal: bentről ki és vissza mindent, kintről
befelé semmit a világon nem engedünk ). -
crok
Topikgazda
válasz
robesz87
#2032
üzenetére
Ez nem egészen van így.. szóval olyat lehet csinálni, hogy kívülről elérni
egy belső gép pontos portját - hiszen így tudsz NAT router mögött "aktív"
módon torrentezni.. jól néznénk ki ha a SOHO routerek tudnák a Cisco-k
meg nem Szóval a lényeg csak annyi, hogy a NAT táblában legyen már
a kommunikációkor bejegyzés. Ha a kommunikációt a NAT inside-ról a
host kezdeményezte kifelé (és dinamikus a NAT) akkor az első kimenő
csomag már kreál NAT bejegyzést a kapcsolatkoz. Kívülről befelé ilyen
nem lesz.. hacsak kézzel meg nem adod Pont mint a SOHO routereknél.
Ez a "static port forwarding". -
crok
Topikgazda
válasz
robesz87
#2027
üzenetére
Ha a NAT-ot jól csinálod, akkor igen
Egyébként egy jó kis megoldás: adott xy site, el kell majdegymást érniük,
de nem akarsz sok melót a konfigokkal. Mindenhol Cisco routert szeretnél
használni (mondjuk DMVPN vagy csak VPN koncentrálással..). Megoldás:
csinálsz egy standard konfigot és nyugodt szívvel osztasz minden LAN-
nak egységes IP címeket ám mindenhol NAT-olsz egy site-specifik loop-
back IP-re! Így a konfigokon nem kell sokat változtatni, csak annyi, hogy
minden site-ra kiküldött routeren a loopback cím lesz más, meg mondjuk
az Internet/szolgáltató elérésének konfigja. Persze jól kell megtervezni. -
crok
Topikgazda
válasz
zsolti.22
#1999
üzenetére
Tévedtem, benne van, 3.132 - 2 cég Area 0-áját teszi összefüggővé, de alapból
írja, hogy ne használd design szerint, mert temp megoldásként még elviselhető.Host-nak én 1700-as routereket teszek be általában (a kép lesz csak host) vagy
linux boxokat (tinycore vagy hasonló kis disztribúciókat).Melyiket nem olvastad amit írtam?
-
crok
Topikgazda
válasz
zsolti.22
#1993
üzenetére
Nos első körben ez egy discontinous net.. a loopback címek egy alhálóban
vannak. :/ Másik: OSPF alap design, hogy az area 0 contiguous. Itt az area
0-kat virtual-linkeled össze? Az nem okos.. A virtual link az arra jó, hogy egy
area-n keresztül csatlakozz az area 0-hoz.. tehát pl 2-1-0 , virtual link 1-en át.
[Szerk.]Vagy én látok valamit rosszul?[ Szerkesztve ]
-
crok
Topikgazda
válasz
jerry311
#1982
üzenetére
Értelmes load-balance sehogy.. egyes gépek a kiosztott def.gw. alapján más-
más linken mennek ki a saját hálójukból.. ha az egyik link elmegy (ami itt
nincs semmilyen módon triggerelve, pedig az életben való jó működéshez kell,
valamint én mind a két HSRP groupban mind a két DSW-n preempt-et állítok)
akkor a másik def.gw. átveszi annak a forgalmát is. Ilyen load-balance -ot úgy
szokás csinálni, hogy a LAN IP tartományt 2 felé veszik és az egyik felét az
egyik DSW oszthatja ki DHCP poolból, a másikat a másik. Így nincs keveredés,
de hátrány, hogy nem tudod megmondani, hogy a poolokból mennyien fognak
IP-t kapni, mivel a DHCP kérés broadcast és mind a két DSW megkapja a
kérést és válaszolni is fog.. innen kvázi random, hogy melyik keret ér a hosthoz
vissza hamarabb és melyiket offer-t választja. Az életben gondok adódhatnak
abból is, ha nincs a HSRP triggerelve megfelelően, mert az upstream link lehet
up/up de ha a routing nem működik rajta keresztül (ha kell ezer okot mondok..)
akkor azon host forgalma, ami egy ilyen DSW-n megy keresztül az blackhole-ba
route-olódik, ha a 2 DSW közt nincs megfelelő routing. Ejj, nehéz ezt nem visual
táblával meg sok filctollal mondani.. könnyebb lenne -
crok
Topikgazda
válasz
jerry311
#1970
üzenetére
És még a routeren is ki lehet kódolni:
R1(config)#key chain decrypt_type_7
R1(config-keychain)#key 0
R1(config-keychain-key)#key-string 7 14141B180F0B
R1(config-keychain-key)#do sh key chain
Key-chain decrypt_type_7:
key 0 -- text "cisco"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now] -
crok
Topikgazda
R1(config-if)#ip ospf authentication message-digest
R1(config-if)#ip ospf message-digest-key 1 m 0 cisco <<<Itt még a "0" miatt ez plain-text
interface FastEthernet0/0
ip address 192.168.1.100 255.255.255.0
ip ospf message-digest-key 1 md5 7 14141B180F0B <<<Ez így már Type 7 (Vigenère) cipher. Ilyet akartál? Ha ez nem megy akkor
az a Packet Tracer hibája lesz - az 5.3.2.0027 alatt bizony ez egy hiba. -
-
crok
Topikgazda
A 209-es hibakód az kb. a "történt valami rossz és nem megy" kategória..
Ezer oka lehet, lehet hogy az IOS-t nem tudja betölteni: mert a default
IOS verzió egy nem létező file-ra mutat. Vagy az IOS nem ehhez a
platformhoz való, vagy véletlen NPE-G2 -t tettél a c7200-ba, ami nem
valami jó választás, mert csak spéci IOS-el hajlandó (nagyon bugosan)
működni. Dynamips vagy bármi más opciót átállítottál? Mert még az
is lehet hogy a Dynamips hypervisor nem kap elég memóriát. Esetleg
a JIT van bekapcsolva, de a géped/OS-ed valamiért nem tudja ezt a
Dynamips-nek megoldani. Elsőre ezeket nézd már meg. IOS verziót
jó lenne ha megírnád.. esetleg a beállított hardware konfigot, NPE és
kártyák, memória, ilyesmi. Szoktam néha c7206VXR-t használni, de
egy c3725 is tökéletesen megfelel, vagy egy c2621XM.. c1720 hostnak.
(IOS-ek sorban:
c1720-12.2-40a -- 64M DRAM
c2600-adventerprisek9-mz.124-15.T14.bin -- 128M DRAM
c3725-adventerprisek9-mz.124-15.T14.bin -- 128M DRAM
c7200-adventerprisek9-mz.124-24.T.bin -- 256M DRAM
Javaslom, hogy szépen nevezd át a bin file-okat zip-re és csomagold ki
és azt add hozzá a GNS3-ban az IOS images menüben.)
[Szerk.]
Plusz egy ok: tűzfal(akat) kapcsold ki vagy engedélyezd a hypervisor
portját mindenképpen - ez is lehet ok (7200 és e felett, konzol portokat
szintén nem árt megnézni, sose lehet tudni.. nekem linux alatt sose
volt még hasonló esetem, mint ez.. nem értem hogy jöhet ki egyes
esetekben egyeseknél :/ ).[ Szerkesztve ]
-
-
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. -
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?[ Szerkesztve ]
-
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. -
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?[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
-
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.[ Szerkesztve ]
-
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 -
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. -
crok
Topikgazda
Max. tapasztalat meg józan ész.. Az ASA securityre van hegyezve, nem
vicces, ha SYN/SYNACK/ACK csomagokat ugyan ahhoz a session-höz
máshonnan kapsz.. Szóval egy egészen hülye szituációban elképzelhető
lenne, hogy mondjuk egyik tunnnelen jött egy SYN, az ASA mögül a dst
válaszol (és ugyan azon a tunnelen válaszol..) de az utolsó ACK már egy
másik tunnelen jön.. na ez nem valami jó, mert "támadásnak" veheti az ASA
hogy nem ott jött az ACK ahol a SYN.. szóval az ACK-t dobja, a session
maga meg marad half-open.. mert nincs ACK.. és kezdi elölről.. egyszer
talán összejön hogy ott jön-ahol-megy, akkor véletlen összeáll a TCP de
amint megint valami gubanc lesz megint megáll majd.. és nézünk majd,
hogy a ping pedig milyen szépen megy -
crok
Topikgazda
válasz
lacika2s
#1793
üzenetére
Site-to-Site VPN tunnellel vagy "csak" crypto map a kimenő interface-eken?
3 tunnellel egy EIGRP (vagy betegebb esetben BGP, de nem tartom kicsit se
szükségesnek) load-balancing.. de vigyázz, ne állíts be packet-based load-
share-t, mindig session-based. Különösen ASA esetében nem nagyon jó,
ha egy-egy session csomagjai más-más interface-en érkeznek.. Csak a
session-based megoldásnak ugye hátulütője, hogy egy-egy session egy
hash által meghatározott úton fog haladni, tehát egy session-el nem tudod
mind a 3 linkedet terhelni (de ez design kérdés, több adatot még nem adtál).
Load Balancing with CEF
ip load-sharing per-packet << a tunnel interface-re, ha per-packet -et akarsz
A default a per-destination load-sharing ha van több út ami bekerülhet a
routing táblába. -
crok
Topikgazda
válasz
FecoGee
#1726
üzenetére
Nincs nekem arra időm és nincs most értelme lekötni a figyelmem egy
gyártóra Annyi technológia, annyi megoldás, annyi gyártó van most
a kezeim közt.. nem látom értelmét most.. nem vagyok cert gyűjtő, nem
érdekel hogy milyen meg merre. Melót szerezni nem plecsnikkel fogok
hanem azzal ahogy és amin dolgozom Hidd el egy papír-CCNP/CCIE
-nél 1000x többet ér az akinek papírja nincs, de nem sz*rja össze magát
ha konzolból kell hardverhibát keresnie. És ezzel a munkáltatók sincsenek
máshogy: azt akarja látni, hogy képben vagy-e, nem azt, hogy le tudsz-e
ülni 2 hétre braindumpot tanulni. Ha kell nekiülök, mint mindenki, de nem
készülök rá, lehet nagyképűen hangzik de van jobb dolgom A CCIE-ben
és egyik ilyen "fokozatban" sincs "hardverközeli élmény", nálunk azért van,
én ezt jobbnak érzem, mint tanulni a certekért. De embere válogatja. Ha
a CCNP-m meg kell hosszabbítani, akkor majd megcsinálok egy Voice
és/vagy egy Security vizsgát, de a CCIE könyv is csak egy nagy össze-
foglaló a CCNP-ből (Route & Switch), nem sok újdonság van benne. A
sok frame-relay kérdés is olyan, hogy azokat a topológiákat ISP-nél nem
használják, általában CE-PE-MPLS_Cloud-PE-CE van mindenhol, nincs
CE-CE-CE mash/partial mash használva, vagy csak elvétve. Nem akarok
feleslegesen belefolyni valamibe, amit nem fogok vagy egyáltalán nem is
használnak. A jövő a metro ethernet, a dark fiber.. a legtöbb helyen a
soros vonalakat megszűntetik már. És mielőtt megköveznek, hogy "de
ha nincs cert akkor nem foglalkoznak velem a HR-en" - nem így van.
A LinkedIn -en nézzetek szét. Regisztráljatok, ha gondoljátok, írjátok meg
a profilotokat jól, adjátok el magatok jól, keresik az embereket, ezt nekem
elhihetitek. Aki kíváncsi, próbálja ki. -
crok
Topikgazda
válasz
f_sanyee
#1684
üzenetére
Szerintem meg R4 kapna EGP-t, R3 már IGP-t, mert R3-nak (ha belépő
szint...) nemigen van EGP kapcsolata, más kérdés hogy R4 az EGP utat
beteszi az IGP-be, így R3 R4-től már IGP-n kap infót az EGP útvonalakról.R4<>ISP -> BGP
R4<>R3 -> OSFPR3 akkor OSPF-ből tanul más AS-ből jövő utakat.
[ Szerkesztve ]
-
crok
Topikgazda
válasz
f_sanyee
#1679
üzenetére
"Mely útvonalak kerülnek automatikusan a szomszédos forgalomirányítók
irányítótábláiba, ha az irányító protokollal a közvetlenül kapcsolódó
hálózatokról cserélnek információt?"Ha nincsenek feleletek, csak ebből kellene megmondani, akkor mi a válasz?
Szerintem az, hogy ha a közvetlenül kapcsolódókról cserélnek akkor a köz-
vetlenül kapcsolódókról cserélnek információt. A dinamikus az a protokollok
által tanult információ. Ha van RIP és van OSPF is de nincs redistribute sehol
se megadva, akkor mindegy mit tanult dinamikusan az OSPF a RIP-be csak
az fog bekerülni, amit network-el kijelöltél és van beleeső interface up/up -ban.
FIXME. De szerintem nem tudtok meggyőzni másról.Szerk.
(De ez amúgy egy erősen megfogható kérdés.. ki mondta hogy meg van-e
adva bármilyen route-map, prefix-list.. na mindegy, ez az én hülyeségem.
A kérdés számomra nem egyértelmű.. én vizsgán egy ilyenhez írnék egy
csomó megjegyzést)[ Szerkesztve ]
-
crok
Topikgazda
És hogy miért jobb (szerintem) a PPP?
- lehet azonosítást kérni (CHAP/PAP)
- lehet alinterface-eket csinálni (HDLC-n nem lehet)
- az alinterface-eket lehet külön VRF-be tenni
- remekül lehet szabályozni a forgalmat rajta (QoS service-policies)De sose felejtsétek el a HDLC-t, mert a legegyszerűbb BERT tesztet
HDLC-vel lehet megcsinálni: ha egy serial link-re teszel/tetetsz hurkot
és az interface-t átállítod HDLC-re és adsz egy kamu IP címet hozzá
akkor ha a saját IP címedet pingeled és van válasz akkor a link jó,
megspékelhetitek egy kis ping x.y.z.w data FFFF size 1500 va re 1000
paranccsal és ez csinál 1500 byte-os pinget, amiben minden adat bit
1-es (ez fontos egy soros volnal esetén, mert ellenőrizhető, hogy a
vonalon minden multiplexer és repeater jól forgatja-e a biteket, esetleg
a scrambling jól működik-e), megvizsgálja hogy a küldött csomag
tartalma megegyezik-e az érkezett tartalmával. Még mielőtt megkérdezi
valaki, hogy dehát ha a saját IP-met pingelem akkor csak magamat
pingelem -> nem, soros vonalon nem tudod magadat pingelni, mivel
a router maga nem ismeri a saját IP-jéhez tartozó L2 címet, így a saját
IP-jére kimenő csomagot is kiküldi azon az interface-en, ami a routing
tábla szerint az IP címhez tartozik. -
crok
Topikgazda
Szerintem ennek a kérdésnek épp csak van köze a hálózatokhoz, ez
csak szövegértelmezés. Ha a közvetlen kapcsolódó utakról cserélnek
információt akkor a szomszédoknak a saját közvetlen kapcsolódó út-
jaidat küldöd el. Alapból ebben benne van a szomszéddal összekötő út,
de ha több utad is van akkor azokat is átküldöd, nem? -
Ú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!
- Politika
- Milyen egeret válasszak?
- World of Tanks - MMO
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- Garmin Fenix 8 AMOLED - a csúcshódítás költséges
- Azonnali játékos kérdések órája
- Elite: Dangerous
- Feltörték a PROHARDVER!-es regisztrációmat! (vagy elvesztettem a belépési emailcímet, 2FA-t)
- DIGI kábel TV
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest