- Apple iPhone 15 Pro Max - Attack on Titan
- Yettel topik
- Google Pixel 6/7/8 topik
- Android alkalmazások - szoftver kibeszélő topik
- Újabb Samsungok telepíthetik a Galaxy AI-t
- Samsung Galaxy Note20 Ultra - a tollnak nincs ellenfele
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- Samsung Galaxy S24 - nos, Exynos
- Vodafone-ra áttért Digi Mobilosok
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Hirdetés
-
Free Play Days 2024 - 18. hét: Headbangers: Rythm Royale
gp Extraként a Star Wars Jedi: Survort is kipróbálhatjuk 5 óra erejéig.
-
Mindent megtudtunk az új Nokia 3210-ről
ma Részletes képek, specifikációk és euróban megadott ár is van a legendás modell újraélesztett verziójához.
-
Megbírságolták a Razert a Zephyr maszkok miatt
ph A cég elég olcsón megússza az ügyfelei félrevezetését, de az üdvözlendő, hogy az Egyesült Államok hatóságai nem siklottak el az ügy felett.
-
Mobilarena
--- 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
-
zsolti.22
senior tag
tusi_: megvan a CCIE? Na grat
Mi is elvagyunk egy TAC-essel, de baszki, tetűlassú. Lassan 4 hete nem tudnak keríteni egy ki#@#&@tt 892-est meg egy legalább 100-as internetet, amit nyilván modemről kellene produkálni (mert manapság még így adja a szolgáltató a netet, modemről ), nem pedig úgy, hogy modem helyett PC-t teszünk rá, ami 100 megás, mert nagyon nem mindegy és nem nagyon kapkodnak. Folyton a hülye webexet emlegeti, hogy webexezzünk. Pedig kapott a nyomorult specifikációt is, hogy miket hogyan teszteltünk és mintha valami óvódással beszélne az ember. Ez a webex is nagyon marketing szagú...inkább oldaná meg a problémát...
Én hamarabb összeraknám a konfigot, mint félig magyar-német-angolosan elmagyaráznám egy mexikói-angol csókának, hogy mi is a problémó.
[ Szerkesztve ]
-
tusi_
addikt
-
zsolti.22
senior tag
Pici ISR és switchportok vannak rajta, kivétel a FA4.
Átraktam az SVI-kre és jó már, csak a sip-pel kellene valamit kezdeni. Kifelé tudok hívni, de befelé nem jön hívás, fel se regisztrál a teló és ilyeneket dobál a konzol:*Mar 2 06:57:13.346: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Forbidden header field found) - dropping udp session a.b.c.d:5060 e.f.g.h:5060 on zone-pair OUTSIDE-to-INSIDE class FORGALOM_CM
*Mar 2 06:55:22.345: %AIC-4-SIP_PROTOCOL_VIOLATION: SIP protocol violation (Invalid Dialog) - dropping udp session a.b.c.d:5060 e.f.g.h:5060 on zone-pair OUTSIDE-to-INSIDE class FORGALOM_CM
Erre még az EMD se mond semmit...
-
zsolti.22
senior tag
Az, hogy megy, az túlzás, lelkes amatőr vagyok max.
Na most megváltoztattam a konfigot, most szépen megy minden.
Kettő dologra lettem figyelmes:
- hiába rotaryztam az ssh portot 22-esen kívül másra, mégis válaszol a nyomorult a 22-es porton is (pedig szerintem nem kéne; nem több SSH portot akarok, hanem egyet, de nem 22-esen )
- a line vty ACL előbb kerül vizsgálatra, mint a ZBF service-policyVégül ez lett a konfigom, hátha valakinek később még jó lesz:
Még valami: hogy tudnám ellenőrizni a show policy-firewall session-ön kívül, hogy valóban működik a tűzfal és dobálja elfelé a bejövő service-policy miatt eldobandó csomagokat (bónuszként konkrétan milyen csomagokat (SRC-DST IPORT akár)?
[ Szerkesztve ]
-
crok
Topikgazda
[Nem fért be az előző szerkesztésbe.]
A class clasd-default-ban a drop helyett írj drop log-ot, akkor van syslog (SRC+DST IP, port).Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
zsolti.22
senior tag
Nagyon úgy néz ki ez a Prime a leírásod alapján, hogy beígértek valamit a nagyközönségnek X időre, aztán közben kezdett fogyni az idő, majd jött a határidő, bár nem voltak teljesen kész vele, de már majdnem elkezdték és kiadták a fél/negyed-kész progit, amit nem is teszteltek le...
Majd ezt is felokosítják, mint az ISE 1.2 (vagy 2.1 vagy hány-pont-hány?); valami rémlik, hogy nem tudta kezelni az alap csomag a TACACS+, csak ha megvetted a legdrágább csomagot, vagy ilyesmi...
[ Szerkesztve ]
-
tusi_
addikt
Talaltam egy BUG-ot, ami hasonlit ehhez.
CSCue76243
Az ugyfelnek volt olyan problemaja, hogy szorvanyosan nem lehetett elerni a switcheket, ping,shh, telnet.... (Ezt a ket switchet csak)Ujra lett inditva, de most meg az NTP nem megy. Az IOS benne van az erintett releasekben
Kulonbseg annyi, hogy a F1 port nincs hasznalva. Shutdown nics, de down, down.....
eat, sleep, play, replay
-
zsolti.22
senior tag
Látszik
Úgy ollóztam ki a konfigom részleteit, van olyan policy-mapom, amit hiányolsz, csak az lemaradt.
Jaja, az ikev2 az egyirányú, a javasolt megoldásod megmagyarázza, hogy miért nem encryptál a routerem csomagokat... Na majd holnap megint megpróbálom!nincs https redirect amúgy
[ Szerkesztve ]
-
A_ScHuLcZ
addikt
Gesztiboy, crok: Egyelőre 7940-el próbálkozom, de lesz itt még 7962, 7906 és 7911 is.
Picivel tovább jutottam, mert találtam egy elírást a konfigban, (kötőjel helyett alulvonal), utána leszedte a firmwaret, de elakadt Phone Unprovisioned hibaüzenettel. Abban gugli segített, hogy ez konfigurációs hibára utal, csak az nem egyértelmű, hogy a routerben az ephone részt, vagy a SIPxxxxxxxxxxxx.cnf fájlt kell-e piszkálnom, és mi hiányozhat. A cnf fájl üres volt, az imént beletettem ezeket a sorokat (google), de nem segített:
image_version: P0S3-07-1-00
line1_name: 100
line1_authname: 100
line1_password: 1234
messages_uri: 999IOS: Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2)
Fájlok:
Directory of flash:/phone/7940-7960/21 -rw- 740 Jun 23 2015 15:32:14 +00:00 XMLDefault.cnf.xml
23 -rw- 15 Jun 23 2015 15:02:14 +00:00 OS79XX.TXT
24 -rw- 302 Jun 23 2015 15:02:08 +00:00 SIP0022905a9bbc.cnf
25 -rw- 27 Jun 23 2015 15:02:08 +00:00 SIPDefault.cnf
26 -rw- 585938 Jun 23 2015 15:02:10 +00:00 P0S3-07-1-00.sb2
27 -rw- 459 Jun 23 2015 15:02:12 +00:00 P0S3-07-1-00.loads
28 -rw- 124552 Jun 23 2015 15:02:12 +00:00 P003-07-1-00.bin
29 -rw- 124956 Jun 23 2015 15:02:12 +00:00 P003-07-1-00.sbn2012348416 bytes total (1918009344 bytes free)
Konfig:
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname CME_teszt
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
no aaa new-model
!
dot11 syslog
ip source-route
ip dhcp excluded-address 192.168.128.1
!
ip dhcp pool voip
network 192.168.128.0 255.255.255.0
option 150 ip 192.168.128.1
lease 7
!
ip cef
!
no ipv6 cef
!
multilink bundle-name authenticated
!
voice-card 0
!
archive
log config
hidekeys
!
interface GigabitEthernet0/0
ip address 192.168.130.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/0.2
description voip vlan
encapsulation dot1Q 701
ip address 192.168.128.1 255.255.255.0
!
interface GigabitEthernet0/1
no ip address
shutdown
duplex auto
speed auto
media-type rj45
!
interface Serial0/1/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/1/1
no ip address
shutdown
clock rate 2000000
!
ip forward-protocol nd
ip http server
no ip http secure-server
ip http path flash:gui
!
tftp-server flash:/phone/7940-7960/P003-07-1-00.bin alias P003-07-1-00.bin
tftp-server flash:/phone/7940-7960/P0S3-07-1-00.loads alias P0S3-07-1-00.loads
tftp-server flash:/phone/7940-7960/P0S3-07-1-00.sb2 alias P0S3-07-1-00.sb2
tftp-server flash:/phone/7940-7960/P003-07-1-00.sbn alias P003-07-1-00.sbn
!
control-plane
!
telephony-service
max-ephones 15
max-dn 20
system message Teszt uzenet
load 7960-7940 P0S3-07-1-00.loads
time-format 24
max-conferences 12 gain -6
web admin system name admin secret 5 $1$vPt2$REEai/o5nwcwFUmOxuuP5.
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
!
ephone-dn 1
number 88
label Teszt1
name Teszt1
!
!
ephone-dn 2
number 55
label Teszt2
name Teszt2
!
!
ephone 1
device-security-mode none
description Teszt telefon
mac-address 0022.905A.9BBC
type 7940
button 1:1 2:2
!
line con 0
line aux 0
line vty 0 4
login
!
scheduler allocate 20000 1000
endui:
debug alapján a vnf fájl lesz a ludas, itt akad el:
*Jun 25 10:02:45.231: TFTP: Looking for CTLSEP0022905A9BBC.tlv
*Jun 25 10:02:45.251: TFTP: Looking for SEP0022905A9BBC.cnf.xml
*Jun 25 10:02:45.251: TFTP: Opened system:/its/vrf1/XMLDefault7940.cnf.xml, fd 9, size 1057 for process 186
*Jun 25 10:02:45.255: TFTP: Finished system:/its/vrf1/XMLDefault7940.cnf.xml, time 00:00:00 for process 186
*Jun 25 10:02:45.291: TFTP: Looking for P0S3-07-1-00.loads
*Jun 25 10:02:45.295: TFTP: Opened flash:/phone/7940-7960/P0S3-07-1-00.loads, fd 9, size 459 for process 186
*Jun 25 10:02:45.295: TFTP: Finished flash:/phone/7940-7960/P0S3-07-1-00.loads, time 00:00:00 for process 186
*Jun 25 10:03:01.947: TFTP: Looking for SIPDefault.cnf
*Jun 25 10:03:01.967: TFTP: Looking for SIP0022905A9BBC.cnf[ Szerkesztve ]
"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
zsolti.22
senior tag
Na sorban akkor reagálok:
Nos, ha TCP 80-on szeretnéd elérni a 192.168.20.2-t 192.168.50.2-ről akkor félig-meddig jó, nem tom' nem-e redirect-el HTTPS-re. Plusz ez csak az egyik oldal, így VPN-t troubleshootolni meglehetősen nehéz.
Nincs HTTPS redirect.
De pl. ehhez nem látok policy-map-et:
zone-pair security VOIP-to-OUTSIDE source VOIP destination OUTSIDE
service-policy type inspect VOIP_TO_OUTSIDE << ilyen policy-map-et nem látokVan a routerben, csak lemaradt
A jövőbeni bővíthetőségre való tekintettel én nem használnék "class-map type inspect match-all"-t hanem match-any-t, hogy utánna hozzáadni egyszerűbb legyen.
Igen, jogos, bele is buktam Viszont mivel ACL-re matcheltetek vele és ez az egy ACL is bőven elég, mert csak azt az egyet kell szerkesztenem, ha valamire szükségem van, így végülis ez is megteszi egyelőre. De igen, a match-any sokkal rugalmasabb...
Ezek itt lent önmagukban még jók lennének, de vissza nem engedi a forgalmat a ZBF, nem elég a pass mert UDP és "titkos" az IPSec
Bezony, igaz, szerintem emiatt sem működött. Este majd újra megpróbálom, ahogy írtam korábban.
Drop log van a végén - szóval nézz logot, hogy mit dob ha dob egyáltalán (állíts buffert rendesen) de szerintem kéne egy SELF_TO_OUTSIDE amiben engeded az IPSec UDP-t, ESP-t visszafelé.
Igen, az volt a log célja, hogy lássam, mi dob és mit, az alapján alakítottam át úgy a konfigot, hogy a tunnel már kiépül, de itt az lesz a hiba, ahogy írtad is fent, hogy nincs SELF-TO-OUTSIDE zóna-párom.
Aztán ha minden kötél szakad akkor az IOS Order-of-operation miatt én feltennék egy ACL-t az OUTSIDE interface-re amiben a forgalmadat (TCP 80 src 192.168.50.2 dst 192.168.20.2) direktben engedném hogy lássam hogy a VPN vagy a ZBF a hiba.
Teljesen kizárnám a VPN hibáját a fentiek miatt, ez ZBF misconfig error lesz.
Kösz a gyors analizálást!
[ Szerkesztve ]
-
zsolti.22
senior tag
Szia!
Sikerült megoldanom, de már ki is ment a fejemből, hogy mi volt a konkrét megoldás. Jó sok ACL-em volt, amit nem is használt végül a router. Onnan jöttem rá, mi a gond, hogy a show crypto engine connections active mutatta, hogy decryptálni tudta a csomagot, de encryptálni már nem akart. Ekkor nézegettem az ACL-eket és azokból az látszott, hogy a NAT-os deny-os ACL sorra is van találat, a crypto ACL-re visszafelé szintén, ennek ellenére mégsem történt meg a csomagok titkosítása. Aztán nézegettem a class-mapokat és ott egy inspectet átírtam pass-ra és egyből ment az egész. Nem is hittem volna, hogy nem lesz lassú a kapcsolat és a router se fog pörögni tőle, így pozitívat csalódtam.
Aztért lehetett ennyire kusza megtalálni a megoldást, mert szerintem nem jól értettem meg a ZBF alapjait és emiatt fölösleges zóna-párjaim lehetnek, amik csak bezavarnak.
Itt ragadnám meg az alkalmat és fejtágítást szeretnék kérni a ZBF-et illetően és nézzük is a konkrét, használatban lévő routerem konfigját. Jelenleg a routeremben 3 zóna van: VOIP, INSIDE, OUTSIDE. Szerintem beszédes zónák, nem kell túlmagyarázni.
A VOIP az VLAN700 SVI-re van felkonfigurálva a routeren és csak egyetlen port tagja ennek a VLAN-nak, mert csak egy telefon van. Ő egy /30-as címet kapott (192.168.20.0/30).
Az INSIDE zóna már nehezebb, ide a VLAN600 és VLAN500 tartozik. A VLAN600 a vezetékes belső hálózat, ami 192.168.15.0/29-es tartományban csücsül, a VLAN500 pedig a belső vezeték nélküli hálózat, az ő címtartománya a 192.168.10.0/29 lett.
Olvastam olyanról, hogy ahol lehet, kerülni kell a SELF zóna használatát, mert igencsak meg tudja nehezíteni az ember életét. Lehet, hogy pont te írtad itt valahol.
Amilyen szabályokat én zónákat csináltam, azok a következők:INSIDE-to-OUTSIDE
Egyértelmű, a wifis és belső vezetékes gépek érjék el az internetet
itt ezeket használom a class-mapomban:
match protocol pop3s
match protocol dns
match protocol icmp
match protocol ntp
match protocol tcp
match protocol udpA policy-mapban őket inspektálom, a class class-defaultot droppolom. Szóval elvileg ha bentről szinte bármit csinálok, akkor arra mindig érkezik vissza válasz, ezzel elvileg nem kell foglalkoznom.
INSIDE-to-VOIP
Egyértelmű, a VOIP telefonomnak van webes felülete, azt szeretném elérni néha, ha konfigurálni kell. Itt én most azt látom, hogy van egy ACL-em, ami engedélyezi a belső gépek számára a VOIP telefon IP címét és TCP 80-as port elérését (permit tcp 192.168.10.0 0.0.0.31 host 192.168.20.2 eq www), de nem inspektál a policy-mapom, hanem passol. Na most ahogy gondolkodom közben, ez jó nagy hülyeség: ha inspect lenne, akkor automatikusan beengedné a router a telefontól érkező HTML tartalmat. Olyan eset önmagától, hogy a telefon 80-as porton egyszer csak forgalmat kezdeményezzen a belső hálózat bármely gépére, olyan soha nem lesz, így ez az INSIDE-to-VOIP és VOIP-to-INSIDE policy-map, ami passol, az szerintem felesleges, és inkább INSIDE-to-VOIP inspect kellene helyette.
Ezek voltak az egyértelmű dolgok, most jön a neheze.
VOIP-to-OUTSIDE
Itt ezeket inspektálom:
match protocol ntp
match protocol dns
match protocol tcp
match protocol udp
(SIP-et ha ideveszem, akkor katasztrófa történik, nem működik)A telefon ugye 5060 forrás- és 5060 cél UDP porton kommunikál kettő szolgáltatóval. Ha inspektálom ezt ACL alapján, akkor elvileg a szolgáltatótól visszaérkező választ a router beengedi. Na de amikor engem megpróbálnak elérni telefonon, akkor a szolgáltató kezdeményez 5060-as porton (vagy STUN 3478-es UDP porton), hogy egyeztessen a telóval és elkezdjen kicsörgetni, emiatt szükség van OUTSIDE-to-VOIP zónára is (jól látom, ugye?). A telefon és a teljes belső hálózat NAT-olva van, tehát ELVILEG a SELF zóna eddig nem jön szóba, mert a router amikor NAT-ol, szépen NAT táblában feljegyzi, milyen forrás socketet milyen cél socketre fordított, ennek alapján dönti el, hogy mely zónákat érinti a forgalom, így elgondolásom szerint nincs szükség OUTSIDE-to-SELF és SELF-to-VOIP zónára. A telefon NTP-n keresztül szereti lekérdezni az időt, ez szintén benne van az inspectben, tehát elvileg az időt is leszinkronizálja magának. Kérdés, hogy az OUTSIDE-to-VOIP az ispect legyen, vagy pass és akkor kell visszafelé is pass? Ha inspect, akkor egy esetleges hívásnál mennyire szopatja a routert a sok dynamikus visszaengedés (egy pár másodperces hívás is több száz vagy már 1000 fölötti darabszámú UDP oda-vissza csomag)?
OUTSIDE-to-SELF
Vannak olyan forgalmak, ami egy az egyben csak a routernek szól és nem mögöttes eszköznek, ilyen forgalom: az SSH, router órájának szinkonizációja, DDNS, uplink DHCP egyeztetés, DNS lekérdezés (konfigurációban meglévő domain-név feloldása). Ha jól látom, akkor ezeket a self zóna nélkül nem tudnám implementálni. Ezeket hiába inspektálom, mert azt hiszem, hogy azt nem is lehet és marad a drop és pass, pass esetén akkor nyilván kell a fordítottja is, azaz SELF-to-OUTSIDE irány is. Ha csinálok SELF-ot-OUTSIDE-ot is, akkor a router kezdi minden forgalomról azt hinni, hogy az a SELF zónából származik (NAT-olás miatt a publikus IP lesz minden internet felé szánt forgalom forrás IP-je, de akkor hülyeség, amit erről korábban fenti írtam?) és elkezdi nem kiengedni a dolgokat. Ez szépen látszik ebben az irányban a class class-default drop logjában (NTP-t biztosan eldobta kifelére menet, SIP-et is, mint a huzat).
És akkor a fentiek tudatában szeretne az ember VPN-t konfigurálni: kérdés, hogy mely zónákat érinti ez? OUTSIDE-to-VOIP egyből, hiszen publikus forrás- és cél IP-jű a csomag, amit a router kap, majd miután kihámozza az ESP részt, akkor egyből megy is a VOIP zónába (tehát a router megvárja, míg kiderül, hogy csak neki szól vagy továbbítani kell valahova és annak megfelelően érinti a zónákat)? Vagy OUTSIDE-to-SELF, mert a router publikus IP-je a csomag célja és egyelőre ennyi látszik, míg a titkosítás nincs decryptálva, majd onnan SELF-to-VOIP és visszafelé VOIP-to-SELF és SELF-to-OUTSIDE vagy egyből VOIP-to-OUTSIDE?
Melyik irány és miért az?
Ja igen, a cél itt az, hogy egy másik telephelyen lévő Cisco router mögüli RFC1918-es IP-jű gép böngészőjébe beírva a 192.168.20.2-t, megjelenjen a VOIP telefon webes felülete.
Nah, túl hosszú lett, remélem, hogy valaki azért elolvassa és tésztavizet önt a poharamba[ Szerkesztve ]
-
zsolti.22
senior tag
Az OUTSIDE_TO_SELF-es témánál összekevertem az irányokat, természetesen SELF_TO_OUTSIDE akart volna lenni, amikor óraszinkron, ddns, stb-ről írtam
Na, most másfél óra alatt megálmodtam az új szabálylistákat, és ahogy nézegettem, így egyelőre teljesen egyértelmű és agyban lefuttatva pont működik minden, amit szeretnék, aztán majd holnap rárakom a routerre és lehet, hogy lesz pofára esés. Az új szabályoknál sehol sem használok pass-t, csak inspectet, mert lusta vagyok megírni az oda-vissza szabályokat.
Íme (lehet értékelni):
class-map type inspect match-any INSIDE_TO_OUTSIDE_CLASS_INSPECT
//belső hálózat protokolljai
match protocol bootps
match protocol bootpc
match protocol pop3s
match protocol dns
match protocol icmp
match protocol ntp
match protocol tcp
match protocol udpclass-map type inspect match-any INSIDE_TO_VOIP_CLASS_INSPECT
//itt a belső hálóról a telefont csak HTTP-n akarom elérni, máshogy nem
match protocol httpclass-map type inspect match-any VOIP_TO_OUTSIDE_CLASS_INSPECT
//a voipnak ezekre a protokollokra van szüksége
match protocol ntp
match protocol dns
//ebben az ACL-ben a SIP, STUN, RTP dolgok vannak definiálva (jó pár perc wireshark csomag-lesegetés után)
match access-group name VOIP_TO_OUTSIDE_INSPECT_ACL
//ez az utóbbi talán nem is kell, hiszen a fentiekkel kb kimerítettem a lehetőségeket, amikre szükség van
match protocol udpclass-map type inspect match-any SELF_TO_OUTSIDE_CLASS_INSPECT
//a router tudjon IP-t kapni, állogassa az órát, kérdezgessen dns-t
match protocol bootps
match protocol bootpc
match protocol ntp
match protocol dns
//frissítse a DDNS-t az ACL alapján
match access-group name SELF_TO_OUTSIDE_DDNS_ACLclass-map type inspect match-any OUTSIDE_TO_SELF_CLASS_INSPECT
//itt vannak az SSH-hoz, bejövő hívás kezdeményezéséhez és a router pingetéséhez szükséges ACE-k
match access-group name OUTSIDE_TO_SELF_INSPECT_ACLpolicy-map type inspect INSIDE_TO_OUTSIDE
class INSIDE_TO_OUTSIDE_CLASS_INSPECT
inspectpolicy-map type inspect INSIDE_TO_VOIP
class INSIDE_TO_VOIP_CLASS_INSPECT
inspectpolicy-map type inspect VOIP_TO_OUTSIDE
class VOIP_TO_OUTSIDE_CLASS_INSPECT
inspectpolicy-map type inspect SELF_TO_OUTSIDE
class SELF_TO_OUTSIDE_CLASS_INSPECT
inspectpolicy-map type inspect OUTSIDE_TO_SELF
class OUTSIDE_TO_SELF_CLASS_INSPECT
inspectHát röviden ennyi, elvileg minden oké lesz. A zónapárok a policy-mapokból látszanak is.
Na és akkor ha most VPN-t akarnék konfigurálni, akkor a fenti zónák elegek, igaz? És ha igen, akkor az OUTSIDE_TO_SELF_INSPECT_ACL-be kellene a két site pub IP-je UDP 500 forrás-céllal, meg ESP-vel, 'oszt jónapot'? Mert szerintem igen![ Szerkesztve ]
-
crok
Topikgazda
Plusz ez a AireOS még olyan friss hogy süt.. egymillió bug lehet még benne.. ha van lehetőséged jelentsd le TAC-re vagy supportforumra írj, hogy nem megy, mert amit eddig írtam mind tipikus hiba - de mennie kellene.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
A_ScHuLcZ
addikt
Végül még péntek délután reseteltem az egészet és kezdtem elölről, de ezúttal már SCCP-vel. Így a telefonok simán beregisztráltak és letöltötték a megfelelő fw-t. A 7940-ek között szépen megy a hívás, viszont a 7911 és 7906-on nem működnek a funkciógombok, nem tudok hívást indítani, sem elfogadni, sem elutasítani, valamint vonal sincs. De ha hívom az azokhoz rendelt melléket, akkor megjelenik a bejövő hívás a kijelzőjükön. Valami hiányozhat?
A konfig érdemleges részei:
ip dhcp pool voice
network 172.22.100.0 255.255.255.0
option 150 ip 172.22.100.1
default-router 172.22.100.1tftp-server flash00307010200.bin
tftp-server flash00307010200.loads
tftp-server flash00307010200.sb2
tftp-server flash00307010200.sbn
tftp-server flash:apps11.9-2-1TH1-13.sbn
tftp-server flash:cnu11.9-2-1TH1-13.sbn
tftp-server flash:cvm11sccp.9-2-1TH1-13.sbn
tftp-server flash:dsp11.9-2-1TH1-13.sbn
tftp-server flash:jar11sccp.9-2-1TH1-13.sbn
tftp-server flash:SCCP11.9-2-1S.loads
tftp-server flash:term06.default.loads
tftp-server flash:term11.default.loadstelephony-service
no auto-reg-ephone
max-ephones 144
max-dn 500
ip source-address 172.22.100.1 port 2000
load 7911 term11.default
load 7960-7940 P00307010200
dialplan-pattern 1 5123781291 extension-length 4
max-conferences 12 gain -6
transfer-system full-consult
secondary-dialtone 9
create cnf-files version-stamp Jan 01 2002 00:00:00ephone-dn 1 dual-line
number 1001
name Teszt1
!
ephone-dn 2 dual-line
number 1002
name Teszt2
!
ephone-dn 3 dual-line
number 1003
name Teszt3
!
ephone-dn 4 dual-line
number 1004
name Teszt4
!
ephone-dn 5 dual-line
number 1005
name Teszt5
!
ephone-dn 6 dual-line
number 1006
name Teszt6
!
ephone-dn 7 dual-line
number 1007
name Teszt7
!
ephone-dn 8 dual-line
number 1008
name Teszt8
!
ephone 1
device-security-mode none
mac-address 0022.905A.9BBC
type 7940
button 1:1
!
ephone 2
device-security-mode none
mac-address 0022.905A.9D9C
type 7940
button 1:2
!
ephone 3
device-security-mode none
mac-address 0022.9003.955C
type 7940
button 1:3
!
ephone 4
device-security-mode none
mac-address 0024.C444.6BD1
type 7962
button 1:4
!
ephone 5
device-security-mode none
mac-address 0021.A084.A71B
type 7911
button 1:5
!
ephone 6
device-security-mode none
mac-address 0021.A02E.5BBB
type 7911
button 1:6
!
ephone 7
device-security-mode none
mac-address E804.62EA.6732
type 7911
button 1:7
!
ephone 8
device-security-mode none
mac-address 0023.5EB8.78B8
type 7906
button 1:8"I'd tell you a joke about UDP, but you probably wouldn't get it."
-
A_ScHuLcZ
addikt
Szerintem pont rossz példányokba futottam bele az első teszteknél, mert az utóbbiak pedig már beregisztrálnak és működnek is. Ugyanazok a típusok és a konfig sem változott.
Elvégre ez a feladat, ki kell szűrni a hibás példányokat, simán előfordulhat, hogy azok rosszak voltak."I'd tell you a joke about UDP, but you probably wouldn't get it."
-
tusi_
addikt
Köszi crok, atnezem
Hedgehanter: Sajnos nem. Legalabbis multkor migralt a kolegam egy ASA-t 7.2-rol 9.1 es eltunt az osszes nat.
Fel kellett vennem az osszeset ujbol. Azt hittem soha nem lesz szuksegem a 8.3 elotti natra. Nesze, elmult egy hetben csak ezekkel szivok.[ Szerkesztve ]
eat, sleep, play, replay
-
quby
őstag
De /24 a másik oldal is és minden más hostnak válaszol a subneten. Csak ennek a routernek nem. Még este le drótcápázom a DHCP-től kezdve. Ott jobban átlátom mint a debugot
(#9060) Cyber_Bird
Igen ESXi. Promicious mode bekapcsolva azon a vswitchen amibe unetlab VM lába és a fizikai háló is lóg.
A legügyesebb állat az ürge, hiszen búzával teli pofazacskóval is képes repülni, miközben egy bagolyt egyensúlyoz a hátán.
-
crok
Topikgazda
Ja igen, meg még ez kellhet:
no errdisable detect cause gbic-invalid[Szerk:] De jó arc ám a Cisco, itt a link, megtaláltam,
"hoztam is ajándékot meg nem is": engedem de nem supportálom:Q. Do the Cisco Catalyst 3750 Series Switches interoperate with SFPs from other vendors?
A. Yes, starting from 12.2(25)SE release, the user has the option via CLI to turn on the support for 3rd party SFPs. However, the Cisco TAC will not support such 3rd party SFPs. In the event of any link error involving such 3rd party SFPs the customer will have to replace 3rd party SFPs with Cisco SFPs before any troubleshooting can be done by TAC.
[ Szerkesztve ]
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
Cyber_Bird
senior tag
Koszi
A
service unsupported-transceiver
no errdisable detect cause gbic-invalidki van adva, a hasznalathoz termeszetesen
Mukodik is egy darabig, aztan random modon megall.Egyebkent most pont ez lett elmondva nekik, mondtak, hogy akkor most vesznek nem ciscobol masik felet es kiprobaljak azzal. Hatjokoszi...
Elmondtuk, hogy erre igy nem tudunk vallalni erdemi supportot, illetve azt is, ahogy irtad, hogy TAC case-re ne is szamitsanak
Egyelore remenykednek, hogy a masik fele nem cisco sfp megoldja a problemajukat.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- 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!
- Robogó, kismotor
- Apple iPhone 15 Pro Max - Attack on Titan
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Yettel topik
- exHWSW - Értünk mindenhez IS
- Villanyszerelés
- Robot fűnyírók
- HiFi műszaki szemmel - sztereó hangrendszerek
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Kerékpárosok, bringások ide!
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen