CCIE Blog

Hi Brian,

Can we use NBAR on the gateway router to prevent internal users from watching video streams from any video web site (like Youtube.com)?

Ahmed

Hi Ahmed,

Yes, NBAR can be used to apply application based filters such as blocking youtube.com traffic. To accomplish this we can categorize traffic based on the HTTP hostname. Next we will create a policy-map that matches the youtube.com class and drops the traffic. Lastly the policy is applied outbound to the Internet. Syntax-wise this would read:

R1#
class-map match-all YOUTUBE
 match protocol http host "*youtube.com*"
!
policy-map DROP_YOUTUBE
 class YOUTUBE
   drop
!
interface FastEthernet0/0
 description TO INTERNET
 service-policy output DROP_YOUTUBE

NBAR for HTTP can also be used to match based on URL string or IANA MIME type. For more information see:

Network-Based Application Recognition and Distributed Network-Based Application Recognition

Cisco IOS has a special feature called local policy routing, which permits to apply a route-map to local (router-generated) traffic. The first way we can use this feature is to re-circulate local traffic (and force it re-enter the router). Here’s an example. By default, locally-generated packets are not inspected by outgoing access-lists. This may cause issues when local traffic is not being reflected under relfexive access-list entries. Say with configuration like that:

!
! Reflect all "session-oriented" traffic
!
ip access-list extended EGRESS
 permit tcp any any reflect MIRROR
 permit icmp any any reflect MIRROR
 permit udp any any reflect MIRROR
!
! Evalute the reflected entries
!
ip access-list extended INGRESS
 evaluate MIRROR
 permit ospf any any
!
interface Serial 0/0
 ip address 54.1.1.6 255.255.255.0
 ip access-group INGRESS in
 ip access-group EGRESS out

You would not be able to telnet out of a router to destinations behind the Serial interface, even though TCP sessions are reflected in access-list. To fix the issue, we may use local-policy to force the local traffic re-enter the router and be inspected by outgoing access-list:

!
! Redirect local telnet traffic via the Loopback interface
!
ip access-list extended LOCAL_TRAFFIC
 permit tcp any any eq 23
!
route-map LOCAL_POLICY 10
 match ip address LOCAL_TRAFFIC
 set interface Loopback0
!
! Traffic sent to Loopback interface re-enters the router
!
interface Loopback0
 ip address 150.1.6.6 255.255.255.50

!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY

With this configuration, local telnet session will re-enter the router and hit the outgoing access-list, thereby triggering a reflected entry. This same idea may be utilized to force CBAC inspection of locally-generated traffic, by since 12.3T there has been a special IOS feature to do this natively.

The other useful application of local policy routing is using it for traffic filtering. For example you may want to prohibit outgoing telnet sessions from local router to a certain destination:

ip access-list extended BLOCK_TELNET
 permit tcp any host 150.1.1.1 eq 23
!
route-map LOCAL_POLICY 10
 match ip address BLOCK_TELNET
 set interface Null 0

!
! Apply the local-policy
!
ip local policy route-map LOCAL_POLICY

The syntax is somewhat similar to the vlan access-maps used on Catalyst switches, and similarly the route-map is applied “globally”, i.e. to all router traffic, going out on any interface. Note that you may use the same idea to block incoming session, simply by reversing entries in access-list. (e.g. “permit tcp any eq 23 host 150.1.1.1″). Best of all, with PBR you may apply additional criteria to incoming traffic, e.g. match packet sizes.

The last example is the use of local PBR to apply special treatment to management/control plane traffic - e.g. use different output interfaces for out-of-band management. With local PBR you may also apply special marking for control traffic, e.g. selectively assign IP precedence values.

ip access-list extended MANAGEMENT_TRAFFIC
 permit tcp any eq 23 any
 permit tcp any eq 22 any
!
route-map LOCAL_POLICY 10
 match ip address MANAGEMENT_TRAFFIC
 set interface Serial 0/1
 set ip precedence 7
!
ip local policy route-map LOCAL_POLICY

Keep these simple features in mind, while considering options for you CCIE lab task solution.

Hi Brian,

I’ve heard that items in a numbered ACL can be deleted without taking down the entire ACL. Is it true and how?

