Showing posts with label switching. Show all posts
Showing posts with label switching. Show all posts

Monday, February 2, 2009

3560 QoS: Per-port per-vlan policing

I know the name is scary, but I do dig Catalyst QoS. This is the second of back-to-back posts on the subject. This is one is a little more complex than classification and decided on a Visio for it:


Per-van policing in the 3560s is different from the 3550s because there is no "match VLAN" clause available. Instead you create hierarchical policies and attach them to the SVI.

Here is the scenario:

VLAN100 will be policed to 64k (192.168.100.0/24)
VLAN200 Will be policed to 128k (192.168.200.0/24)

Because of bursts, I was not able to get these exact rates, but you will see how these policies are applied and the effect they have on traffic flow. Plus you can always play with the burst sizes on your own :)

Here is the tracker I created on R2:

access-list 1 permit 192.168.100.1
access-list 1 permit 192.168.100.3
access-list 2 permit 192.168.200.5
!
class-map match-any VLAN100
match access-group 1
class-map match-any VLAN200
match access-group 2
!
policy-map TRACKER
class VLAN100
class VLAN200
!
interface Ethernet0/0
no ip address
load-interval 30
full-duplex
!
interface Ethernet0/0.100
encapsulation dot1Q 100
ip address 192.168.100.2 255.255.255.0
service-policy input TRACKER
!
interface Ethernet0/0.200
encapsulation dot1Q 200
ip address 192.168.200.2 255.255.255.0
service-policy input TRACKER

All configuration is being done on SW2. There really is not an order of operations to follow, but basically you just need to make sure class-maps and policy-maps are created before you apply them. The logical flow is what you want to get used to. Otherwise you will be jumping into and out of classes and policies, reconfiguring them like I did :)

At our child (aka "second") level we have a class-map that matches the interface and we have our policer. The interface matching here is whats is referred into in the first clause of "per-port per-vlan" policing.

class-map match-all TRUNK
match input-interface FastEthernet0/13
!
policy-map VLAN100-POLICER
class TRUNK
police 64000 12000 exceed-action drop
policy-map VLAN200-POLICER
class TRUNK
police 128000 24000 exceed-action drop

As far as I know, this "bottom" or "second" level class-map can only match input-interface. And this second level policy must be a policer.

Now, at the parent level we create a new class to match IP traffic and then apply our child polices below that. This top-level class must match an ACL (match protocol ip gave me errors when applying the policy).

access-list 100 permit ip any any
!
class-map match-all IP
match access-group 100
!
policy-map VLAN100-PARENT
class IP
set ip precedence 1
service-policy VLAN100-POLICER
policy-map VLAN200-PARENT
class IP
set ip precedence 2
service-policy VLAN200-POLICER

Notice that I have the "set ip precedence" clause in our parent policies. These first level policies are required to have an action. You will get an error message stating this if you try to apply it to the SVI without an action:

SW2(config)#int vlan 100
SW2(config-if)#service-policy input VLAN100-PARENT
%QoS: No action is configured in the policymap VLAN100-PARENT classmap IP, or it is being modified.


So make sure you have set or trust clause in there. Now we can apply them to the SVIs:

mls qos
!
interface FastEthernet0/13

mls qos vlan-based
!
interface Vlan100
no ip address
service-policy input VLAN100-PARENT
!
interface Vlan200
no ip address
service-policy input VLAN200-PARENT

From R1, R3 and R5 I will send a bunch of pings to R2:

R1#ping 192.168.100.2 re 1000000
R3#ping 192.168.100.2 re 1000000
R5#ping 192.168.200.2 re 1000000

Let's look at R2 after a few minutes.

R2#sho policy-map interface e0/0.100 | section VLAN100
Class-map: VLAN100 (match-any)
107819 packets, 12722642 bytes
30 second offered rate 50000 bps
Match: access-group 1
107819 packets, 12722642 bytes
30 second rate 50000 bps

R2#sho policy-map interface e0/0.200 | section VLAN200
Class-map: VLAN200 (match-any)
156873 packets, 18511014 bytes
30 second offered rate 107000 bps
Match: access-group 2
156873 packets, 18511014 bytes
30 second rate 107000 bps

We don't see the limits of 64k and 128k being reached, but the drops on the senders indicate that policing is working. And we can also tell VLAN 200 is getting roughly twice the bandwidth that VLAN 100 is getting. We could get closer to the limit by adjusting the burst sizes appropriately.

