Archive for July, 2008

Jul
30

After reviewing the customer issues with our secure PDF application LockLizard we have decided to switch back to standard PDFs.   You will find in the next coming days that the existing products secured using LockLizard available through your members’ site account in standard PDF format.

The idea behind us using LockLizard was to cut down on the amount of piracy our support team has to deal with on a daily basis.  BUT if our measures to fight piracy cause our paying customer’s headaches then it’s not a good solution.

We have implemented a few new solutions to deal with piracy and one of them uses steganography to ensure that each user’s PDF is unique in addition to the standard watermarks (email address, IP address, etc).  This means that even if a user removes the watermark and reprints or converts the PDF into a new PDF it will still be identifiable by our support team as to who’s account it came from.  We had to add some bigger servers for this since the PDFs are generated on the fly.  We additionally had a crawler written that goes out and looks for pirated material and then automatically gets the files removed.

Lastly anyone want to buy a $10,000+ secure PDF application ;-)

Tags: , , , ,

Jul
28

NTP security goal is to prevent unauthorized time sources to affect time synchronization within a set of network devices. Cisco IOS offers two methods of securing NTP infrastructure:

1) NTP Access Control. Limit types of NTP access and NTP sources associating with out router.
2) NTP Authentication. Validate the identity of NTP sources.

Let’s see how access control works. It is convenient to classify NTP messages in two types:

1) Control messages. Documented in RFC 1305 Appendix B, serve the purpose, usually fulfilled by SNMP. Without digging into any details, let’s just say the control messages are for reading and writing internal NTP variables and obtaining NTP status information. Not to deal with time synchronization itself.
2) NTP request/update messages. Those are used for actual time synchronization. Request packet obviouly asks for synchronization information, and update packet contains synchronization information, and may change local clock.

IOS router defines the following four types of access for NTP:

1) Peer – permits router to respond to NTP requests and accept NTP updates. NTP control queries are also accepted. This is the only class which allows a router to be synchronized by other devices.
2) Serve – permits router to reply to NTP requests, but rejects NTP updates (e.g. replies from a server or update packets from a peer). Control queries are also permitted.
3) Serve-only – permits router to respond to NTP requests only. Rejects attempt to synchronize local system time, and does not access control queries.
4) Query-only – only accepts NTP control queries. No response to NTP requests are sent, and no local system time synchronization with remote system is permitted.

IOS router may associate an access-list with any of the above access-types, classifying NTP message sources by their types. Two rules are observed by IOS when an incoming NTP packet is matched against configured types of access:

1) All access-groups associated with access types are scanned in the ordrer presented above (from 1 to 4) – that is, following from most permissive to most restrictive. The first match is used to determine the message source access type.
2) If any of the access types has been defined with an ACL, all other access types are implicitly denied. Just by restricting some sources, you may effectively block all others as well

Now here is a catch. If your router is configured as NTP master, and you set up any access-control group, you must allow “peer” access type to a source with IP address “127.127.7.1”. This is because “127.127.7.1” is the internal server created by ntp master command, which the local router synchronizes to. If you forget to enable it peer access, your server will always be out of sync. Here are some examples. First one: configure R1 as NTP master and allow the server to be polled for NTP updates just by one client. Client should receive updates just from one source:

R1:
access-list 1 permit 127.127.7.1
access-list 2 permit 150.1.2.2
ntp master
ntp access-group peer 1
ntp access-group serve-only 2

R2:
access-list 1 permit 150.1.1.1
ntp source Loopback0
ntp access-group peer 1
ntp server 150.1.1.1

A more complicated example. R1 and R3 are both NTP masters, peering via NTP. R2 is a client to both of them. Configure so that R1 and R3 only allow R2 to poll themselves for time updates, and allow synchronizing each other. Correspondingly, R2 should only accept NTP updates from R1 or R3.

R1:
access-list 2 permit 150.1.2.2
access-list 3 permit 150.1.3.3
access-list 3 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 3
!
! The following is needed to poll our peer from
! a consistent source IP address
!
ntp source Loopback0
ntp peer 150.1.3.3

R3:
access-list 2 permit 150.1.2.2
access-list 1 permit 150.1.1.1
access-list 1 permit 127.127.7.1
ntp master
ntp access-group serve-only 2
ntp access-group peer 1
ntp source Loopback0
ntp peer 150.1.1.1

R2:
access-list 13 permit 150.1.1.1
access-list 13 permit 150.1.3.3
ntp source Loopback0
ntp access-group peer 13
ntp server 150.1.1.1
ntp server 150.1.3.3

Some show commands output for the last example:

