Interface on Aaron's Worthless Words

Junos - Logical Tunnel Interfaces with Virtual Routers

Sat, 02 Mar 2013 00:00:00 +0000

There are a few ways to leak routes in and out of virtual routers in Junos. On the list is a cool feature called the logical tunnel interface.

So, what am I talking about? One way to separate traffic on a router is to use virtual routers (VRs) so that you wind up with multiple routing tables on the same router. This separate traffic, but you will usually (read: always) have a demand to get traffic from one VR to another. There are a few different way to do that (see rib-group, instance-import, next-table, et al.), but one really cool way to do it is through logical tunnel interfaces.

Some Exercises with IPv6 ACLs

Fri, 15 Apr 2011 00:00:00 +0000

ACLs in IPv6 aren’t that different from what you’re used to dealing with in the IPv4 world. You create a list of denies and permits for use with some other structure like filtering, PBR, and all sorts of other stuff. Let’s take a look at building an ACL and filtering traffic with it.

For those playing at home, here’s the setup I used to generate the configs and get the output. Execute some click action for the whole thing.

Stubby Post - What's an IDB?

Fri, 03 Sep 2010 00:00:00 +0000

I posed the philosophical question on Twitter the other day asking if single trunk links should be in an EtherChannel bundle just in case you need to expand later. I didn’t really expect an answer, but the ever-verbose @WannabeCCIE pointed out (in not so many words) that you should watch your IDBs. What is that?

That’s an interface descriptor block. I admit that I’m not intimately familiar with them, bu they’re data structs in IOS used to keep track of the interfaces on that device. They come in two flavors - hardware and software. HWIDBs usually represent a physical interface but they also represent tunnels, SVIs, PortChannels, subinterfaces, and any other virtual interface that you can configure. The SWIDBs represent the layer-2 encapsulation of each HWIDB, so you’ll see entries talking about Ethernet, HDLC, PPP, etc. That means that every interface you have on a router consumes two IDBs (there are always exceptions). That’s important because each platform and IOS version combination has a limit to the number IDBs that device supports.

ONT Notes - AutoQoS

Wed, 10 Feb 2010 00:00:00 +0000

AutoQoS benefits
- Automates QoS for most deployments
- Protects business-critical apps to maximize availability
- Simplifies QoS deployments
- Reduces configuration errors
- Cheaper, faster, and simpler deployments
- Follows DiffServ
- Allows complete control over QoS configs
- Allows modification of auto-generated configs
AutoQoS phases of evolution
- AutoQoS VOIP - Early version that configures the basics without discovery
- AutoQoS for Enterprise - Second version that only runs on routers and uses two-step process
  - Autodiscovery using NBAR
  - Generation of class maps
AutoQoS key elements
- Application classification
- Policy generation
- Configuration
- Monitoring and reporting
- Consistency
Interfaces that you can configure AutoQoS on
- Serial ifs with PPP and HDLC
- FR point-to-point subifs (NOT multipoint)
- ATM point-to-point subifs
- FR-to-ATM links
Prerequsites
- No Qos policy already configured on if
- CEF enabled on if
- Correct bandwidth configured on if
- IP address on low-speed if
Configuring AutoQoS Enterprise on a router (NOT a switch)
- auto qos discovery - begins discovery process
- auto qos - generates and applies MQC-based policies
Configuring AutoQoS VOIP
- auto qos voip [ trust | cisco-phone ]
Verifying AutoQoS on router
- show auto discovery qos - get autodiscovery results
- show auto qos - examine configuration generated
  - Number of classes
  - Classification options
  - Marking options
  - Queuing mechanisms
  - Other QoS mechanisms
  - If, subif, PVC where policy is applied
- show policy-map interface - look at if stats
Verify AutoQoS VOIP
- show auto qos
- show policy-map interface
- show mls qos maps - shows CoS to DSCP mappings
Possible issues with AutoQoS
- Too many traffic classes - manually consolidate some
- Configuration doesn’t change - rerun AutoQoS
- Configuration may not fit your situation - fine-tune it by hand
Fine-tuning AutoQoS
- Use QPM
- CLI
- copy policy into editor, change, reapply
AutoQoS can match on characteristics besides ACLs and NBAR
- match input interface
- match cos
- match ip precedence
- match ip dscp
- match ip rtp

ONT Notes - Pre-classify and End-to-end QoS

Thu, 04 Feb 2010 00:00:00 +0000

VPNs (Didn’t ISCW cover this?)
- Provide
  - Confidentiality
  - Integrity
  - Authentication
- Types
  - Remote-access
    - Client-initiated
    - NAS-initiated
  - Site-to-site
    - LAN-to-LAN
    - Extranet
L3 Tunneling protocols
- GRE
- IPSec
Pre-classify allows traffic to be classified before being sent across a tunnel or crypto-ed.
- qos pre-classify
- Provides a view into the original IP headers
- To classify on pre-tunnel header, apply the policy to the tunnel interface WITHOUT pre-classify.
- To classify on post-tunnel header, apply the policy to the physical interface WITHOUT pre-classify.
- To classify on pre-tunnel header, apply the policy to the physical interface WITH pre-classify.
SLA - agreement with provider to guarantee QoS mechanisms across their network based on your markings.
- Assures availability, loss, throughput, delay, and jitter.
End-to-end QoS
- To be effective, each hop in the path must have QoS configured similarly.
- Necessary in three locations
  - Campus - within the customer network
  - The edges - customer facing the provider, provider facing customer
  - On the provider network
QoS tasks
- Campus access switches
  - Speed/duplex settings
  - Classification
  - Trust
  - Phone/access switch configs
  - Multiple queues on switch ports, including priority for VOIP
- Campus distribution
  - L3 policing and marking
  - Multiple queues on switch ports, including priority for VOIP
  - WRED
- WAN edge
  - SLA definitions
  - LLQ
  - LFI
  - WRED
  - Shaping
- Provider cloud
  - Capacity planning
  - PHB
  - LLQ
  - WRED
Enterprise campus QoS implementation
- Implement multiple queues to avoid congestion
- Assign VOIP and video to highest priority queue
- Esablish trust boundaries
- Use policing to rate-limit excess traffic
- Use hardware QoS when possible
Control Plane Policing (CoPP)
- Applies QoS policy to traffic destined for the router
  - Routing protocols
  - Management protocols
- Can be used to avoid DOS attacks
- Applied to control-plane in global config