CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 18 lis 2017, 22:21

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 9 ] 
Autor Wiadomość
Post #1 : 30 gru 2014, 10:50 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2009, 18:36
Posty: 62
Cześć,


Przerabiam część EIGRP z: CCNP v6 ROUTE i na stronie 26 zaczyna się: Chapter 2 Lab 2-2, EIGRP Load Balancing. Taka sama topologia w GNS3, z tym, że połączenia serialowe są:

R1
Serial0/0 connected to R2 on port Serial0/0
Serial2/0 connected to R3 on port Serial2/0
R2
Serial0/0 connected to R1 on port Serial0/0
Serial0/1 connected to R3 on port Serial0/1
R3
Serial0/1 connected to R2 on port Serial0/1
Serial2/0 connected to R1 on port Serial2/0

Podpunkt f. z Step 5 na str. 37 to ćwiczenie, w którym należy pingować 10.1.102.1 z R3, wszystko wykonane zgodnie z instrukcjami, poza tym, że wyłączone jest w obliczaniu metryki K1.
Kod:
R3#show ip route
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/8 is variably subnetted, 12 subnets, 2 masks
C       10.1.3.8/30 is directly connected, Loopback39
D       10.1.2.8/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D       10.1.1.8/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C       10.1.3.0/30 is directly connected, Loopback31
D       10.1.2.0/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D       10.1.1.0/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C       10.1.3.4/30 is directly connected, Loopback35
D       10.1.2.4/30 [90/640000] via 10.1.203.2, 00:14:25, Serial0/1
D       10.1.1.4/30 [90/640000] via 10.1.103.1, 00:14:25, Serial2/0
C       10.1.103.0/29 is directly connected, Serial2/0
D       10.1.102.0/29 [90/1024000] via 10.1.203.2, 00:14:25, Serial0/1
                      [90/1024000] via 10.1.103.1, 00:14:25, Serial2/0
C       10.1.203.0/29 is directly connected, Serial0/1
Kod:
R3#show ip route 10.1.102.1
Routing entry for 10.1.102.0/29
  Known via "eigrp 100", distance 90, metric 1024000, type internal
  Redistributing via eigrp 100
  Last update from 10.1.203.2 on Serial0/1, 00:15:14 ago
  Routing Descriptor Blocks:
    10.1.203.2, from 10.1.203.2, 00:15:14 ago, via Serial0/1
      Route metric is 1024000, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 11/255, Hops 1
  * 10.1.103.1, from 10.1.103.1, 00:15:14 ago, via Serial2/0
      Route metric is 1024000, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
Dodatkowo wyłączony cef, więc ping na 10.1.102.1 leci:
Kod:
*Mar  1 01:38:32.743: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar  1 01:38:32.743: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar  1 01:38:32.747: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar  1 01:38:32.747: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
*Mar  1 01:38:32.787: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar  1 01:38:32.787: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar  1 01:38:32.795: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar  1 01:38:32.799: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
Kontynuując zadanie, robię shut na interfejsie S2/0 na R1 (do R3) i ping mi zrywa na czas hold timera ale jak położę S0/1 na R2 (do R3) to nie ma żadnej przerwy.

Dlaczego tak się dzieje? skoro są 2 trasy do 10.1.102.1 i wyłączony CEF to czy R3 w przypadku padu połączenia z R1 nie powinien od razu pchać całości ruchu przez R2?


Na górę
Post #2 : 30 gru 2014, 11:48 
Offline
CCIE
CCIE

Rejestracja: 17 gru 2010, 15:23
Posty: 788
Lokalizacja: Dublin
Cytuj:
Cześć,


Przerabiam część EIGRP z: CCNP v6 ROUTE i na stronie 26 zaczyna się: Chapter 2 Lab 2-2, EIGRP Load Balancing. Taka sama topologia w GNS3, z tym, że połączenia serialowe są:

R1
Serial0/0 connected to R2 on port Serial0/0
Serial2/0 connected to R3 on port Serial2/0
R2
Serial0/0 connected to R1 on port Serial0/0
Serial0/1 connected to R3 on port Serial0/1
R3
Serial0/1 connected to R2 on port Serial0/1
Serial2/0 connected to R1 on port Serial2/0

