Home > Practice TSHOOT Tickets with Packet Tracer & EVE-NG

Practice TSHOOT Tickets with Packet Tracer & EVE-NG

March 6th, 2019 in Guide Go to comments

Special thanks to Buddy who sent us these files. Please say thanks to him. Now you can practice most TSHOOT Tickets with Packet Tracer v6.1. Please download all the tickets in one file here: https://www.networktut.com/download/Cisco_PT_6_1_TSHOOT_Package.zip. All the guides were included in that file.

Note: Please use at least the final Packet Tracer v6.1 (STUDENT Release) or above to open them. Below is a screenshot of the pkt files:

 TSHOOT_Tickets_PT61.jpg

*********************
From Buddy:

Please notice: It’s mainly all the Packet Tracer TSHOOT L2 based trouble tickets, that needs to be reconfigured with STATIC IP addresses at the PC Clients by today

Thus when reconfiguring the two PC Clients with static IP addresses, please remember to also EXCLUDE the two Client IP addresses (.3 and .4) within the DHCP Pool at DHCP Server R4, at the same time.

****************************

Special thanks to Marcus for creating the TSHOOT topology with EVE-NG network emulator (currently this is one topology file with working configuration, not the tickets). You can download this file here: https://www.networktut.com/download/TShoot_300-135-TT_EVE-NG.zip. Below is screenshot of the EVE-NG file:

TSHOOT_Working_topology_EVE-NG.jpg

Note:
+ EVE-NG emulator must be installed to open this file.
+ This file uses these IOL images (but you may use other IOL images):
 – i86bi_LinuxL2-AdvEnterpriseK9-M_152_May_2018.bin
 – i86bi_LinuxL3-AdvEnterpriseK9-M2_157_3_May_2018.bin
+ Importing steps:
1. click ACTIONS/Import external labs
2. select target lab but don’t unzip it then import
3. BEFORE starting any nodes on ASW1,ASW2,DSW1,DSW2 select the Layer2 IOL image that is present in your eve.
4. click More actions/Start all nodes

