26 March 2025

CML Gotcha

 So I had to take a quick change from learning Juniper to learning Cisco ISE.  I have an EVE-NG environment but I figured I will stand up a Cisco CML environment real quick as well using the free tier to do some testing.  I wanted a network of about four switches and a router running in CML and then use virtual machines with external connectors to connect this all together.  I followed the user guide for creating the external connectors and got bit hard.  I ended up reloading my box 3 times with full installs before it worked.  This is version 2.8.1-14.

If you create a bridge and then delete the bridge and then try to re-create a bridge it will assign all interfaces to the new bridge. The only way I found to fix this was re-loading the whole system.  Great times.  

When I created a bridge, I could not get it to show in the user terminal as an available external connector.  The issue was that I was naming the bridge something other than bridge{XX}.  I was using things like MGMT or Workstation.  That would not be recognized by the system.  What I ended up having to do was leave the bridge name what was default and then in the user terminal change the label to what I wanted.  This is different than the documentation where it says you can name it.  

Oh well live and learn.  

29 October 2024

SRX Fun with Tap Mode and Logging

 To do a tap mode on the SRX is more than just what is in the user guide for security policies.  I had to use this site to find out more.  


First, set up your interface for promiscuity.  

set interfaces ge-0/0/10 promiscuous-mode

Next setup the tap mode under security forwarding-options 

set security forwarding-options mode tap interface ge-0/0/0

You can then setup a routing instance if you need but I didn't worry about that.  I set up my flow and log settings 

set security flow tcp-session no-syn-check
set security flow tcp-session no-sequence-check
set security log mode stream
set security log report

After that was setting up the zone configuration

set security zones security-zone tap-zone interfaces ge-0/0/10.0
set security zones security-zone tap-zone application-tracking

Finally I setup the policy for testing.  

set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match source-address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match destination -address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match application any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then permit
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-init
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-close

The switch was easier to setup for SPAN.

set forwarding-options analyzer SRX_SPAN input ingress interface xe-0/0/10.0
set forwarding-options analyzer SRX_SPAN input ingress interface xe-0/0/6.0
set forwarding-options analyzer SRX_SPAN input egress interface xe-0/0/6.0
set forwarding-options analyzer SRX_SPAN output interface xe-0/0/5.0

To verify TAP mode, use run show security flow status.

root@SRX03> show security flow status     
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Tap mode: enabled
    Enhanced services mode: Disabled
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: Hash-based
    GTP-U distribution: Disabled
    SCTP distribution: Enabled
  Flow ipsec performance acceleration: off
  Flow gre performance acceleration: off
  Flow packet ordering
    Ordering mode: Hardware
  Flow power mode: Enabled
  Flow power mode IPsec: Enabled
  Flow power mode IPsec QAT: Disabled
  Fat core group status: off
  Flow inline fpga crypto: Disabled
root@SRX03> 

And to verify the flow is being seen with policies

root@SRX03> show security flow session    
Session ID: 1389, Policy name: tap-policy/5, Timeout: 60, Session State: Valid
  In: 172.18.33.33/514 --> 10.1.1.100/514;udp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 3, Bytes: 3422, 
  Out: 10.1.1.100/514 --> 172.18.33.33/514;udp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 0, Bytes: 0, 

Session ID: 1390, Policy name: tap-policy/5, Timeout: 4, Session State: Valid
  In: 192.168.1.100/24 --> 10.1.1.10/12044;icmp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 1, Bytes: 84, 
  Out: 10.1.1.10/12044 --> 192.168.1.100/24;icmp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 0, Bytes: 0, 

Now logging was not right either in the user guide.  It missed the part of seeting the mode.  After playing this was my final security log config.

set security log mode stream
set security log format sd-syslog
set security log report
set security log source-address 172.18.33.33
set security log stream trafficlogs severity debug
set security log stream trafficlogs host 10.1.1.100

28 October 2024

Security Policies

 So I learned something interesting.  Sounds fundamental but just never really thought about it.  


I was trying to ping from an SRX loopback to another.  I had ping allowed on the zone host-inbound-traffic but it would not ping.  Interfaces were in the correct zone.  I could see the traffic going to the firewall on a packet capture but could not ping.  