Key things to remember:
  • Child classes use match input-interface
  • Child policies use police
  • Parent classes match ACL (I think you can also match dscp, maybe others)
  • Parent policies must have an action (e.g. set or trust)
  • Apply parent policies to SVI
I strongly recommend getting your hands dirty with these configurations if you want to master them. I read a lot about switch qos, but it wasn't until I started playing around with scenarios like this that I got a better understanding of how to do it and what is required. If we truly understand what each QoS method does, then we should have no trouble deciphering what we are asked to do on the lab :)

3560 QoS: VLAN-Based Classification

This is a topic I learned about while reading blogs over at IE. Here is the original:

Comparing Traffic Policing Features in the 3550 and 3560 switches

I have the following topology:

R1----|
R3---SW1---SW2---R2
R5----|

R1,R3 are in vlan 100, 192.168.100.0/24
R5 is in vlan 200, 192.168.200.0/24

R2 is on a trunked port with the following configuration:

interface Ethernet0/0.100
encapsulation dot1Q 100
ip address 192.168.100.2 255.255.255.0
ip accounting precedence input
no snmp trap link-status
!
interface Ethernet0/0.200
encapsulation dot1Q 200
ip address 192.168.200.2 255.255.255.0
ip accounting precedence input
no snmp trap link-status

On SW2 we will enable vlan-based qos and then mark traffic based on ACLs. First we make the ACLs:

ip access-list extended ICMP
permit icmp any any
ip access-list extended TCP
permit tcp any any

Next we make our class-maps and policy-maps:

class-map match-all ICMP
match access-group name ICMP
class-map match-all TCP
match access-group name TCP

policy-map VLAN
class TCP
set ip precedence 5
class ICMP
set ip precedence 3

Next enable mls qos, vlan-based qos and apply the policy to an SVI. Note that the SVI does not need an IP address:

mls qos

int f0/13
interface FastEthernet0/13
switchport trunk encapsulation dot1q
switchport trunk native vlan 50
switchport mode trunk
mls qos vlan-based

int vlan 100
service-policy input VLAN
int vlan 200
service-policy input VLAN

Now run some tests. Here I Ping and Telnet from R5, telnet from R1 and then ping from R3:

R5#ping 192.168.200.2 rep 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 192.168.200.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/3/4 ms
R5#

R5#telnet 192.168.200.2
Trying 192.168.200.2 ... Open

R2>exit

[Connection to 192.168.200.2 closed by foreign host]
R5#

R1#telnet 192.168.100.2
Trying 192.168.100.2 ... Open

R2>exit

[Connection to 192.168.100.2 closed by foreign host]
R1#

R3#ping 192.168.100.2 re 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 1/3/4 ms
R3#

Verify on R2:

R2#sho int precedence
Ethernet0/0.100
Input
Precedence 3: 50 packets, 5900 bytes
Precedence 5: 46 packets, 2953 bytes
Ethernet0/0.200
Input
Precedence 3: 100 packets, 11800 bytes
Precedence 5: 15 packets, 969 bytes
R2#

Saturday, January 31, 2009

RSPAN between 3550 and 3560 - Multiple Sources

Topology is as follows:

R5----SW1----SW2----SW4----R4/R6

R4 and R6 are on VLAN 300, 192.168.250.0/24 subnet
R5 is on VLAN 100, connected to port f0/5 of SW1
Inter-switch links are dot1q trunks
I will set up RSPAN between the switches and use debug ip packet with an ACL to verify.

3550 is the source:

SW4(config)#vlan 999
SW4(config-vlan)#remote-span
SW4(config)#monitor session 1 source vlan 300 rx
SW4(config)#monitor session 1 destination remote vlan 999 reflector-port f0/12


3560 is connected to the monitor:

SW1(config)#monitor session 1 source remote vlan 999
SW1(config)#monitor session 1 destination interface f0/12


On R5 We can verify like this:

R5(config)#access-list 1 permit 192.168.250.4 0.0.0.0
R5(config)#access-list 1 permit 192.168.250.6 0.0.0.0
R5(config)#no service timestamps debug
R5#debug ip packet 1 detail
IP packet debugging is on (detailed) for access list 1
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89


Here we can see EIGRP packets from VLAN 300, which verifies our monitoring is working. The only place I specified "remote-span" under a VLAN was the source 3550. However, I have read that that this required on all switches that carry the remote-span VLAN.

Let's add a source on SW2, where R2 is plugged into f0/2. We will put it on a different VLAN just to prove it is working:

SW2(config)#int f0/2
SW2(config-if)#sw a v 150