Comments (50) Comments
Comment pages
1 2 3 11 618
  1. Mark
    July 1st, 2014

    Could you give packet tracer 6.1 also?

  2. networktut
    July 2nd, 2014

    @Mark: We are sorry but you have to find PT6.1 by yourself. Please google it.

  3. Tuấn
    July 2nd, 2014

    Thanks u

  4. Tuấn
    July 2nd, 2014

    Give me link Packet Tracer v6.1 (build 111) :) . Thanks

  5. Anonymous
    July 2nd, 2014

    I checked all tickets are working fine as per strategy given by Khattak or Naren except for TT#10.
    In this ticket, client must be able to ping 10.1.4.5 but, it cannot.
    Thanks to Buddy who posted these wonderful labs for us and also requested to look at this ticket and update.

  6. Buddy
    July 2nd, 2014

    Hello Forum!

    Thank’ for your wellcome to my newly uploaded PT 6.1 based TSHOOT Tickets, that matches the official documentation and info (demands) from Cisco and on this Site – close to 100%

    However, here’s some pratical info about the PT based TSHOOT Ticket Solution:

    1)
    Pls. study the “READ ME FIRST” .txt file carefully before using the Tickets! – The file contains important and usefull info for you! – Then follow the Guidelines given within the file!

    2)
    Don’t forget to also study the repective “Pull Down Menues” at the BOTTOM at each PT Ticket Screen – They ALSO (most often) contains valuable information when preparing for the exam!

    3)
    Loopback TESTING I/F’s for BOTH IPv6 and IPv4 based Routing has been configured on all Devices everywhere within the Ticket Topologies as follows:

    R1:
    Loopback1:
    IPv4 address 1.1.1.1 /32
    IPv6 address FEC0::1:1 /122

    R2:
    Loopback2:
    IPv4 address 2.2.2.2 /32
    IPv6 address FEC0::2:2 /122

    Etc. etc. – Use theese VERY easily remembered addresses when testing and troubleshooting each ticket!

    4)
    Have fun and practice HARD, to get a real hardcore CCNP Network Troubleshooter (NOT just relying on more or less “strange” memorized/preprogrammed xxx “Strategies”! – Which is NOT very usefull IRL!!!)

    /Buddy

  7. Buddy
    July 2nd, 2014

    @Anonymous:

    Well, I don’t know what Mr. Khatakk (and others) claims about TSHOOT Ticket#10 within their predefined TSHOOT “Strategies”, since I’ve never used them myself, but instead pacticed normal regular Network Troubleshooting during my CCNP TSHOOT Studies etc.

    But if he claims, that within Ticket#10 – the client must be able to ping 10.1.4.5 – he is definitly WRONG, simply because the two (EIGRP) Devices: DSW1 and R4 do NOT become EIGRP Neigbors over the (routed EIGRP) Link, that connect the two Devices within this Ticket#10 – (Because they Work within two DIFFERENT EIGRP Areas (10 and 1 respectively).

    Therefore the Client will ONLY be able to reach until the 10.1.4.6 Interface controlled by DSW1.

    You can simply test, what I’m talking about, by entering the following command sequence on Router R4 within Ticket#10:

    ena
    conf t
    NO router eigrp 1
    !
    router eigrp 10
    redistribute ospf 1 metric 100000 10 255 1 1500
    network 10.1.4.4 0.0.0.3
    network 10.1.4.8 0.0.0.3
    network 10.1.21.128 0.0.0.31
    no auto-summary
    !
    end
    !
    Then you’ll notice, that DSW1 and R4 NOW becomes fully EIGRP Neighbors, (because they now operates within the SAME EIGRP AS), and therefore the Client now has FULL IPv4 Connectivity throughout the total IPv4 Topology for the actual Ticket!

    (Thus the Symptom Mr Khatakk is describing within his “TSHOOT Strategy” fits a little better within Ticket#11 – The EIGRP->OSPFv2 redist Ticket! – Because here, the Client will be able to reach until IP add 10.1.4.5, but NOT reach IP add 10.1.1.10 – because of MISSING Redisribution among the two Protocols!!!)

    So, pls be a little carefull in just blindly relying on everything various “Strategies” etc. claims to be true! (at least – without FULLY undestanding, what is really going on within the actual Ticket Problem!)

    Wish you well on your TSHOOT Studies and within Exam!

    /Buddy

  8. Tuấn
    July 2nd, 2014
  9. Tuấn
    July 2nd, 2014

    Tic 9 have 2 err, ip helper in R4 and port channel in ASW1

  10. Buddy
    July 2nd, 2014

    Nope,

    R4 IP Helper Loopback I/F:
    interface Loopback21
    ip address 10.1.21.129 255.255.255.224

    and:

    ASW4:
    switchport trunk allowed vlan (1),20,200

    both – apears to be correct within ticket9, according to reliable info obtained elsewhere –

    (although vl1 isn’t mandatory / important / relevant for this ticket)

    so, pls skip vl1 on the cmd-line, if you don’t likes it there, it doesn’t make any difference when solving the ticket.

    It’s just an uninteresting / not relevant DETAIL within TT9…

  11. Buddy
    July 2nd, 2014

    BTW – Also the R4 Loopback21 I/F isn’t relevant or interesting for TT9 AT ALL!!!

  12. tcp804
    July 3rd, 2014

    So far I couldn’t get PT6.1; the latest I can find is 6.0.1 and labs don’t work on 6.0.1

  13. Shooter
    July 3rd, 2014

    @tcp804:
    The brand new PT 6.1 “Student” version (released just 4 days ago) is now availble @ Cisco NetSpace for Cisco NetAcademy Students and ditto Alumni’s.

  14. Om
    July 4th, 2014

    Hello all
    Can any one answer my question –
    Apart from the same question as below in Trouble Tickets in real exam, whether some clue is also provided to start with or we have to find all 15 issues without any hint with same question again and again?
    Trouble Ticket Question –
    Client 1 is unable to reach the external WEB Server: 209.65.200.241.
    Thus, You are requested to troubleshoot the cause of the problem and identify the following:
    1: The faulty Device
    2: The faulty Technology
    3: The curative Action to solve the problem
    Thanks in advance

  15. Om
    July 4th, 2014

    Some people are also quoting that 4 TTs are changed. If any has an update over this then plz do share ur experience or views.

  16. Anna
    July 4th, 2014

    @All:

    Yop – TSHOOT Tickets appears to run much better and FASTER within the new PT 6.1 STUDENT version, compared to the the former Build 111 (Beta) Version! – No doubt about that :-)

    I also noticed, that when turning OFF the PT 6.1 “LINK LIGHTS” while troubleshooting each Ticket – improved the overall Ticket Performance considerably! – (due to Ticket Lab guidelines).

    So – Thank’s to Buddy for some real nice (and not least well documented) TSHOOT Ticket Labs!

  17. Samo
    July 4th, 2014

    Ticket 9 is giving me tough time.
    Can somebody please help. I can’t figure out what the problem is.
    I corrected the allowed vlan 10, 200 but still cant access web server

  18. Samo
    July 4th, 2014

    Thank you guys, I figured out. it was was the DHCP.

    And thanks to BUDY. You have been very helpful indeed.

  19. Buddy
    July 4th, 2014

    @Samo
    No big deal!
    You’ve probably a problem in getting a legal DHCP IP add (e.g. 10.2.1.X) into Client1
    (It takes a little while to get an IP add on the Client!)
    Therfore:
    1) First solve Ticket 9 due to guidelines included
    2) Then go into the Client1 “Config Tab” and Switch back and forth between “DHCP” and “Static” a couple of times – Then suddenly you’ll get your needed IP Add + other relevant IP Info on the Client from DHCP Server R4, and everything will be working nice and easy :-)

  20. Samo
    July 4th, 2014

    Hi Buddy,

    Thank you for the info. It takes less than a minute till I get the ip address.
    Could you please help one more question. I have done all of them as per the Read Me file considering TT2, TT6 and TT11.

    I am stuck in TT13. Can you please help. Thanks in advance

  21. Buddy
    July 4th, 2014

    @Samo:
    OK, then you can go and take a cup of coffee meanwhile :-)
    About your TT13 Problem – Well, I think I know what you’re stuck in: Again DHCP – Right!?
    Therefore pls. read my Tech Note at the very BOTTOM on the Answer3 Pull Down Menu for TT13 – Here I think you’ll find the answer to your Problem!?
    (Within indeed TT13 – DHCP Server R4 operates EXTREEMLY SLOW, for some odd reason!)
    Therefore the suggested R4: “wr/reload” can speed up the process!
    However, after I wrote the note, I found out, that if you WAIT long enough – Client1 will still get his IPv4 Address etc. from DHCP Server R4!

  22. Samo
    July 4th, 2014

    @Buddy,

    Thank you very much. It worked but really too slow to get the ip address.
    I am doing the last bit of the preparation. Thank you indeed, your help and GNS3 Talk as well as Networktut are awesome. Will update you after the exam.

    Thanks

  23. Buddy
    July 4th, 2014

    @Samo:
    Just another 2 Tips:
    1)
    While waiting for the DHCP IPv4 address delivery to Client1 – Just jump to ASW1 (or2), and continue your testing from one of theese devices.
    I’ve configured ASW1 & 2, so they’ve also IPv4 Connectivity throughout the total TSHOOT Topology –
    (It’s due to an minor problem with the “IP Default Gateway” Command within PT 6.1 Layer2 Switches – The PT Development Team knows about this minor Problem)
    2)
    Use Ip add. 10.1.1.1 as a GOOD Central (starting) “Test Point”, to find out if you’ve to go “North/West” or “South” within your ongoing troubleshooting process – It turned out to be extreemly effecient (at least for myself) regarding the “10.x.x.x” Tickets :-)

    NOW run ALL Tickets Anonymously with PT Link Lights TURNED OFF in order to really learn EFFECIENT Network Troubleshooting WITHOUT beforehand knowing what problem, you are going to solve! – (Just like IRL!!!)

    Do this repeatedly until you really masters it – WITHOUT thinking about diverse “mysterious/Preprogrammed” Strategies etc. (often filled with errors etc.)

    Instead: Practice and LEARN “REAL” Network Troubleshooting!!!

  24. Buddy
    July 4th, 2014

    Samo:
    Yep, that’s indeed why you should do an R4: wr/reload (after solving the Problem) – Then the Client Ip is delivered quite Fast!!!

  25. Samo
    July 4th, 2014

    @Buddy,

    10.1.1.1 is my perfect milestone. If I pass, then I focus on R1, BGP and NAT. If I have to come down, then I test 10.1.1.2 if both fail, then I get back to R4, and so on. The delay to receive the IP add from DHCP was really troublesome, but it stimulates more troubleshooting and thinking. To be honest, I do appreciate so much for these tickets and guidance accompanying it.

    Thank you Buddy.

  26. Diego
    July 4th, 2014

    Hi I just downloaded the packet tracer files, but I cannot find the Pull Down Menues” at the BOTTOM at each PT Ticket Screen.

    Thanks

  27. Buddy
    July 4th, 2014

    @Samo:
    Yop, You just got the point, and you now seems to be quite “fit” for exam!
    So good luck and all the best on exam!
    (PS – My latest post right above (R4 wr/reload), was off course in connection with TT13!)

  28. Buddy
    July 4th, 2014

    @Diego:
    The mentioned Pull Down Menu(es) are located Just within the middle / Bottom of the (total) PT Ticket Screen (just to the right of the Device Section there) – Look after the text either “Main Scenario” or “Ticket Ansvers:”, and (left) click on the Little “v” there – Then you’ll (normally) find 3 Submenues: Answer 1 – Answer 2 – Answer 3 each containing the respective Answer for the Ticket + (quite often) additional valuable (tech) info etc. that (sometimes) can be usefull when preparing for exam. – OK!?

  29. An IMPORTANT Update!!!
    July 5th, 2014

    Further testing of the TSHOOT Tickets within PT 6.1 has shown, that at least the FINAL official Packet Tracer v6.1 “STUDENT” Release should be used to run the tickets as desired!!!

    This final release operates MUCH Faster and quite more reliable/stable, compared to the former Build 111 (Beta) release, and thus it solves a couple of issues like slow DHCP operation + slow L2/L3 Convergence etc.

    /Buddy

  30. Buddy
    July 5th, 2014

    Sorry, but above PT version is just release 6.0.1 and Thus NOT compatible with Tickets! – Therefore – Use the FINAL PT release 6.1 STUDENT instead!

  31. Joe
    July 7th, 2014

    Buddy,
    Thanks for your incredible workmanship in these labs. I have done all of them and have found it very helpful for improving my diagnostic speed and approaches. They have a very realistic feel. Thumbs up for bringing this to PT!

  32. Curious
    July 7th, 2014

    I tried to do a traceroute from the working file.
    Is the traceroute valid guys? isn’t it the hop 10.1.4.9 should be 10.1.4.5 since vlan 10 is already active? Or the 10.1.4.9 just tells us it is Router R4.

    Thanks.

    PC>tracert 209.65.200.241

    Tracing route to 209.65.200.241 over a maximum of 30 hops:

    1 0 ms 0 ms 0 ms 10.2.1.1
    2 0 ms 0 ms 2 ms 10.1.4.9 <—
    3 1 ms 2 ms 0 ms 10.1.1.9
    4 3 ms 3 ms 1 ms 10.1.1.5
    5 10 ms 10 ms 10 ms 10.1.1.1
    6 18 ms 10 ms 11 ms 209.65.200.226
    7 28 ms 10 ms 29 ms 209.65.200.241

    Trace complete.

  33. nooby
    July 7th, 2014

    Hi everyone, I need packet tracer for this,
    please share,

    thank you

  34. Buddy
    July 7th, 2014

    @Curious – (Whauu – Here we’re having an REAL “awake” Student) :-)

    Yop, You’re absolutely right about this issue being a little “tricky” case, that I’ve been fighting against for some time.

    However due to my testing, I think it’s related to the HSRP failover, that – (within approx 60% of the cases) – ain’t quite in SYNC between the two HSRP Devices: DSW1 and 2.

    For the remaining 40% of the cases, it seems to work, as it’s supposed to!

    Now, If you try to run PC>tracert – twice – First a normal one, and then you do an R4 fa0/0 shut / no shut – and then run it once more – You’re getting:

    First the “normal” one:

    PC>tracert 209.65.200.241

    Tracing route to 209.65.200.241 over a maximum of 30 hops:

    1 13 ms 1 ms 0 ms 10.2.1.2
    2 19 ms 13 ms 2 ms 10.1.4.9 tracert 209.65.200.241

    Tracing route to 209.65.200.241 over a maximum of 30 hops:

    1 1 ms 9 ms 1 ms 10.2.1.1
    2 0 ms 2 ms 13 ms 10.1.4.5 <—- now it's OK!
    3 13 ms 10 ms 10 ms 10.1.1.9
    4 26 ms 11 ms 21 ms 10.1.1.5
    5 16 ms 50 ms 20 ms 10.1.1.1
    6 22 ms 23 ms 24 ms 209.65.200.226
    7 22 ms 24 ms 24 ms 209.65.200.241

    Trace complete, and NOW we're in Business :-)

  35. Buddy
    July 7th, 2014

    Upps – some lines unfortunatly disappear’ed within the FIRST output above, but this output was excactly the same as the one above from YOU Curious!

  36. Buddy
    July 7th, 2014

    @Curious: So you can call the above “Work arround” – kind of a “Kick in the a..” Solution :-)

  37. Buddy
    July 7th, 2014

    Thank’s Joe!
    I’m happy if the presented PT based TSHOOT Labs can support both Yours and other CCNP Students TSHOOT Training :-)

  38. NhanVo
    July 8th, 2014
  39. aboss
    July 8th, 2014

    Hi,

    In packet tracer 6.1 build 111 the BGP session seams to be up even if there is no ip connectivity may it be due to wrong ip or wrong ACL. See TT3 and TT5. This is very misleading :) at least for me.

    R1#sh ip bgp summary
    BGP router identifier 1.1.1.1, local AS number 65001
    BGP table version is 1, main routing table version 6
    0 network entries using 0 bytes of memory
    0 path entries using 0 bytes of memory
    0/0 BGP path/bestpath attribute entries using 0 bytes of memory
    0 BGP AS-PATH entries using 0 bytes of memory
    0 BGP route-map cache entries using 0 bytes of memory
    0 BGP filter-list cache entries using 0 bytes of memory
    Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
    BGP using 32 total bytes of memory
    BGP activity 0/0 prefixes, 0/0 paths, scan interval 60 secs

    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    209.65.200.226 4 65002 0 0 1 0 0 00:01:00 4

    R1#
    R1#
    R1#
    R1#ping 209.65.200.226

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 209.65.200.226, timeout is 2 seconds:
    …..
    Success rate is 0 percent (0/5)

    R1#

  40. aboss
    July 8th, 2014

    In packet tracer 6.1 build 111 while troubleshooting TT9

    switchport trunk allow vlan x,x,x,x commands

    Do not get copied on the port-channel member interfaces which on real equipment happens this can cause you to disregard the trunking issue if you look at a member interface only

  41. Curious
    July 8th, 2014

    @Buddy
    Yup it works when I tried to do the workaround. Thank you for clarifying this also. In the exam we are not allowed to do a traceroute right?

    There are still other issues that I noticed like in the BGP ticket. Since the neighbor ip is wrong, BGP neighbor peering should not go up. I don’t know if in the simulation during exam if the sh ip bgp summary is right.

    R1#sh ip bgp summary
    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    209.56.200.226 4 65002 0 0 1 0 0 00:05:33

    Anyway, what you’ve done here is really a great help in practicing tshoot. More power to you. By the way buddy, what exam now are you planning to take ?

  42. mone901
    July 8th, 2014

    @Buddy
    Meanwhile, thanks for the great work!!!

    I have a question: how do I find the IP of the client in the real exam??? I can get into CMD mode and type ipconfig in client 1???

    thanks for reply =)

  43. Buddy
    July 8th, 2014

    @Curious and aboss:

    Wehww – It was quite a number of some quite tricky questions, not that easy to answer just in short :-)

    But I’ll try to answer some of them due to the best of my ability.

    Regarding Ticket 3 and 5 (the eBGP problems), I think they both “Basicly” Works as they are supposed to, due to their individual descriptions e.g. here on this site – both in terms of Troubleshooting and Solving the two Tickets – Right!?

    Regarding the eBGP “Theory” relevant for the two Tickets I’ll like to refer to the Wendel Odem Routing Book: Page 430(mid) – 432(top) that describes the relevant eBGP Neighbor issues quite well, I think – However in addition to this, I’ll like add some relevant eBGP listings & conclusions specific for the two Tickets:

    R1#sh ip bgp – (this is a VERY NICE command, when tshooting theese kind of things!)
    BGP table version is 1, local router ID is 1.1.1.1
    ***output obmitted***
    Network Next Hop Metric LocPrf Weight Path

    R1#
    Above you can see, that the BGP Table is completely EMPTY, because we’ve no legal eBGP Neighbors within Ticket 3 and 5 – Excactly as we should expect! – Right!?

    R1#sh ip bgp summ
    BGP router identifier 1.1.1.1, local AS number 65001
    ***output obmitted***
    Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
    209.56.200.226 4 65002 0 0 1 0 00:02:58 4

    Yep, it’s correct, that output from sh ip bgp summ above isn’t 100% correct – The rightmost coloum just above should have listed an eBGP neighbor state of “Idle” instead of “4” (pfx received), since we’ve not any active eBGP Neighborship(s) or ditto communication here!!!

    Regarding TT9 – Well, you’re probably right on that – (I haven’t tried this myself on real gear) – But since the allowed VLAN*s has been configured on INDEED Po “Trunks” (13&23), and NOT on Member ports, I think, that the TroubleShooter should also stay FOCUSED on INDEED THIS and NOT be paying to much attention on all the individual “Member Ports” within the two Trunks in this regard – (It could be quite complex to troubleshoot all this if there were hundreds and hundreds of them – Right!?)

    Hope this helps – I’ve been trying to answer your questions the best I could, since there’s only “limited” Space here, you know…

  44. Buddy
    July 8th, 2014

    @mone901:
    You just go into e.g. Cient1 and do an “ipconfig” – Then you’ll get all the info you need regarding this Client (both on Exam and within the PT Labs here!)

  45. Buddy
    July 8th, 2014

    @Curious and aboss:

    Just a small addition regardig indeed TT5:

    Within this Ticket – Transit Net: 209.65.200.224/30 is being BLOCKED by the ACL, and therefore the R1 and the ISP Router can’t communicate over this (very important) Transit Net via eBGP, because the 2 routers cannot get into eBGP status: “Established” Neighbor relationship. – (Thus the rightmost coloum: pfx/received of “4” turns out to be WRONG within the R1 sh ip bgp summ output, as already mentioned!)

  46. Buddy
    July 8th, 2014

    @Curious and aboss:

    Also – a quite IMPORTANT thing regarding d.o.:

    The Output within the sh ip bgp summ rightmost coloum: “pfx/received” tells:

    A “number” here tells: I’ve an “Established” eBGP Neighbor Relationship with that specific eBGP Neighbor listed within my eBGP Config.

    A Status by the word “Idle” within the same coloum tells: I’ve an eBGP “Neighbor” Statement within my eBGP Config, but for some reason, I can’t “see” that neighbor at the moment.

    Remaining eBGP “States” are listed at Page 430 (mid) within Wendell Odem’s Routing Book.

  47. NhanVo
    July 8th, 2014

    Hello Buddy,

    Could you please explain with more clearly about TT6 – VLAN Filter. The bug of this TT is still and I dont know I will choose ASW1 or DSW1 in the real test.

    And what is the explain:
    “VLAN Filter : You still need to select ASW1 to get VLAN ACL/Port ACL in the next page. If you selet DSW1, Next page would not show VLAN ACL/Port ACL.”

    I’m really dont understand this ticket.

    Thanks a lot

  48. Buddy
    July 8th, 2014

    @NhanVo: Pls study TT6 here on this Site – I can’t do it any better – Pay special attention to the Note at the bottom of the TT6 description – I think it answers your question!

  49. NhanVo
    July 9th, 2014

    Okay Buddy, thanks bro :)

  50. Buddy
    July 9th, 2014

    An important note – (once again):
    As mentioned a couple of times – The present PT based TSHOOT Tickets has been developed for INDEED the official PT 6.1 “STUDENT” release, and thus NOT to the former PT “Build 111 – BETA” version!!!
    The former Build 111 BETA version ain’t able to run most Tickets in a satisfactory way, and thus it should be AVOIDED whenever possible!!!
    Pls be AWARE on this!!!
    Thank you!

Comment pages
1 2 3 11 618