Posts Tagged ‘3560’

Apr
25

Here ye, here ye, VTP experts. (We are not referring to the Vandenberg Test Program, although they are very likely experts in their field as well.  :) )

Can you predict the results of a 3 switch VTP client/server scenario?

SW1-3, are connected, as shown in the diagram.

VTP question for Blog

Here is the initial output of show VTP status, and show VLAN brief on each. Note that SW1 and SW3 are servers, while SW2 is a client.   We will be adding a failure to the network in just a moment. Continue Reading

Tags: , , ,

Oct
30

In this post we will look at the basic classification and marking features available in the 3550 and 3560 switches. Basic features include packet marking using port-level settings and port-level policy-maps. Discussing Per-VLAN classification is outside the scope of this document.

The Catalyst QoS implementation bases on Differentiated Services model. In a few words, the ideas of this model could be outlined as follows:

1) Edge nodes classify ingress packets based on local policy and QoS label found in packets.
2) Edge nodes encode traffic classes using a special field (label) in packets to inform other nodes of the classification decision.
3) Core and edge nodes allocate resources and provide services based on the packet class.

Continue Reading

Tags: , , , , , , ,

Sep
11

People are often confused with per-VLAN classification, policing and marking features in the Catalyst 3550 and 3560 models. The biggest problem is lack of comprehensive examples in the Documentation CD. Let’s quickly review and compare traffic policing features available on both platforms. The material below is a condensed excerpt of several Catalyst QoS topics covered in the “QoS” section of our IEWB VOL1 V5. You will find more in-depth explanations and large number of simulation-based verifications in the upcoming section of the workbook.

Continue Reading

Tags: , , , , , , , ,

Jul
14

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.

Private VLANs

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: , , , , , , , ,

Jul
08

Generally, flow-control is a mechanics allowing the receiving party of a connection to control the rate of the sending party. You may see many different implementations of flow-control technologies at different levels of OSI model (e.g. XON/XOFF for RS232, TCP sliding window, B2B credits for Fibre Channel, FECN/BECN for Frame-Relay, ICMP source-quench message, etc). Flow-Control allows for explicit feedback loop and theoretically implementing loss-less networks that avoid congestion.

For the original Ethernet technology on half-duplex connections there was no possibility of implementing explicit flow control, since only one side could send frames at time. However, you may still remember the Cisco’s so-called “back-pressure” feature on some of the older switches, e.g. Cisco Catalyst 1924. The idea was that switch may send barrage of dummy frames on a half-duplex link, effectively preventing the attached station from transmitting information at given moments of time.

Continue Reading

Tags: , , , ,

Jul
05

UDLD (Unidirectional Link Detection) is Cisco proprietary extension for detecting a mis-configured link. The idea behind it is pretty strighforward – allow two switches to verify if they can both send and receive data on a point-to-point connection. Consider a network with two switches, A and B connected by two links: “A=B”. Naturally, if “A” is the root of spanning tree, one of the ports on “B” will be blocking, constantly receiving BPDUs from “A”. If this link would turn uni-directional and “B” would start missing those BPDUs, the port will eventually unblock, forming a loop betwen “A” and “B”. Note that the problem with unidirectional links usually occurs on fiber-optical connections and is not common on UTP (wired) connections, where link pulses are used to monitor the connection integrity.

The confusion about UDLD is that Cisco provides quite unclear description of the feature operations be it on CatOS or IOS platform. So here is a short overview of how UDLD works.

1) Both UDLD peers (switches) discover each other by exchanging special frames sent to well-known MAC address 01:00:0C:CC:CC:CC. (Naturally, those frames are only understood by Cisco switches). Each switch sends it’s own device ID along with the originator port ID and timeout value to it’s peer. Additionally, a switch echoes back the ID of it’s neighbor (if the switch does see the neighbor). Since some versions of CatOS and IOS you can change UDLD timers globally.

2) If no echo frame with our ID has been seen from the peer for a certain amount of time, the port is suspected to be unidirectional. What happens next depends on UDLD mode of operations.

3) In “Normal” mode, if the physical state of port (as reported by Layer 1) is still up, UDLD marks this port as “Undetermined”, but does NOT shut down or disable the port, which continues to operate under it’s current STP status. This mode of operations is informational and potentially less disruptive (though it does not prevent STP loops). You can review the “undetermined” ports using CLI show commands when troubleshooting the STP issues though.

3) If UDLD is set to “Agressive” mode, once the switch loses it’s neighbor it actively tries to re-establish the relationship by sending a UDLD frame 8 times every 1 second (surpisingly this coincides with TCP keepalives retry values used by FCIP on Cisco MDS storage switches :) . If the neighbor does not respond after that, port is considered to be unidirectional and brought to “Errdisable” state. (Note that you can configure “errdisable recovery” to make switch automatically recover from such issues)

4) UDLD “Aggressive” will only brings link to errdisable state when it detects “Bidirectional” to “Unidirectional” state transition. In order for a link to become “Bidirectional”, UDLD process should first hear an echo packet with it’s own ID from a peer on the other side. This prevents link from becoming errdisabled when you configure “Aggressive” mode just on one side. The UDLD state of such link will be “Unknown”.

5) UDLD “Aggressive” inteoperates with UDLD “Normal” on the other side of a link. This type of configuration means that just one side of the link will be errdisabled once “Unidirectional” condition has been detected.

