Task 1.1 - access-list hardware program nonblocking

Hi,

Is this command exclusive of 3550? My 3560 is not taking it. I though the 3550s were now long gone in v4 lab and now all 4 switches were 3560s. I would appreciate if someone could clarify this for me.

Thanks,

Jorge

Comments

  • I can confirm for you that in the lab exam configuration portion - it is indeed 4 3560s. 

    There are still some places in Volume 2 where the command is indeed "legacy" to the 3550. We will eventually remove such instances. 

     

  • Thanks!

    I feel relief once again.

    Regards,

    Jorge

  • Two additional questions:

    1)

    In scenario 1.1 there is requirement that R5 must be able to ping R4's interface address using packet size of 1600 bytes.

    In solution guide, system mtu on switches is set to 1504. Shouldn't it be 1604 and additionally on router interfaces set to 1600?

    Or there is typo in lab scenario and should be requirement of 1500 instead of 1600.

    2)

    lab SG says that we shoud limit broadcast traffic using "storm-control broadcast-level 7.50". Isn't it better just to use "storm-control broadcast level bps 750k"?

    This way we don't need to care about interface speed. Or it is another legacy from 3550?

     

    Another confusing thing - in 1.1 verification section there is testing with command "pimg 130.1.54.4 size 1600" which is obviously wrong, because without making interface mtu larger on router, router would fragment those packets to it's own outgoing interface MTU (1500). So we can enter even ping size 5000 and it will work.

    Proper way to test MTU issues is ping with "df-bit" option, which forbid router to fragment those packets.

    regards,

  • In scenario 1.1 there is requirement that R5 must be able to ping R4's interface address using packet size of 1600 bytes.

    In solution guide, system mtu on switches is set to 1504. Shouldn't it be 1604 and additionally on router interfaces set to 1600?

    Or there is typo in lab scenario and should be requirement of 1500 instead of 1600.

    I initially thought this however, you cannot set the system mtu to larger than 1546 bytes on the 3550 switches aka SW3 and SW4.

    So if you set system mtu to 1504 the ping with size 1600 will work.  Of course these packets are fragmented, as out router's interface MTU is 1500.

    The solution is valid as there is no constraint saying that packets must not be fragmented between R4 and R5!

    In the real world clearly this would not be a good solution - but the lab is nothing to do with the real world :-)


    HTH

     

  • So if you set system mtu to 1504 the ping with size 1600 will work.  Of course these packets are fragmented, as out router's interface MTU is 1500.

    In this task there is an implicit requirement saying that packet of size 1500 byte should work without fragmentation just like in a normal case therefore we have system mtu 1504. There is also an explicit requirement saying that packet of size 1600 bytes should work and task no where mentioned about DO NOT DO fragmantation therefore this requirement is fulfilled automatically via framentation otherwise we had to set mtu of 1604 as well.


  • Also in INE racks a system mtu of 1604 will not work as SW3 and SW4 are 3550 switches.

    Sent from BlackBerry



    From: dcancerian [mailto:[email protected]]

    Sent: Sunday, April 01, 2012 03:22 AM
    To: Patrick Barnes

    Subject: Re: [iewb-rs-vol2-v5-lab15] Task 1.1 - access-list hardware program nonblocking

     

     


    imagewelshydragon:

    So if you set system mtu to 1504 the ping with size 1600 will work.  Of course these packets are fragmented, as out router's interface MTU is 1500.

     

    In this task there is an implicit requirement saying that packet of size 1500 byte should work without fragmentation just like in a normal case therefore we have system mtu 1504. There is also an explicit requirement saying that packet of size 1600 bytes should work and task no where mentioned about DO NOT DO fragmantation therefore this requirement is fulfilled automatically via framentation otherwise we had to set mtu of 1604 as well.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx

     

Sign In or Register to comment.