Rack1R1#show ntp associations detail
150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2222.362546B9 (00:06:58.211 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 12.466
delay 24.70 msec, offset 0.0294 msec, dispersion 0.05
precision 2**18, version 3
org time D2AA2222.363128BC (00:06:58.211 UTC Sun Jan 1 2012)
rcv time D2AA2222.395A8A9D (00:06:58.224 UTC Sun Jan 1 2012)
xmt time D2AA221C.BA22B989 (00:06:52.727 UTC Sun Jan 1 2012)
filtdelay =    24.77   24.70   24.69   24.69   24.81   24.78   25.16   24.60
filtoffset =    0.01    0.03    0.01    0.01    0.07    0.02    0.30    0.04
filterror =     0.02    0.03    0.05    0.06    0.08    0.09    0.11    0.12

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 17, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
rcv time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
xmt time D2AA224F.BA09890A (00:07:43.726 UTC Sun Jan 1 2012)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02    0.99    1.97    2.94 15995.3 15995.3 15995.3 15995.3
Reference clock status:  Running normally
Timecode:

Rack1R3#show ntp associations detail
150.1.1.1 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode active, peer mode active, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 13.474
delay 24.70 msec, offset 0.0428 msec, dispersion 0.84
precision 2**16, version 3
org time D2AA2252.BA44EC9D (00:07:46.727 UTC Sun Jan 1 2012)
rcv time D2AA2252.BD81F301 (00:07:46.740 UTC Sun Jan 1 2012)
xmt time D2AA2262.362614E6 (00:08:02.211 UTC Sun Jan 1 2012)
filtdelay =    24.99   24.70   24.69   25.02   24.70   24.67   24.67   24.66
filtoffset =   -0.15    0.04   -0.06    0.16   -0.04   -0.04    0.03   -0.02
filterror =     0.75    0.76    0.78    0.79    0.81    0.82    0.84    0.85

127.127.7.1 configured, our_master, sane, valid, stratum 7
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.00, reach 377, sync dist 0.015
delay 0.00 msec, offset 0.0000 msec, dispersion 0.02
precision 2**18, version 3
org time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
rcv time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
xmt time D2AA2263.36244305 (00:08:03.211 UTC Sun Jan 1 2012)
filtdelay =     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filtoffset =    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
filterror =     0.02    0.99    1.01    1.02    1.04    1.05    1.07    1.08
Reference clock status:  Running normally
Timecode: 

Rack1R2#show ntp associations detail
150.1.1.1 configured, our_master, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA224F.BA0A656E (00:07:43.726 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 17, sync dist 2924.316
delay 92.15 msec, offset -814906.4035 msec, dispersion 2877.85
precision 2**16, version 3
org time D2AA225B.921F769B (00:07:55.570 UTC Sun Jan 1 2012)
rcv time D2AA258A.85F5230D (00:21:30.523 UTC Sun Jan 1 2012)
xmt time D2AA258A.6E599935 (00:21:30.431 UTC Sun Jan 1 2012)
filtdelay =    92.15   90.97   90.84  136.81    0.00    0.00    0.00   91.34
filtoffset = -814906 -814908 -814909 -814886    0.00    0.00    0.00    2.22
filterror =     0.02    0.99    1.97    2.94 16000.0 16000.0 16000.0    7.83

150.1.3.3 configured, selected, sane, valid, stratum 8
ref ID 127.127.7.1, time D2AA2263.362511B6 (00:08:03.211 UTC Sun Jan 1 2012)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.05, reach 377, sync dist 13.916
delay 24.57 msec, offset -814905.7885 msec, dispersion 1.59
precision 2**18, version 3
org time D2AA2273.89780E2F (00:08:19.536 UTC Sun Jan 1 2012)
rcv time D2AA25A2.747F40E8 (00:21:54.455 UTC Sun Jan 1 2012)
xmt time D2AA25A2.6E3030A3 (00:21:54.430 UTC Sun Jan 1 2012)
filtdelay =    24.57   24.73   24.70   24.84   24.64   24.75   24.55   24.67
filtoffset = -814905 -814907 -814907 -814907 -814907 -814907 -814907 -814907
filterror =     0.02    0.99    1.01    1.02    1.04    1.05    1.07    1.08

Tags: ,

Jul
27

Note: You may want to read a newer blog post on MSTP here Understanding MSTP

Before we begin with MSTP (Multiple Spanning Trees Protocol), I would like to note that this tutorial is going to be is divided in two parts. The first part describes how MSTP works inside a single region (the definition of the term will follow later). The second part is dedicated to MSTP region interaction with other regions and different STP protocols (IEEE STP, RSTP and Cisco PVST+).

Historical Review

First, a short history tour. In the beginning, there was IEEE STP protocol (originally, there also was DEC variant [the original] invented by Radia Perlman and IBM STP protocols, but those are fossils now), which was adapted for use with multiple VLANs and 802.1q trunks. A single shared tree, sometimes called Mono Spanning Tree by Cisco, or more often – Common Spanning Tree is shared by all VLANs. The obvious drawback of this design is impossibility to perform VLAN traffic engineering across redundant links: if a link is blocked, it is blocked for all VLANs. To overcome this, Cisco suggested its proprietary PVST/PVST+ solution, running a separate STP instance for each VLAN. This solution permits using different logical topology for each VLAN, effectively allowing for L2 traffic engineering. However, with the number of VLANs growing, PVST becomes a waste of switch resources and management burden, for the number of logical topologies is usually much smaller than the number of active VLANs.

As time passed, STP evolved into RSTP and Cisco answered with Rapid-PVST+: the fast STP, but with the same per-VLAN instance concept. The single spanning-tree instance used by IEEE and per-VLAN STP implemented by Cisco represents two poles in the space of possible solutions. Seeing the limitations of PVST approach, Cisco came with idea of decoupling the STP instance from a VLAN (they were bound together in PVST). The initial implementation was called MISTP (Multiple Instances Spanning Tree) and later evolved into new IEEE 802.1s standard called MSTP (Multiple Spanning Trees Protocol). As we would see later, this evolution process led to some terminology confusion, and small features mismatch between IEEE MSTP and Cisco MSTP implementation.

Logical and Physical Topologies

Look at the diagrams below:

Physical and Logical Topologies

Cisco’s original proposal was as follows. Instead of running an STP instance for each VLAN, let’s run a number of VLAN-independent STP instances (representing logical topologies) and then map each VLAN to the most appropriate logical topology (instance). Thus, the number of STP instances is kept to minimum (saving switch resources), but the network capacity is utilized in optimal fashion, by using all possible paths for VLAN traffic. The switch forwarding logic for VLAN traffic was changed a little bit. In order for a frame to be forwarded out of a port, two conditions must be met: first, VLAN must be active on this port (e.g. not filtered) and second, the STP instance the VLAN maps to, must be in non-discarding state for this port. Obviously, due to multiple logical topologies a single port could be blocking for one instance and forwarding for another (note that in (R)PVST+ a port is either forwarding or discarding for a VLAN).

Mapping VLANs to Instances

Implementing MSTP

Now that the basic idea is understood, let’s think how it could be implemented. The following questions need to be answered:

  • Topology Calculation. How to build multiple STP instances (logical topologies) in a single physical topology? Should we run multiple STP instances each with own BPDUs? If yes, then how would we distinguish every instance’s BPDUs: PVST+ uses VLAN tags for that, but now STP instances are independent of VLANs?
  • Information Distribution.How to make all switches aware of VLAN to instance mappings? Should we distribute instance ID along with VLAN number? If yet, then how could we ensure all switches use consistent numbering?
  • Consistency Check. How to ensure the above mapping is consistent across all switches? That is, would switch1 know that switch2 maps VLAN2 to the same instance 1 and not insance2?

Original Cisco MISTP pre-standard implementation sends separate BPDUs for each instance – this allows for separate STP calculations. Each BDPU contains instance number and a list of VLANs, mapped on sending switch to this particular instance – this allows for consistency check. However, the table to map VLANs to instance numbers has to be configured on each switch separately – that is, there is no automated mechanism to distribution VLAN to instance mappings. This is what Cisco did originally, but the IEEE 802.1s standard implementation made this mechanics more elegant. Before we continue discussing IEEE’s implementation, let’s define MSTP region as a collection of switches, sharing the same view of physical topology partitioning into set of logical topologies. For two switches to become members of the same region, the following attributes must match:

  • Configuration name
  • Configuration revision number (16 bits)
  • The table of 4096 elements which map the respective VLAN to STP instance number

IEEE 802.1s implementation does not send a BDPU for each active STP instance, nor does it encapsulate VLAN list in each configuration message. Instead of that, a special STP instance number 0 called Internal Spanning Tree (IST or MSTI0) is designated to carry all “signaling” information. The BPDUs for IST contain all standard RSTP information for IST itself, as well as carry additional informational fields. Among others fields there are configuration name, revision number and a hash value computed over VLAN to STP instance mapping table contents. Using just this compact information it’s easy to detect misconfiguration on two neighboring switches.

What about other instances, besides the IST thing? Well, obviously, all VLANs could be mapped to IST – this is the default configuration. Effectively, this represents the case of classic IEEE RSTP with all VLANs sharing the same spanning-tree. Of course, other instances also exit, and they are called MSTIs – multiple spanning tree instances. Each MSTI may assign different priorities to switches, may have different link costs, port priorities and thus end up with it’s own logical topology. Now if the 802.1s standard implementation does not send separate BDPUs for each MSTI, how does it accomplish separate topologies? The MSTIs information is piggybacked into IST BPDUs in special MRecord fields (one for every active MSTI), which carries root priority, designated bridge priority, port priority and root path cost among others. Let’s see how this whole thing works.

First of all, since MSTP convergence mechanism stems from RSTP, there is no BDPU relaying process downstream from the root bridge. Every switch emits configuration BPDUs on it’s own, every Hello interval seconds. Every BDPU has full information about IST, and also MRecord for every MSTI . Using the RSTP convergence mechanics, separate STP instances are built for IST and every MSTI, using the information from IST BPDU and MRecords (root/designated bridge priorities, port priority, root path cost etc). Note that STP timers such as Hello, ForwardTime, MaxAge could only be tuned for IST, the instance 0. All other instances (MSTIs) inherit the timers from IST – this is the natural result of all MSTI information being piggybacked in IST BPDUs. Just as a side note, MSTP does not use MaxAge timer to age out old information, like RSTP/STP do. Instead of this, IST BDPUs has special field called MaxHops. IST root sends BPDUs with hop count equal to MaxHops and every other downstream switch decrements the hop count field on reception of IST BPDU. As soon as hop count becomes zero, the information in BPDU is ignored, and the switch may start declaring itself as new IST root. The old MaxAge/ForwardDelay timers are still used when MSTP interacts with RSTP, STP or (R)PVST+ bridges.

Caveats arising from VLAN/STP decoupling

Before we jump to configuration examples, let’s consider some issues, which may arise from the fact that spanning-tree instances now are not directly tied to VLANs. The general rule should be as following: “If a VLAN is active on a particular primary link (e.g. this link is non-backup in your logical topology), ensure the STP instance it maps to is forwarding on this link”. Consider the following example:

MSTP Broken Config 1

In this topology, VLANs are manually pruned on trunks. Since the filtering is not consistent with the respective MSTI blocking decisions, VLAN2 traffic is blocked between SW1 and SW2. To avoid this situation, do not use “VLAN pruning” static method of distributing VLANs across trunks when you have MSTP enabled.

Another classic example, which may arise when you map VLANs to default IST:

MSTP Broken Config 2

Since there is just one STP instance, it blocks one of the ports. Unfortunately, this is the only port that VLAN3 can use. To avoid such situations, use separate STP for each logical topology (e.g. MSTI1 and MSTI2 in this case for VLAN2/VLAN3) and avoid mapping VLANs to IST. Keep IST only for information distribution, but load-balance traffic using MSTIs.

Configuration Example

Now that we have basic understanding of how MSTP works inside a region, let’s jump to the configuration stage. Consider the following physical topology already mentioned above:

MSTP Config Sample

The topology has VLANs 1, 10,20,30,40,50,60. We want to achieve the following:

1) VLANs 10,20,30 should follow uplink from SW3 to SW1
2) VLANs 40,50,60 should follow uplink from SW3 to SW2
3) If any of the uplinks fail, the respective VLANs should use the other uplink

To accomplish this, we need to create two MSTIs – let’s give them numbers 1 and 2. SW1 will be the root for instance 1 and SW2 will be the root for instance 2. As for IST (MSTI0), let’s make SW3 the root switch for it (though it’s not recommended to assign root roles to access switches). VLAN 1 will remain mapped to IST, VLANs 10,20,30 to MSTI1, and VLANs 40,50,60 to MSTI2. Here is the configuration (pretty simple, inside a region):

SW1:
spanning-tree mode mst
!
spanning-tree mst configuration
 name REGION1
 instance 1 vlan 10, 20, 30
 instance 2 vlan 40, 50, 60
!
spanning-tree mst 1 priority 8192
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/16
 switchport trunk encapsulation dot1q
 switchport mode trunk

SW2:
spanning-tree mst configuration
 name REGION1
 instance 1 vlan 10, 20, 30
 instance 2 vlan 40, 50, 60
!
spanning-tree mst 2 priority 8192
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/16
 switchport trunk encapsulation dot1q
 switchport mode trunk

SW3:
spanning-tree mst configuration
 name REGION1
 instance 1 vlan 10, 20, 30
 instance 2 vlan 40, 50, 60
!
spanning-tree mst 0 priority 8192
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/16
 switchport trunk encapsulation dot1q
 switchport mode trunk

Let’s review the effect of our configuration.

SW1#show spanning-tree mst configuration
Name      [REGION1]
Revision  0     Instances configured 3

Instance  Vlans mapped
--------  ---------------------------------------------------------------------
0         1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1         10,20,30
2         40,50,60
-------------------------------------------------------------------------------
SW1#show spanning-tree mst               

