Topology

graph LR
net1(LAN1_172.17.99.0/24) 
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4

Configuration and Analysis

The default next hop of an aggregate route is reject:

root@R4> show configuration routing-options rib inet.0 aggregate 
defaults {
    preference 189;
}
route 10.22.1.0/26;

root@R4> 
root@R4> show route protocol aggregate 

inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.22.1.0/26       *[Aggregate/189] 00:00:58
                       Reject

inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

root@R4> 
root@R4> show route 10.22.1.0/26 exact detail 

inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
10.22.1.0/26 (1 entry, 1 announced)
        *Aggregate Preference: 189
                Next hop type: Reject, Next hop index: 0
                Address: 0x77c5434
                Next-hop reference count: 2
                Kernel Table Id: 0
                State: <Active Int Ext>
                Local AS:    22 
                Age: 7:22 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 5-Resolve tree 3 
                AS path: I  (LocalAgg)
                Flags:                  Depth: 0        Active
                AS path list:
                AS path: I Refcount: 2
                Contributing Routes (2):
                        10.22.1.0/27 proto Direct
                        10.22.1.32/27 proto Static
                Thread: junos-main 

root@R4> 

#LessonLearned The contributing routes may be of different routing protocols or pseudoprotocols.

First, let’s see if QoS is enabled on the switch: QoS is disabled. We should enable it on global configuration level: If we want to display QoS settings for an interface, we do a show mls qos interface command: At this stage we still did not define trust boundaries. That’s why Trust State and Trust Mode say “not trusted”. And we did not specify whether we’ll trust a device or not. To define trust boundary with auto-qos, we either trust all CoS values coming on the switch interface or we trust CoS values only if an ip phone is connected to the switch port. With auto qos voip trust, we tell the switch to trust CoS on each packet coming on the switch interface: If we want to further limit trust boundary, we can tell the switch to trust CoS values only if a Cisco ip phone is detected on the port: Finally, on a 3550 switch, show auto qos and show auto qos interface give the same output:

Enabling Loop Guard on an interface level does not enable it for the whole system. In fact, a “show spanning-tree summary total” is a bit misleading in this case.

To configure loop guard on an interface:

“loop guard default” is disabled because we haven’t issued a “spanning-tree loopguard default”. Easy:

verify that QoS is enabled:

Enable QoS:

At this stage, all interfaces are by default untrusted. This means that any frame with a priority value will be remarked as CoS/IP Precedence/DSCP value = 0.

Trust CoS values of incoming frames. Useful for trunks:

Trust CoS values only if an attached Cisco ip phone exists (conditional trust):

At this stage, the trust boundary moves to the IP phone. Any priority value of any attached PC frames is untrused, thus remarked with priority 0.

In this lab, I learned the following:

• configuring a HSRP group on physical interfaces,
• testing how a PC can reach a remote subnet through a redundant gateway, by configuring its default gateway as the HSRP virtual address,
• testing how the second router becomes Active,
• testing interface tracking.

For interface tracking, at first, I thought there was a problem with the lab. Topology: configure interface tracking and a decrement value: When I shut down ser0/0 on R2, I expected R2 to become Standby router. But reality bites: Then I checked on R3. R3 is still Standby, not Active ! So what’s wrong? Here’s what Cisco says: How Object Tracking Affects the Priority of an HSRP Router