Archive for the ‘interface’ tag
Junos – Logical Tunnel Interfaces with Virtual Routers
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.
The logical tunnel (lt-0/0/0) interface is a special little guy that allows you to connect its units to each other. The result is similar to connecting an Ethernet cable from one physical interface to another. With a little configuration, these guys provide a point-to-point interface that you can include in your routing setup. Let’s look at an example.
set interfaces lt-0/0/0 unit 100 encapsulation ethernet set interfaces lt-0/0/0 unit 100 peer-unit 200 set interfaces lt-0/0/0 unit 100 family inet address 192.168.0.100/24 set interfaces lt-0/0/0 unit 200 encapsulation ethernet set interfaces lt-0/0/0 unit 200 peer-unit 100 set interfaces lt-0/0/0 unit 200 family inet address 192.168.0.200/24
The encapsulation lines are pretty straightforward. In this case, I want the link to appear as an Ethernet interface, but you can choose frame-relay, vlan, bridging, and others.
The peer unit lines tell what unit is connected to what other unit. Each lt-0/0/0 unit is a point-to-point link, so you have to tell the router what’s on the other end of the link (sorry…no multiaccess here). In this case, I want unit 100 to connect to unit 200, so I configure both units with the appropriate peer unit.
Of course, we can all figure out that we’re using IPv4 on these new units as well. In this case, I’ve put both interfaces on the 192.168.0.0/24 network (how original!).
Now that we have our interfaces configured, we need to put these interfaces into the correct VR. Don’t forget the security zone, too, if you’re running in flow mode. That’s beyond the scope here, though.
set routing-instances VR100 instance-type virtual-router set routing-instances VR100 interface lt-0/0/0.100 set routing-instances VR100 interface lo0.100 set routing-instances VR200 instance-type virtual-router set routing-instances VR200 interface lt-0/0/0.200 set routing-instances VR200 interface lo0.200
I put lo0.100 and lo0.200 in there to have something to advertise. You’ll see that in a second.
Now, let’s see if we can ping across.
root@TestSRX# run ping 192.168.0.100 routing-instance VR200 PING 192.168.0.100 (192.168.0.100): 56 data bytes 64 bytes from 192.168.0.100: icmp_seq=0 ttl=64 time=1.879 ms 64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=3.480 ms <SNIP>
Woot! It works. Now we can treat these new interaces as if they are regular ole Ethernet. Since I’m not ready to try and blog about IS-IS, let’s just use the standard OSPF. I’m not going to go through the steps to configure OSPF, but here’s the routing table after all the interfaces are included.
root@TestSRX# run show route
VR100.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[Direct/0] 00:41:33
> via lo0.100
10.0.0.200/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.200 via lt-0/0/0.100
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.100
192.168.0.100/32 *[Local/0] 00:38:21
Local via lt-0/0/0.100
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
VR200.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.100/32 *[OSPF/10] 00:00:28, metric 1
> to 192.168.0.100 via lt-0/0/0.200
10.0.0.200/32 *[Direct/0] 00:41:33
> via lo0.200
192.168.0.0/24 *[Direct/0] 00:38:21
> via lt-0/0/0.200
192.168.0.200/32 *[Local/0] 00:38:21
Local via lt-0/0/0.200
224.0.0.5/32 *[OSPF/10] 00:01:18, metric 1
MultiRecv
Look! OSPF routes! Sweet. Just to keep my OCD at bay, let’s ping from the loopback of one VR to the loopback of the other.
root@TestSRX# ping source 10.0.0.100 routing-instance VR100 10.0.0.200 PING 10.0.0.200 (10.0.0.200): 56 data bytes 64 bytes from 10.0.0.200: icmp_seq=0 ttl=64 time=1.463 ms 64 bytes from 10.0.0.200: icmp_seq=1 ttl=64 time=1.443 ms <SNIP>
Well, look at that. It works again.
Let’s look back at the topic we’re discussing, though. If we use OSPF between the VRs, we need to make sure our routing design allows us to filter routes between the VRs; the risk is that you may wind up having all the routes from each VR advertised to the other. Kind of defeats the purpose, eh? Running BGP between the VRs might be an option that allows you to control what routes go in and out. Statics might be the answer, as well. As long as you can filter the advertisements, you wind up with a pretty elegant solution for sharing routes between VRs.
Send any Marshmallow Peeps questions my way.
Some Exercises with IPv6 ACLs
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.
The first thing you need to know is that all IPv6 ACLs are extended and named. There’s no concept of numbering and using standard list types that include the destination only. This is a good thing in my opinion, and I’ve been doing that in my IPv4 ACLs for many years now. This allows (forces?) you to use descriptive names and very specific entries. Sometimes my entries are too specific, but that’s usually because people don’t include all the requirements. I digress.
Creating an IPv6 ACL is so similar to the way you do it IPV4 that I don’t even want to mention it. I’ll just give an example that we’ll use in a second. As usual, we’re using IOS on Cisco devices.
ipv6 access-list TRANSIT-ACL permit tcp host 2001:DB8:0:1::2 host 2001:DB8::1 eq telnet deny ipv6 any any log
No numbers or ACL types means the config is a lot simpler and cleaner. You can see that TRANSIT-ACL is allowing telnet from 2001:db8:0:1::2 to 2001:db8::1 and denying everything else. Of course, it’s also logging the denies to syslog so we know what’s going on. This shouldn’t be foreign to you at all. Note: This is a lab, and we’re just allowing telnet as a demonstration. You should always yell at people who try to use telnet and show them how to use SSH. Just sayin’.
On a tangent, I just realized that I actually typed deny any any log in the last line, and the router took it to mean all IPv6. Cool.
At some point, you’ll want to see what kind of matches you’re getting on the ACL. You can do a show ipv6 access-list or just a show access-list to see them. Of course, if you have any IPv4 ACLs configured, those will be included in the latter, bu the output of each is the same in relation to IPv6.
R2#show access-lists
IPv6 access list TRANSIT-ACL
permit tcp host 2001:DB8:0:1::2 host 2001:DB8::1 eq telnet (24 matches) sequence 10
deny ipv6 any any log (19 matches) sequence 20
Here you can see the entries of each ACL and see that this ACL has already been applied somewhere since it has hits. The obvious difference between the output here and that from an IPv4 ACL is the sequence number. In the IPv4 world, the sequence will come before the function (10 permit tcp …). Here, it comes afterwards. I’m not yet sure if this is better or not. I’ll reserve judgement when I get some more experience with it.
If you’ve done ACLs a lot, you can probably tell that this ACL was meant for filtering traffic on an interface. Let’s apply it to F0/1 to do such.
interface FastEthernet0/1 no ip address ipv6 address 2001:DB8:0:1::1/64 ipv6 traffic-filter TRANSIT-ACL in
Make note that we use the traffic-filter directive on the interface along with the ACL name and the direction. Simple stuff.
There is a problem here, though. If you remember your extensive IPv6 training, you know that we no longer have the concept of ARP to map layer-3 addresses to layer-2 addresses. To find layer-2 neighbors, IPv6 devices use neighbor discovery (ND), which itself uses ICMPv6, to look for connected devices. Since ICMPv6 is a layer-3 protocol like IP, when you apply this ACL as indicated, you’ll not find any new neighbors on F0/1. If a new router has a route to 2001:db8:0:1::1, there’s no way to discover the layer-2 address, and I’ll let you guess how that works out. Not very well. The fix is just to allow ICMPv6 into the interface; the details of that will run away very quickly, so I’ll save it for later.
When one device sends ND packets, it uses it’s link local address as the source and the multicast address of FF01::1 (the all routers group) as the destination. You can see that in the log from before we fixed our neighbor problem.
*Mar 1 01:10:07.735: %IPV6-6-ACCESSLOGDP: list TRANSIT-ACL/20 denied icmpv6 FE80::C002:15FF:FE58:0 -> FF02::1 (134/0), 2 packets R2# *Mar 1 01:15:07.739: %IPV6-6-ACCESSLOGDP: list TRANSIT-ACL/20 denied icmpv6 FE80::C002:15FF:FE58:0 -> FF02::1 (134/0), 2 packets R2# *Mar 1 01:21:07.735: %IPV6-6-ACCESSLOGDP: list TRANSIT-ACL/20 denied icmpv6 FE80::C002:15FF:FE58:0 -> FF02::1 (134/0), 1 packet
This look pretty standard, but you can see that the message content includes the ACL name followed by the sequence number. Now you can see exactly which entry is denying the traffic instead of having to go through the whole 8482482-line ACL to see what happened. I’m digging that a lot.
Make sure you check out Packetlife’s post on IPv6 ACLs as well. As always, there’s good stuff going on there.
Send any Cadbury Creme Eggs questions to me.
Stubby Post – What’s an IDB?
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.
If you check out one of Cisco’s pages on IDBs, you’ll see a pretty table showing the limits. The 3640 running 12.4(25b) that I run in my GNS3 lab has a limit of 800 IDBs. That means that I can have 400 interfaces configured at most. That little 800 series router running 12.1T that you still have running at the VP’s house has an IDB limit of 300 or 150 interfaces. The 7200 in the data center running 12.3 can handle 20,000 IDBS or 10,000 interfaces!
If you guessed that you can see your IDBs by typing show idb, then you guessed right. That will show you the IDB limit, how many are being used, a summary table, and a list of all the IDBs with their details. Remember that there may be more interfaces on your device that just physical. You may have an SVI, loopback interface, or even a null or two. These all count towards the limit.
Before you get freaked out and start checking the IDB limits on all your devices, take a breath. I’ve never run into the IDB limit on any device and I’ve never heard of anyone who has. I’m sure someone has, but I don’t remember hearing about any. Think about it for a second. If I took my 3640 and filled it with 4 NM-16ESWs, I’d only have 128 IDBs used (16 ports * 4 modules * 2 IDBs for each port). Don’t forget the null interface and VLAN 1 SVI by default (VLANs take 1; VLAN SVIs take 2 each). That brings the count to 133. Let’s add 100 more VLANs and SVIs on this guy. Now we’re up to 433. How about we put each interface into a channel group of its own. That adds another 128, which is 561. Only 239 more to go.
Unless you’re doing something out of the ordinary, I don’t think the IDB limit will be a problem. Of course, that depends on your definition of “ordinary”.
Send any sort indexes questions my way.
ONT Notes – AutoQoS
- 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
- VPNs (Didn’t ISCW cover this?)
- Provide
- Confidentiality
- Integrity
- Authentication
- Types
- Remote-access
- Client-initiated
- NAS-initiated
- Site-to-site
- LAN-to-LAN
- Extranet
- Remote-access
- Provide
- 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
- Campus access switches
- 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
- Applies QoS policy to traffic destined for the router