##### MST0    vlans mapped:   1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge        address 0019.5684.3700  priority      32768 (32768 sysid 0)
Root          address 0012.d939.3700  priority      8192  (8192 sysid 0)
              port    Fa0/16          path cost     0
Regional Root address 0012.d939.3700  priority      8192  (8192 sysid 0)
                                      internal cost 200000    rem hops 19
Operational   hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured    hello time 2 , forward delay 15, max age 20, max hops    20

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Desg FWD 200000    128.15   P2p
Fa0/16           Root FWD 200000    128.18   P2p 

##### MST1    vlans mapped:   10,20,30
Bridge        address 0019.5684.3700  priority      8193  (8192 sysid 1)
Root          this switch for MST1

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Desg FWD 200000    128.15   P2p
Fa0/16           Desg FWD 200000    128.18   P2p 

##### MST2    vlans mapped:   40,50,60
Bridge        address 0019.5684.3700  priority      32770 (32768 sysid 2)
Root          address 001e.bdaa.ba80  priority      8194  (8192 sysid 2)
              port    Fa0/13          cost          200000    rem hops 19

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13           Root FWD 200000    128.15   P2p
Fa0/16           Altn BLK 200000    128.18   P2p 

SW1#show spanning-tree mst interface fastEthernet 0/13

FastEthernet0/13 of MST0 is designated forwarding
Edge port: no             (default)        port guard : none        (default)
Link type: point-to-point (auto)           bpdu filter: disable     (default)
Boundary : internal                        bpdu guard : disable     (default)
Bpdus sent 561, received 544

Instance Role Sts Cost      Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0        Desg FWD 200000    128.15   1-9,11-19,21-29,31-39,41-49,51-59
                                     61-4094
1        Desg FWD 200000    128.15   10,20,30
2        Root FWD 200000    128.15   40,50,60

SW1#show spanning-tree mst interface fastEthernet 0/16

FastEthernet0/16 of MST0 is root forwarding
Edge port: no             (default)        port guard : none        (default)
Link type: point-to-point (auto)           bpdu filter: disable     (default)
Boundary : internal                        bpdu guard : disable     (default)
Bpdus sent 550, received 1099

Instance Role Sts Cost      Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0        Root FWD 200000    128.18   1-9,11-19,21-29,31-39,41-49,51-59
                                     61-4094
1        Desg FWD 200000    128.18   10,20,30
2        Altn BLK 200000    128.18   40,50,60

Note a few things here. The cost values are much higher than the default STP costs, and MSTIx is called MSTx (e.g. IST is MST0). Aside from that, note the term “Regional Root” which is to be explained in details in Part 2. As for this part, you can see that configuration MSTP inside a region is pretty simple. You just need to execute some caution, when filtering and mapping VLANs, but if you plan logical topologies in advance this should not cause any problems.

Tags: , , , , , , , ,

Jul
20

I found it important to make a small post in reply to the following question:

Hi Petr
i’m still confused between
mls qos min-reserve and wrr-queue bandwidth
what is the difference between the two

thx

The 3550 WRR (weighted round robin) scheduler algorithm utilizes four configurable queues at each interface of the switch. Let’s consider just FastEthernet ports for simplicity in this post. For each queue, the following important parameters could be configured:

1) WRR scheduling weight. Defines how much attention the queue is given in case of congestion. The weight essentially defines the number of packets taken from queue each time WRR scheduler runs through queues in sequence. WRR weights are defined per-interface using the command wrr-queue bandwidth w1 w2 w3 w4. Theoretically, if each queue holds packets of approximately the same size, the proportion of bandwidth guaranteed to queue number “k” (k=1..4) is: wk=wk/(w1+w2+w3+w4) [this formula does not hold strict if packet sizes are much different]. If queue 4 is turned into priority by using priority-queue out, than it’s weight is ignored in computations (w4 is set to 0 in the above formula). The currently assigned weights could be verified as follows:

SW4:
interface FastEthernet 0/1
 wrr-queue bandwidth 10 20 30 40

Rack1SW4#show mls qos interface queueing
FastEthernet0/1
Egress expedite queue: dis
wrr bandwidth weights:
qid-weights
 1 - 10
 2 - 20
 3 - 30
 4 - 40
...

2) Queue size. Number of buffers allocated to hold packets when the queue is congested. When a queue grow up to this limit, further packets are dropped. The queue size value is not explicitly configurable per FastEthernet interface. Rather, each queue is mapped to one of eight globally configurable “levels”. Each level, in turn, is assigned the number of buffers available to queues mapped to this level. Therefore, the mapping is as following: queue-id -> global-level -> number-of-buffers. By default, each of eight levels is assigned the value of “100″. This means that every queue mapped to this level will have 100 buffers allocated. The interface-level command to assign a level to a queue is wrr-queue min-reserve Queue-id Global-level. By default, queues 1 through 4 are mapped to levels 1 through 4. Look at the following example and verification:

SW4:
mls qos min-reserve 1 10
mls qos min-reserve 2 20
mls qos min-reserve 3 30
mls qos min-reserve 4 40
!
! Assign 40 buffers to queue 1
! Assign 30 buffers to queue 2
! Assign 20 buffers to queue 3
! Assign 10 buffers to queue 4
!
interface FastEthernet0/1
 wrr-queue min-reserve 1 4
 wrr-queue min-reserve 2 3
 wrr-queue min-reserve 3 2
 wrr-queue min-reserve 4 1

Rack1SW4#show mls qos interface fastEthernet 0/1 buffers
FastEthernet0/1
Minimum reserve buffer size:
 10 20 30 40 100 100 100 100
Minimum reserve buffer level select:
 4 3 2 1

3) CoS values to Queue-ID (1,2,3,4) mapping table (per-port). Defines (per-interface) which outgoing packets are mapped to this queue based on the calculated CoS value. The interface-level command to define the mappings is wrr-queue cos-map Queue-ID Cos1 [Cos2] [Cos3] … [Cos8]. For example:

SW4:
interface FastEthernet0/1
 wrr-queue cos-map 1 0 1 2
 wrr-queue cos-map 2 3 4
 wrr-queue cos-map 3 6 7
 wrr-queue cos-map 4 5

Rack1SW4#show mls qos interface fastEthernet 0/1 queueing
FastEthernet0/1
Egress expedite queue: dis
wrr bandwidth weights:
qid-weights
 1 - 10
 2 - 20
 3 - 30
 4 - 40
Cos-queue map:
cos-qid
 0 - 1
 1 - 1
 2 - 1
 3 - 2
 4 - 2
 5 - 4
 6 - 3
 7 - 3

Note that the CoS value is either based on the original CoS field from the incoming frame (if CoS was trusted) or is calculated using the global DSCP to CoS mapping table (for IP packets).

Note that for GigabitEthernet ports on the 3550 platform, the configuration options are more flexible – you can specify queue-depths per-interface, configure drop thresholds, map DSCP value to thresholds and define the drop strategy. However, this topic is for separate post :) .

Tags: , , , ,

Jul
19

For the benefit of those who do not have access to the lab below is the task and the diagram:

4.11. IGP Redistribution
• Redistribute between RIP and OSPF on SW1.
• Redistribute between OSPF and EIGRP on R2, R3, and R4.
• Ensure that full reachability is maintained throughout the IGP domain when the Frame Relay circuit between R3 and R5 is down.

3 Points

First off this task is only worth 3 points but will take most people 45 minutes to 1 hour to complete due to the fact the requirements create a routing loop. This means that it’s really not worth 3 points in the real lab due to the fact you’re giving away 1 hour of your 8 hours for just 3 points. In the real lab most people would be better off just getting full IP reachability and moving on. Think about it like this. If you could give up 3 points in every lab and implement you own solution to obtain full IP reachability would you be better off?

When you run across a redistribution task in a lab your first goal is to determine what is the minimum redistribution needed to achieve full reachability. This is your “safety net” in the event you are not able to complete the task as required or do not have the time to fully complete the task as required. You can pass the lab without getting these 3 points but you can’t really expect to pass the lab without having full IP reachability.

Since our first goal is just to determine what is needed to obtain full IP reachability lets look at this network and determine where we need to perform redistribution to achieve this. Obviously we must redistribute between RIP and OSPF on SW1 to provide reachability between the OSPF and RIP domains. Since this will be a single point of redistribution between RIP and OSPF and these protocols are only both run on one router (SW1) we will not have any problems. This means we can just redistribute RIP into OSPF, then OSPF into RIP and finally verify our redistribution by viewing the routing tables and doing some basic pinging. No tagging, filtering, distribute-list, etc is needed on SW1.

Once the RIP and OSPF redistribution is finished and verified we should then move onto the EIGRP and OSPF redistribution. Do not make the mistake of moving onto the EIGRP and OSPF redistribution without first verifying your RIP and OSPF redistribution. You must verify each stage of the network as it’s built. If you wait until the end of the IGP section to test for full IP reachability it will be much harder to determine what the cause of the problems are. Think about it like this. If I gave you a network and told you to find 10 errors in it would it be easier to find the 10 errors after I’ve applied all of the configuration or would it be easier to check for the errors as I apply each part of the configuration? If you didn’t answer the latter I would hope you never have aspirations on becoming an airline engine inspector ;-)