In newer IOS versions sequence numbers can be used to quickly edit, add, and remove entries from a named extended access-list. However in all IOS versions that support named extended access-lists, numbered extended access-lists can actually be treated like named lists where their name is the number. Without sequence numbers you can’t add or edit lines, but if you need to remove a single line from somewhere in the list without deleting it you can. Take the following example:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 100 permit tcp any any
R1(config)#access-list 100 permit udp any any
R1(config)#access-list 100 permit ospf any any
R1(config)#access-list 100 permit eigrp any any
R1(config)#do show access-list 100
Extended IP access list 100
    permit tcp any any
    permit udp any any
    permit ospf any any
    permit eigrp any any

Now let’s suppose that we want to remove the second line that permits udp. Normally we would have to say “no access-list 100″, then recreate the list without line number two. However by treating this like a named access-list we have a second option:

R1(config)#ip access-list extended 100
R1(config-ext-nacl)#no permit udp any any
R1(config-ext-nacl)#end

R1#show access-list 100
Extended IP access list 100
    permit tcp any any
    permit ospf any any
    permit eigrp any any

Tada! The list stays intact but the second line has been removed.

First off we need to understand that traceroute is a technique to have the routers between the source and destination reveal themselves and finally have the destination reveal itself. Traceroute can be implemented using ICMP, UDP, and even TCP so as a CCIE when someone asks you to filter “traceroute” you should get a little background as to the traceroute application/OS’s being used to trigger the reply from the destination. Example: Windows uses ICMP echoes by default, most Linux OS’s use UDP by default but can use ICMP echoes (-I option), and the IOS uses UDP. There are also implementations that use TCP.

The goal of traceroute is to have the routers between the source and destination reveal themselves and finally have the destination reply so that you know you have reached it. The routers reveal themselves by sending Time Exceeded (aka TTL-Exceeded) ICMP packets back to the source when the TTL is decremented to zero. The traceroute implementation can determine its reached the destination by having it reply to an ICMP echo request, send an ICMP port unreachable to a packet sent to an unused UDP port, or completing the TCP three-way handshake.

************************************************************************

ICMP based traceroute:

In this example we are sending ICMP echo requests to www.cisco.com and looking for the ICMP echo reply to know that we have reached the final destination.

[root@digdug root]# traceroute -I www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte
packets
1 198.132.102.1 (198.132.102.1) 1.658 ms 1.975 ms 1.968 ms
2 foo.hostrack.net (202.101.143.254) 5.394 ms 22.382 ms 2.966 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 20.132 ms 20.494 ms 20.195 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 19.749 ms 25.827 ms 26.814 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 29.108 ms 19.864 ms 20.066 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 26.338 ms 26.232 ms 26.821 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 46.424 ms 45.996 ms 45.675 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.653 ms 46.513 ms 46.803 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 46.693 ms 46.619 ms 46.446 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 46.556 ms 46.954 ms 46.944 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 30.818 ms 31.769 ms 32.685 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 30.589 ms 30.626 ms 30.448 ms
13 * * *
14 www.cisco.com (198.133.219.25) 28.916 ms 28.994 ms 28.944 ms
************************************************************************

UDP based traceroute:
In this example we are sending UDP packets with a starting port number of 33434 to www.cisco.com. Note that we don’t ever get a reply from www.cisco.com because their firewall will not allow our UDP packets to arbitrary high ports in.

[root@digdug root]# man traceroute | grep “UDP port number”
-p Set the base UDP port number used in probes (default is 33434).
[root@digdug root]#
[root@digdug root]# traceroute www.cisco.com
traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets
1 198.132.102.1 (198.132.102.1) 1.725 ms 1.866 ms 1.841 ms
2 foo.hostrack.net (202.101.143.254) 4.887 ms 4.281 ms 4.482 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.266 ms 21.152 ms 20.826 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 58.829 ms 42.033 ms 24.007 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.448 ms 23.277 ms 21.446 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.816 ms 27.259 ms 27.210 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.540 ms 46.954 ms 47.198 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 48.072 ms 47.247 ms 46.667 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 51.728 ms 51.437 ms 48.304 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.563 ms 48.878 ms 47.807 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.562 ms 32.653 ms 31.318 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.327 ms 31.831 ms 31.516 ms
13 * * *
14 * * *

************************************************************************
TCP based traceroute:

In this example we are sending TCP SYN packets to port 80 looking for the destination to complete the three-way-handshake. Once the handshake
is complete we know that we have reached the destination. Obviously Cisco’s firewall is going to allow packets to TCP port 80 destined for it’s web server.