SW2(config)#vlan 999
SW2(config-vlan)#remote-span

SW2(config)#monitor session 1 source interface f0/2
SW2(config)#monitor session 1 destination remot vlan 999

If we jump to R5, we won't see any packets from R2...hmm...oh yeah, the ACL!

R5(config)#access-list 1 permit 192.168.0.2 0.0.0.0

There we go:

IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0
UDP src=1985, dst=1985
IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.5, len 88, rcvd 0, proto=89
IP: s=192.168.250.4 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89
IP: s=192.168.0.2 (Ethernet0/0), d=224.0.0.2, len 48, rcvd 0
UDP src=1985, dst=1985
IP: s=192.168.250.6 (Ethernet0/0), d=224.0.0.5, len 80, rcvd 0, proto=89


Looks like we got HSRP packets from R2 and OSPF packets from R4 and R6.

Key things to remember:

-Reflector port needed on 3550
-remote-span command used under the RSPAN VLAN. In this example, I only did it on the source, but I would verify that you need it on all devices with this VLAN.
-To allow destination port to connect back to the network use "ingress" keyword on session destination command

Monday, January 26, 2009

Dynamic ARP Inspection with NON-DHCP hosts

The Dynamic ARP Inspection concept is well understood, but sometimes the commands and requirements can be hard to remember. This scenario shows how DAI works with DHCP snooping to block ARP requests from untrusted ports and how NON-DHCP clients can still be apart of the network.

R1,R3 and R5 are all on VLAN100, connected to switch SW1:

R1 = Static host
R3 = DHCP Server
R5 = DHCP client

SW1 has ARP Inspection and DHCP snooping enabled already, with trust enabled on the port connected to R3.

SW1#sho run | inc snoop|arp
ip dhcp snooping vlan 100
ip dhcp snooping
ip arp inspection vlan 100
ip dhcp snooping trust

R5 gets an IP address from R3 and now we have the following entry on SW1:

SW1#sho ip dhcp snooping binding 
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ ----------- ---------- ------------- ---- ---------------
00:00:00:00:00:05 192.168.0.5 86381 dhcp-snooping 100 FastEthernet0/5
Total number of bindings: 1

R5 tries to ping R1 but can't:

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:

*Jan 7 09:36:20.361: IP: tableid=0, s=192.168.0.5 (local), d=192.168.0.1
(Ethernet0/0), routed via RIB

*Jan 7 09:36:20.361: IP: s=192.168.0.5 (local), d=192.168.0.1 (Ethernet0/0),
len 100, sending

*Jan 7 09:36:20.361: ICMP type=8, code=0
*Jan 7 09:36:20.361: IP ARP: creating incomplete entry for IP address:
192.168.0.1 interface Ethernet0/0

*Jan 7 09:36:20.361: IP ARP: sent req src 192.168.0.5 0000.0000.0005,
dst 192.168.0.1 0000.0000.0000 Ethernet0/0

On SW1 we see this:

SW1#debug arp
07:43:49: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa0/1, vlan 100.
([0000.0000.0001/192.168.0.1/0000.0000.0005/192.168.0.5/07:43:49 UTC Mon Mar 1 1993])


SW1 is not allowing the ARP reply from R1 because the port is untrusted in the arp inspection configuration and R1's address is not in the DHCP snooping database. We can see the request make it on R1:

R1#
*Mar 2 00:31:09.685: IP ARP: rcvd req src 192.168.0.5 0000.0000.0005,
dst 192.168.0.1 Ethernet0/0

*Mar 2 00:31:09.685: IP ARP: sent rep src 192.168.0.1 0000.0000.0001,
dst 192.168.0.5 0000.0000.0005 Ethernet0/0

But R5 never gets the reply. For NON-DHCP hosts we can create an ARP ACL and apply it to the DAI configuration:

SW1(config)#arp access-list ARP-TEST
SW1(config-arp-nacl)#permit ip host 192.168.0.1 ?
mac Sender MAC address
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac ?
H.H.H Sender MAC address
any Any MAC address
host Single Sender host
SW1(config-arp-nacl)#permit ip host 192.168.0.1 mac host 0000.0000.0001
SW1(config-arp-nacl)#exit
SW1(config)#ip arp inspection filter ARP-TEST vlan 100

Now let's ping:

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 8/9/12 ms
R5#

There is another option for the DAI filter and that is "static".

SW1(config)#ip arp inspection filter ARP-TEST vlan 100 ?
static Apply the ACL statically