Podpunkt f. z Step 5 na str. 37 to ćwiczenie, w którym należy pingować 10.1.102.1 z R3, wszystko wykonane zgodnie z instrukcjami, poza tym, że wyłączone jest w obliczaniu metryki K1.
Kod:
R3#show ip route
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/8 is variably subnetted, 12 subnets, 2 masks
C       10.1.3.8/30 is directly connected, Loopback39
D       10.1.2.8/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D       10.1.1.8/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C       10.1.3.0/30 is directly connected, Loopback31
D       10.1.2.0/30 [90/640000] via 10.1.203.2, 00:14:23, Serial0/1
D       10.1.1.0/30 [90/640000] via 10.1.103.1, 00:14:23, Serial2/0
C       10.1.3.4/30 is directly connected, Loopback35
D       10.1.2.4/30 [90/640000] via 10.1.203.2, 00:14:25, Serial0/1
D       10.1.1.4/30 [90/640000] via 10.1.103.1, 00:14:25, Serial2/0
C       10.1.103.0/29 is directly connected, Serial2/0
D       10.1.102.0/29 [90/1024000] via 10.1.203.2, 00:14:25, Serial0/1
                      [90/1024000] via 10.1.103.1, 00:14:25, Serial2/0
C       10.1.203.0/29 is directly connected, Serial0/1
Kod:
R3#show ip route 10.1.102.1
Routing entry for 10.1.102.0/29
  Known via "eigrp 100", distance 90, metric 1024000, type internal
  Redistributing via eigrp 100
  Last update from 10.1.203.2 on Serial0/1, 00:15:14 ago
  Routing Descriptor Blocks:
    10.1.203.2, from 10.1.203.2, 00:15:14 ago, via Serial0/1
      Route metric is 1024000, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 11/255, Hops 1
  * 10.1.103.1, from 10.1.103.1, 00:15:14 ago, via Serial2/0
      Route metric is 1024000, traffic share count is 1
      Total delay is 40000 microseconds, minimum bandwidth is 64 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
Dodatkowo wyłączony cef, więc ping na 10.1.102.1 leci:
Kod:
*Mar  1 01:38:32.743: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar  1 01:38:32.743: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar  1 01:38:32.747: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar  1 01:38:32.747: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
*Mar  1 01:38:32.787: IP: tableid=0, s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), routed via RIB
*Mar  1 01:38:32.787: IP: s=10.1.203.3 (local), d=10.1.102.1 (Serial0/1), len 100, sending
*Mar  1 01:38:32.795: IP: tableid=0, s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), routed via RIB
*Mar  1 01:38:32.799: IP: s=10.1.103.3 (local), d=10.1.102.1 (Serial2/0), len 100, sending
Kontynuując zadanie, robię shut na interfejsie S2/0 na R1 (do R3) i ping mi zrywa na czas hold timera ale jak położę S0/1 na R2 (do R3) to nie ma żadnej przerwy.

Dlaczego tak się dzieje? skoro są 2 trasy do 10.1.102.1 i wyłączony CEF to czy R3 w przypadku padu połączenia z R1 nie powinien od razu pchać całości ruchu przez R2?
Pingasz fizyczny adress na R1, nie wiem czy GNS wspiera keepalive dla warstwy L1 i jesli polozysz link na R1 to nie wiem czy R3 widzi to i pewnie czeka az hold time minie i dopiero przelaczy trafic na R2.

Pokaz jak wyglada na R3
Kod:
sh ip cef 10.1.102.1 internal

Dodatkowo widze ze ping idzie z adresu 10.1.203.3 zrob ping z Loo na R3 i zobacz czy wtedy zadziala.


[EDIT] pokaz jeszcze
Kod:
sh ip cef exact-route 10.1.203.3 10.1.102.1 
wtedy bedziemy mieli juz jasnosc jakim linkiem leca pakiety.

Pozdro,


Na górę
 Tytuł:
Post #3 : 30 gru 2014, 13:31 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2009, 18:36
Posty: 62
Proszę bardzo:
Kod:
R3#sh ip cef 10.1.102.1 internal
10.1.102.0/29, version 69, epoch 0, per-destination sharing
0 packets, 0 bytes
  via 10.1.203.2, Serial0/1, 0 dependencies
    traffic share 1
    next hop 10.1.203.2, Serial0/1
    valid adjacency
  via 10.1.103.1, Serial2/0, 0 dependencies
    traffic share 1
    next hop 10.1.103.1, Serial2/0
    valid adjacency

  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes
  Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)

  Hash  OK  Interface                 Address         Packets
  1     Y   Serial0/1                 point2point           0
  2     Y   Serial2/0                 point2point           0
  3     Y   Serial0/1                 point2point           0
  4     Y   Serial2/0                 point2point           0
  5     Y   Serial0/1                 point2point           0
  6     Y   Serial2/0                 point2point           0
  7     Y   Serial0/1                 point2point           0
  8     Y   Serial2/0                 point2point           0
  9     Y   Serial0/1                 point2point           0
  10    Y   Serial2/0                 point2point           0
  11    Y   Serial0/1                 point2point           0
  12    Y   Serial2/0                 point2point           0
  13    Y   Serial0/1                 point2point           0
  14    Y   Serial2/0                 point2point           0
  15    Y   Serial0/1                 point2point           0
  16    Y   Serial2/0                 point2point           0
  refcount 13

R3#sh ip cef exact-route 10.1.203.3 10.1.102.1
10.1.203.3      -> 10.1.102.1     : Serial2/0 (next hop 10.1.103.1)
Czyli wygląda, że leci przez R1. Tylko czy tak powinno być? Czy w tej sytuacji nie powinien korzystać z obu tras, bo CEF jest wyłączony - mam no ip cef i no ip route-cache na interfejsach. Może to poprostu 'feature' GNS3 :)


Na górę
 Tytuł:
Post #4 : 30 gru 2014, 15:20 
Offline
CCIE
CCIE

Rejestracja: 17 gru 2010, 15:23
Posty: 788
Lokalizacja: Dublin
Cytuj:
Proszę bardzo:
Kod:
R3#sh ip cef 10.1.102.1 internal
10.1.102.0/29, version 69, epoch 0, per-destination sharing
0 packets, 0 bytes
  via 10.1.203.2, Serial0/1, 0 dependencies
    traffic share 1
    next hop 10.1.203.2, Serial0/1
    valid adjacency
  via 10.1.103.1, Serial2/0, 0 dependencies
    traffic share 1
    next hop 10.1.103.1, Serial2/0
    valid adjacency

  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes
  Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)

  Hash  OK  Interface                 Address         Packets
  1     Y   Serial0/1                 point2point           0
  2     Y   Serial2/0                 point2point           0
  3     Y   Serial0/1                 point2point           0
  4     Y   Serial2/0                 point2point           0
  5     Y   Serial0/1                 point2point           0
  6     Y   Serial2/0                 point2point           0
  7     Y   Serial0/1                 point2point           0
  8     Y   Serial2/0                 point2point           0
  9     Y   Serial0/1                 point2point           0
  10    Y   Serial2/0                 point2point           0
  11    Y   Serial0/1                 point2point           0
  12    Y   Serial2/0                 point2point           0
  13    Y   Serial0/1                 point2point           0
  14    Y   Serial2/0                 point2point           0
  15    Y   Serial0/1                 point2point           0
  16    Y   Serial2/0                 point2point           0
  refcount 13

R3#sh ip cef exact-route 10.1.203.3 10.1.102.1
10.1.203.3      -> 10.1.102.1     : Serial2/0 (next hop 10.1.103.1)
Czyli wygląda, że leci przez R1. Tylko czy tak powinno być? Czy w tej sytuacji nie powinien korzystać z obu tras, bo CEF jest wyłączony - mam no ip cef i no ip route-cache na interfejsach. Może to poprostu 'feature' GNS3 :)