Finally after playing and playing I found out that what I had to do was allow the traffic to go from zone UNTRUST to zone UNTRUST.  I had it already in UNTRUST to junos-host so that was not an issue.  I was under the impression that since my external interface and my loopback were in UNTRUST and I was allowing it from UNTRUST to junos-host, it would be good.  Boy was I wrong.  


Which after I got it working it made since.  I was going from UNTRUST to UNTRUST to junos-host.  Explained why my VPN was not working as well.  


Anyways, live and learn.  Time for more labbing. 



22 October 2024

SRX Flow Logging

So I am loving me some Juniper over Cisco for sure.  But there are a lot of things to get used to anymore as well.  One is logging.  How does it work?  What happened to seeing stuff fly across the screen and lock my console up?  Ah the fun old days.  

So trying to troubleshoot some BGP on the SRX I had to play with logging.  I tried and tried to make it work and well kept falling flat.  That is because I was in the wrong dang area.  I was trying to look at flows coming across the device and tried doing traceoptions in security and in policies.  Both did not work.  To make this work I found an article on what i was missing.

Basically I had to enable logging under security flow.  Some people are probably reading that and going duh but these are my notes so whatever.  

Anyways I didn't do a packet filter because I am on a small home grown network but I did play around and found what I wanted and more.  

Below is my setup for a quick logging setup to see what is passing through the firewall

jmctsm@srx05# show security flow    
traceoptions {
    file flow_log size 1m files 100;
    flag basic-datapath;
}

That way all I had to do was run a show log flow_log to see what was passing.  That showed me what I wanted to see and more.  That BGP to my device didn't work as I wanted it not to but BGP from the device to an outside device did work.  

And on to other things.

Firewall Filters vs Host Inbound Services vs Junos-Host Zone

 So many ways to block traffic with Juniper SRX.  So you can either do a firewall filter (think ACL), allow or deny a service on host-inbound, and also control it via the junos-host zone.  Time to see how they all play together.



Based on this topology I have the CORE and the SRX05 doing BGP with each other.  I have both ge-0/0/0 and ge-0/0/1 in security zone UNTRUST.  Actually before I mention that, let's not forget that if an interface is not in a security zone, it is in the NULL zone and that means it accepts nothing.  It does nothing.  It just sits there and tells things to go away.

I started out with allowing only specific traffic in on my zone and then said I am testing to screw it.  

jmctsm@srx05# show security zones security-zone UNTRUST 
host-inbound-traffic {
    system-services {
        ping;
        all;
    }
    protocols {
        bgp;
        all;
    }
}
interfaces {
    ge-0/0/0.0;
    ge-0/0/1.0;
}

That allowed BGP to come up on both sides (skipping BGP configuration).  So that worked.  But what happens if I put a filter in place.  Hmmmm

jmctsm@srx05# show firewall 
filter INCOMING_UNTRUST {
    term DENY_BGP {
        from {
            protocol tcp;
            port bgp;
        }
        then {
            reject;
        }
    }
    term ALLOW_ALL {
        then accept;
    }
}

jmctsm@srx05# show interfaces ge-0/0/0    
unit 0 {
    family inet {
        filter {
            input INCOMING_UNTRUST;
        }
        address 172.16.5.5/24;
    }
}

[edit]
jmctsm@srx05# run show bgp summary 
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 1 Peers: 2 Down peers: 1
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
172.16.5.1            65000          0          0       0       3       26:56 Connect
172.16.55.1           65000         62         61       0       2       26:53 Establ
  inet.0: 0/0/0/0

So a firewall filter blocked my BGP.  So that tells me it is 

firewall filter -> host-inbound 

So now let's play with the junos-host zone.  I created a policy of 