If we applied this argument to the command, DAI would only check the ARP ACL and not fallback to the DHCP snooping database. That would prevent R5 ARPs from being allowed:

SW1(config)#ip arp inspection filter ARP-TEST vlan 100 static

R5#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#

Check debugs on SW1:

SW1#
07:52:53: %SW_DAI-4-ACL_DENY: 1 Invalid ARPs (Req) on Fa0/5, vlan 100.
([0000.0000.0005/192.168.0.5/0000.0000.0000/192.168.0.1/07:52:53 UTC Mon Mar 1 1993])


Requests are being denied inbound on f0/5 now.

Wednesday, January 14, 2009

STP: UplinkFast and BackBoneFast

This is I lab made to get familiar with the two STP features Uplinkfast and Backbonefast. RSTP (802.1w) includes these features but I don't seem to get the BackboneFast behavior when using "spanning-tree mode rapid-pvst+".

These features are similar but they are used to provide fast convergence in different scenarios depending on where the failure is in the STP toplogy.

Here is Topology #1 with SW1 configured as Root for VLAN13 where R1 and R4 reside. The Red Xes mark where STP is blocking:


Without Uplinkfast or Backbonefast enabled, lets see how long it takes STP to converge if port 13 on SW2 is shut:

R4 starts the ping while we shut the port on SW2

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!................!!!!!!

We missed about 16 pings and our topology has now converged. Let's enable UplinkFast on SW2, SW3 and SW4 and test again:

SW2(config)#spanning-tree uplinkfast
SW3(config)#spanning-tree uplinkfast
SW4(config)#spanning-tree uplinkfast


When you re-enable Port 13 on SW2, it takes awhile to come back up. It doesn't move through the LIS and LRN states according to the output but it will come up and you will see this message:

02:31:17: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0013 FastEthernet0/13 moved to Forwarding (UplinkFast)

Now Let's ping from R4 again and the shut port 13 on SW2:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!

One ping lost - WOW! Very fast. Let's build upon this failed scenario and look our new topology. Now we have SW2 forwarding through SW4 on it's way to the root SW1.

Let's see how long it takes to converge if we shut port 13 on SW4:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We miss about 9 pings here. What happened? Well in short, when SW4 path to root went down, it started thinking that it was the new root. This caused a new STP election to occur and SW4 finally had to wait until it heard the new SW1 BPDUs from SW1 > SW3 > SW2 > SW4.

