logo CCIE Blog

Helping you become a Cisco Certified Internetwork Expert


rss Entries (RSS) | rss Comments (RSS)
Welcome to Internetwork Expert's CCIE Blog

Welcome to Internetwork Expert’s CCIE Blog! This site is dedicated to helping you in your pursuit of becoming a Cisco Certified Internetwork Expert in Routing & Switching, Voice, Security, Service Provider, and Storage. Through this blog you can submit questions to our expert instructors, Brian Dennis - Quad-CCIE #2210, Brian McGahan – Triple CCIE #8593, and Petr Lapukhov - Quad-CCIE #16379. Check back daily as this blog will be updated frequently.

Click here to submit a question.

May 8th, 2008

Using NBAR for Application Filtering

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

February 13th, 2008

Tricks with Local Policy Routing

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.

January 31st, 2008

Understanding Private VLANs

Private VLAN concepts are quite simple, but Cisco’s implemenation and configuration steps are a bit confusing - with all the “mappings” and “associations” stuff. Here comes a short overview of how private VLANs work.

To begin with, let’s look at the concept of VLAN as a broadcast domain. What Private VLANs (PVANs) do, is split the domain into multiple isolated broadcast subdomains. It’s a simple nesting concept - VLANs inside a VLAN. As we know, Ethernet VLANs are not allowed to communicate directly, they need L3 device to forward packets between broadcast domains. The same concept applies to PVLANS - since the subdomains are isolated at level 2, they need to communicate using an upper level (L3 and packet forwarding) entity - such as router. However, there is difference here. Regular VLANs usually correspond to a single IP subnet. When we split VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, but they need to use router (another L3 device) to talk to each other (for example, by means of local Proxy ARP). In turn, router may either permit or forbid communications between sub-VLANs using access-lists.
Why would anyone need Private VLANs? Commonly, this kind of configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.

For our sample configuration, we will take VLAN 100 and divide it into two PVLANs - sub-VLANs 101 and 102. Take the regular VLAN and call it primary (VLAN 100 in our example), then divide ports, assigned to this VLAN, by their types:

Promiscuous (P): Usually connects to a router - a type of a port which is allowed to send and receive frames from any other port on the VLAN
Isolated (I): This type of port is only allowed to communicate with P-ports - they are “stub”. This type of ports usually connects to hosts
Community (C): Community ports are allowed to talk to their buddies, sharing the same group (of course they can talk to P-ports)

In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different port types. First comes the Primary VLAN - simply the original VLAN (VLAN 100 in our example). This type of VLAN is used to forward frames downstream from P-ports to all other port types (I and C ports). In essense, Primary VLAN entails all port in domain, but is only used to transport frames from router to hosts (P to I and C). Next comes Secondary VLANs, which correspond to Isolated and Community port groups. They are used to transport frames in the opposite direction - from I and C ports to P-port.

Isolated VLAN: forwards frames from I ports to P ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames uptstream to the P-ports of the primary VLAN.

This is how it works:

Primary VLANs is used to deliver frames downstream from router to all hosts; Isolated VLAN transports frames from stub hosts upstream to the router; Community VLANs allow frames exchange withing a single group and also forward frames in upstream direction towards P-port. All the basic MAC address learning and unknown unicast flooding princinples remain the same.

Let’s move to the configuration part (Primary VLAN 100, Isolated VLAN 101 and Community VLAN 102).

Step 1:

Create Primary and Secondary VLANs and group them into PVLAN domain:

!
! Creating VLANs: Primary, subject to subdivision
!
vlan 100
 private-vlan primary

!
! Isolated VLAN: Connects all stub hosts to router
!
vlan 101
 private-vlan isolated

!
! Community VLAN: allows a subVLAN within a Primary VLAN
!
vlan 102
 private-vlan community

!
!  Associating
!
vlan 100
 private-vlan assoc 101,102

What this step is needed for, is to group PVLANs into a domain and establish a formal association (for syntax checking and VLAN type verifications).

Step 2:

Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary.


!
! Isolated port (uses isoalated VLAN to talk to P-port)
!
interface FastEthernet x/y
 switchport mode private-vlan host
 switchport private-vlan host-association 100 101

!
! Community ports: use community VLAN
!
interface range FastEthernet x/y - z
 switchport mode private-vlan host
 switchport private-vlan host-association 100 102

Step 3:

Create a promiscuous port, and configure downstream mapping. Here we add secondary VLANs for which traffic is received by this P-port. Primary VLAN is used to send traffic downstream to all C/I ports as per their associations.

!
! Router port
!
interface FastEthernet x/y
 switchport mode private-vlan promisc
 switchport private-vlan mapping 100 add 101,102

if you need to configure an SVI on the switch, you should add an interface correspoding to Primary VLAN only. Obviously that’s because of all secondary VLANs being simply “subordiantes” of primary. In our case the config would look like this:


interface Vlan 100
 ip address 172.16.0.1 255.255.255.0

Lastly, there is another feature, worths to be mentioned, called protected port or Private VLAN edge. The feature is pretty basic and avaiable even on low-end Cisco switches, allows to isolate ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configurated as protected, are also configured not to receive unknown unicast (frame with destination MAC address not in switch’s MAC table) and multicast frames flooding for added security.

Example:


interface range FastEthernet 0/1 - 2
 switchport mode access
 switchport protected
 switchport block unicast
 switchport block multicast

December 28th, 2007

Understanding Traceroute

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]#

-->