First off we need to determine what are the minimum points of redistribution needed between OSPF and EIGRP to obtain full IP reachability. Normally this is easy to determine but in this network we have a backup link being used. In the real lab we don’t need to worry about redundancy or sub-optimal routing unless specified directly or indirectly. In this case we need to take redundancy into consideration since full IP reachability will need to be obtained when the network is in two different states. The first state is when the backup link is in the standby mode. The second state is when the backup interface is active due to the fact the primary link is down. In this case the backup link is the serial between R4 and R5 and the primary link is the Frame Relay connection between R3 and R5.

Now that we know what items to take into consideration for the EIGRP and OSPF redistribution we can determine that at a minimum EIGRP and OSPF will need to be redistributed on R4 and either R2 or R3. R4 is selected for redistribution because when the backup link is active it will need to provide connectivity between R5 and the rest of the network.

Where we start having problems is with the redistribution on R2 or R3 so lets look at what the problem is. OSPF routes going into EIGRP will not present a problem because once the OSPF routes are in EIGRP they will have a higher AD. Remember that the problems with redistribution occur when we take a higher AD protocol and then redistribute it into a lower AD protocol and finally attempt to redistribute it back into the original higher AD protocol (Higher->Lower->Higher). In this case the OSPF routes will have an AD of 170 when redistributed into EIGRP. Since the AD of EIGRP external is 170 these routes will not overtake the original OSPF routes. So lower AD protocol to higher AD protocol isn’t a problem. For those who have always wondered why the external distance of EIGRP is 170 now you know ;-)

Now that we know we shouldn’t have any problems with the OSPF routes going into EIGRP we next need to consider if we’ll have any problems with EIGRP routes going into OSPF. By default EIGRP internal routes have an AD of 90 and an AD of 170 for external routes. This being the case we’ll need to consider the higher->lower->higher problem for both types of routes (internal and external). For the internal EIGRP routes there won’t be a problem since we will be going from a lower AD protocol to higher AD protocol. It’s the external EIGRP routes that weren’t originally OSPF routes. In this lab a previous task asked for the Ethernet segments (E0/0 and E0/1) on R5 to be redistributed into EIGRP. These are the routes which we will see that create the routing loop problem.

We should now be able to see what the problem is. It’s the external EIGRP routes being redistributed into OSPF and then possibly back into EIGRP. This is because we have the higher->lower->higher situation. The higher (external EIGRP) going into a lower (OSPF) and finally back into a higher (external EIGRP).

To illustrate the problem I have mutual redistribution configured between EIGRP and OSPF on both R2 and R3. We can see from the output below that R2 and R3 can not reach R5′s E0/0 interface but they can reach R5′s Loopback0 interface. The only difference is the Loopback is an internal EIGRP route while the Ethernet is an external EIGRP route. This is exactly what we expected to happen.

Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.23.3 16 msec 17 msec 16 msec
  2 132.1.0.2 36 msec 32 msec 36 msec
  3 132.1.23.3 32 msec 32 msec 32 msec
  4 132.1.0.2 52 msec 56 msec 52 msec
  5 132.1.23.3 48 msec 48 msec 48 msec
  6 132.1.0.2 68 msec 68 msec 68 msec
  7 132.1.23.3 64 msec 68 msec 64 msec
  8 132.1.0.2 88 msec 88 msec 84 msec
  9 132.1.23.3 105 msec 96 msec 96 msec
 10 132.1.0.2 120 msec 104 msec 101 msec
Rack1R2#
Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  44 msec
Rack1R2#

Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.2 28 msec 32 msec 28 msec
  2  *  *  *
  3 132.1.0.2 44 msec 48 msec 44 msec
  4  *  *  *
  5 132.1.0.2 60 msec 64 msec 64 msec
  6  *  *  *
  7 132.1.0.2 76 msec 84 msec 81 msec
  8  *  *  *
  9 132.1.0.2 269 msec 128 msec *
 10  *  *  *
Rack1R3#
Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

Now that we know what the problem is we need to consider all of the possible solutions and implement the simplest solution. First off we could break this potential routing loop by just removing redistribution from R2. The output below shows the traceroutes from R2 and R3 to R5 when redistribution has been removed from R2.

Rack1R2#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.23.3 16 msec 16 msec 16 msec
  2 132.1.35.5 44 msec *  60 msec
Rack1R2#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.0.3 28 msec 32 msec 28 msec
  2 132.1.35.5 56 msec *  56 msec
Rack1R2#

Rack1R3#traceroute 150.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 150.1.5.5

  1 132.1.35.5 28 msec *  28 msec
Rack1R3#traceroute 132.1.5.5 ttl 1 10

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.35.5 32 msec *  28 msec
Rack1R3#

It may seem like everything is working now but there is actually another problem that we need to resolve. R6 is not getting the external EIGRP routes originated by R5′s.

Rack1R6#show ip route 132.1.5.0
% Subnet not in table
Rack1R6#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21154560, type internal
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:14:03 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:14:03 ago, via FastEthernet0/0.26
      Route metric is 21154560, traffic share count is 1
      Total delay is 45100 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 3

Rack1R6#

So lets look back at the first router who should be receiving them and view it’s routing table.

Rack1R3#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2560512256, type external
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 00:43:58 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 00:43:58 ago, via Serial1/1.1
      Route metric is 2560512256, traffic share count is 1
      Total delay is 20010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Rack1R3#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 20640000, type internal
  Redistributing via ospf 1, eigrp 10
  Advertised by ospf 1 subnets
  Last update from 132.1.35.5 on Serial1/1.1, 20:48:19 ago
  Routing Descriptor Blocks:
  * 132.1.35.5, from 132.1.35.5, 20:48:19 ago, via Serial1/1.1
      Route metric is 20640000, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 1

Rack1R3#

So R3 has them. Next lets go to R2 and view it’s routing table.

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:02:36 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:02:36 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#show ip route 150.1.5.0
Routing entry for 150.1.5.0/24
  Known via "eigrp 10", distance 90, metric 21152000, type internal
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 21:14:51 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 21:14:51 ago, via Serial0/1
      Route metric is 21152000, traffic share count is 1
      Total delay is 45000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 5/255, Hops 2

Rack1R2#

R2 has the external EIGRP route (R5′s Ethernet0/0) as an OSPF route and the internal EIGRP route (R5′s Loopback0) still as an internal EIGRP route. This is what we expect to happen since the OSPF route has an AD of 110 and the external EIGRP route has an AD of 170. But why doesn’t R6 get the 132.1.5.0/24 route? R6 doesn’t get the route because EIGRP is not sending it due to the fact the route isn’t in the routing table as an EIGRP route. This is important to understand so let me repeat it. When EIGRP goes to send an update to it’s neighbors it selects the routes from the IP routing table and not the EIGRP topology table. This is the same behavior as RIP in that the route must be in the routing table as a RIP route or a connected route advertised by RIP before it can be sent. So what routes is EIGRP sending? It’s going to send the directly connected routes that EIGRP is advertising from the network statement under the routing process and the dynamically learned EIGRP routes in the routing table. Of course it will not send the EIGRP routes from the routing table back out the same interface they were learned on due to split horizon. So this is why the 132.1.5.0/24 route does not get advertised onto R6 even though EIGRP has the route from R3 in it’s topology table.

Rack1R2#show ip eigrp topology 132.1.5.0/24
IP-EIGRP (AS 10): Topology entry for 132.1.5.0/24
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
  Routing Descriptor Blocks:
  132.1.23.3 (Serial0/1), from 132.1.23.3, Send flag is 0x0
      Composite metric is (2561024256/2560512256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 40010 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 2
      External data:
        Originating router is 150.1.5.5
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)
Rack1R2#

The goal of any solution to this problem is to ensure that the 132.1.5.0/24 route is installed into R2′s routing table as an EIGRP route. Basically there are a few standard methods we could use to achieve this goal so lets list them out:

1) Administrative distance
2) Filtering
3) Summarization

Using administrative distance there are multiple ways to resolve the problem. Below I’ve listed a few of them.

1) Change the administrative distance of the external EIGRP routes to be lower than the OSPF routes on R2.
2) Change the administrative distance of the external OSPF routes to be higher than the external EIGRP routes on R2.
3) Change the administrative distance for all of the OSPF routes to be higher than the external EIGRP routes on R2.
4) Change the administrative distance of just the OSPF routes originated by R3 on R2.
5) Change the administrative distance of just the 132.1.5.0/24 OSPF route on R2.
6) Change the administrative distance of just the 132.1.5.0/24 OSPF route originated by R3 on R2.

As we can see there are a lot of options using AD to ensure the 132.1.5.0/24 gets installed into R2′s routing table as an EIGRP route. If we were to select one of the options, option 6 would be the best. The reason 6 would be the best option is because it’s the most specific option. We normally want to select the most specific solution as we don’t want to implement a solution that could effect other routes. There are actually a couple schools of thought on this and both could be considered correct. The other way of looking at it would be to select the simplest solution regardless of what other routes it effects. Personally I prefer to select the most precise solution assuming that it’s not overly complicated.

Let’s look at what option 6 applied to R2:

Rack1R2(config)#ip access-list standard OSPF_AD
Rack1R2(config-std-nacl)#permit 132.1.5.0
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)# distance 171 150.1.3.3 0.0.0.0 OSPF_AD
Rack1R2(config-router)#^Z
Rack1R2#
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:01:24 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:01:24 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip ospf database external 132.1.5.0

            OSPF Router with ID (150.1.2.2) (Process ID 1)

		Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1513
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 132.1.5.0 (External Network Number )
  Advertising Router: 150.1.3.3
  LS Seq Number: 80000001
  Checksum: 0x6F09
  Length: 36
  Network Mask: /24
	Metric Type: 2 (Larger than any link state path)
	TOS: 0
	Metric: 20
	Forward Address: 0.0.0.0
	External Route Tag: 0

Rack1R2#

Now the route is in R2′s routing table as an EIGRP route R6 should have learned it from R2. R6 should also now be able to reach R5 E0/0.

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:02:08 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:02:08 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 4 msec
  2 132.1.23.3 16 msec 20 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can see that the administrative distance solution works. Now lets look at the filtering option and remove the administrative distance solution. The simplest filtering option would be to not allow R2 to install the 132.1.5.0/24 OSPF route into it’s routing table.

Rack1R2(config)#ip access-list standard OSPF_FILTER
Rack1R2(config-std-nacl)#deny 132.1.5.0
Rack1R2(config-std-nacl)#permit any
Rack1R2(config-std-nacl)#router ospf 1
Rack1R2(config-router)#distribute-list OSPF_FILTER in
Rack1R2(config-router)#^Z
Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:06 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:06 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#

The next option we listed was to use summarization. Before we do that I’ll remove the distribute list and then summarize the 132.1.5.0/24 route to 132.1.4.0/23 when it’s advertised by OSPF on R3. By doing this R2 will receive the 132.1.5.0/24 via external EIGRP from R3 over the serial and the 132.1.4.0/23 via OSPF from R3 over the Frame Relay link. Since the external EIGRP route is more specific R2 will use it to reach R5′s E0/0 interface and in turn advertise the route onto R6.

Rack1R3(config)#router ospf 1
Rack1R3(config-router)#summary-address 132.1.4.0 255.255.254.0

Rack1R2#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561024256, type external
  Redistributing via eigrp 10
  Last update from 132.1.23.3 on Serial0/1, 00:00:21 ago
  Routing Descriptor Blocks:
  * 132.1.23.3, from 132.1.23.3, 00:00:21 ago, via Serial0/1
      Route metric is 2561024256, traffic share count is 1
      Total delay is 40010 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 2

Rack1R2#show ip route 132.1.4.0
Routing entry for 132.1.4.0/23
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 64
  Last update from 132.1.0.3 on Serial0/0, 00:00:26 ago
  Routing Descriptor Blocks:
  * 132.1.0.3, from 150.1.3.3, 00:00:26 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R2#

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:39 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:39 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 0 msec 4 msec 0 msec
  2 132.1.23.3 16 msec 16 msec 16 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

Technically we could have not allowed the 132.1.5.0/24 route from being redistributed into OSPF on R3 by filtering it with a route-map. Additionally we could have also used the “not-advertise” option on the summary command to summarize the route but not advertise. This is basically just a different way of filtering since the not-advertise option summarizes the routes but doesn’t advertise the summary.

To this point we have achieve full IP reachability but we have not met the requirements of the task. The task stated that redistribution should be done on both R2 and R3. We’ve only done it on R3. Now we need to perform redistribution on R2. We will need to implement whatever solution we used on R3 on R2.