Widze ze dalej masz odpalony per-destination sharing na R3, wiec traffic bedzie szedl jednym tylko linkiem. Jesli wygenerowalbys wiecej IP flow to wtedy traffic bylby balansowany pomiedzy dwa lacza.
Kod:
R3#sh ip cef 10.1.102.1 internal
10.1.102.0/29, version 69, epoch 0, per-destination sharing
Daj na R3 na obu interfejsach
Kod:
ip load-sharing per-packet
nastepnie daj globalnie
Kod:
ip cef accounting load-balance-hash
Zrob ping z R3 do tego adresu i wyswietl sobie staty za pomoca
Kod:
show ip cef  x.x.x.x internal

powinienes wtedy zobaczyc ile pakietow bylo wypchanych i jakim laczem.


Pozdro,


Na górę
 Tytuł:
Post #5 : 05 sty 2015, 13:33 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2009, 18:36
Posty: 62
Przede wszystkim dzięki za pomoc.

@martino76 - jak wspomniałem, CEF miałem wyłączony i debug ip packet pokazywał shareowanie pomiędzy interfejsami :)

Jak się okazało była to wina GNS/softu/Windowsa. Odtworzyłem na Ubuntu na najnowszym GNS3 i soft c3725-adventerprisek9-mz.124-15.T14 i działa jak należy, tzn jest load-sharing (bez CEF) i wypada co drugi pakiet po shut na interfejsach z R1/R2 do R3.


Pzdr.


Na górę
 Tytuł:
Post #6 : 05 sty 2015, 17:41 
Offline
member
member
Awatar użytkownika

Rejestracja: 21 gru 2014, 12:10
Posty: 18
Cytuj:
Przede wszystkim dzięki za pomoc.

@martino76 - jak wspomniałem, CEF miałem wyłączony i debug ip packet pokazywał shareowanie pomiędzy interfejsami :)

Jak się okazało była to wina GNS/softu/Windowsa. Odtworzyłem na Ubuntu na najnowszym GNS3 i soft c3725-adventerprisek9-mz.124-15.T14 i działa jak należy, tzn jest load-sharing (bez CEF) i wypada co drugi pakiet po shut na interfejsach z R1/R2 do R3.


Pzdr.
Tak to niestety z GNSem bywa, ile razy z czymś walczyłem, a był to zwykły bug.
Jeśli masz trochę wolnego RAMu, polecam labowanie na wirtualnych CSR1000v, albo VIRLu.
Dużo bardziej niezawodne.


Na górę
 Tytuł:
Post #7 : 21 sty 2015, 14:33 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2009, 18:36
Posty: 62
Cytuj:
Cytuj:
Przede wszystkim dzięki za pomoc.

@martino76 - jak wspomniałem, CEF miałem wyłączony i debug ip packet pokazywał shareowanie pomiędzy interfejsami :)

Jak się okazało była to wina GNS/softu/Windowsa. Odtworzyłem na Ubuntu na najnowszym GNS3 i soft c3725-adventerprisek9-mz.124-15.T14 i działa jak należy, tzn jest load-sharing (bez CEF) i wypada co drugi pakiet po shut na interfejsach z R1/R2 do R3.


Pzdr.
Tak to niestety z GNSem bywa, ile razy z czymś walczyłem, a był to zwykły bug.
Jeśli masz trochę wolnego RAMu, polecam labowanie na wirtualnych CSR1000v, albo VIRLu.
Dużo bardziej niezawodne.

Tak, tylko, że CSR pożera 3GB ramu, więc przy 8GB słabo to wypada - a chyba swapping nie wchodzi w grę ;)


--------------------------------------------------------------

Nie zakładam nowego tematu, więc zadam pytanie tutaj.

Przerabiając dalej LAB-GUIDA z pierwszego postu, Chapter 6 Lab 6-3 przedstawia toplogię:

R1-eBGP-R2-iBGP-R3-eBGP-R1

Sytuacja jest taka, że dla tras z R1 na R2 ustawiamy LOCAL-PREF na 150 a na R3 na 125. Nie rozumiem, dlaczego po takim zabiegu na R2 widzę tylko trasy z LP 150 a na R3 z 150 i 125.
Kod:
R2#show ip bgp
BGP table version is 6, local router ID is 172.16.64.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i172.16.0.0       172.16.32.1              0    100      0 i
*>                  0.0.0.0                  0         32768 i
*> 192.168.1.0/30   192.168.1.5              0    150      0 200 i
r> 192.168.1.4/30   192.168.1.5              0    150      0 200 i
*> 192.168.100.0    192.168.1.5              0    150      0 200 i

