Task 3.2

The answer to this task is just wrong. It's wrong for three reasons:

1. The solution uses PBR without specifying that it is possible to use PBR in the question (recall that the Do's & Don'ts at the start of the lab stated PBR cannot be used)

2. There are changes to satisfy the second part of the question, i.e. that traffic from R5 to R6 goes via R4.

3. There's no verification step in the answer

IE, please correct.

Comments

  • The wording is not clear to me.

    The first requirment

    R4 sends IPv6 traffic from R6 destined for R5 directly to R5, the R4 is not even in the path from R6 to R5.  Is it asking R4 shold be on the path for IPv6 traffic from R6 to R5?

     

     

     

  • What I understood is that the IPv6 traffic , the tunnel traffic, had to pass through R4 both ways forcefully.

     

    If that was the case what I did and I´m not sure it is a valid solution, I just changed the bandwidth in the interfaces, R5 interface Ser0/0/0 bandwidth to 512 and R4´s to 1024. . . . . and that did it. I am not modifying the cost values of OSPF DIRECTLY, but indirectly.

    Would this be ok?

     

    * CORRECTION, I DID NOT READ WELL THE INSTRUCTION. Pay me no attention

  • I Agree about PBR, it is prohibited according to do and donts.

     but, the point 2 that you mention, I think that in my lab it was configured  in task 2.1 (Ospf neighbor cost).

    I configured this solution :  is it ok? 

    I advertised loopback 0 of router 5 in bgp just to make ebgp ad distance better than ospf:

    Before Change: 


    Rack1R6#trac 150.1.5.5                    

     

    Type escape sequence to abort.

    Tracing the route to 150.1.5.5

     

      1 192.10.1.1 4 msec

        192.10.1.2 40 msec

        192.10.1.1 0 msec

      2 154.1.23.3 20 msec

        154.1.13.3 24 msec

        154.1.23.3 20 msec

      3 154.1.0.4 36 msec 56 msec 36 msec

      4 154.1.45.5 56 msec *  56 msec

     

    After change: 


    Rack1R3#show ip route 150.1.5.5

    Routing entry for 150.1.5.0/24

      Known via "bgp 300", distance 20, metric 0

      Tag 400, type external

      Last update from 154.1.0.5 00:13:50 ago

      Routing Descriptor Blocks:

      * 154.1.0.5, from 154.1.0.5, 00:13:50 ago

          Route metric is 0, traffic share count is 1

          AS Hops 1

          Route tag 400

    Rack1R6#trac 150.1.5.5

     

    Type escape sequence to abort.

    Tracing the route to 150.1.5.5

     

      1 192.10.1.1 4 msec 0 msec 0 msec

      2 154.1.13.3 24 msec 24 msec 20 msec

      3 154.1.0.5 40 msec *  36 msec

    Rack1R6#ping 2001:CC1E:1:56::5 repeat 1000

     

    Type escape sequence to abort.

    Sending 1000, 100-byte ICMP Echos to 2001:CC1E:1:56::5, timeout is 2 seconds:

    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Success rate is 100 percent (40/40), round-trip min/avg/max = 36/37/40 ms

    Rack1R6#

     

     

  • The solution for this is obviously fucked.

    After seeing this post and the previous BGP suggestion, I did the following:


    • Advertised Loop0 of R6 into BGP
    • Set IP OSPF NET POINT-TO-POINT on Loop so the OSPF route wouldn't win due to being /32 (Could have just used dist-list in at R5)
    • Filtered 150.1.6.0 from BGP advertisement from R3-R5
    • Added route-map BGPtoR5 on R4 to modify next-hop for 150.1.6.0 to R4 (else is 150.1.0.3).
    Tested and all works. Sure there's a simpler way but that'll do me for now.

     

  • I doubt that solution would be that complex. The main problem here is that OSPF will ALWAYS take R4 as next hop for whatever traffic. This is due to task 2.1 (guess) earilier when we set OSPF cost for both R4 and R5. R4 will alwasy win due to lower cost. No route-map will help as either interface or next hop will make traffic transit R4 by default.

    One of "clever" solutions would be to change "bandwidth" on both R4 (512) and R5 (1024) to reflect cost on the other side of respective links (neighbor costs on R3). This way return traffic from R5 will transit R4 again. But changing bandwidth will result in changing cost which is prohibited.

    The whole task seems not worked out properly.

    Tom

  • The only solution I see in this task is PBR and that's what i did, even though it was prohibited, and it worked. We are not allowed to manipulate the cost and on the other hand, manipulating the bandwidth interface will result in the cost being changed. INE should either remove prohibiting the use of PBR in the dos and donts, or explicitly mention to use PBR. 


     

  • Hi all,

       Task wording was fixed; breakdown was added; all will be posted within May coming updates.

    Regards,

  • Hello Cristian,

    I reviewed the "updated version" posted a couple of days ago and the wording is exactly the same, the solution has some outputs. I guess that where it says R4 the first time it should say R3, as per the solution. In other hand such solution only satisfies the first requirement, the return traffic is still going directly to R3.

    m'I missing something?

    Cheers.... Victor.

     

     

     

     

  • Hi Victor,

        Full updates will be published soon now.

    All the best and good luck with your studies,

  • Techedit team,

    Even with 1)PBR now allowed and 2) wording fixed to say R3 the solution doesn't work.

    The reason is that the route to 154.1.0.5 on R3 points to R4!

    Rack1R3#sh ip route 154.1.0.5

    Routing entry for 154.1.0.5/32

      Known via "ospf 1", distance 110, metric 98, type intra area

      Last update from 154.1.0.4 on Serial1/0, 00:15:17 ago

      Routing Descriptor Blocks:

      * 154.1.0.4, from 150.1.5.5, 00:15:17 ago, via Serial1/0

          Route metric is 98, traffic share count is 1

     

    The
    reason this is so is because the host route (/32) for 154.1.0.5 is
    added( presumably when you change the ospf network type to
    point-to-multipoint??)

    That routes as a better cost via R4 because of the cost manipulations made in the earlier OSPF section.

    Evey setting ip next-hop to 154.1.0.5 the route goes via R4!

  • Hi Victor,

        Full updates will be published soon now.

    All the best and good luck with your studies,


    Still not updated. But I learned quite a bit from the Task.

     

  • I have a very difficult time to understand the wording on 1st bullet.

    Qutoe" configure the newtowrk so that r3 sends ipv6 traffic from r6 destined for r5 directly to r5" unquoted.  What kinds of wording is that?

    I understand the configs and how the solution works but I lost the point because I really don't understand "the" wordings.

  • It is a very cool task indeed, although the solution guide is not right yet, as on 10.07.2011. ;)

     

    But if you try to satisfy the 2nd bullet(traffic from r5 back to r6 should go via r3) with PBR, you will realize a very special gotcha: 

    Since MPLS is enabled on the interface towards R4, the router will encapsulate the packet into mpls first. Then PBR changes the next-hop, and tries to send packet out on the frame-relay interface. Since this is an mpls packet now, and mpls is not enabled on the frame-relay interface, the router will drop the packet. The workaround is to filter the LDP label advertisement on R4, to not advertise a label for 150.x.6.6.

    An other issue is that the selection of the output interface through setting the next hop to 154.x.0.5 is not possible, because the /32 is known from ospf, through R4. A possible workaround with a dummy IP mapping:

     

    interface Serial0/0/0

     frame-relay map ip 154.16.0.200 503

    and then:


    route-map PBR_IPv6IP permit 10

     match ip address ACL_IPV6IP

     set ip next-hop 154.16.0.200





    Gabor

     

  • yes...I'll agree with that..... some of these questions and the method in which it's asked is rediculous...... not good gramar I would say.... but anyway.....

    Hopefully a bit more clear in the lab

     

  • The bigger question for me is, where would we find protocol numbers come lab day? I would not want to have to learn all possible protocol numbers by heart

  • Hi there

     

    you can check within the doc cd..... under the security  ASA 5500 firewall..... go to the configuration guide and then reference guide.....

    http://www.cisco.com/en/US/docs/security/asa/asa84/asdm65/configuration_guide/ref_ports.html

     

    this should be available during the lab.....

    or

    do "sh ip nbar port-map ?"....

    this should display the well known protocols and ports....

     

    Hope this helps....

     

     

     

  • nbar port map only shows ports, not protocol numbers. And the page you showed doesn't have protocol number 41, as mentioned by the task. It's great if they need something like this done on a protocol number actually in the documentation, but would be unfair to ask a question like this if it wasn't 

  • It's great if they need something like this done on a protocol number actually in the documentation, but would be unfair to ask a question like this if it wasn't 

    In my exam, the task mentioned something about "number" that I couldn't remember what it was referring to. I opened Cisco Doc and found the answer. So, don't worry so much here. I don't think Cisco would like CCIE to memorize protocol numbers.

    Good luck for your study!

  • If you know how to enable the protocol that your aren't sure of the number, you could enable it and use debug ip packet detail to get that information.

  • Yeah that was my thought too. A bit of a hassle but at least it works

  • Hi there

    yes, agreed...not all protocols are shown...but the most likely ones are..... for this task I also tried the "debug ip packet detail"..... I only seen one hit for 41.... and tried to see why not any more hits when generating traffic over the tunnel....couldn't realy see why.... got me to waist a lot of time on that...but the better method was to put a ACL on the transit device...I think it was R3...the one in the middle...and then do a deny any log..... this clearly shown the log for 41 being triggered......

     

    just another way of doing it!

     

    hope it helps!

     

  • Hi,

      Yes, a transit ACL it is a good approach, as long as there are not too many protocols passing through the filter, which you don't know the numbers.

    Good luck with your studies!

  • If you know how to enable the protocol that your aren't sure of the number, you could enable it and use debug ip packet detail to get that information.

    I usually collect the information from netflow after this create ACL and turn on debug ip packet detail <ACL number>. This might help you guys as well

    R2#show ip cache flow
    IP packet size distribution (72 total packets):
       1-32   64   96  128  160  192  224  256  288  320  352  384  416  448  480
       .000 .847 .152 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

        512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
       .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

    IP Flow Switching Cache, 4456704 bytes
      3 active, 65533 inactive, 51 added
      896 ager polls, 0 flow alloc failures
      Active flows timeout in 30 minutes
      Inactive flows timeout in 15 seconds
    IP Sub Flow Cache, 533256 bytes
      0 active, 16384 inactive, 0 added, 0 added to flow
      0 alloc failures, 0 force free
      1 chunk, 1 chunk added
      last clearing of statistics never
    Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
    --------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
    TCP-BGP             16      0.0         2    50      0.0       5.4      15.4
    UDP-other           32      0.0         1    65      0.0       0.0      15.4
    Total:              48      0.0         1    57      0.0       1.8      15.4

    SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
    Fa1/0         1.1.1.1         Local         2.2.2.2         06 00B3 41EB     2
    Fa1/0         12.12.12.1      Null          224.0.0.9       11 0208 0208     1
    R2#show ip flow top 10 aggregate source-address sorted-by packets

    There are 3 top talkers:

    IPV4 SRC ADDR         bytes        pkts       flows
    ===============  ==========  ==========  ==========
    1.1.1.1                  99           2           1
    23.23.23.3               92           1           1
    12.12.12.1               52           1           1


    R2(config)#access-list 100 permit ip host 23.23.23.3 any
    R2(config)#^Z
    R2#debupg
    *Nov 25 00:36:54.019: %SYS-5-CONFIG_I: Configured from console by console
    R2#debug ip packet detail 100

    HAPPY STUDY

    [:D]

  • Hi nnn

    Does the netflow show the protocol number for the required technology?

     

    not sure if I see it?

    please elaborate?

     

    thanks

  • Does the netflow show the protocol number for the required technology?

    JJ,

    the purpose of Netflow example is to identify source/destination sending more traffic. After this you can make specific ACL.

    Just turning debug ip packet details is not good if you have more heavy traffic so better use debug ip packet detail <ACL>, that would be easier, isn't it?

    HAPPY STUDY

    [:D]

     

  • Yes , nnn

     

    agree.... just thought I missed something wrt the output of the netflow stats..... 

     

     

  • Techedit team,

    Even with 1)PBR now allowed and 2) wording fixed to say R3 the solution doesn't work.

    Evey setting ip next-hop to 154.1.0.5 the route goes via R4!

    No it doesn't. 

    debug ip detail before you apply the PBR config to R3 and after. Note which interface the protocol 41 packets come in on. 

    Prior to PBR on R3, they'll come in Fa0/1, after PBR, they'll come in S0/0/0, so whatever R3 is doing in, it's dropping it on the right DLCI for the frame relay connection.

    The second part of the task, PBR'ing it back to R3 from R5 seems to be missing from the Solution Guide.

  • Hi Gabor,

    Very interesting ! Did you manage to see R5 drop the mpls encapsulated packet in some debug output ? I did not find a way to debug that problem so I am curious to how you reached this conclusion, but you are right about the mpls problem : my ipv6 eigrp neighborship was flapping and I could not figure out why. Well spotted.

     

    As for the second issue you mention, like you someone before me already mentioned, this is actually not an issue. Looking at interface counters on R5, R3 and R4, it is clear that for some reason PBR does not follow the ospf /32 route, but sends the traffic on the connected interface towards R3. Don't ask me why !

     

    Thanks.

Sign In or Register to comment.