Rack1R2(config)#router ospf 1
Rack1R2(config-router)#redistribute eigrp 10 subnets
Rack1R2(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R2(config-router)#
Rack1R2(config-router)#router eigrp 1
Rack1R2(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R2(config-router)#

We can now verify that we still have reachability from R6:

Rack1R6#show ip route 132.1.5.0
Routing entry for 132.1.5.0/24
  Known via "eigrp 10", distance 170, metric 2561026816, type external
  Redistributing via eigrp 10
  Last update from 132.1.26.2 on FastEthernet0/0.26, 00:00:04 ago
  Routing Descriptor Blocks:
  * 132.1.26.2, from 132.1.26.2, 00:00:04 ago, via FastEthernet0/0.26
      Route metric is 2561026816, traffic share count is 1
      Total delay is 40110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 3

Rack1R6#traceroute 132.1.5.5   

Type escape sequence to abort.
Tracing the route to 132.1.5.5

  1 132.1.26.2 4 msec 0 msec 4 msec
  2 132.1.23.3 16 msec 16 msec 20 msec
  3 132.1.35.5 48 msec *  44 msec
Rack1R6#

We can now do a full reachabilty test to ensure everything is reachable. We will also need to do another reachabilty test when the backup link is active. Before we do that we should implement the same solution we used to stop the routing loop on R2 and R3 on R4. We do this because when the Frame Relay link between R3 and R5 is down the 132.1.5.0/24 route will be redistributed into OSPF on R4.

Rack1R4(config)#router ospf 1
Rack1R4(config-router)#redistribute eigrp 10 subnets
Rack1R4(config-router)#summary-address 132.1.4.0 255.255.254.0
Rack1R4(config-router)#
Rack1R4(config-router)#router eigrp 1
Rack1R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
Rack1R4(config-router)#

I need to add that for simplicity I only discussed the solution in regards to the 132.1.5.0/24 network but in the full solution we would need to consider the other network that is being redistributed into EIGRP on R5 (192.10.1.0/24). Also you may have noticed that the routing loop problem only occurred because a previous task asked us to redistributed the connected Ethernet interfaces into EIGRP on R5. If we would have just solved that 2 point task by advertising it natively using network statements we wouldn’t have had any routing loop problems and only lost the 2 points ;-)

Lastly you will find similar in-depth discussions added to the new IEWB-RS Volume II version 5 in regards to route redistribution. It’s important that everyone understands not only the solution we chose but what problems the solution is resolving along with any other possible solutions.

Tags: , , ,

Jul
19

The tutorial presented below is a small excerpt from the “System Management” section of beta IEWB-RS Vol I version 5.

SNMPv3 protocol a security model, defining new concepts to replace the old community-based pseudo-authentication and provide communication privacy by means of encryption. The new concepts are: user, group and security level. A group defines the access policy for a set of users. An access policy defines which SNMP objects can be accessed for reading and writing or which SNMP objects can generate notifications to the members of a group. Policy is defined by associating the respective read, write or notify view with a group. By using a notify view, a group determines the list of notifications its users can receive. A group also defines the security model and security level for its users.

Essentially, all groups form a table, which maps users to their read/write/notify views and security models. Note that if a group is defined without a read view than all objects are available to read. Contrary to that, if no write or notify view is defined, no write access is granted and no objects can send notifications to members of the group. The notify view is usually not configured manually. Rather, it’s added by the snmp-server host command automatically, when a users in a group is bound to a notification target host. Note that SNMP will use the username configured with snmp-server host along with the security model specified to authenticate and possibly encrypt the notifications. If the security model is set to «noauth» then a plain username is sent in a manner resembling the old community string.

The following security models exist: SNMPv1, SNMPv2, SNMPv3. The following security levels exits: “noAuthNoPriv” (no authentiation and no encryption – noauth keyword in CLI), “AuthNoPriv” (messages are authenticated but not encrypted – auth keyword in CLI), “AuthPriv” (messages are authenticated and encrypted – priv keyword in CLI). SNMPv1 and SNMPv2 models only support the “noAuthNoPriv” model since they use plain community string to match the incoming packets. The SNMPv3 implementations could be configured to use either of the models on per-group basis (in case if “noAuthNoPriv” is configured, username serves as a replacement for community string). All users sharing a group utilize the same security model, however, the specific model settings (password, encryption key) are sep per-user. Note that SNMPv3 does not send passwords in clear-text and uses hash-based authentication with either MD5 or SHA1 functions (HMAC authentication – the packet conted is hashed along with authentication key to produce the authentication string). For encryption, statically configured keys are used along with DES56 symmetric cipher (that mean the same key should be configured on NMS for the particular user).

Consider the example below. Three groups are created. Groups «NORMAL» and «RESTRICTED» are used to control remote users access and group «TRAP» is used to send notifications. Note that only read-view is specified for group “RESTRICTED” and it’s limited to IfEntry fields for a fixed interface index. The group «RESTRICTED» has an access-list applied to control the NMS stations the users can access from. Note that the groups have different security levels. Next, three users are created, one for each group respectively, with their authentication and encryption keys. Finally, SNMP link up and down notifications are enabled and SNMP trap destination host is configured. This operation automatically creates and assigns the «notify» view for the respective group (will appear in show commands output below).


!
! Access-List to control users in the RESTRICTED group.
!
access-list 99 permit 155.1.146.0 0.0.0.255

!
! Set ifIndexes persistent, for view definition is based on IfIndexes
!
snmp-server ifindex persist 

!
! The first view covers the “ISO” sub-branch and the second one covers
! all “lifEntry” fields for interface with IfIndex 3 (Serial 0/0).
!
snmp-server view NORMAL iso included
snmp-server view RESTRICTED ifEntry.*.3 included

!
! Define three groups. The first one allows to read and write
! into a large portion of the MIB tree. The second one allows reading
! just information specific to Serial 0/0 interface, and limits user
! access based on access-list
!
! The third group is for sending traps. A user belonging to this group
! will be utilized to send trap messages. Its name and password
! will be used to create authentication credentials in a trap message
! and the users privacy password will be used to encrypt the packet.
! Note that this group has NO notify view defined, which is done on
! on purpose. The notify view will be automatically populated when
! notification hosts are configured and bound to users
!

snmp-server group NORMAL v3 priv read NORMAL write NORMAL
snmp-server group RESTRICTED v3 auth read RESTRICTED access 99
snmp-server group TRAP v3 priv

!
! Users, their passwords and encryption keys are defined now
!
snmp-server user NORMAL NORMAL v3 auth sha CISCO priv des56 CISCO
snmp-server user RESTRICTED RESTRICTED v3 auth sha CISCO
snmp-server user TRAP TRAP v3 auth sha CISCO priv des56 CISCO

!
! Allow sending traps and configure a destination host. Note that when
! a host is configured and bound to SNMPv3 username, the corresponding
! group notify view is populated based on traps allowed for this
! particular destination. This is why it’s not required to configure
! the notify view for a group.
!
snmp-server enable traps snmp linkup linkdown
snmp-server host 155.1.146.100 traps version 3 priv TRAP

Perform some basic verifications next using the show commands. Note that SNMPv3 users do not appear in the running configuration for security reason (different management channel) but you can see some information using show snmp users command. Also, pay attention to the automatic view assigned to the “TRAP” group.

Rack1R6#show snmp user 

User name: TRAP
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: TRAP

User name: NORMAL
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: DES
Group-name: NORMAL

User name: RESTRICTED
Engine ID: 80000009030000119221DA80
storage-type: nonvolatile	 active
Authentication Protocol: SHA
Privacy Protocol: None
Group-name: RESTRICTED

Rack1R6#show snmp group
groupname: ILMI                             security model:v1
readview : *ilmi                            writeview: *ilmi
notifyview: 
row status: active

groupname: ILMI                             security model:v2c
readview : *ilmi                            writeview: *ilmi
notifyview: 
row status: active

groupname: TRAP                             security model:v3 noauth
readview :           writeview: 
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F
row status: active

groupname: TRAP                             security model:v3 priv
readview : v1default                        writeview: 
notifyview: 
row status: active

groupname: NORMAL                           security model:v3 priv
readview : NORMAL                           writeview: NORMAL
notifyview: 
row status: active

groupname: RESTRICTED                       security model:v3 auth
readview : RESTRICTED                       writeview: 
notifyview: 
row status: active	access-list: 99

Rack1R6#show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
NORMAL iso - included nonvolatile active
v1default iso - included permanent active
v1default internet.6.3.15 - excluded permanent active
v1default internet.6.3.16 - excluded permanent active
v1default internet.6.3.18 - excluded permanent active
v1default ciscoMgmt.394 - excluded permanent active
v1default ciscoMgmt.395 - excluded permanent active
v1default ciscoMgmt.399 - excluded permanent active
v1default ciscoMgmt.400 - excluded permanent active
RESTRICTED ifEntry.0.3 FF:EF included nonvolatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F iso.2.840.10036 - included volatile active
*tv.FFFFFFFF.FFFFFFFF.FFFFFFFF0F internet - included volatile active

Tags: , , , , , , , ,

Jul
18

IEWB-RS Volume I Version 5 Bridging and Switching labs are now significantly updated with the detailed breakdown sections and are posted on the members site. This section alone is nearly 200 pages now. A sample of them can be viewed here. Questions and comments should be posted on the CCIE R&S Lab Workbook Volume I Version 5.0 section of Internetwork Expert’s Online Community.

Happy labbing!

Brian

Tags: , , ,

Jul
17

Cisco switches run different types of STP protocol, depending on whether the connected port is access, ISL trunk or 802.1q trunk. Natively, Cisco switch runs a separate STP instance for each configured and active VLAN (this is called Per-VLAN Spanning Tree or PVST) and standard IEEE compliant switches run just one instance of STP shared by all VLANs. Due to that reason, a group of switches running IEEE compatible STP protocol is called MST (Mono Spanning Tree) region, not to be confused with MSTP (multiple spanning tree).

Access Ports. Cisco switches run the IEEE version of STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will inter-operate perfectly, joining the respective access VLAN’s STP instance with the IEEE STP instance (MST).

ISL Trunks. Cisco switches run PVST (Per-VLAN Spanning Tree) on ISL trunk links. The same IEEE STP BPDUs are sent for each VLAN, encapsulated with additional ISL header, which also carries the VLAN number. The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.

802.1q Trunks. Cisco switches run PVST+ (Per VLAN Spanning Tree Plus) on 802.1q trunks. This is where things are getting a bit complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST BPDUs across MST region to connect to other Cisco switches across the IEEE region. For further consideration, we’ll call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on IEEE side only one STP instance exists, contrary to multiple STP instances of PVST+ region. The first question is: if we want to interoperate with IEEE single tree, which PVST VLAN’s STP instance should be joined with MST? Cisco has chosen VLAN 1 for this purpose. Joined together, instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases:

Case 1: Cisco switch connects to an IEEE switch using a 802.1q trunk with default native VLAN (VLAN 1)

IEEE side sends IEEE STP BPDUs to the IEEE multicast MAC address. These BPDUs are consumed and processed by VLAN 1 STP instance on Cisco switch (PVST+ region). The Cisco switch simply recognizes untagged IEEE BPDUs as belonging to VLAN 1 STP instance.

The PVST+ side (Cisco switch) sends IEEE STP BPDUs corresponding to local VLAN 1 STP to IEEE MAC address as untagged frames across the link. At the same time, special new SSTP (shared spanning tree, synonym to PVST+) BPDUs are being sent to SSTP multicast MAC address “0100.0ccc.cccd” also untagged. These SSTP BPDUs are encapsulated using IEEE 802.2 LLC SNAP header (SSAP=DSAP=”0xAA” and SNAP PID=”0x010B”). These BPDUs carry the same information as the parallel IEEE STP BPDUs for VLAN 1, but have additional fields, notably a special TLV with the source VLAN number. Note that IEEE switches do not interpret the SSTP BPDUs, but simply flood them through the respective VLAN topology. This facilitates BPDU tunneling in case there are other Cisco switches connected to IEEE cloud.

As for non-native VLANs (VLANs 2-4095) Cisco switch sends only SSTP BPDUs, tagged with respective VLAN number and destined to the SSTP MAC address. (Please remember that all SSTP BPDUs carry a VLAN number they belong to). The respective VLAN STP instances are “transparently expanded” across the MST region, considering it as a “virtual hub”. (Note that this may have some traffic engineering implications, since to non-CST VLANs the cost of traversing MSTP region equals to the cost of the link used to connect to the first MSTP switch).

Now the question is, why would Cisco switch send the same VLAN1 BPDU twice – destined to IEEE and SSTP multicast MAC addresses? Isn’t it supposed for the Cisco switch to join its VLAN 1 STP instance with the MST? The reason for sending additional SSTP BPDUs across VLAN 1 is purely informational, to perform consistency checking. The idea is to inform all other potential Cisco switches attached to MST cloud about our native VLAN. The receiving switch will only use IEEE BPDUs for VLAN 1 (CST) computations and will ignore SSTP BPDUs sent on VLAN 1.

For the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0x010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.

Case 2: Cisco switch connects to IEEE switch using 802.1q trunk with non-default native VLAN (e.g VLAN 100).

IEEE switch sends IEEE STP BPDUs to IEEE multicast MAC address and those BPDUs are processed by VLAN 1 (CST) STP instance in the Cisco switch.

PVST+ side (Cisco switch) sends untagged IEEE STP BPDUs corresponding to VLAN 1 (CST) STP to IEEE MAC address across the link. This is done for the purpose of joining the local VLAN 1 instance and the IEEE instance into CST. At the same time, VLAN 1 BPDUs are replicated to SSTP multicast address, tagged with VLAN 1 number (to inform other Cisco switches that VLAN 1 is non-native on our switch). Finally, BPDUs of the native VLAN instance (VLAN 100 in our case) are sent untagged using SSTP encapsulation and destination address. Of course, native VLAN100 BPDUs, (even though they are untagged) carry VLAN number inside a special TLV SSTP header.

As in Case 1 for the remaining non-native VLANs (VLANs 2-4095) Cisco switch sends SSTP BPDU only, tagged with respective VLAN tag and destined to the SSTP MAC address. The other Cisco switches connected to the MSTP cloud receive the SSTP BPDUs and process the using the respective VLAN STP instances.

Consider the diagram below. SW1 and SW2 are Cisco switches, running STP instances for VLANs 1,2 and 3. Router R3 is converted into bridge (CRB mode and the same bridge-group on E0/0 and E0/1 interfaces, using IEEE STP protocol) to simulate an IEEE compatible switch. VLAN 1 STP instances of SW1 and SW2 are joined with STP instance running in R3. VLANs 2 and 3 consider path across R3 as another segment linking SW1 and SW2 and their SSTP information is passed transparently across R3.

pvst-plus-topology

The current situation in the topology is as following:

Rack1SW2#show spanning-tree vlan 1

 VLAN1 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address cc07.00c1.0000
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 32768, address cc02.00c0.0000
  Root port is 44 (FastEthernet1/3), cost of root path is 19
  Topology change flag set, detected flag not set
  Number of topology changes 12 last change occurred 00:00:39 ago
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 44 (FastEthernet1/3) of VLAN1 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.44.
   Designated root has priority 32768, address cc02.00c0.0000
   Designated bridge has priority 32768, address cc02.00c0.0000
   Designated port id is 128.5, designated path cost 0
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 7650, received 2445

 Port 56 (FastEthernet1/15) of VLAN1 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.56.
   Designated root has priority 32768, address cc02.00c0.0000
   Designated bridge has priority 32768, address cc06.00c0.0000
   Designated port id is 128.56, designated path cost 19
   Timers: message age 3, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 7, received 3827

Rack1SW2#show spanning-tree vlan 2

 VLAN2 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 8192, address cc07.00c1.0006
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 8192, address cc06.00c0.0006
  Root port is 44 (FastEthernet1/3), cost of root path is 19
  Topology change flag set, detected flag not set
  Number of topology changes 7 last change occurred 00:00:14 ago
          from FastEthernet1/15
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 44 (FastEthernet1/3) of VLAN2 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.44.
   Designated root has priority 8192, address cc06.00c0.0006
   Designated bridge has priority 8192, address cc06.00c0.0006
   Designated port id is 128.44, designated path cost 0
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 5889, received 372

 Port 56 (FastEthernet1/15) of VLAN2 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.56.
   Designated root has priority 8192, address cc06.00c0.0006
   Designated bridge has priority 8192, address cc06.00c0.0006
   Designated port id is 128.56, designated path cost 0
   Timers: message age 2, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 2, received 3821

Rack1SW2#show spanning-tree vlan 3

 VLAN3 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address cc07.00c1.0001
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 8192, address cc06.00c0.0007
  Root port is 44 (FastEthernet1/3), cost of root path is 19
  Topology change flag set, detected flag not set
  Number of topology changes 4 last change occurred 00:00:16 ago
          from FastEthernet1/15
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 44 (FastEthernet1/3) of VLAN3 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.44.
   Designated root has priority 8192, address cc06.00c0.0007
   Designated bridge has priority 8192, address cc06.00c0.0007
   Designated port id is 128.44, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 3689, received 332

 Port 56 (FastEthernet1/15) of VLAN3 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.56.
   Designated root has priority 8192, address cc06.00c0.0007
   Designated bridge has priority 8192, address cc06.00c0.0007
   Designated port id is 128.56, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 3, received 3832

R3 (the IEEE bridge) is the root for VLAN 1 (CST) and SW1 is the root for VLANs 2 and 3. Note that R3 has no idea about VLANs 2 and 3 and transparently floods SSTP BPDUs which could be seen on SW2 (non-root switch). As it should be, VLAN 1 BPDUs are received as IEEE STP BPDUs and SSTP copies are ignored.

Rack1SW2#debug spanning-tree bpdu
Spanning Tree BPDU debugging is on
Rack1SW2#
STP: VLAN1: config protocol = ieee, packet from FastEthernet1/3  , linktype IEEE_SPANNING , enctype 2, encsize 17
STP: enc 01 80 C2 00 00 00 CC 02 00 C0 00 01 00 26 42 42 03
STP: Data     00000000008000CC0200C00000000000008000CC0200C0000080050000140002000F00
STP: VLAN1 Fa1/3:0000 00 00 00 8000CC0200C00000 00000000 8000CC0200C00000 8005 0000 1400 0200 0F00

STP: VLAN1: config protocol = ieee, packet from FastEthernet1/15  , linktype IEEE_SPANNING , enctype 2, encsize 17
STP: enc 01 80 C2 00 00 00 CC 06 00 C0 F1 0F 00 26 42 42 03
STP: Data     00000000008000CC0200C00000000000138000CC0600C0000080380100140002000F00
STP: VLAN1 Fa1/15:0000 00 00 00 8000CC0200C00000 00000013 8000CC0600C00000 8038 0100 1400 0200 0F00

STP: VLAN3: config protocol = ieee, packet from FastEthernet1/3  , linktype SSTP , enctype 3, encsize 22
STP: enc 01 00 0C CC CC CD CC 06 00 C0 F1 03 00 32 AA AA 03 00 00 0C 01 0B
STP: Data     00000000002000CC0600C00007000000002000CC0600C00007802C0000140002000F00
STP: VLAN3 Fa1/3:0000 00 00 00 2000CC0600C00007 00000000 2000CC0600C00007 802C 0000 1400 0200 0F00

STP: VLAN3: config protocol = ieee, packet from FastEthernet1/15  , linktype SSTP , enctype 3, encsize 22
STP: enc 01 00 0C CC CC CD CC 06 00 C0 F1 0F 00 32 AA AA 03 00 00 0C 01 0B
STP: Data     00000000002000CC0600C00007000000002000CC0600C0000780380000140002000F00
STP: VLAN3 Fa1/15:0000 00 00 00 2000CC0600C00007 00000000 2000CC0600C00007 8038 0000 1400 0200 0F00

STP: VLAN2: config protocol = ieee, packet from FastEthernet1/3  , linktype SSTP , enctype 3, encsize 22
STP: enc 01 00 0C CC CC CD CC 06 00 C0 F1 03 00 32 AA AA 03 00 00 0C 01 0B
STP: Data     00000000002000CC0600C00006000000002000CC0600C00006802C0000140002000F00
STP: VLAN2 Fa1/3:0000 00 00 00 2000CC0600C00006 00000000 2000CC0600C00006 802C 0000 1400 0200 0F00
STP: VLAN2: config protocol = ieee, packet from FastEthernet1/15  , linktype SSTP , enctype 3, encsize 22
STP: enc 01 00 0C CC CC CD CC 06 00 C0 F1 0F 00 32 AA AA 03 00 00 0C 01 0B

Now let’s see how consistency checking is performed by PVST+.

Case 1: Change the native VLAN on SW1 connection to R3:

SW1:
interface FastEthernet 1/3
 switchport trunk native vlan 2

Rack1SW2#
%SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 2 on FastEthernet1/3 VLAN1.

%SPANTREE-2-BLOCK_PVID_PEER: Blocking FastEthernet1/3 on VLAN2. Inconsistent peer vlan.PVST+: restarted the forward delay timer for FastEthernet1/3

%SPANTREE-2-BLOCK_PVID_LOCAL: Blocking FastEthernet1/3 on VLAN1. Inconsistent local vlan.PVST+: restarted the forward delay timer for FastEthernet1/3

Note that SW2 detects untagged packet with VLAN ID 2, which does not correspond to the locally configured default native VLAN 1. The corresponding port is put in «inconsistent» state. The reason SW2 detects this condition (and not SW1) is because SW1 sending SSTP BPDUs and SW2 is not (it receives superios BPDUs). As soon as native VLAN is converted back to «1» on SW1, consistency is restored:

%SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet1/3 on VLAN2. Port consistency restored.

%SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet1/3 on VLAN1. Port consistency restored. PVST+:Inconsistency timer expired. inconsistency 0
                 cleared for FastEthernet1/3
 PVST+:Inconsistency timer expired. inconsistency 0
                 cleared for FastEthernet1/3

It is also possible to restore consistency by making VLAN 2 native on SW2 connection as well.

Case 2: Convert SW2 connection to R3 into an access-port in VLAN2:

SW2:
interface FastEthernet 1/3
 switchport access vlan 2
 switchport mode access

Rack1SW2#
%SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet1/3 VLAN2.
%SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet1/3 on VLAN2. Inconsistent port type.PVST+: restarted the forward delay timer for FastEthernet1/3

Now the access port receives untagged SSTP BPDUs from SW1 with VLAN ID TLV equal to 1. Since this does not match the locally configured VLAN, the port is declared «type-inconsistent» – the other side is trunk and the local side is an access port.

Note that it is still possible to configure the access port in VLAN1 if the other switch trunks are all using the default native VLAN. This way, only CST is expanded through the MST region and joined with VLAN1 STP instance in SW2. To summarize, if you have a group of Cisco switches connected to the same MSTP cloud (other vendor’s switches) observe the following rules:

1) Use the same interface types – i.e. either all switches are connected using access ports or using trunk ports.