from-zone UNTRUST to-zone junos-host {
    policy DENY_BGP {
        match {
            source-address any;
            destination-address any;
            application junos-bgp;
        }
        then {
            deny;
        }
    }
    policy ALLOW_ALL {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
default-policy {
    deny-all;                           
}


That did nothing.  BGP still formed for my 55.1 neighbor.  So what happens if I remove the host-inbound services?  Nothing changed yet again.  The BGP session still came back up.   So starting over from scratch I then removed the interface from the UNTRUST zone and now BGP drops.  Time to figure this out more.

So even with no host-inbound and no junos-host security policy, BGP still forms to the neighbor on the UNTRUST interface.  Just freaking weird. 

And I think that I found my issue.  BGP is allowed to connect no matter if I have host-inbound-traffic on or not or allowed in a policy for junos-host.  

So let's try something easier.  Ping.  Without a host-inbound policy I cannot ping. Easy enough.  But let's allow that there and deny it on the junos-host policy and see what happens.

[edit security policies from-zone UNTRUST to-zone junos-host]
jmctsm@srx05# show 
policy DENY_BGP {
    match {
        source-address BGP_PEER_05;
        destination-address any;
        application junos-bgp;
    }
    then {
        deny;
    }
}
policy DENY_PING_FROM_5_1 {
    match {
        source-address BGP_PEER_05;
        destination-address any;
        application junos-ping;
    }
    then {
        deny;
    }
}
policy ALLOW_ALL {
    match {
        source-address any;
        destination-address any;        
        application any;
    }
    then {
        permit;
    }
}

That blocks traffic from 172.16.5.1 as expected.  So again this is good to find out that apparently some traffic is allowed through always and some can be denied.  Interesting.

Also even if the policy is there for zone junos-host but no host-inbound-traffic, the traffic can be denied.

So what we have is a firewall filter will block before any policies then if no junos-host zone is used and only host-inbound-traffic, all things allowed by host-inbound-traffic can come into the firewall.  To be specific you can use either a firewall filter (which has to be applied at all possible interfaces) or use the junos-host zone.  

Fun time with SRX. 


UPDATE:

I figured out finally why BGP would still come up from a neighbor even if BGP is not allowed via junos-host zone or host-inbound-traffic.  BGP is a TCP server client protocol that either side can initiate from.  Looking at the logs, when the CORE device tries to initiate to the SRX, the SRX denies the traffic.  BUT if the SRX initiates the traffic to the CORE it works.  The policy is not blocking that by any outside method and since the SRX is stateful it allows all communications back in from the "server".

To SRX from CORE = BAD
From SRX to CORE = Established

 


14 October 2024

My Path to JNCIE-SEC

On Friday (11 Oct 2024), I passed my JCNIP-SEC.  That was 13 Juniper certifications in less than 12 months.  I have done in no particular order.

JNCIA-JUNOS/DEVOPS/DC/SEC/MISTAI

JNCIS-ENT/SP/DC/SEC/DEVOPS

JNCIP-ENT/DC/SEC

I started down the path of Juniper certifications because I wanted to do something new.  I wanted to try and learn something else beside Cisco.  I didn't know where to start so I started with JNCIA-JUNOS.  I used the Open Learning and Eve-NG to watch the videos and then get hands-on with what I was seeing.  I fell in love with the command line syntax of Juniper and their way of displaying the configurations.  That lead to following the path of more free learning to see what parts I like of Juniper. 

After I started to get some Juniper under my belt my company reached out to see about doing certain tests for partner requirements, so I did things like DC and Devops (wasn't going to do them but they paid so away I go to learn).  I also did JNCIS-SEC for that reason.  That brought back my love of security.  So I figured then that is where I want to go for my JNCIE.  But first I had some other personal goals like the 5A-3S-1P and 5S Credly badges because I wanted them.

Security for me has always been fun because there is always someone out there smarter than you so it keeps you having to learn.  It means you have to keep pushing to know what is happening.  Learn the new bad techniques and the new good techniques.  So I said heck with it and did the JNCIP-SEC, got my 3P along the way as well, and said time for the JNCIE-SEC.

Having a CCIE I know that there is more than hands on for an Expert level test.  There is understanding other ways of doing things, what happens if I do something over here, and the understanding of what in the crap is going on behind the scenes.  Those pieces are what made me miss my first attempts at my CCIE and once I had them down I was more prepared and could pass.  So for this Expert level test I have a reading list already planned that will grow and grow I am sure.  I am starting with 

Juniper SRX Series: A Comprehensive Guide to Security Services on the SRX Series

Juniper Day One: SRX Series Up and Running with Advanced Security Services

SRX Getting Started - Configuration Examples & Troubleshooting (JumpStation)

The Unofficial JNCIE-ENT Prep Guide 

The last one I know is for JNCIE-ENT but Jeff has some really good info in it for configurations so I am going to read through it.  Combine these four things with all the docs that I can get my hands on from Juniper and any blog posts as well, I am hoping to go into this with as much as I can from more than just configuration but theory.  We will see what happens.  

For the hands on I have an Eve-NG lab that I use as well as the Study Bundle from Juniper.  I also signed up for some classes from them for ATP and just other pieces again to make sure that I cover all that I can.  I am expecting this test to be rough.  My goal is 6 to 8 months that I sit for it but we will see.  

I am using this blog as nothing more than a note place for me.  It may or may not have pretty pictures.  It will be more on my thoughts of what I learned that day more than likely so probably incoherent.  But we will see what comes from it.  



08 July 2024

NetSkope Fun

 Well not exactly JNCIE related but still a pain to talk about. 


My company uses NetSkope and while I am not a fan of it because of personal reasons I am learning to live with it.  Today though was a fun time.  I have a virtual Ubuntu machine that I was going to use for dev stuff in AWS.  And because I was NAT'ing from the virtual machine to the internet NetSkope threw a nice little hissy fit.  After working with help desk for an hour we found the issue.  


So let's start local.  My physical machine.  The error was 


SSL validation failed for https://ec2.us-east-2.amazonaws.com/ [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1006)


Which was the same error on my linux box.  To fix this I had to run an AWS command to point to the correct CA even if it was trusted already on the computer.

aws configure set default.ca_bundle “C:\ProgramData\Netskope\STAgent\data\nscacert_combined.pem"


And voila.  Fixed the issues on Windows.


For Linux I had to get the root CA cert used for NetSkope and my company and append it to the aws cert file

cat rootca.pem >> ~/aws/dist/aws-cli/awscli/botocore/cacert.pem

Then I had to create an environment variable and put that in my .bashrc file

export AWS_CA_BUNDLE=/path/to/ca-cert/cacert.pem


And again a voila moment.  But one last thing.  Firefox didn't like that and didn't like that I added it to the trust store of the actual system so I had to import that manually.  But now all works and I am good.  Things work great when you have great tech support.  

09 May 2024

Time to Start Back

 Well the time has come to start back with blogging what I learn.  I am starting on the journey of my JNCIE and that will be either ENT or DC.  I have been working on learning Juniper for the past 8 months or so and have done all the free training that I can from them. Now I have to really buckle down.  I have to put my money where my mouth is.

Overall the path to where I am now (JNCIA-JUNOS/DC/DEVOPS/SEC, JNCIS-ENT/SP, JNCIP-ENT) hasn't been that bad.  I am studying right now for the JNCIP-DC (let's see how that goes next week) and that has the most new stuff for me.  Having a strong route/switch background from Cisco helped to prepare me with really only learning the nuances of how to program their devices.

Now on to the fun stuff. I know that no matter the path, I have to learn and make sure that I have routing protocols down like a champ.  That is where I will start.  I won't be writing every day.  I will try every week though to talk about some new thing that I did that week in a protocol.  

To do this I will be using EVE-NG Pro with vMX, vEX, and vQFX images. I have also loaded Apstra and Junos Space on their so that I can do either way on that one.  

This is just my way of making sure that I hold myself accountable to all my studying.  

11 October 2014

Security or Stopping Users from Wasting Time and Money


Security is one of the things that first brought me into IT.  It is just one of those fun and awesome topics.  I also liked it because there is always someone smarter than you out there and you have to stay on top of your game.  I went with R&S for my CCIE because it was just what I was doing at the time.  Security is something I will be looking at later on.  And on to the fun we go.

What I am gathering is that if you have the if-authenticated method for an authorization AAA policy and that method is used, the policy will assign the privilege that is located in the line configuration.  In other words, if you have privilege level 15 in the line configuration and if-authenticated is the method used by exec, the user will get level 15 privileges.  This can be used as a backup for TACACS too which could be a possibility on the test.

When configuring the command privilege <mode> level <#> <command>, be specific with the commands allowed.  If all commands are allowed for a specific subset, include the keyword all.  To include all the ip commands under the interface mode, use privilege interface all level 4 ip.  Also when using those commands with AAA, include the commands aaa authorization exec <method> local and under the line configuration authorization exec <method>.

I always seem to forget this and I don't know why.  To allow path MTU discovery to work, you have to allow icmp packet-too-big in and/or out.  Since traceroute sends 30 probes by default, you can set an ACL for tracoute from UDP port 33434 to 33464.  You can add in a couple of extras if need be.  The replies will either be ICMP time-excceded or ICMP port-unreachable.

Using PBR to match packets to route to Null0 is a good idea it seems.  But say you want to keep unreachable messages from getting back out.  You can add the no ip unreachables to the null interface and this will block them just as if it was a regular interface.

And here I thought that for uRPF you had to create an ACL for the addresses to block automatically.  Got that wrong.  The ACL is checked only for packets that violate RPF.  If the ACL has a permit for a violation, then the packet still goes on through.  If you add the internal subnets, you can potentially allow in spoofed traffic which is what you are really trying to avoid.

Holy Crap.  I just spent a lot of time on how to use NBAR for Content-Based Matching thinking that I was looking for some security feature.  All they want to know is can you turn on NBAR in a class-map.  I did that in the QoS section  but sure.  Let's do it again.  Frustrated not at the task but that I wasted all that time.  Well, wasted is the wrong word.  Used it in a different learning environment.

Didn't know that.  Hmm...  NBAR will classify traffic independent of the way the policy-map is set up.  It applies to both directions of the flow.  So you can apply the policy-map looking out and still catch everything coming in

The command ip access-list log-update threshold is for saying how often a packet is logged.  The command ip access-list logging interval tells the device how often to kick a packet up to be process switched.  Making that a low number and the log-update threshold higher can reduce the load on the device.  This doesn't take into consideration packets heading to the router since they are process switched anyway.

VLAN filters are ingress only.  To do outbound, you can do an access-list on an SVI.  Think of them also as route-maps in structure that then are applied to VLANs.  They also not only hit transit traffic but anything generated locally on the device as well.  And finally, always re-apply the vlan filter after making a change.  They are not dynamic and more static in nature.  After upgrading my IOL Layer 2 images, I finally got one that didn't crash.  Problem is that the previous image and this one does NOT have vlan filters.  Just awesome.

Protocol numbers for MAC access-lists suck.  After some digging, I think that I found some.
ARP - 0x806
STP - lsap 0x4242 and 0x010b
VTP - 0x2003
CDP - 0x2000
DTP - 0x2004
UDLD - 0x0111

When setting the maximum number of mac-addresses on a trunk port per VLAN, include the maximum number as well.  The VLAN portion will allow that number per VLAN but if you allow 2 addresses in, since the default maximum for the port is 1, it won't work.

Using port-security on a port connected to a device with HSRP can lead to violations unless one of two things is corrected.  One can be to increase the allowed MAC addresses to 2 to account for the extra MAC.  The other is to issue the standby use-bia address on the HSRP device.  This causes HSRP to use the burned in address for the HSRP MAC instead of the dynamically generated one.

The command ip dhcp snooping trust is applied to ports that connect to either DHCP servers or other switches (uplinks).  This command also has to be on any port where a DHCP packet is received with a non-zero "giaddr".  It also causes messages received on the configured upon port to not create entries in the DHCP Snooping binding database.  Also to make an IOS DHCP server take in an all zero giaddr packets, use one of three options:
1) at the global level, use ip dhcp relay information trust-all
2) at the interface level, use ip dhcp relay information trusted
3) configure the DHCP snooper with no ip dhcp snooping information option to not insert Option 82
There is the other option of trusting where the information came from on the snooper but that doesn't really help anything on ports attached to clients.