BackboneFast can speed up this process, when SW2 starts hearing this inferior BPDUS from SW4 (who is cliaming to be root when port 13 goes down") and special query process takes place to speed up convergence. Let's enable it and check the pings again. This goes on all switches.

SW1(config)#spann backbonefast
SW2(config)#spann backbonefast
SW3(config)#spann backbonefast
SW4(config)#spann backbonefast

R4#ping 2001:13::1 re 1000000

Type escape sequence to abort.
Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Rapid Spanning Tree Protocol (802.1w) includes these features natively. In failover scenario #2 (shutting port 13 on SW4), only backbonefast provided quick convergence while Rapid-PVST+ did not. If have any ideas why, please let me know.

Friday, January 9, 2009

Blocking traffic to random unicast MAC addresses

Ran into this command today. Never even knew about it:

Rack1SW1(config)#int f0/22
Rack1SW1(config-if)#switchport ?
access Set access mode characteristics of the interface
backup Set backup for the interface
block Disable forwarding of unknown uni/multi cast addresses
host Set port host
mode Set trunking mode of the interface
nonegotiate Device will not engage in negotiation protocol on this
interface
port-security Security related command
priority Set appliance 802.1p priority
private-vlan Set the private VLAN configuration
protected Configure an interface to be a protected port
trunk Set trunking characteristics of the interface
voice Voice appliance attributes


Rack1SW1(config-if)#switchport block unicast
Rack1SW1(config-if)#switchport block multicast


From the DocCD:

"By default, the switch floods packets with unknown destination MAC addresses out of all ports. If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can block a port (protected or nonprotected) from flooding unknown unicast or multicast packets to other ports."

Configuring Port Blocking

Tuesday, December 23, 2008

Making a VLAN IPv6 only

Here is the simple topology for this lab. R1 and R2 are on VLAN 12. VLAN12 needs to be IPv6 only. We test this my assigning IPv4 and IPv6 addresses to both routers and then pinging.

R1---SW1---SW2---R2

R1:

IPv4: 192.168.12.1/24
IPv6: 2001::1/64

R2:

IPv4: 192.168.12.2/24
IPv6: 2001::2/64

Making a vlan IPv6 only requires more configuration than I previously thought. This was my first attempt. On all switches:

mac access-list extended IPv6
permit any any 0x86DD 0x0
vlan access-map IPv6only 10
action forward
match mac address IPv6
vlan filter IPv6only vlan-list 12


So R1 pings R2:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 192.168.12.2


But wait, let's remove the filter, ping, add the filter back, and ping again.

SW1(config)#no vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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

SW1(config)#vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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


R1 can still ping. What happened? Well the original filter wasn't blocking IP, it was only blocking ARP packets. Remember MAC access-lists do not have an implicit deny for the IP ethertype but they do have an implicit deny for all the other ethertypes. So once we removed the filter and allowed ARP through, R1 was able to ping R2 when the filtered was applied.

To make the vlan IPv6 only I had to specify a drop action in an empty access-map statement:

SW1(config)#vlan access-map IPv6only 20
SW1(config-access-map)# action drop


R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#


But wait, let's check out spanning-tree:

SW1#sho spanning-tree vlan 12 | inc root
This bridge is the root
SW2#show spanning-tree vlan 12 | inc root
This bridge is the root


This is bad because both switches forward out all ports when they think they are root. If we had multiple links between these switches, we would have a loop. You may start seeing these messages:

SW2#
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 00b0.6410.3901 in vlan 12 is flapping between port Fa0/13 and port Fa0/14
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 0007.eb14.4f81 in vlan 12 is flapping between port Fa0/13 and port Fa0/14


We need to allow STP bpdu's in our original MAC access-list. Do this now:

SW1(config)#mac access-list extended IPv6
SW1(config-ext-macl)#permit any any lsap 0xAAAA 0x0


Now we see SW2 blocking on the port f0/14 (for VLANs 1 and 12):

SW2#sho span | inc BLK
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/14 Altn BLK 19 128.16 P2p


Verify R1 can ping R2 via IPv6 and not IPv4:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 2001::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
R1#


I used 0xAAAA because this what lsap type PVST uses. I don't know where I got this but I think I saw it on GS somehwere. I have also seen 0x4242 used but I think this is for normal STP (802.1d). In any case, only the 0xAAAA worked for me.

Monday, December 22, 2008

Extended Range VLAN - FAIL

I was reading an old post on CCIE talk about extended range vlans and I learned something new. The post is here: CCIE Talk

If a Catalyst switch has any routed ports then it uses an extended vlan as an "internal vlan" for that port. Why? I don't know but it's something to take caution with if you run into any issues.

Check it out:

SW1#sho vlan internal usage

VLAN Usage
---- --------------------


Now let's create a routed port:

SW1(config)#int f0/24
SW1(config-if)#no sw


Now we have VLAN 1006 taken up:

SW1#sho vlan internal usage

VLAN Usage
---- --------------------
1006 FastEthernet0/24

SW1#


What happens if we try to create or modify VLAN 1006? Let's see:

SW1(config)#vlan 1006
SW1(config-vlan)#exit
% Failed to create VLANs 1006
VLAN(s) not available in Port Manager.
%Failed to commit extended VLAN(s) changes.
00:06:13: %PM-4-EXT_VLAN_INUSE: VLAN 1006 currently in use by FastEthernet0/24
00:06:13: %SW_VLAN-4-VLAN_CREATE_FAIL: Failed to create VLANs 1006: VLAN(s) not available in Port Manager
SW1(config)#


FAIL. What if we were supposed to use VLAN 1006? Shut it down, enable VLAN 1006, then re-enable the port.

SW1(config)#int f0/24
SW1(config-if)#shut
SW1(config)#do show vlan internal usa

VLAN Usage
---- --------------------

SW1(config)#vlan 1006
SW1(config-vlan)#exit
SW1(config)#int f0/24
SW1(config-if)#no shut
SW1(config-if)#exit
SW1(config)#do show vlan internal usa

VLAN Usage
---- --------------------
1007 FastEthernet0/24


The switch uses the next number.

Friday, December 19, 2008

IP Source Guard

I was reading through the 3560 Configuration guide looking for things to lab and I came up with this. I already had DHCP snooping configured from my last lab so it was real easy.

Topology:

R1---SW1---R3

R1 has an address via DHCP:

R1#show ip int brief | ex unas
Ethernet0/0 192.168.12.1 YES DHCP up up


R1 can ping R3 on it's subnet:

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms


Sw1 has dhcp snooping already enabled. Here we configure IP source guard:

SW1(config)#int f0/1
SW1(config-if)#ip verify source


Now on R1 if we change the IP address, we cannot ping anymore:

R1(config)#int e0/0
R1(config-if)#ip address 192.168.12.100 255.255.255.0
R1(config-if)#^Z

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)