2) Ensure Native VLAN (PVID) is the same on all trunks used to connect to an MST region.

Now let’s see the implications that arise from the fact that non-CST VLANs see the MST region as simply a link or a “hub”. Based on that fact, it is possible to adjust priority values on not physically directly connected switches and influence root port election. For example, set the port priority of direct connection between SW1 and SW2 (port FastEthernet 1/15 to 64 (the default is 128):

SW1:
interface FastEthernet 1/15
 spanning-tree port-priority 64

Rack1SW2#show spanning-tree vlan 2

 VLAN2 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 8192, address cc07.00c1.0006
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 8192, address cc06.00c0.0006
  Root port is 56 (FastEthernet1/15), cost of root path is 19
  Topology change flag not set, detected flag not set
  Number of topology changes 15 last change occurred 00:07:22 ago
          from FastEthernet1/3
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 44 (FastEthernet1/3) of VLAN2 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.44.
   Designated root has priority 8192, address cc06.00c0.0006
   Designated bridge has priority 8192, address cc06.00c0.0006
   Designated port id is 128.44, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   BPDU: sent 0, received 8

 Port 56 (FastEthernet1/15) of VLAN2 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.56.
   Designated root has priority 8192, address cc06.00c0.0006
   Designated bridge has priority 8192, address cc06.00c0.0006
   Designated port id is 64.56, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 3
   BPDU: sent 9, received 4683

Note that in above output, on both ports (root and alternative) we see the same designated bridge (SW1) – even though SW2 directly connects to R3 using port FastEthernet 1/3. Now let’s make port Fa 1/3 of SW2 the root port by adjust the priority of port connecting SW1 to R3:

SW1:
interface FastEthernet 1/3
 spanning-tree port-priority 32

Rack1SW2#show spanning-tree vlan 3

 VLAN3 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 32768, address cc07.00c1.0001
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 8192, address cc06.00c0.0007
  Root port is 44 (FastEthernet1/3), cost of root path is 19
  Topology change flag set, detected flag not set
  Number of topology changes 6 last change occurred 00:00:31 ago
          from FastEthernet1/15
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 44 (FastEthernet1/3) of VLAN3 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.44.
   Designated root has priority 8192, address cc06.00c0.0007
   Designated bridge has priority 8192, address cc06.00c0.0007
   Designated port id is 32.44, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   BPDU: sent 1, received 170

 Port 56 (FastEthernet1/15) of VLAN3 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.56.
   Designated root has priority 8192, address cc06.00c0.0007
   Designated bridge has priority 8192, address cc06.00c0.0007
   Designated port id is 64.56, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 3
   BPDU: sent 4, received 4850

To recap what has been said in a few words: PVST+ is used on 802.1q trunks to tunnel PVST instances across an MST cloud and build a CST consisting of PVST VLAN 1 and IEEE MST. PVST+ BPDUs contain special TLV with the source VLAN ID, which allows interconnected switches to detect inconsitencies or misconfigurations.

Tags: , , , , ,

Jul
15

Look at the following NAT scenario (thanks to Huan Pham on Groupstudy for the example). R2 is configured to translate R1 Loopback0 IP address to one of it’s own Loopback0 IP addresses:

R2:
ip nat inside source static 150.1.1.1 150.1.2.100
!
interface Serial 0/1
 ip nat inside
!
inerface FastEthernet 0/0
 ip nat outside

All hosts behind Ethernet segment can reach R1 using the IP address “150.1.2.100”. Now the question is to make a user logged in R2 to telnet to “150.1.2.100” and reach R1 Loopback0. Lets start straight with the final working configuration:

R2:
interface Loopback0
 ip nat outside
!
ip nat inside source static 150.1.1.1 150.1.2.100
ip nat outside source static 150.1.2.2 155.1.23.22

!
! Route returning packets from R1 over Loopback0
!
ip route 155.1.23.22 255.255.255.255 150.1.2.254

To verify it, enable the following debugging and telnet to 150.1.2.100 from R2:

Rack1R2#debug ip nat detailed
IP NAT detailed debugging is on

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ... Open

User Access Verification

Password: 

!
! NAT on the outside direction
!
NAT: o: tcp (150.1.2.2, 39064) -> (150.1.2.100, 23) [22225]
NAT: s=150.1.2.2->155.1.23.22, d=150.1.2.100 [22225]
NAT: s=155.1.23.22, d=150.1.2.100->150.1.1.1 [22225]

!
! NAT on the inside direction
!

NAT: i: tcp (150.1.1.1, 23) -> (155.1.23.22, 39064) [0]
NAT: s=150.1.1.1->150.1.2.100, d=155.1.23.22 [0]
NAT: s=150.1.2.100, d=155.1.23.22->150.1.2.2 [0]

As we can see from this output, the packet leaving Loopback0 is looped back and uses the both static NAT translation: first, to translate it’s source from “150.1.2.2” to “155.1.23.22” and the second to translate it’s destination from “150.1.2.100” to “150.1.1.1”. The resulting packet has src=”155.1.23.22” and dst=”150.1.1.1”.

Then a packet from R1 (src=”150.1.1.1”, dst=”155.1.23.22”) comes back. Since this packet enters NAT inside interface, a routing lookup is performed first, and the static route configured is used to route incoming packet to Loopback0 interface. Without the static route, R2 will attempt to route the packet either to itself (by default) or back to R3 (with no-alias keyword configured for NAT entry). So the static route saves the day, and packet source is translated using NAT inside rule (from “150.1.1.1” to “150.1.2.100”). After that, packet loops back to R2 and has it’s destination translated using NAT outside rule (from “155.1.23.22” to “150.1.2.2”). Looks fine.

Now what would happen if we remove the static route?

R2:
access-list 100 permit tcp any any eq telnet
access-list 100 permit tcp any eq telnet any

Rack1R2#debug ip packet detail 100
IP packet debugging is on (detailed) for access list 100
Rack1R2#debug ip nat detailed
IP NAT detailed debugging is on
Rack1R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Rack1R2(config)#no ip route 155.1.23.22 255.255.255.255 150.1.2.254
Rack1R2(config)#^Z

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ...
!
! TCP SYN packet leaves R2, destination/source translated
!
NAT: o: tcp (150.1.2.2, 45879) -> (150.1.2.100, 23) [14437]
NAT: s=150.1.2.2->155.1.23.22, d=150.1.2.100 [14437]
NAT: s=155.1.23.22, d=150.1.2.100->150.1.1.1 [14437]

IP: tableid=0, s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), len 44, sending
    TCP src=45879, dst=23, seq=1022925953, ack=0, win=4128 SYN