By default a switch that is snooping will not accept DHCP packets with Option 82 coming into untrusted ports.  This can be changed with the command ip dhcp snooping information option allow-untrusted.  It still rejects packets with a giaddr of 0.  Fix this by trusting ports where that comes in to the switch.

Dynamic ARP Inspection (DAI) looks at ARP packets received on untrusted ports, which by default is all of them.  It allows the packet if it matches what is in the ARP inspection table.  While good for preventing some attacks, ARP poisoning, it can break other things, like PROXY ARP.  To trust a port, use the interface command ip arp inspection trust.  You can also configure DAI to validate source and destination MACs in ARP packets and/or validate the IP, which seems to make sure that 255.255.255.255 or 0.0.0.0 are not bound.  By default, DAI uses the DHCP bindings tables to build mapping information.  For those that use static IPs, you have to use an ARP access-list.  This list is checked first, followed by the DHCP table.  This behaviour can be changed with an explicit deny on the end of the table.  To do logging with DAI, you need to have the log keyword in the ACL and turn logging on with ip arp inspection vlan <VLAN_ID> logging acl-match <matchlog|none>.  You can also log probes and DHCP bindings.

Oh, great.  Another layer 2 security feature that throws me.  IP source guard helps to beat MitM attacks by applying a layer 3 filter to configured ports.  It is dependent upon having DHCP snooping enabled first.  Once you enable it, only packets that match the DHCP snooping database or static IP/MAC assignments are allowed.  DHCP packets are allowed so that clients can get layer 3 addresses.  It can also be combined with DAI.  When you configure IP source guard with the port-security option, you have to also have port-security enabled.  If you configure IP source guard on a trunk port, you have to have DHCP snooping trust on that port too.