To complete this overview, remember that UDLD is designed to be a helper for STP. Therefore, UDLD should be able to detect an unidirectional link before STP would unblock the port due to missed BPDUs. Thus, when you configure UDLD timers, make sure your values are set so that unidirectional link is detected before “STP MaxAge + 2xForwardDelay” expires. Additionally, notice that UDLD function is similar to STP Loopguard and Bridge Assurance feature found in newer switches. The benefit of UDLD is that it operates at physical port-level, whereas STP may not be able to detect a malfunctioning link bundled in an Etherchannel. This is why you normally use all features together – they don’t replace but truly complement each other.

Tags: , , ,

Jun
26

The goal of this article is to discuss how would the following configuration work in the 3560 series switches:

interface FastEthernet0/13
 switchport mode access
 load-interval 30
 speed 10
 srr-queue bandwidth shape 50 0 0 0
 srr-queue bandwidth share 33 33 33 1
 srr-queue bandwidth limit 20

Before we begin, let’s recap what we know so far about the 3560 egress queuing:

1) When SRR scheduler is configured in shared mode, bandwidth allocated to each queue is based on relative weight. E.g. when configuring “srr-queue bandwidth share 30 20 25 25″ we obtain the weight sum as 30+20+25+25 = 100 (could be different, but it’s nice to reference to “100”, as a representation of 100%). Relative weights are therefore “30/100”, “20/100”, “25/100”, “25/100” and you can calculate the effective bandwidth *guaranteed* to a queue multiplying this weight by the interface bandwidth: e.g. 30/100*100Mbps = 30Mbps for the 100Mbps interface and 30/100*10Mbps=3Mbps for 10Mbps interface. Of course, the weights are only taken in consideration when interface is oversubscribed, i.e. experiences a congestion.

2) When configured in shaped mode, bandwidth restriction (policing) for each queue is based on inverse absolute weight. E.g. for “srr-queue bandwidth shape 30 0 0 0” we effectively restrict the first queue to “1/30” of the interface bandwidth (which is approximately 3,3Mbps for 100Mbps interface and approximately 330Kbps for a 10Mbps interface). Setting SRR shape weight to zero effectively means no shaping is applied. When shaping is enabled for a queue, SRR scheduler does not use shared weight corresponding to this queue when calculating relative bandwidth for shared queues.

3) You can mix shaped and shared settings on the same interface. For example two queues may be configured for shaping and others for sharing:

interface FastEthernet0/13
 srr-queue bandwidth share 100 100 40 20
 srr-queue bandwidth shape  50  50  0  0

Suppose the interface rate is 100Mpbs; then queues 1 and 2 will get 2 Mbps, and queues 3 and 4 will share the remaining bandwidth (100-2-2=96Mbps) in proportion “2:1”. Note that queues 1 and 2 will be guaranteed and limited to 2Mbps at the same time.

4) The default “shape” and “share” weight settings are as follows: “25 0 0 0” and “25 25 25 25”. This means queue 1 is policed down to 4Mbps on 100Mpbs interfaces by default (400Kbps on 10Mbps interface) and the remaining bandwidth is equally shared among the other queues (2-4). So take care when you enable “mls qos” in a switch.

5) When you enable “priority-queue out” on an interface, it turns queue 1 into priority queue, and scheduler effectively does not account for the queue’s weight in calculations. Note that PQ will also ignore shaped mode settings as well, and this may make other queues starve.

6) You can apply “aggregate” egress rate-limitng to a port by using command “srr-queue bandwidth limit xx” at interface level. Effectively, this command limits interface sending rate down to xx% of interface capacity. Note that range starts from 10%, so if you need speeds lower than 10Mbps, consider changing port speed down o 10Mbps.

How will this setting affect SRR scheduling? Remember, that SRR shared weights are relative, and therefore they will share the new bandwidth among the respective queues. However, shaped queue rates are based on absolute weights calculated off interface bandwidth (e.g. 10Mbps or 100Mbps) and are subtracted from interface “available” bandwidth. Consider the example below:

interface FastEthernet0/13
 switchport mode access
 speed 10
 srr-queue bandwidth shape 50 0 0 0
 srr-queue bandwidth share 20 20 20 20
 srr-queue bandwidth limit 20

Interface sending rate is limited to 2Mbps. Queue 1 is shaped to 1/50 of 10Mps, which is 200Kbps of bandwidth. The remaining bandwidth 2000-200=1800Kbps is divided equally among other queues in proportion 20:20:20=1:1:1. That is, in case on congestion and all queues filled up, queue 1 will get 200Kbps, and queues 2-4 will get 600Kbps each.

Continue Reading

Tags: , , , , , ,

Mar
03

The 3560 QoS processing model is tightly coupled with it’s hardware architecture borrowed from the 3750 series switches. The most notable feature is the internal switch ring, which is used for the switch stacking purpose. Packets entering a 3560/3750 switch are queued and serviced twice: first on the ingress, before they are put on the internal ring, and second on the egress port, where they have been delivered by the internal ring switching. In short, the process looks as follows:

[Classify/Police/Mark] -> [Ingress Queues] -> [Internal Ring] -> [Egress Queues]

For more insights and detailed overview of StackWise technology used by the 3750 models, visit the following link:

Cisco StackWise Technology White Paper

Continue Reading

Tags: , , , , , , , ,

Jan
31

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: , , , , , , , , ,

Categories

CCIE Bloggers