IP: tableid=0, s=150.1.1.1 (Serial0/1), d=155.1.23.22 (Serial0/1), routed via RIB

!
! Reply packet comes back from R1, destined to 155.1.23.22. Since we don’t have
! a static route to send this packet for NAT translation, but we have a local alias
! the router accepts the packet. But the destination address if 155.1.23.22, while
! the TCP session was sourced from 150.1.2.2. Therefore, the router sends an RST.
!
IP: s=150.1.1.1 (Serial0/1), d=155.1.23.22 (Serial0/1), len 44, rcvd 3
    TCP src=23, dst=45879, seq=3088708722, ack=1022925954, win=4128 ACK SYN
IP: tableid=0, s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), routed via FIB

IP: s=155.1.23.22 (local), d=150.1.1.1 (Serial0/1), len 40, sending
    TCP src=45879, dst=23, seq=1022925954, ack=0, win=0 RST

% Connection timed out; remote host not responding

!
! ICMP pings still work! This is because router will accept reply to any of it’s IP addresses
!

Rack1R2#ping 150.1.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/85/173 ms

With the two translations but no static route, the “inside” translation never kicks in (no “NAT: i” message) since the packet is routed to router itself. This is the way inside NAT works, and this breaks TCP connections, but ICMP is still working.

Okay but maybe that special outside translation that changes the IP address of R2 from “150.1.2.2” to “155.1.23.22” is not needed at all? Let’s remove it too, leaving ourselves with just one translation, and test connectivity again:

Rack1R2(config)#no ip nat outside source static 150.1.2.2 155.1.23.22
Rack1R2(config)#^Z
Rack1R2#
NAT: deleting alias for 155.1.23.22
NAT: deleting alias from redundancy list for 155.1.23.22
ipnat_remove_static_cfg: id 35, flag A

Rack1R2#telnet 150.1.2.100
Trying 150.1.2.100 ...
!
! Packet is translated using outside direction.. TCP session to 150.1.2.100
! is redirected to 150.1.1.1
!
NAT: o: tcp (150.1.2.2, 42616) -> (150.1.2.100, 23) [62052]
NAT: s=150.1.2.2, d=150.1.2.100->150.1.1.1 [62052]

IP: tableid=0, s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), len 44, sending
    TCP src=42616, dst=23, seq=874820746, ack=0, win=4128 SYN
IP: tableid=0, s=150.1.1.1 (Serial0/1), d=150.1.2.2 (Loopback0), routed via RIB

!
! A reply arrives.. but it’s sourced from 150.1.1.1 and destined to 150.1.2.2.
! What that means is that R2 attempts to accept packet to it’s own IP address,
! but since it never initiated a connection to 150.1.1.1 (only to 150.1.2.100)
! the response is dropped and RST is sent!
!
IP: s=150.1.1.1 (Serial0/1), d=150.1.2.2, len 44, rcvd 4
    TCP src=23, dst=42616, seq=2431427125, ack=874820747, win=4128 ACK SYN

IP: tableid=0, s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), routed via FIB
IP: s=150.1.2.2 (local), d=150.1.1.1 (Serial0/1), len 40, sending
    TCP src=42616, dst=23, seq=874820747, ack=0, win=0 RST

% Connection timed out; remote host not responding

!
! Pings still work, since router accepts responses from any IP
!
Rack1R2#ping 150.1.2.100

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/64/65 ms
Rack1R2#

Now you see, that in order to make router perform “loopback NAT” you need two NAT rules and a static route. All this is pretty explainable if you look at the way inside and outside NAT work. And if you want more NAT scenarios, watch out for our soon-to-be released “IP Services” section of IEWB-RS VOL1 v5 Beta.

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

Categories

CCIE Bloggers