Interesting.  ACLs applied to switch interfaces can only be applied to traffic coming in.  It cannot be applied to traffic leaving the interface.  Now on SVI interfaces, you can do both.  Maybe that is why they are SVI, they swing both ways.  Swinging Virtual Interfaces.

Messed that up.  Was setting up a user to be able to telnet into a router and then only allow them out to a specific router.  Instead what I did was limit all users.  I needed the access-class option for the username.  Well, shoot.

Beautiful.  The commands login on-failure and login on-success are not in the master command guide.  Just wonderful.  Luckily the commands are not that hard to figure out.

Setting up views can be great to limit commands and setting them up isn't so bad.  Just have to remember to do some initial things.  One is to enable aaa new-model.  Two is to have an enable password.  Three is for interfaces, you not only need to include the command for the interface you are allowing the view into but also to include the interface command.  Not that hard after all that.

The command ip icmp rate-limit is not in the Security section.  It is in the IP Application Services section.  It is basically saying send an unreachable every so many milliseconds.  If you use the df keyword, it specifies the number to send for each packet with the df bit set.  All others fall under the rate with the non-df bit set.

When setting up control plane policing and you need to match ARP, you can do match protocol arp.  Other NBAR matching doesn't work.  Also in the policy map, there are only two options available for the traffic: drop and police.  Police also allows the use of the rate keyword which comes in handy for limiting inbound and outbound traffic.  But that is only one option. You can still police by speed.  The configuration guide of this is under QoS and again, not under the security section.  I believe this is because of the MQC being used.

