Posts from ‘Advanced Security’
The two engineers, as they grabbed a quick lunch, looked over the following diagram.
The 13.0.0.0/24 network is GRE. The routing in place, uses the tunnel interfaces to reach the remote networks of 1.1.1.0 and 3.3.3.0. The IPSec policy is to encrypt all GRE traffic between R1 and R3. R1 and R3 are peering with each other using loopback 11 and loopback 33 respectively.
The technicians considered the traffic pattern if a host on the 3.3.3.0/24 network sent a packet to a device on the 1.1.1.0/24 network.
Then they reviewed the configurations (below), and discussed them. Based on what they saw, they just couldn’t agree completely with each other regarding the following questions?
1. How many IP headers would be in each packet.
2. What would the source and destination address be of each IP header.
3. What order the IP headers would be in (beginning with the outside header).
4. Would the IPSec be using transport or tunnel mode.
5. Would this be called IPSec over GRE, GRE over IPSec, or something else, (like “nightmare”).
So they called for the expert, YOU, to assist in these questions.
Are you up to the challenge. Answering even 1 of them will be appreciated, so take moment now, and GO FOR IT !
Post your ideas, and we will put all the people who post ideas into a virtual hat, and draw a winner to receive 100 rack tokens to our preferred lab gear provider, graded labs. Please have your posts in by
Continue Reading
Flexible Packet Matching is a new feature that allows for granular packet inspection in Cisco IOS routers. Using FPM you can match any string, byte or even bit at any position in the IP (or theoretically non-IP) packet. This may greatly aid in identifying and blocking network attacks using static patterns found in the attack traffic. This feature has some limitation though.
a) First, it is completely stateless, e.g. does not track the state/history of the packet flow. Thus, FPM cannot discover dynamic protocol ports such as use by H.323 or FTP nor cannot it detect patterns split across multiple packets. Essentially, you are allowed to apply inspection per-packet basis only.
b) Additionally, you cannot apply FPM to the control-plane traffic, as the feature is implemented purely in CEF switching layer. Fragmented traffic is not assembled for matching, and the only inspected packet is the initial fragment of the IP packet flow.
c) IP packets with IP options are not matched by FPM as well, because they are punted to the route processor.
d) Lastly, this feature inspects only unicast packets and does not apply to MPLS encapsulated packets.
Configuring an FPM filter consists of a few steps.
(1) Loading protocol headers.
(2) Defining a protocol stack.
(3) Defining a traffic filter.
(4) Applying the policy & Verifying
Let’s look at every of these steps in depth.
Fragmented IPv4 traffic may cause you a lot of problems in real life. Not only it increases the load on router CPUs, but also impacts applications performance (e.g. TCP needs to re-send the whole packet on a single fragment loss). In addition to that, traffic fragmentation is used in numerous network attacks, allowing an attacker to bypass firewalls or IDSes in some situations. Due to all these reasons, you may want to avoid fragmentation at all and/or ensure your network is insulated from fragmented packets. Unfortunately, there are cases when using IPv4 fragmentation is unavoidable.
Tags: adjust-mss, attacks, df-bit, fragmentation, mtu, pmtud, tcp, virtual-reassembly
The security appliance supports two kinds of priority queuing – standard priority queuing and hierarchical priority queuing. Let’s configure each in this third part of our blog.
Standard Priority Queuing
This queuing approach allows you to place your priority traffic in a priority queue, while all other traffic is placed in a best effort queue. You can police all other traffic if needed.
Step 1: Create the priority queue on the interface where you want to configure the standard priority queuing. This is done in global configuration mode with the priority-queue interface_name command. Notice this will place you in priority queue configuration mode where you can optionally manipulate the size of the queue with the queue-limit number_of_packets command. You can also optionally set the depth of the hardware queue with the tx-ring-limit number_of_packets command. Remember that the hardware queue forwards packets until full, and then queuing is handled by the software queue (composed of the priority and best effort queues).
pixfirewall(config)# priority-queue outside pixfirewall(config-priority-queue)#
Step 2: Use the Modular Policy Framework (covered in Part 2 of these blogs) to configure the prioritized traffic.
pixfirewall(config-priority-queue)# exit pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# service-policy PM-VOICE-TRAFFIC interface outside pixfirewall(config)# end
Hierarchical Priority Queuing
This queuing approach allows you to shape traffic and allow a subset of the shaped traffic to be prioritized. I have cleared the configuration from the security appliance in preparation for this new configuration. Notice with this approach, you do not configure a priority queue on the interface. Also notice with this approach the nesting of the Policy Maps.
pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# policy-map PM-ALL-TRAFFIC-SHAPE pixfirewall(config-pmap)# class class-default pixfirewall(config-pmap-c)# shape average 2000000 16000 pixfirewall(config-pmap-c)# service-policy PM-VOICE-TRAFFIC pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# service-policy PM-ALL-TRAFFIC-SHAPE interface outside pixfirewall(config)# end
Verifications for Priority Queuing
These verification commands can be used for both forms of priority queuing. Obviously, you can examine portions of the running configuration to confirm your Modular Policy Framework components. For example:
pixfirewall# show run policy-map ! policy-map PM-VOICE-TRAFFIC class CM-VOICE priority class CM-VOICE-SIGNAL priority class class-default policy-map PM-ALL-TRAFFIC-SHAPE class class-default shape average 2000000 16000 service-policy PM-VOICE-TRAFFIC !
Another example:
pixfirewall# show run class-map ! class-map CM-VOICE-SIGNAL match dscp af31 class-map CM-VOICE match dscp ef !
To verify the statistics of the standard priority queuing configuration, use the following:
pixfirewall# show service-policy priority Interface outside: Service-policy: PM-VOICE-TRAFFIC Class-map: CM-VOICE Priority: Interface outside: aggregate drop 0, aggregate transmit 0 Class-map: CM-VOICE-SIGNAL Priority: Interface outside: aggregate drop 0, aggregate transmit 0
You can also view the priority queue statistics for an interface using the following:
pixfirewall# show priority-queue statistics outside Priority-Queue Statistics interface outside Queue Type = BE Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0 Queue Type = LLQ |Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0
To verify the statistics on the shaping you have done with the hierarchical priority queuing, use the following:
pixfirewall# show service-policy shape Interface outside: Service-policy: PM-ALL-TRAFFIC-SHAPE Class-map: class-default shape (average) cir 2000000, bc 16000, be 16000 (pkts output/bytes output) 0/0 (total drops/no-buffer drops) 0/0 Service-policy: PM-VOICE-TRAFFIC
The next blog entry on this subject will focus on the shape tool available on the PIX/ASA.
Thanks so much for reading!
Tags: asa, llq, mpf, pix, priority-queuing
How do you apply most of your QoS mechanisms on a Cisco router? You use the Modular Quality of Service Command Line Interface (MQC). The approach is similar on the PIX/ASA, but the tool does feature some important differences. Also, Cisco has renamed the tool to the Modular Policy Framework. One reason for this is the fact that it is used for more than just QoS. For example, the MPF is also used for application inspection and Intrusion Prevention configurations on the ASA.
The three steps used by MPF are pretty famous at this point. Here they are:
Step 1: Define the traffic flows that you want to manipulate using what is called a Class Map. Do not confuse this with a Map Class that you might remember from Frame Relay configurations. A nice analogy for the Class Map is a bucket that you are pouring the traffic into that you want to manipulate.
Step 2: Take those buckets of traffic from Step 1 and define the particular policy that will apply. The structure used for this is called a Policy Map. An example might be to police Web traffic (defined in a Class Map) to a particular rate.
Step 3: Assign the Policy Map to an interface or all interfaces on the system using what is called a Service Policy.
Let’s examine the syntax for these various commands.
pixfirewall(config)# class-map ? configure mode commands/options: WORD < 41 char class-map name type Specifies the type of class-map
Notice the Class Map syntax includes a type option on the security appliance, the possible types include inspect, management, and regex and represent the variety of configurations the Modular Policy Framework can carry out.
Something else interesting about the Class Map on the security appliance is the fact that there is no options for match-any or match-all. This is because on the security appliance you can only have one match statement. There are exceptions to this, and that is after using either the match tunnel-group or match default-inspection-traffic commands.
Here you can see the match options on the security appliance to fill these buckets of traffic:
pixfirewall(config-cmap)# match ? mpf-class-map mode commands/options: access-list Match an Access List any Match any packet default-inspection-traffic Match default inspection traffic: dscp Match IP DSCP (DiffServ CodePoints) flow Flow based Policy port Match TCP/UDP port(s) precedence Match IP precedence rtp Match RTP port numbers tunnel-group Match a Tunnel Group
Obviously, a powerful option is the ability to match on an access list, since this allows matching on very specific criteria, such as well Web traffic requests from a source to a specific destination. Here is an example:
pixfirewall(config)# access-list AL-EXAMPLE permit tcp any host 10.10.10.200 eq www pixfirewall(config)# class-map CM-EXAMPLE pixfirewall(config-cmap)# match access-list AL-EXAMPLE
For step 2, we use the Policy Map. There are also types of these components that can be created. Notice that you are not in Policy Map configuration mode long, you switch immediately to Policy Map Class configuration mode to get your configuration complete.
pixfirewall(config)# policy-map PM-EXAMPLE pixfirewall(config-pmap)# class CM-EXAMPLE pixfirewall(config-pmap-c)# police output 56000 10500
Here you can see the third strep. The Service Policy applies the Policy Map. You can assign the Policy Map to an interface or all interfaces with the following syntax:
pixfirewall(config)# service-policy PM-EXAMPLE global
Here is a single interface example:
service-policy PM-EXAMPLE interface inside
Notice that a direction is not specified as you would on a router. Notice the direction of policing was actually specified in the Policy Map.
What happens if there is a global policy and an interface policy? Well the interface policy wins out and controls the interface.
The next blog entry on this subject will focus on the priority queuing tool available on the security appliance.
Tags: asa, classification, mpf, mqc, pix, policy-map
Due to the non-decreasing interest to the post about Private VLANs, I decided to make another one, more detailed – including a diagram and verification techniques.
Introduction
To begin with, recall that VLAN is essentially a broadcast domain. Private VLANs (PVANs) allow splitting the domain into multiple isolated broadcast “subdomains”, introducing sub-VLANs inside a VLAN. As we know, Ethernet VLANs can not communicate directly with each other – they require a L3 device to forward packets between separate broadcast domains. The same restriction applies to PVLANS – since the subdomains are isolated at Level 2, they need to communicate using an upper level (L3/packet forwarding) device – such as router.
In reality, different VLANs normally map to different IP subnets. When we split a VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, yet now they need to use a router (L3 device) to talk to each other (for example, by using Local Proxy ARP). In turn, the router may either permit or forbid communications between sub-VLANs using access-lists. Commonly, these 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.
Private VLANs Terminology
The following is the reference diagram that we are going to use to illustrate Private VLAN concepts and functionality.
For our sample configuration, we take VLAN 1000 and divide it into three PVLANs – sub-VLAN 1012 (R1 and R2), sub-VLAN 1034 (R3 and R4) and sub-VLAN 1055 (router R5 only). Router R6 will be used as layer 3 device, to resolve the layer 3 communication issue. We name VLAN 1000 as “Primary” and classify the ports, assigned to this VLAN, based on their types:
- Promiscuous (“P”) port: Usually connects to a router. This port type is allowed to send and receive L2 frames from any other port on the VLAN.
- Isolated (“I”) port: This type of port is only allowed to communicate with “P”-ports – i.e., they are “stub” port. You commonly see these ports connecting to hosts.
- Community (“C”) port: Community ports are allowed to talk to their buddies, sharing the same community (group) and to “P”-ports.
In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different types of ports. We group the VLANs in “Primary” and “Secondary”.
- Primary VLAN (VLAN 1000 in our example). This VLAN is used to forward frames downstream from “P”-ports to all other port types (“I” and “C” ports) in the system. Essentially, Primary VLAN embraces all ports in the domain, but only transports frames from the router to hosts (from “P” to “I” and “C”).
- Secondary 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.
- Secondary Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames upstream to the P-ports of the primary VLAN.
How Private VLANs Work
Here are the key aspects of Private VLAN functioning:
- The Primary VLAN delivers frames downstream from the router (promisc port) to all mapped hosts.
- The Isolated VLAN transports frames from the stub hosts upstream to the router
- The Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards “P”-ports.
- Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding procedure within boundaries of primary/secondary VLANs.
Private VLANs could be trunked. The secondary VLAN numbers are used to tag frames, just as with regular VLANs, and the primary VLAN traffic is trunked as well. However, you need to configure Private VLAN specific settings (bindings, mappings) on every participating swtich, as it’s not possible to use VTPv2 to dissiminate that information . This due to the fact that VTPv2 has no TLVs to carry private VLANs information. VTPv3 was designed to overcome this limitation among others.
Configuring Private VLANs
We have primary VLAN 1000, Isolated VLAN 1005 (R5) Community VLAN 1012 (R1, R2) and Community VLAN 1034 (R3, R4).
Step 1:
First, disable VTP, i.e. enable VTP transparent mode. After disabling VTP, create Primary and Secondary VLANs and bind them into PVLAN domain:
SW1: vtp mode transparent ! ! Creating primary VLAN, which is shared among secondary’s ! vlan 1000 private-vlan primary ! ! Community VLAN for R1 and R2: allows a “subVLAN” within a Primary VLAN ! vlan 1012 private-vlan community ! ! Community VLAN for R3 and R4 ! vlan 1034 private-vlan community ! ! Isolated VLAN: Connects all stub hosts to router. ! Remember - only one isolated vlan per primary VLAN. ! In our case, isolates R5 only. ! vlan 1055 private-vlan isolated ! ! Associating the primary with secondary’s ! vlan 1000 private-vlan association 1012,1034,1055
This step is needed is to group PVLANs into a shared domain and establish a formal association (for syntax checking and VLAN type verifications). Repeat the same operations on SW2, since VTP has been disabled.
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. Also, enable trunking between switches, to allow private VLANs traffic to pass between switches.
SW1: ! ! Community port (links R1 to R2 and “P”-ports) ! interface FastEthernet0/1 description == R1 switchport private-vlan host-association 1000 1012 switchport mode private-vlan host spanning-tree portfast ! ! Community port (links R3 to R4 and “P”-ports) ! interface FastEthernet0/3 description == R3 switchport private-vlan host-association 1000 1034 switchport mode private-vlan host spanning-tree portfast ! ! Isolated port (uses isolated VLAN to talk to “P”-ports) ! interface FastEthernet0/5 description == R5 switchport private-vlan host-association 1000 1055 switchport mode private-vlan host spanning-tree portfast ! ! Trunk port ! interface FastEthernet 0/13 switchport trunk encapsulation dot1q switchport mode trunk SW2: interface FastEthernet0/2 description == R2 switchport private-vlan host-association 1000 1012 switchport mode private-vlan host spanning-tree portfast ! interface FastEthernet0/4 description == R4 switchport private-vlan host-association 1000 1034 switchport mode private-vlan host spanning-tree portfast ! ! Trunk port ! interface FastEthernet 0/13 switchport trunk encapsulation dot1q switchport mode trunk Next, Verify the configuration on SW1: Rack1SW1#show vlan id 1012 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1012 VLAN1012 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1012 enet 101012 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1012 community Fa0/1 Rack1SW1#show vlan id 1034 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1034 VLAN1034 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1034 enet 101034 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1034 community Fa0/3 Rack1SW1#show vlan id 1055 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1055 VLAN1055 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1055 enet 101055 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1055 isolated Fa0/5 Rack1SW1#show interfaces fastEthernet 0/13 trunk Port Mode Encapsulation Status Native vlan Fa0/13 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/13 1-4094 Port Vlans allowed and active in management domain Fa0/13 1,1000,1012,1034,1055 Port Vlans in spanning tree forwarding state and not pruned Fa0/13 1,1000,1012,1034,1055 Verify on SW2: Rack1SW2#show vlan id 1000 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1000 VLAN1000 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1000 enet 101000 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1012 community Fa0/2, Fa0/6 1000 1034 community Fa0/4, Fa0/6 1000 1055 isolated Fa0/6 Rack1SW2#show vlan id 1012 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1012 VLAN1012 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1012 enet 101012 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1012 community Fa0/2, Fa0/6 Rack1SW2#show vlan id 1034 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1034 VLAN1034 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1034 enet 101034 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1034 community Fa0/4, Fa0/6 Rack1SW2#show vlan id 1055 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1055 VLAN1055 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 1055 enet 101055 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 1000 1055 isolated Fa0/6 Rack1SW2#show interface fastEthernet 0/13 trunk Port Mode Encapsulation Status Native vlan Fa0/13 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/13 1-4094 Port Vlans allowed and active in management domain Fa0/13 1,1000,1012,1034,1055 Port Vlans in spanning tree forwarding state and not pruned Fa0/13 1,1000,1012,1034,1055
Step 3:
Create a promiscuous port and configure downstream mappings. Here we add secondary VLANs for which traffic is received by this particular “P”-port. Primary VLAN is used to send traffic downstream to all “C” and “I” ports per their associations.
SW2: ! ! Promiscuous port, mapped to all secondary VLANs ! interface FastEthernet0/6 description == R6 switchport private-vlan mapping 1000 1012,1034,1055 switchport mode private-vlan promiscuous spanning-tree portfast Verify the promiscuous port configuration: Rack1SW2#show int fa 0/6 switch | beg private Administrative Mode: private-vlan promiscuous Operational Mode: private-vlan promiscuous Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055) Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)
If you need to configure an SVI on a switch to communicate with private VLAN members, you should add an interface corresponding to Primary VLAN only. Obviously that’s because all secondary VLANs are “subordinates” of primary. After an SVI has been created, you have to map the required secondary VLANs to the SVI (just like with a promiscuous port) in order to make communications possible. You may exclude some mappings from SVI interface, and limit it to communicating only with certain secondary VLANs.
SW1: ! ! SW1 SVI is mapped to all secondary VLANs ! interface Vlan 1000 ip address 10.0.0.7 255.255.255.0 private-vlan mapping 1012,1034,1055 SW2: ! ! SW2 SVI is mapped to 1012/1034 only, so it’s cant communicate with R5 ! interface Vlan1000 ip address 10.0.0.8 255.255.255.0 private-vlan mapping 1012,1034
Now to verify the configuration, configure R1-R6 interfaces in subnet “10.0.0.0/24” and ping broadcast addresses.
Rack1R1#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.2, 4 ms Reply to request 0 from 10.0.0.6, 4 ms Reply to request 0 from 10.0.0.8, 4 ms Rack1R3#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.4, 4 ms Reply to request 0 from 10.0.0.6, 4 ms Reply to request 0 from 10.0.0.8, 4 ms Rack1R5#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 1 ms Reply to request 0 from 10.0.0.6, 1 ms Rack1R6#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.1, 4 ms Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.2, 4 ms Reply to request 0 from 10.0.0.5, 4 ms Reply to request 0 from 10.0.0.3, 4 ms Reply to request 0 from 10.0.0.4, 4 ms Reply to request 0 from 10.0.0.8, 4 ms
Lastly, there is another feature, called protected port or “Private VLAN edge”. The feature is pretty basic and is available even on low-end Cisco switches. It allows isolating 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 configured 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
Tags: 3560, arp, ccie, community, isolated, level2, private-vlan, promiscuous, vlan
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.
Tags: filtering, pbr, policy-routing, reflexive-acls
You may want to see the updated version of this post at:
http://blog.internetworkexpert.com/2008/07/14/private-vlans-revisited/
—
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
Tags: 3550, 3560, arp, association, ccie, community, isolated, mapping, private-vlan, promiscuous
