eigrp equal load balancing

Pytania dt. certyfikacji CCNP, CCDP, CCSP, CCIP oraz CCVP
Wiadomość
Autor
tns
wannabe
wannabe
Posty: 62
Rejestracja: 31 lip 2009, 18:36

eigrp equal load balancing

#1

#1 Post autor: tns »

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: Zaznacz cały

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: Zaznacz cały

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: Zaznacz cały

*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?

martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

Re: eigrp equal load balancing

#2

#2 Post autor: martino76 »

tns pisze: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: Zaznacz cały

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: Zaznacz cały

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: Zaznacz cały

*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: Zaznacz cały

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: Zaznacz cały

sh ip cef exact-route 10.1.203.3 10.1.102.1 
wtedy bedziemy mieli juz jasnosc jakim linkiem leca pakiety.

Pozdro,

tns
wannabe
wannabe
Posty: 62
Rejestracja: 31 lip 2009, 18:36

#3

#3 Post autor: tns »

Proszę bardzo:

Kod: Zaznacz cały

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 :)

martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

#4

#4 Post autor: martino76 »

tns pisze:Proszę bardzo:

Kod: Zaznacz cały

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: Zaznacz cały

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: Zaznacz cały

ip load-sharing per-packet
nastepnie daj globalnie

Kod: Zaznacz cały

ip cef accounting load-balance-hash
Zrob ping z R3 do tego adresu i wyswietl sobie staty za pomoca

Kod: Zaznacz cały

show ip cef  x.x.x.x internal

powinienes wtedy zobaczyc ile pakietow bylo wypchanych i jakim laczem.


Pozdro,

tns
wannabe
wannabe
Posty: 62
Rejestracja: 31 lip 2009, 18:36

#5

#5 Post autor: tns »

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.

Awatar użytkownika
Jurand
member
member
Posty: 18
Rejestracja: 21 gru 2014, 12:10

#6

#6 Post autor: Jurand »

tns pisze: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.

tns
wannabe
wannabe
Posty: 62
Rejestracja: 31 lip 2009, 18:36

#7

#7 Post autor: tns »

Jurand pisze:
tns pisze: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: Zaznacz cały

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: Zaznacz cały

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: Zaznacz cały

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

martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

#8

#8 Post autor: martino76 »

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,

tns
wannabe
wannabe
Posty: 62
Rejestracja: 31 lip 2009, 18:36

#9

#9 Post autor: tns »

makes sense now ;)


Dzięki!

ODPOWIEDZ