You can silently drop all packets with IP options using the command ip options drop.  If you want some, then use ACLs.  Packets with IP options are process-switched on a router and increase the proc load on the router.

19 September 2014

Quirky Operational Situations or QoS

 QoS is something that I never had to deal with in a work environment.  The only time I ever have to deal with it is on the tests.  Makes it something interesting to do.  Honestly, though, it really ain't so bad on the routers.  Switch QoS is something that is a little different.

Order is important in a policy-map.  It applies from the top down.  Screw the order up and you can mess up what was intended.  A class that matches TCP before a class matching HTTP will never get to the HTTP class.

A lot of tasks for INE and iPexpert (v4) seem to want to try to transfer images from one device to another.  Good idea for testing to make sure that HTTP, FTP, ACLs, QoS, etc, is working.  Problem is in GNS3, it is hard to do that.  I just fire up SLA and run it.  May not be the best for some aspects of testing but it works.  It won't flood a link but it at least will match HTTP traffic.  Commands that I use are
ip sla 1
 tcp-connect 155.1.146.1 80
 threshold 1000
 timeout 1000
 frequency 1
ip sla schedule 1 life forever start-time now

To limit the size of the FIFO queues for traffic classes, use the queue-limit command.  Starting in 15.2(2)T, the default for this was packets.  In other words, a queue-limit 24 would mean that the queue had a size of 24 packets.  This command can be used for queue sizes in other queuing methods as seen in a minute. 

Turning on WFQ for the class-default class is done through the fair-queue command under that class in the policy map.  Once turned on, you can modify the queue sizes with the queue-limit command. 

Nested service policies have always gotten me and I don't know why.  I can do nested loops in programming.  Anyways, say you want to make the overall bandwidth of an interface to be shaped to a specific number and also for the classes to have certain attributes as well. What what you do is create a parent policy that only has class-default as a class, apply the shaping to it, and then use the service-policy command to apply a child policy that has your classes broken out in it.  Not really that hard and yet I still screw it up every time.  Cisco only allows up to three policy maps to be in a nest.  Say you shape with the first one (all traffic), shape even more for the second (TCP traffic), and the third is super specific (HTTP).

