Tuesday, April 24, 2018


In order no to expose tasks solutions in the comments of specific task, in case you have any questions, corrections or comments, please post on this page. 


  1. A correction for the "OSPF task #5. Fine tuning" lab:

    For the maximum redistributed prefixes, the warning threshold is set as percentage both in IOS and IOS XR, so the solution should read "10 70", not "10 7".

    1. Thanks Anton! I've updated the solution with correct values.

  2. A correction for the "OSPFv3 task #3. Authentication" lab:

    On R2, the interface-level null auth command is missing in the config (although explained in the notes).

  3. A comment for the "Basic BGP" lab:

    Well here it really makes sense to specify in the task that IGP is to be configured, because I really thought it's some intentionally worst-practice IBGP-only exercise, so I built it all up with "redistribute connected". :-) By the way, I believe that in your setup R2 and R4 won't advertise the network when announced by the network statement, because it's not in the routing table (unless e.g. a static route to Null0 is created), so aggregate address would do better (which option I used in my IBGP-only solution).

    1. This comment has been removed by the author.

    2. Hi Anton,

      Please note that the task diagram includes OSPF area 0 for AS12, to the use of OSPF as IGP for AS12 is implied.

    3. Yeah indeed, I noticed the OSPF and ISIS areas on the diagram when I already posted the comment and proceeded to the next lab. Sorry for the confusion.

  4. A comment to BGP Task #4:

    To be in line with the solution, the task should request to prevent advertisement of specific loopback addresses. Otherwise the reader feels no requirement to suppress them.

  5. A comment to MPLS Task #2:

    It's a good point of subtask #3 that R6, while advertising only loopback labels to R7, should advertise all labels to all other peers. It trains one to be attentive; for example I completely forgot to fulfil this implicit requirement.

    But the way to fulfil it which is shown in your solution is incorrect. It is suggested that

    no mpls ldp advertise-labels
    mpls ldp advertise-labels for 11 to 7
    mpls ldp advertise-labels for 1 to 2

    where ACL 1 permits any (prefixes) and ACL 2 means "all peers except R7".

    But this is not gonna work. R7 will receive only loopback labels indeed, but R1, R2 and R5 will receive labels only for non-loopback prefixes (instead of receiving labels for all prefixes). The reason for that is explained in Cisco documentation:

    "If more than one (prefix acl, peer acl) pair from multiple mpls ldp advertise-labels commands matches a prefix, the (prefix acl, peer acl) pair in the first such command (as determined by the show running-config command) applies to the prefix"


    In other words, when a prefix is matched by an "mpls ldp adv" command, it can be matched no more by any subsequent instances of the command. This is a good example of an extremely user-unfriendly command logic, as well as the whole logic of the "mpls ldp adv" construct, I should say.

    The way in which the requirement of the task could be fulfilled is e.g. this:

    no mpls ldp advertise-labels
    mpls ldp advertise-labels for 11
    mpls ldp advertise-labels for 16 to 2

    where ACL 11 is like yours, it permits loopback prefixes only, ACL 2 is also like yours, it lists all peers except R7, while ACL 16 is e.g. like this:

    access-list 16 permit

    In this logic, first we disable all label advertisement. Then we enable advertisement of loopback labels to all peers. Thus R7, R1, R2 and R5 will all get the loopback labels. Finally, we say that R1, R2 and R5 (but not R7) also need to get non-loopback labels as well. Technically, ACL 16 does match loopbacks as well, but, as noted above, once they were already matched by the preceding instance of the "mpls label adv" command, they are effectively not matched by this one ( while the non-loopback prefixes are).

    1. Hi Anton,

      Thanks again for your valuable feedback! Unfortunately, I don't have those lab configuration available any longer. I will rebuild the scenario and post the updated solution.

  6. Hi Dimitry,

    The "Central Services" lab page fails for me, has it been deleted or just some temporary problems out there on the server?

    1. Hi Anton,

      The link was broken, should be working now. Thank you for letting me know!

    2. Thanks, it's working now!

      I'd like to suggest that the same goal can be achieved by configuring export maps on PE's which would set additional route-targets for selected prefixes (so that those prefixes would be imported by R1 only).

      So maybe it makes sense to include this as the second option into the task, for variety.

  7. A comment to L3VPN task #4:

    The solution violates the general restrictions which prohibit static routing.

    In some parts this can be circumvented. For the prefix advertisement into BGP, one can use selective redistribution of connected prefixes with subsequent "aggregate-address".

    For the Customer A vrf, I used redistribution of BGP into ISIS on R6. This way internet routes propagate from R6 to R7 inside the L3VPN, and R6 is introduced into the traffic route from R7's perspective.

    Lastly, "neighbor ... default-originate" command can be used on CUST_B PE's to provide the default route to CE's.

    But I don't see how the routing out of the CUST_B vrf and back from the internet to the "48.0" prefixes can be arranged without static routing (or some sort of PBR maybe, which is also prohibited). So it's just better to explicitly allow some static routes in the task; but, once again, they can be disallowed for the CUST_A part, since that can be done without.

    It also makes sense to instruct the reader to create additional loopbacks on the CE's to represent the public prefixes.

    Last but not least, the next hop adjustment is missing on R3 in the solution (while present on R2). The config for R7 is completely missing.

    Overall, a very good lab, trains one to be attentive and to consider various solutions. But the restrictions (which then turn out not to be in force) is what is confusing.

  8. L3VPN task #9 - one more excellent lab!

    A couple of comments:

    On R2 and R4, it makes sense to apply a route-map on the BGP-to-OSPF redistribution, otherwise the internet routing table may end up in the OSPF database, which is undesirable.

    The static route to Null0 on R7 violates the general guidelines. The same goal can be achieved via aggregate-address plus redistribution from OSPF (or of the connected local loopback).

  9. A comment to the "Simple L2VPN" lab:

    Configs of R3 and R7 erroneously feature VLAN 75 instead of VLAN 87. This should be corrected either in configuration or in the task.

    Also, it makes sense to migrate the solution to the new L2VPN syntax (l2vpn xconnect context).