Verify IP source guard is in effect on SW1:

SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- -----------------
Fa0/1 ip active deny-all 12


Set R1 to get address via DHCP:

R1(config)#int e0/0
R1(config-if)#ip address dhcp
*Mar 1 02:53:06.259: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address 192.168.12.4, mask 255.255.255.0, hostname R1


Now R1 can ping again:

R1#ping 192.168.12.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms


Verify on SW1:

SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
--------- ----------- ----------- --------------- -----------------
Fa0/1 ip active 192.168.12.4 12


You can also configure static bindings, but I will probably do that in another blog :)

Monday, December 8, 2008

Two vlans, One Port, No trunk

I recall a task somewhere I don't remember where we needed two vlans on one port but no trunk...in this case you can use a voice vlan for your second vlan. It is very easy to test:

Topology:

R1---SW1---SW2---R2

R1's interface:

interface Ethernet0/0

interface Ethernet0/0.2
encapsulation dot1Q 2
ip address 139.1.2.101 255.255.255.0


SW1:

interface FastEthernet0/1
switchport access vlan 11
switchport voice vlan 2


SW2:

SW2#show cdp ne | in R2
R2 Fas 0/2 135 R S I 3640 Eth 0/0
SW2#

Rack1SW2#show run int f0/2
Building configuration...

Current configuration : 83 bytes
!
interface FastEthernet0/2
switchport access vlan 2
switchport mode access


So let's ping from R1 to R2 (139.1.2.2)

Rack1R1#ping 139.1.2.2

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

Sunday, November 9, 2008

Quick way to see who if you are STP root for a VLAN

I had a task to configure SW1 as root for even vlans and SW2 as root for odd vlans. Here is the way I parsed the "show spanning-tree" command:

Rack1SW1#show spanning-tree | inc VLAN|This
VLAN0001
VLAN0003
VLAN0004
This bridge is the root
VLAN0005
VLAN0007
VLAN0017
VLAN0023
VLAN0028
This bridge is the root
VLAN0038
This bridge is the root
VLAN0056
This bridge is the root
Rack1SW1#

Sunday, November 2, 2008

Some VTP Stuff

Here are some random things I labbed and debugged while configuring VTP.

Topology:

SW4 === SW3 === SW2

SW4 = VTP server
SW3 = VTP transparent
SW2 = VTP client

1) If VTP domain names don't match, then trunk cannot be negotiated:

This is on R3 and R4 while domain names were different, Trunk links were in "dynamic desirable" mode.

12:29:06: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/23 because of VTP domain mismatch.
12:29:06: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/24 because of VTP domain mismatch.


And on R4:

IPeCat4#show int trunk


So we statically configure trunking both sides (or change domain names...more on that later)

IPeCat3(config)#int rang f0/23 - 24
IPeCat3(config-if-range)#sw mo trunk
IPeCat3(config-if-range)#int po 34
% Command exited out of interface range and its sub-modes.
Not executing the command for second and later interfaces
IPeCat3(config-if)#sw mo trunk
IPeCat3(config-if)#

IPeCat3#show int trunk

Port Mode Encapsulation Status Native vlan
Po34 on 802.1q trunking 100


2) Debugging VTP

IPeCat3#debug sw-?
sw-ip-admission sw-vlan

IPeCat3#debug sw-vlan ?
badpmcookies vlan manager incidents of bad PM (Port Manager) cookies
cfg-vlan config vlan
events vlan manager events
ifs vlan manager ifs error tests
management vlan manager management of internal vlans
mapping vlan mapping
notification vlan manager notifications
packets vlan manager packets
redundancy VTP VLAN redundancy
registries vlan manager registries
vtp vtp protocol debugging

IPeCat3#debug sw-vlan vtp ?
events vtp events
packets vtp packets
pruning vtp pruning events
redundancy vtp redundancy
xmit vtp packets transmitted


3) Domain must match for vtp packets to pass through

IPeCat4(config)#vlan 420
IPeCat4(config-vlan)#exit

SW3 denies it:

IPeCat3#
12:34:48: VTP LOG RUNTIME: Dropping packet received on trunk Po34 - not in domain ipexpert
12:34:48: VTP LOG RUNTIME: Dropping packet received on trunk Po34 - not in domain ipexpert
IPeCat3#


SW2 does not know about the VLAN now:

IPeCat2#show vlan id 420
VLAN id 420 not found in current VLAN database
IPeCat2#

We must change domain name on SW3:

IPeCat3(config)#vtp domain ipexpert
Changing VTP domain name from wrong to ipexpert
IPeCat3#show vtp sta | inc Domain
VTP Domain Name : ipexpert
IPeCat3#


(This takes while)

12:37:55: VTP LOG RUNTIME: Relaying packet received on trunk Po34 - in TRANSPARENT MODE (nc = false)
12:37:55: VTP LOG RUNTIME: Relaying packet received on trunk Po34 - in TRANSPARENT MODE (nc = false)


SW2 has the vlan now:

IPeCat2#show vlan | inc 420
420 VLAN0420 active
420 enet 100420 1500 - - - - - 0 0
IPeCat2#

Wednesday, August 27, 2008

L3 etherchannel tunnel

I am gonna start this off by saying that the only way I know to get over my fear of something is to learn to love it. This is how I am learning to conquer layer 2 tunneling. Today was the first day I got an L2 tunneling task to work without using the solution guide. And my solution didn't match but it still worked perfectly!

Here is the topology:

SW3====SW1====SW4

SW3 f0/14-15 connects to SW1 f0/17-18
SW4 f0/14-15 connects to SW1 f0/20-21

SW3 and SW4 need to form an L3 etherchannel. I will start off by explaining my thoughts on how this should work. The only protocol I think we should tunnel is lacp or pagp. Other solutions have dot1q-tunnel and some other stuff but I don't see why those are needed. If I am mistaken...please comment!

So this what I did on SW1:

int range f0/17 - 18, f0/20-21
l2protocol-tunnel point-to-point lacp


Then I configure SW3 and SW4 as such:

int range f0/14-15
shut
no switchport
channel-group 1 mode active
int po 1
no switchport
int range f0/14-15
no shut

The interfaces came up and then came down and this was my message:

%EC-5-L3DONTBNDL2: Fa0/15 suspended: LACP currently not enabled on the remote port.
%EC-5-L3DONTBNDL2: Fa0/14 suspended: LACP currently not enabled on the remote port.

Now I started to think about the tunneling and what could go wrong. I usually always end up with an "l2ptguard error detected" but I was NOT getting that message this time. Instead it just didn't work...

I thought about other labs I did where tunneled packets came back to the same switch over trunks or other ports on the same vlan. This would be bad if SW3 tried to form an etherchannel with itself!

I decided to separate the ports that SW3 and SW4 connected to by vlans. I was allowed to create 1 extra vlan, I knew this was fine because the other set of ports would use native vlan 1.

So I picked one port that connects to SW3 and one that connects to SW4 and put these in vlan 100:

int range f0/17,f0/20
switchport access vlan 100

and waited....

and waited....

Nothing happened. I swear I has this thing in the bag! So I swent to SW3 and SW4 and shut both f0/14-15 down. Then I brought them up again. Then I waited about 15 seconds and what did I see:

%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to up
%LINK-3-UPDOWN: Interface Port-channel1, changed state to up

WOOH OOH! I was at work at the time and you know the looks I got! ;)

SW3#show eth sum | beg Gr
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------
1 Po1(RU) LACP Fa0/14(P) Fa0/15(P)

I know that l2protocol tunneling is still my weakness. And to think how it can affect reachability makes my cringe, but I am gonna learn to love it and hopefully soon I can conquer it.

Thursday, July 17, 2008

Switching - Dot1q and L2 protocol tunneling

This is a pretty fairly simple lab, but I had never done dot1q tunneling so I wanted to keep it simple.

Network:

[R2 ]---vlan 4---------------[sw1]
[sw1]---asymmetric trunk---[sw2]
[sw2]---dot1q trunk---------[sw3]
[sw3]---asymmetric trunk---[sw4]
[sw4]---vlan 4---------------[R4 ]

Here are the relevant configs with descriptions under the interfaces. Note that the R2 and R4 fastethernet interfaces are on the subnet 192.168.0.0/24.

SW1:
!
interface FastEthernet0/2
description to R2 f0/0
switchport access vlan 4
switchport mode access
!
interface FastEthernet0/12
description to SW2 f0/12
switchport trunk encapsulation dot1q
switchport mode trunk