[root@digdug root]# tcptraceroute www.cisco.com
tcptraceroute: Symbol `pcap_version’ has different size in shared object, consider re-linking
Selected device eth3, address 198.132.102.93, port 41440 for outgoing packets
Tracing the path to www.cisco.com (198.133.219.25) on TCP port 80, 30 hops max
1 198.132.102.1 (198.132.102.1) 1.575 ms 1.507 ms 1.469 ms
2 foo.hostrack.net (202.101.143.254) 4.840 ms 5.090 ms 4.596 ms
3 ser4-0.core01.las.switchcommgroup.com (66.209.64.41) 21.205 ms 20.895 ms 21.430 ms
4 pos1-0.core02.las.oc48a.switchcommgroup.com (66.209.64.218) 21.682 ms 21.012 ms 21.059 ms
5 500.POS4-0.GW1.VEG2.alter.net (157.130.238.193) 21.185 ms 21.304 ms 20.939 ms
6 129.at-0-0-0.CL1.PHX2.ALTER.NET (152.63.115.26) 27.176 ms 28.615 ms 27.644 ms
7 0.so-4-0-0.XL1.SJC2.ALTER.NET (152.63.55.101) 47.659 ms 48.220 ms 47.667 ms
8 POS1-0.XR1.SJC2.ALTER.NET (152.63.56.138) 47.534 ms 48.483 ms 47.183 ms
9 193.ATM7-0.GW5.SJC2.ALTER.NET (152.63.48.77) 64.413 ms 51.058 ms 49.007 ms
10 ciscosys-gw1.customer.alter.net (65.208.80.242) 48.156 ms 49.197 ms 47.534 ms
11 sjce-dmzbb-gw1.cisco.com (128.107.239.89) 31.685 ms 32.633 ms32.895 ms
12 sjck-dmzdc-gw1.cisco.com (128.107.224.69) 32.291 ms 33.900 ms35.461 ms
13 www.cisco.com (198.133.219.25) [open] 31.041 ms 31.667 ms 32.775 ms
[root@digdug root]#

Access-list address and wildcard pair calculations are based
around the AND and XOR logic gates.

AND: The output is high only when both inputs A and B are high.

A AND B
______________
| A | B | out |
| 0 | 0 |  0  |
| 0 | 1 |  0  |
| 1 | 0 |  0  |
| 1 | 1 |  1  |
--------------

XOR: The output is high when either of inputs A or B is high, but not if
both A and B are high.

A XOR B
______________
| A | B | out |
| 0 | 0 |  0  |
| 0 | 1 |  1  |
| 1 | 0 |  1  |
| 1 | 1 |  0  |
--------------

To find the most specific address and wildcard pair that will
match two addresses, A and B, we use the gates AND and XOR. The address
we will check in the access-list is A AND B. The wildcard used to check
in this list will be A XOR B.

access-list 1 permit [address_to_check] [wildcard_used_to_check]

Take the following example:

We have two IP addresses, 10.20.30.40, and 40.30.20.10. How do we
create an access-list that is the most specific match for these two
addresses? First, write both addresses out in binary:

10.20.30.40 = 00001010.00010100.00011110.00101000
40.30.20.10 = 00101000.00011110.00010100.00001010

To find the address_to_check, take the logical AND of these addresses.

   00001010.00010100.00011110.00101000
&& 00101000.00011110.00010100.00001010
--------------------------------------
   00001000.00010100.00010100.00001000

This is our address_to_check: 8.20.20.8

To find the matching wildcard_used_to_check, we take the logical XOR of
these addresses.

    00001010.00010100.00011110.00101000
XOR 00101000.00011110.00010100.00001010
---------------------------------------
    00100010.00001010.00001010.00100010

This is our wildcard_used_to_check: 34.10.10.34

Therefore, the most specific match for both 10.20.30.40 and 40.30.20.10
would be:

access-list 1 permit 8.20.20.8 34.10.10.34

Here’s one more:

A = 1.2.3.4
B = 5.6.7.8

1.2.3.4 = 00000001.00000010.00000011.00000100
5.6.7.8 = 00000101.00000110.00000111.00001000

A && B  = 00000001.00000010.00000011.00000000
A XOR B = 00000100.00000100.00000100.00001100

Therefore the access-list would read:

access-list 1 permit 1.2.3.0 4.4.4.12