As soon as the bandwidth command is given under a class in a policy map, CBWFQ is used.  Each bandwidth commands means that that class-map has a FIFO queue attached to it as well.  If you configure a bandwidth command under the default class, you turn off fair-queuing.  This turns it into a single FIFO queue.  If all you have is class-default and you do a bandwidth statement, you have turned the entire interface into a FIFO queue.

If you try to mix bandwidth and bandwidth percent in the same policy-map, it won't work.  All units must be the same across all the classes.  Didn't do this, but figured that it was was still a good thing to know. 

When coming up with a LLQ policy, you need to always remember your Layer 2 overhead.  LLQ accounts for that and can screw you up if you forget it.

A task was asking for dropping of packets using random-detect.  I figured out how to get it on, but as for actually getting the dropping working, I didn't get that.  Solution was to use random-detect precedence, which now makes sense.  With random-detect precedence, you tell it what precedence, the minimum and maximum thresholds and the probability.  But the question I had was how do you know the precedence to filter on and only get the packets you want?  Another portion of this task was to mark all packets of a certain type with IP precedence 2.  I took that to mean as they left the interface.  They did it as the packets moved in to the ingress interface and then did random-detect on the egress.  Sneaky.

CBWFQ has three main drop policies
1) Tail-drop
    -- default for user-defined classes
2) Congestive Discard for WFQ
3) Random Early Detection (RED)

To enable random drops on unclassified traffic, the configuration seems to need fair-queue to be enabled in the policy.  Do that and then enable random-detect  also. 

When doing RED with ECN, you may need to enable TCP ECN.  Do this with ip tcp ecn.  And of course, that command doesn't seem to be available in 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S3.  Awesome. 

Fun times configuring CIR and Bc values.  Bc stands for Burst Committed.  CIR is Committed Information Rate.  AR is Access Rate (line speed).  Tc is Time Committed.  Shapers send packets every Tc milliseconds, essentially separating them by Tc time periods.  Tc cannot be configured manually on a device but you can use it come up with CIR and Bc.  Bc = CIR * (Tc/1000) which means that the Bc is equal to the CIR times the Tc in seconds.  The lower the Tc the more the processor will work.  There is also Excess Burst (Be) which comes into play.  The maximum Be value is equal to the AR minus the CIR all multiplied by the Tc in seconds or maxBe = (AR - CIR) * (Tc/1000). 

Single-Rate Three Color Marker (srTCM) is a system that has always boggled my mind.  Think I am starting to understand it now.  For every 1/CIR milliseconds a token is put into the bucket.  The space between those tokens is Ti ms.  The size of the bucket is Bc.  Excess tokens that are not used are transferred to the excess bucket for size Be.  I am thinking that a token is the amount of information that can be send in Tc.  So when a packet comes in that is size X, it is checked first against the Bc bucket.  If it is less than or equal to the amount of tokens it is marked with the conform action and the Bc bucket is deducted the size of the packet.  If it is less than or equal to the Be bucket, then it is marked with the exceed action and the Be bucket is deducted the size of the packet.  Finally, it's marked with the violate action if it fails the others. 

To account for the sliding window content correctly, it is better to set the policer Bc to the shaper burst size plus the average packet size.  This will also give you a little wiggle room.

Two-Rate Three Color Marker (trTCM) uses two different buckets that fill with tokens based on the time intervals configured with Bc and Be.  One is for the CIR and the other is for the Peak Information Rate (PIR).  There are still three possible outcomes like with srTCM.  If the packet is greater than the tokens in the PIR bucket is violates.  If the packet is greater than the tokens in the CIR bucket, it exceeds and the PIR bucket is docked the size of the packet.  Finally, if the other two are are not met, the packet conforms and the PIR and CIR buckets are docked the size of the packet.  Cool.  Think I am getting this now.

QoS pre-classify can only be done on tunnel interfaces, virtual templates, and crypto maps.  The command is unavailable on any other interface types.  It can only be enabled for IP packets as well.  This command allows the IOS to apply QoS before the data is encrypted and tunneled.  Without this, the interface that has the service-policy applied to it will treat the tunnel as one flow and not respective flows.  This command will cause the router to see the header before being put in a tunnel and then use that header for matching class-maps.  Class-based traffic shaping doesn't work for DMVPN, so it looks like qos pre-classify is the way to go.