SW2:
!
interface FastEthernet0/12
description to SW1 f0/12
switchport access vlan 30
switchport mode dot1q-tunnel
!
interface FastEthernet0/23
description to SW3 f0/23
switchport trunk encapsulation dot1q
switchport trunk native vlan 23
switchport mode trunk


SW3:
!
interface FastEthernet0/23
description to SW2 f0/23
switchport trunk encapsulation dot1q
switchport trunk native vlan 23
switchport mode trunk
!
interface FastEthernet0/24
description to SW4 f0/24
switchport access vlan 30
switchport mode dot1q-tunnel


SW4:
!
interface FastEthernet0/4
description to R4 f0/0
switchport access vlan 4
switchport mode access
!
interface FastEthernet0/24
description to SW3 f0/24
switchport trunk encapsulation dot1q
switchport mode trunk


Ping from R2 to R4:

R2#ping 192.168.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/52 ms
R2#


Now let's say I want SW1 and SW4 to see each other as CDP neighbors. And I also want SW1 to be a VTP server and SW4 to be a VTP client.

SW2:

interface FastEthernet0/12
description to SW1 f0/12
l2protocol-tunnel cdp
l2protocol-tunnel vtp


SW3:

interface FastEthernet0/24
description to SW4 f0/24
l2protocol-tunnel cdp
l2protocol-tunnel vtp


Verify CDP tunneling, SW1 and SW4 are NOT directly connected!

SW4:

SW4#show cdp ne

Device ID Local Intrfce Holdtme Capability Platform Port ID
SW1 Fas 0/24 125 R S I WS-C3560-2 Fas0/12
R4 Fas 0/4 132 R 3640 Fas0/0


Verify VTP tunneling:

SW1:

SW1(config)#vlan 13
SW1(config-vlan)#name test


SW4:

SW4#show vtp status | inc Oper
VTP Operating Mode : Client

SW4#show vlan brief | inc 13
13 test active

Pretty cool, eh? That's it for now...

Wednesday, July 16, 2008

3550 QoS - Trusting, Mapping and Override

Here's the network:

[R2]---[SW3]---[trunk, native vlan 1]---[SW4]---[R4 ]

R2 sets ip-prec to 2:

interface FastEthernet0/0
ip address 192.168.0.2 255.255.255.0
rate-limit output 16000 8000 8000 conform-action set-prec-transmit 2 exceed-action set-prec-transmit 2


Packet capture show packets still marked when they reach R4 (using Dyngen for routers, binding them to NICs on the PC and then connecting them to the 3550's).

As soon as I enable mls qos on SW3, packets are no longer marked:

SW3(config)#mls qos

To get the 3550 to keep the marking I configure qos trust on the incoming ports:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust


To get the switch to remark the packets, configure cos override:

SW3(config)#int f0/2
SW3(config-if)#mls qos cos override
SW3(config-if)#mls qos cos 4


These packets show up as CS4 on R4. Note that the override command removes the trust command and vice versa:

SW3(config)#int f0/2
SW3(config-if)#mls qos trust


SW3#show run int f0/2
!
interface FastEthernet0/2
switchport mode dynamic desirable
mls qos cos 4
mls qos trust dscp
end


If the trust and "mls qos cos 4" commands exist, the trust takes effect and will not override the DSCP. So the COS4 override mapped to CS4...where does this mapping take place? Here:

SW3#show mls qos maps cos-dscp
Cos-dscp map:
cos: 0 1 2 3 4 5 6 7
--------------------------------
dscp: 0 8 16 24 32 40 48 56


Suppose we want COS4 to be mapped to AF41...which is DSCP 34. We can do this:

SW3(config)#mls qos map cos-dscp ?
<0-63> 8 dscp values separated by spaces
SW3(config)#mls qos map cos-dscp 0 8 16 24 34 40 48 56


Here's part of my wireshark capture in plain text:

Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.2 (192.168.0.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x88 (DSCP 0x22: Assured Forwarding 41; ECN: 0x00)
1000 10.. = Differentiated Services Codepoint: Assured Forwarding 41 (0x22)


Ok here's an interesting one: what happens if I configure QoS on SW4 and set it to trust the COS instead of the DSCP value?

SW4(config)#int f0/24
SW4(config-if)#mls qos trust ?
cos Classify by packet COS
device trusted device class
dscp Classify by packet DSCP
ip-precedence Classify by packet IP precedence

SW4(config-if)#mls qos trust cos


It remarks the packet to CS4 based on the cos-dscp map, of course!