R3#show ip bgp
BGP table version is 25, local router ID is 172.16.32.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i172.16.0.0       172.16.64.1              0    100      0 i
*>                  0.0.0.0                  0         32768 i
r>i192.168.1.0/30   172.16.64.1              0    150      0 200 i
r                   192.168.1.1              0    125      0 200 i
*>i192.168.1.4/30   172.16.64.1              0    150      0 200 i
*                   192.168.1.1              0    125      0 200 i
*>i192.168.100.0    172.16.64.1              0    150      0 200 i
*                   192.168.1.1              0    125      0 200 i
Sprawdzałem na R3 jakie trasy rozgłasza do R2 i rozgłasza tylko tą do Null0. Jednak położenie interfejsu pomiędzy R2 a R1 (preferowanego) routing poprawnie przerzuca się na trasy ze LP 125 - znowu bug? jeśli nie, to dlaczego R3 nie rozgłasza tras do R2 kiedy LP jest inny niż default. Bo kiedy nie zmieniam LP to oba routery widzą po 2 trasy.


Konfiguracje, obcięte tylko do potrzebnych części:

R2:
Kod:
interface Loopback0
 ip address 172.16.64.1 255.255.255.0

interface Serial0/0
 ip address 192.168.1.6 255.255.255.252
 shutdown
 clock rate 2000000

interface Serial0/1
 ip address 172.16.1.1 255.255.255.0
 clock rate 128000

router eigrp 1
 network 172.16.0.0
 no auto-summary

router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 network 172.16.0.0
 neighbor 172.16.32.1 remote-as 64512
 neighbor 172.16.32.1 update-source Loopback0
 neighbor 172.16.32.1 next-hop-self
 neighbor 192.168.1.5 remote-as 200
 neighbor 192.168.1.5 route-map T1_IN in
 no auto-summary
!
ip forward-protocol nd
ip route 172.16.0.0 255.255.0.0 Null0

route-map T1_IN permit 10
 set local-preference 150
R3:
Kod:
interface Loopback0
 ip address 172.16.32.1 255.255.255.0

interface Serial0/0
 ip address 192.168.1.2 255.255.255.252
 clock rate 128000

interface Serial0/1
 ip address 172.16.1.2 255.255.255.0
 clock rate 2000000

router eigrp 1
 network 172.16.0.0
 no auto-summary
!
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 network 172.16.0.0
 neighbor 172.16.64.1 remote-as 64512
 neighbor 172.16.64.1 update-source Loopback0
 neighbor 172.16.64.1 next-hop-self
 neighbor 192.168.1.1 remote-as 200
 neighbor 192.168.1.1 route-map T2_IN in
 no auto-summary
!
ip forward-protocol nd
ip route 172.16.0.0 255.255.0.0 Null0

route-map T2_IN permit 10
 set local-preference 125


Na górę
 Tytuł:
Post #8 : 21 sty 2015, 16:22 
Offline
CCIE
CCIE

Rejestracja: 17 gru 2010, 15:23
Posty: 788
Lokalizacja: Dublin
Witam,

Jest to poprawne zachowanie, gdyz R2 rozglasza prefixy z LP 200 do R3, ktory ustawia je jako best. Wiec nie ma sensu rozglaszac tych samych prefixow do R2, skoro R2 rozglasza je z lepszym atrybutem. Jest to podstawa BGP, gdzie BGP rozglasza tylko best prefix a nie wszystkie.

Jest taka funkcjonalnosc, ktora nazywa sie BGP Best External zerknij na link, ktora pozwala na rozglaszanie obu prefixow w przypadku dual home.

Pozdro,


Na górę
 Tytuł:
Post #9 : 22 sty 2015, 07:57 
Offline
wannabe
wannabe

Rejestracja: 31 lip 2009, 18:36
Posty: 62
makes sense now ;)


Dzięki!


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 9 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl