The South African Networkers at Cisco Live! website is online for those who want to have a look. The conference/event/networking symposium is from December 1 – 4, 2008 and registration opens in August. The ticket prices seem steep (unless you are in government, a CCIE or an educator) but from past Cisco events there should be something of value in going.
Tag Archive for 'CCIE'
Since late last week there has been some waves in the online networking community about a post by Robert Williams from CertGuard. Since that post many things have happened, I am however not going to talk about the specific situation, how it is probably affecting the mentioned CCIE etc. Some notable comment can be read from members of the networking community like Colin McNamara, Arden Packeer and Greg Ferro
I have been following the situation and reading responses and trying to figure this out for myself. I am however finding myself with more questions than answers as I try and get information to make an educated decision as to the this whole story. My main questions are around Certguard.
To kick off why this whole thing is upsetting me and probably many other people. I practice what I do on my good name, If it calls for it I spend extra non-billing hours (working days without sleep) keeping my good name in tact with clients who are not happy with a product or service either I or a competitor placed because my good name and the good name of my vendor of choice is important to me. This extends into daily life where dressing appropriately for functions, being on time for meetings (early ussually) and being affable and amiable in company goes to preserving my good name. I have spent time, been careful and made sure my name is not sullied and not dragged through any mud or tarnished by schoolboy playground antics because people buy products and services from people. Basic marketing theory says that word of mouth is the best and worst marketing where one good experience brings maybe one extra customer; one bad experience sends 10 customers away forever. In the end of the day my good name is very important to me because it is my brand and my image. This situation is upsetting because it has to do directly with this concept and the sullying of someone’s good name in a disgraceful very underhanded way.
CertGuard seems to be a self appointed Information Technology (IT) Watchdog where it concerns test taking and certifications. How this is done around the back-end isn’t so clear to me at this point. I have read that they have no affiliation with Cisco or Pearson Vue (I only care about their links with Cisco I don’t much care whether Microsoft or another vendor uses their products/services). Their website isn’t exactly transparent as to all their specifics but I will outline my thoughts and findings below.
I want to know WHAT they do, they say they keep the industry clean by focusing on braindumps websites. For those who don’t know what braindumps are these are basically compiled documents of test questions that may or may not appear in the exams. A braindump is not certified study material according to the agreement you sign every time you take a Cisco exam. The fact remains to me that they aren’t affiliated with Cisco and they make a leap somewhere from “braindumps websites” to “decertifying individuals” that is a bit far fetched and I don’t know how that happens. This leap is more than just bothering me, its annoying me, I have looked through the CertGuard website, done Google Searches and tried asking others but no one knows WHAT they do other than selling a product type service.
Personally I learnt in grade school that cheating was wrong, I received a degree without trying to write crib notes on various body parts to get them into exams (a girl wrote half the theory on her breasts in one exam thinking it was the only place the invigilator wouldn’t look) and I certainly know that unless I know something outright I am not going to pass any exam (sometime down the line I am going to look stupid if I don’t know how to do something I have written an exam on). The company doesn’t seem to be closing down braindump websites but monitoring them, they dont seem affiliated with Cisco to take away a certifications from individuals and they seem to be selling information based products to end-users and not vendors. This whole thing leaves me with more questions than answers.
What CertGuard is doing is great in theory (noble and almost altruistic) protecting the intrinsic value of something like a certification (which is not like a conferred degree) is in everyones interest that is working towards getting that certification. What is rubbing me raw though is what do they actually do? Are they working for a Vendor at a higher level or are they trying to create a new economy for validating online 3rd party course content information? Are they trying to become the de facto “trusted authority” for who you can use for content and who you cant? Or are they none of the above and I’m just to stupid to see what they really do and don’t do.
One of the links in the pecking order that’s also bothering me is how CertGuard can share/give/pass information as a “trusted authority” to Cisco/Vue (other) and as a trusted authority Cisco/Vue acts on the information by tripping someone of a certification (if at all). My concern here is that I have paid a small fortune to get learning material, certifications, hardware and training from Cisco and/or Cisco Partners, I have spent countless hours in front of books, PEC, and at training losing sleep, weekends and time I could have spent focusing on other activities. If a company who is not affiliated with Cisco, recognized by Cisco and was not given a mandate by Cisco starts to act “as-if” they are working on behalf of Cisco I am going to be a very unhappy camper and would hope Cisco Systems and the community at large cuts them down to size instead of siding with them because you may be next.
I am unsure of CertGuards place in the macro network environment and how they interact with the ecosystem at this point. Is this a fear based marketing and advertising ploy in very bad taste to drum up traffic and in the end sales for their products. Network World seems to rubber stamp them and if not endorse them fully by allowing them a place from which to gather an audience. Their website doesn’t clearly state anything substantial about them, I want specifics, facts and concrete information if they are so important to the industry. I want to know that my future as a small fish in a big pond in the network industry isn’t going to be jepordized by some unknown CEO from a company who you know but also dont know what they do (I don’t trust them nor know anything about nor care about them*) turns my world upside down one sunny day.
The modus operandi of using a highly visible public platform in the network industry to blackball a blogger without prior consultation or attempted mediation is uncouth to say the least. This is something that I don’t think I can agree was/is the correct method(s) or acceptable in the least. As a person who is active online, who writes (in my case notes from various sources) and posts them to a blog, my concern is am I going to be the next lamb to slaughter (probably not but the fear is there). As rational or irrational as that is who will be the next target for Mr Williams? If you note their services they offer Blog & Forum Monitoring (feels like big brother is watching).
I certainly don’t get paid for blogging I also don’t know anyone who does, I am certainly not going to jeopardize my future so that someone can take me out at the knees for something because they feel a need to scratch something that itches.
*An online business without a complete website explaining at least Who they are, What they do, How they do it, Where they come from, How they relate to me, Why I should care, Why they should be there and have a Telephone number and Physical address FOR THE REASON I VISITED THE SITE in plain view without the need to search for it or do a whois on the domain in my experience is trying to scam me in some way.
In this case Who is Certguard to me as a Cisco Networker? What does CertGaurd have to do with Cisco? How does Certguard do what they do with relation to Cisco and Cisco Certification and the mechanics of it? Where is their value proposition with relation to Cisco and Cisco Certification? How this relates to my studies and certification process with Cisco? Why this will and will not affect me and my life? Why CertGaurd should be there and exist at all and affect my life? and where can I call someone if they make my life hell and/or buy a plane ticket to come make someones life hell if need be?
Finally I have probably edited this thing a 100 times to get it to say what I want I am adding links to the Disclaimer and if you want to know about me and finally should anyone try and muck me around thus far all posts fall under the following notice:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.
Followup: Ethan Banks is back in action, his blog post can be found here.
Followup: Robert Williams public apology to Ethan Banks and the Network Community.
If the feature talks about trusted/untrusted ports then access ports (facing end-devices or downstream) are untrusted and trunk/other ports (facing distribution/core or upstream) are trusted
DHCP Spoofing and Starvation
DHCP is a protocol that allows end-devices to get network configurations from a central server (router, switch, MS Server). A DHCP server can be spoofed by an attacker whereby end-devices receive network configuration from the attacker DHCP and not the legitimate DHCP server.
The reason why one would want to spoof a DHCP server is because the intruder can configure end-devices with IP Address, Domain Name Service (DNS) and Default Gateway (DG) of their choosing and not the legitimate information; the attacker will then play man in the middle.
Mitigating DHCP Snooping
DHCP Snooping is a Cisco Catalyst feature allowing for configuration of switch ports as either trusted or untrusted so that the ports can respond to DHCP requests. Trusted ports can source all DHCP messages and can host or be an uplink to a DHCP server. Untrusted ports can source requests only. If a rogue device on an untrusted port attempts to send a DHCP response packet, the port is shut down (errdisabled).
Configuration
Step 1:Configure DHCP snooping globally.
switch#configure terminal
switch(config)#ip dhcp snooping
Step 2: Configure Trusted and Untrusted ports.
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#ip dhcp snooping trust
By default all ports are untrusted
Step 3:Configure DHCP Option 82 Insertion.
switch#configure terminal
switch(config)#ip dhcp snooping information option
This is optional and is to let the forwarded DHCP request packet contain information on the switch port where it originated
Step 4:Configure rate limiting on untrusted ports.
switch#configure terminal
switch(config)#interface gigabitethernet 0/2
switch(config-if)#ip dhcp snooping limit rate packets per second rate
Step 5:Configure DHCP snooping for selected VLANs.
switch#configure terminal
switch(config)#ip dhcp snooping vlan number 1,3-6
Step 6:Confirm the configuration
switch#show ip dhcp snooping
STP Comprimises – STP Operation Protection
STP has two protection methods on ports where PortFast has been enabled. In proper configs PortFast will only be enabled on downstream ports (outward facing) that connect to end-devices. As was discussed in previous posts it is an understood theory that Broadcast Packet Data Unit (BPDU) will not come from these interfaces, if this should happen BPDU guard and BPDU filtering provide protection (this could either signal config error or an attack).
- BPDU Guard is used to protect the switched network from problems that may arise from the receipt of BPDUs from ports that they shouldn’t be coming from. This could be from honest mistake or someone trying to add a switch.
- BPDU Filtering affects how the switch acknowledges BPDUs seen on PortFast configured ports. The functionality differs depending on whether it is configured globally or per-port.
- BPDU Root Guard protects against a switch outside the designated network attempting to become the root bridge by blocking it access until the receipt of its BPDUs ceases.
STP Operation Protection – Configuration of BPDU Guard
Step 1:Enable BPDU Guard Globally
switch#configure terminal
switch(config)#spanning-tree portfast bpduguard
Step 2 
isplay BPDU Configuration information
switch#show spanning-tree summary totals
STP Operation Protection – Configuration of BPDU Filtering
As mentioned earlier there are two methods of configuring BPDU Filtering, below are the two methods and the differences in how these implementations will affect configuration
STP Operation Protection – Configuration of BPDU Filtering – Global
switch#configure terminal
switch(config)#spanning-tree portfast bpduguard default
In a valid config, PortFast ports do not receive BPDUs. If a PortFast enabled port receives a BPDU then it signals an invalid config, BPDU Guard puts the port in errdisabled state.
BPDU Filtering has these affects:
- Affects all operational PortFast ports on switches that do not have BPDU filtering configured on the individual ports (i.e. you can have Global and port-based active at the same time)
- If BPDUs are seen, port loses PortFast status, BPDU filtering is disabled, and STP sends and receives BPDUs on the port as it should with other STP ports on a switch.
- Upon startup, the port transmits 10 BPDUs. If this port receives any BPDUs during that time, PortFast and BPDU filtering is disabled.
STP Operation Protection – Configuration of BPDU Filtering – Port
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#spanning-tree bpduguard enable
At the interface level (port-level) you can enable BPDU guard without also enabling PortFast. When the port receives a BPDU it is put into a errdisabled state.
BPDU Filtering has these affects:
- It ignores all BPDUs received.
- It sends no BPDUs.
Config this on ports that connect to known end-points that would/should/will never ever see a BPDU.
AND EXPLICIT configuration of PortFast BPDU filtering on a port that is not connected to an end-device can create bridging loops. The port ignores BPDUs and changes to a forwarding state. This does not happen when PortFast BPDU Filtering is enabled globally. This means that if you config this on a port that may be/is connected to another switch and needs to participate in STP in some way/form then it is always in the forward state.
STP Operation Protection – Configuration of BPDU Filtering – Confirmation
switch#spanning-tree summary totals
Confirming Configuration on a specific port
switch#spanning-tree interface gigabitethernet 0/0 detail
STP Operation Protection – Root Guard
Root Guard is a feature that limits on which switch ports the root bridge can be negotiated on. If a root guard-enabled port receives BPDUs that are better that those of the current root bridge, then the port will transition into a root-inconsistent state (STP listenning state).
Root Guard is configured on a per-port basis, recovery requires no intervention. A root guard port is in an STP-designated port state. When root guard is enabled on a port, the switch does not allow that port to become an STP root port. The port remains an STP-designated port.
Root guard should be enabled on all ports that the root bridge is not anticipated on and never will be.
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 01. Moved to root-inconsistent state
Configuration
Step 1:Enable Root Guard on an interface
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#spanning-tree guard root
Step 2:Verify Root Guard on an interface
switch#show running-config interface gigabitethernet 0/1
Step 3:Verify if any port is in the Root Guard inconsistent state
switch#show spanning-tree inconsistentports
STP Forwarding Loops – Unidirectional Link Detection (UDLD)
A unidirectional link occurs when traffic is transmitted between neighbours in only one direction; this can cause spanning tree loops. UDLD allows detection when this occurs and shuts down the affected interface when it is detected.
UDLD is a layer-2 protocol that works with Layer-1 mechanisms to determine the status of a link. The switch periodically transmits UDLD packets on a UDLD enabled interface; if the packets are not echoed back in a specific time frame, the link is flagged as unidirectional and shut down (for this to work devices on both ends must support UDLD).
UDLD falls outside STP but has benifits to STP in detecting unidirectional links which can cause loops. UDLD can do one of two things depending on whether it is configured as “Normal” or “Aggressive”.
- Normal Mode UDLD changed the port to undetermined when UDLD messages/echoes stop coming back
- Aggressive Mode UDLD errdisables the port after UDLD messages/echoes stop coming back and it makes 8 re-establishing attempts.
UDLD uses MAC 0100.0CCC.CCCC (01-00-0c-cc-cc-cc) with sub-network Access Protocol (SNAP) High Level Data Link Control (HDLC) protocol type 0×0111.
Configuration
Step 1: Enable UDLD
Step 1.1:On fiber and non-fiber (copper) interfaces
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#udld enable
Step 1.2:Globally on Fiber switch interfaces
switch#configure terminal
switch(config)#udld enable
Step 2: Disable UDLD
Step 2.1:On nonfiber interfaces individually
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#no udld enable
Step 2.2:On Fiber interfaces
switch#configure terminal
switch(config)#udld disable
Step 3:Reset all interfaces that have been errdisabled by UDLD
switch#udld reset
Step 4:Verify UDLD
switch#show idld interface gigabitethernet 0/1
STP Forwarding Loops – Loop Guard
Similar to UDLD, Loop Guard grants protection for STP when a link is unidirectional and BPDUs are being sent and not received. Without loop guard a unidirectional link will transition to forwarding when it stops receiving BPDUs. When loop guard is enabled and a link stops receiving BPDUs, the interface will move into a STP loop-inconsistent blocking state.
SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 0/1 in vlan 2. Moved to loop inconsistent state.
When a BPDU is received again on the port, the port will transition to the appropriate state without intervention.
Configuration
Step 5:Enable Loop Guard
Step 5.1:Globally configure Loop Guard
switch#configure terminal
switch(config)#spantree global-default loopguard enable/disable
Step 5.1 
er-Port Loop Guard
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#spanning-tree guard loop
Step 6:Verify Loop Guard
switch#show spantree guard 0/1
E-2-LOOPGUARDBLOCK: port 0/1 restored in vlan 2
Loop guard is enabled on ports that are participating in spanning tree and are redundant at Layer-2. When a switch stops receiving BPDUs on its root or blocking ports, it will transition the ports to loop-inconsistent, which does not pass traffic. Loop Guard is configured per port on, Loop Guard does not work with Root Guard, and should not be enabled on PortFast ports.
With Loopguard and EtherChannel. the first operational port is used for BPDUs; if the link is unidirectional, loop guard transitions ALL links of the channel to loop-inconsistent. This is not desirable because the inherit redundancy gained through channeling is lost.
MAC Spoofing – IP Source Guard
Similar to DHCP snooping, IP Source Guard this feature can be enabled on a untrusted port to prevent IP address Spoofing.
When started all IP traffic on the port is blocked, except DHCP packets that are caputred by the DHCP snooping feature. When a end-device then receives a valid IP Address from the DHCP server, or when a static IP Address is configured by the user, a per-port and VLAN Access Control List (PVACL) is instaled on the port.
This restricts the end-device to those source IP Addresses configured in the binding; any IP traffic with a different source IP address will be dropped.
Step 1:Configure DHCP snooping globally.
switch#configure terminal
switch(config)#ip dhcp snooping
Step 2:Configure DHCP snooping for selected VLANs.
switch#configure terminal
switch(config)#ip dhcp snooping vlan number 1,3-6
Step 3: Configure Trusted and Untrusted ports.
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#ip dhcp snooping trust
By default all ports are untrusted
Step 4:Configure IP Source Guard, Source IP, and Source MAC Address filtering on the Port.
switch#configure terminal
switch(config)#interface gigabitethernet 0/2
switch(config-if)#ip verify source vlan dhcp-snooping port-security
Step 5:Configure rate limiting on untrusted ports.
switch#configure terminal
switch(config)#interface gigabitethernet 0/2
switch(config-if)#ip dhcp snooping limit rate packets per second rate
Step 6 
Optional if not a DHCP End-Device) Configure a static IP Binding on the port.
switch#configure terminal
Switch(config)#ip source binding mac-address vlan vlan-id ip-address interface interface-name
ARP Spoofing
Address Resolution Protocol (ARP) Operation is that a end-device (A) sends a broadcast to determine the MAC Address of a end-device (B) with a particular IP Address. The end-device (B) at that IP Address replies with a MAC Address. The originating end-device (A) caches the ARP response, uses it to populate the destination Layer-2 header and then goes on to send a packet.
By spoofing ARP operation an attacking system then plays man in the middle and appears to be the destination sought by senders. All packets sent to the attacker will be forwarded to the correct end-device after being relayed through the attacking system.
Dynamic ARP Inspection (DIA)
DIA determines the validity of an ARP packet based on a valid MAC address-to-IP Address binding stored in a DHCP snooping database. To ensure validity these actions are taken:
- Forwards ARP packets received on trusted interfaces without any checks.
- Intercepts all ARP packets on untrusted ports.
- Verifies that each intercepted packet has a valid binding before forwarding the packet that can update a local ARP Cahce.
- Drops, logs or drops and logs ARP packets with invalid bindings.
Configuration
Step 0:Enable DHCP Snooping
Step 1:Configure DIA on a VLAN or VLAN Range
switch#configure terminal
switch(config)#ip arp inspection vlan 1,2,3,4,5
Step 2:Enable DIA trust on an interface (sets the interface as trusted)
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#ip arp inspection trust
Step 3:Configures DIA to drop ARP Packets when the IP Addresses are invalid, or when MAC Addresses in the body of the ARP packet do not match the addresses specified in the Ethernet header.
switch#configure terminal
switch(config)#ip arp inspection validate src-mac dst-mac ip
A post to do with DIA can be found at Richard Bannisters CCIE Blog
Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.
VLAN Hopping
VLAN Hopping is a network attack whereby an end-device sends packets to/or collects packets from a VLAN that should not be accessible to that end-device. This is done by tagging the invasive traffic with a specific VLAN ID (VID) or by negotiating a trunk link to send or receive traffic on penetrated VLANs. VLAN hopping can be done by switch spoofing or double tagging.
In a Switch spoofing attack the attacker configures an end-device to spoof itself as a switch (this can be a linux pc). The attack emulates Inter-Switch Link (ISL) or 802.1Q signaling along with Dynamic Trunk Protocol (DTP). This is signaling to attempt to establishing a trunk connection with the company switch.
Any switch port configured with DTP auto, upon receipt of a DTP packet generated by the attacking device, will become a trunk port and then accept traffic destined for any VLAN supported on any trunk on that link. The attacker can then send/collect packets from/to any VLAN.
Double Tagging is another method of VLAN Hopping, this is when a workstation generates frames for two 802.1Q headers, this causes the switch to forward the frames onto a VLAN that would normally be inaccessible to the attacker through legitimate means.
The first switch to encounter the double tagged 802.1Q frame strips the first header frame (native VLAN), and forwards the frame out a trunk link, the second switch then forwards the frame according to the other 802.1Q frame header. Should the tag not match the native VLAN of the attacker, the frame will go untagged and flooded to only the original frame.
Best Practices to Mitigate VLAN Hopping
- Configure all unused ports as access ports so that trunking cannot be negotiated across those links.
- Place all unused ports in the shutdown state and associate them with a VLAN designed for only unused ports, carrying no user data traffic (that means not the Native VLAN either).
- When establishing a trunk link, purposefully configure arguments so that:
- The native VLAN will be different form any data VLANs
- Trunking is set up as “on” rather than as negotiated.
- The specific VLAN range will be carried on the trunk
Configuration
To Mitigate against VLAN hopping attacks the following is the config. First select a range of interfaces:
switch#configure terminal
switch(config)#interface range gigabitethernet 0/1-48
Now configure the ports as access ports this in turn will turn off DTP
switch(config-if)#switchport mode access
Assign the ports to an unused VLAN (not the Native VLAN)
switch(config-if)#switchport access vlan vlan-id
NB the above commands will not work in VoIP (voice) networks. Cisco IP Phones use trunks (DTP).
VLAN Access Control Lists
There are three kinds of ACLs:
- Router Access Control Lists (RACLs)supported in the TCAM hardware on Cisco Multi-layer switches (MLS). Can be applied to any router interface, such as a switch virtual interface (SVI) or Layer 3 routed port.
- Port Access Control List (PACL)filters traffic at the port level. PACLs can be applied on a Layer-2 switch port, trunk port, or EtherChannel port.
- Vlan Access Control Lists (VACLs)(a.k.a VLAN Access Maps) supported on software on Cisco MLS.
Cisco Catalyst switches support four ACL lookups per packet*:
- ingress (1) and egress (2) security lookup
- ingress (3) and egress (4) Quality of Service (QoS) look-up
This following section all went over my head or just about and I have no idea whether this works or not or is correct or not for more information.
There are cases where certain Access Control Entries (ACEs) must be combined in each ACLs due to limitations of TCAM hardware. The merge process is also responsible for other functions like expanding ACEs due to a lack of Layer 4 Operations Pointers (L4Op Pointers) or Logical Operational Units (LOUs).
Cisco catalyst Switches use two features to perform a merge
- order independent algorithm merge
- order dependant algorithm merge
Order Independent Merge (OIM) is based on Binary Decision Diagrams(BDD), ACLs are merged from a series of oder-dependant actions to a set of order-independent masks and patterns. The resulting ACE can be very large, and processor and memory intensive.
Order Dependant Merge (ODM) is not bit-based. The computation is much faster and is less processor intensive.
RACLs are supported in hardware through IP standard and IP extended ACSs, with permit and deny actions. ACL processing is an intrinsic part of the packet forwarding process. ACL entries are programmed in hardware. Lookups occur in the pipeline, whether ACLs are configured or not. With RACLs access list statistics and logging are not supported.
*You can get some switches with two security lookups and 1 QoS lookup in each direction (6 total).
Configuring VACLs
VACLs apply to all traffic on a VLAN. VACLs use standard and extended Cisco IOS IP and IPX ACLs, and MAC Layer-named ACLs and VLAN access-maps.
VACLs follow route-map conventions, in which map sequences are check in order (top-down).
Each VLAN access map can consist of one or more map sequence, each sequence with a match clause and an action clause. The match clause specifices IP, IPX, or MAC ACLs for traffic filtering and the action clause specifies the action to be taked when a match occurs. When a flow matches a permit ACL entry, the assciated action is taken and the flow is not checked against the remaining sequences. When a flow matches a deny ACL entry, it will be checked against the next ACL in the same sequence or the next sequence. If aflow does not match any ACL entry and at least on ACL is configured for that packet, the packet is denied.
Three VACL actions are permitted:
- Permit (with capture, Catalyst 6500 only)
- Redirect (Catalyst 6500 only)
- Deny (with logging, Catalyst 6500 only)
Two features are supported on Catalyst 6500 only:
VACL Capturewhere Forwarded packets are captured on the capture port. The capture option is only permit ACEs. The capture port can be an IDS port or an Ethernet port. The capture port must be an egress VLAN for layer-3 switched traffic.
VACL Redirect where matching packets are redirected to specific ports. You can configure up to five redirect ports. Redirect ports must be in a VLAN where a VACL is applied.
Define a VLAN Access MAP
switch#configure terminal
switch(config)#vlan access-map map-name seq# insert to/delete from
Configure the match clause in a VLAN access map sequence
switch(config-access-map)#match options
Configure actions
switch(config-access-map)#action options
Apply the VACL to VLANs
switch(config)#vlan filter map-name vlan-list list
Verify configuration
switch(config)#show vlan access-map map-name
Source for this Config document Section
Internet Service Providers (ISP) often have devices from multiple clients, in addition to their own servers resident on a single demilitarized zone(DMZ) segment of VLAN. Cisco Catalyst 6500/4500 switches Private Virtual Local Area Networks (PVLAN) to keep some switch ports shared and some switch ports isolated, even if the ports exist in the same VLAN. The 2950 and 3550 support “protected ports”, which are functionally the same on a per-switch basis.
Traditionally ISPs used one VLAN per customer, with each VLAN having its own subnet. A layer 3 device the provides interconnectivity between VLANs and Internet destinations. Problems with this method:
- Supporting a VLAN per customer may require a high number of interfaces on ISP network devices.
- Spanning Tree becomes more complicated with many VLAN iterations.
- Network address space must be divided into many subnets, which wastes space and increases management complexity.
- Multiple ACL applications are required to maintain security on multiple VLANs, resulting in increased management complexity.
PVLANs provide Layer-2 isolation between ports within the same VLAN, thereby eliminating the need for VLAN and IP subnet per customer.
A Port in a PVLAN can be one of three types:
- Isolated: port has complete Layer-2 separation from other ports within the same PVLAN, except for promiscuous ports; blocks all traffic to isolated ports except from promiscuous ports. Traffic received from an isolated port is forwarded only to promiscuous ports.
- Promiscuous: ports can communicate with all ports within the PVLAN. The default Gateway (DG) is probably be hosted as a promiscuous port.
- Community: ports communicate among themselves and their promiscuous ports. These interfaces are isolated at Layer-2 from all other interfaces in other communities, or in isolated ports within their PVLAN.
Trunks carry all VLAN traffic so isolated, promiscuous and community PVLAN traffic may enter and leave a switch through trunks
PVLAN ports are associated with a set of supporting VLANs that are used to create the PVLAN structure.
- As a Primary VLAN: carrying traffic from promiscuous ports to isolated, community and other promiscuous ports in the same primary VLAN.
- As an Isolated VLAN: carrying traffic from isolated ports to a promiscuous port.
- As a Community VLAN: carrying traffic between secondary VLANs. You can extend PVLANs across multiple devices by trunking primary, isolated, and community VLANs to other devices that support PVLANs.
A promiscuous port can service only one primary VLAN. A promiscuous port can service one isolated VLAN or many community VLANs.
Configuring
Step 1: Set VTP Mode to Transparent
switch#configure terminal
switch(config)#vtp mode transparent
You may also want to check VTP version, password and domain while you are at VTP configuration
Step 2: Create the secondary VLANs (Isolated and community VLANs are secondary VLANs)
switch#configure terminal
switch(config)#vlan 102
switch(config-vlan)#private-vlan isolated
switch(config-vlan)#end
switch#show vlan private-vlan type
Step 3: Create the primary VLAN
switch#configure terminal
switch(config)#vlan 100
switch(config-vlan)#private-vlan primary
switch(config-vlan)#end
switch#show vlan private-vlan type
Step 4: Associate the secondary VLAN with the primary VLAN. Only one isolated VLAN can be mapped to a primary VLAN, but more than one community VLAN can be mapped to a primary VLAN
switch#configure terminal
switch(config)#vlan 100
switch(config-vlan)#private-vlan association add 102
switch(config-vlan)#end
switch#show vlan private-vlan type
When associating secondary VLANs with primary VLANs use these best practices:
- Make sure that the VLAN IDs contain only one isolated VLAN ID (VID)
- Use the remove keyword with the secondary VID to clear association; there can only be one association.
- Use the no keyword to clear all association from the primary VLAN.
- Do not allow the command to take effect until you exit VLAN configuration submode.
Step 5: Configure an interface as an isolated or community port.
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#switchport mode private-vlan host
switch(config-if)#end
switch#show interfaces gigabitethernet 0/1 switchport
Step 6: Associate the isolated port or community port with the primary/secondary VLAN pair
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#switchport private-vlan mapping 100 102
switch(config-if)#end
switch#show interfaces gigabitethernet 0/1 switchport
Step 7: Configure an interface as a promiscuous port
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#switchport mode private-vlan promiscuous
switch(config-if)#end
switch#show interfaces gigabitethernet 0/1 switchport
Step 8: Map the promiscuous port to the primary/secondary VLAN pair
switch#configure terminal
switch(config)#interface gigabitethernet 0/1
switch(config-if)#switchport private-vlan host-association mapping 100 102
switch(config-if)#end
switch#show interfaces gigabitethernet 0/1 switchport
Step 9: Permit Routing of Secondary VLAN Ingress Traffic
switch#configure terminal
switch(config)#interface vlan 100
switch(config-if)#private-vlan mapping add 102
switch(config-if)#end
switch#show interfaces private-vlan mapping
The sources for this config section include this Cisco 4500 document and this document. Finally CCIE Blog gave me a some insight and hint as to WTF the difference between the host and promiscious ports on the interface config was.
Definition
Logical Operation Unit (LOU) are hardware registers used to store {operator, operand} tuplesfor Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port numbers specified in an IP extended ACL, VACL, or QoS ACL. These tuples are called Layer 4 Operations (L4Op).
Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.
References I want to rememeber:
Hucaby, D. (2007). CCNP Self-Study: CCNP BCMSN Official Exam Certification Guide, Fourth Ed, VLAN Access Lists (page. 413-414). Indianapolis: Cisco Press.
Common VLAN configuration errors made when configuring VLANs are listed below.
802.1Q Native VLAN Problem
An 802.1Q trunk link doesn’t encapsulate frames but adds a tag and re-calculates the frame-check sequence (FCS) of the frame. The 802.1Q trunk also allows for untagged frames to pass through the trunk on the NATIVE VLAN. A common configuration error is when there is a trunk link and the NATIVE VLAN is not the same on both sides of the trunk causing connectivity issues.
802.1Q Native VLAN Resolution
- NATIVE VLANs must coincide on both ends of the trunk link otherwise a trunk link may not form.
- Cisco NATIVE VLAN is default VLAN 1, for security purposes make the NATIVE VLAN something that is not used for normal purposes.
switch(config-if)#switchport trunk native vlan 1-4094 - If there is a NATIVE VLAN mismatch CDP (if used and active) will issue a “native VLAN mismatch” error.
- On select versions of IOS CDP may not be transmitted if VLAN 1 is not working or automatically be disabled on the trunk.
- If there is a NATIVE VLAN mismatch on either side of an 802.1Q trunk, layer-2 loops may occur because VLAN 1 STP bridge protocol data units (BPDUs) are sent to the IEEE STP MAC untagged.
- When troubleshooting VLANs note that a link can have one NATIVE VLAN association when in access mode and another when in trunk mode.
Trunk Link Problems
There are certain elements that determine whether a trunk link is formed or not, the elements that determine this are the trunking mode, the encapsulation type, the VTP domain, and the hardware capabilities of the connected ports.
Trunks can be configured to either statically or autonegotiate trunks with the use of Dynamic Trunking Protocol (DTP), for autonegotiation the switches must be in the same VTP Domain. There are however certain other small things to take note of about the configuration with trunk links.
Through the use of the switchport command trunks can be autonegotiated. There are certain variations of the command that will not setup a successful trunk through; the command is below and there are some of the options available: swtich(config-if)#switchport mode dynamic / auto / desirable / trunk We wish to config a trunk link the following options will not create a trunk. swtich1(config-if)#switchport mode autoThis shows both interfaces in switchport mode auto and will not config a trunk.
swtich2(config-if)#switchport mode autoswtich1(config-if)#switchport mode dynamicThis shows one interface switchport mode dynamic desirable and the other static access and will not config a trunk.
swtich2(config-if)#switchport mode accessswtich1(config-if)#switchport mode trunk
swtich2(config-if)#switchport mode auto
This shows one interface switchport mode trunk and the other interface switchport interface auto. This config will not create a trunk because the interface set to trunk will not send DTP frames and then the auto interface will switch to being an access port.
This topic is something I can feel in my bones will come up in tests you either have this topic down or don’t have a clue and guestimate. I think I am going to try and know it because it’s easy enough to make a table and just learn; check out CCIE Pursuit for a table on the 3550/3560 routers and bitmindframes for more info on each DTP config state.
DTP Requirements
The reason a Network Administrator would deploy DTP is to automate to a degree the trunking process. To give you more of an explanation if a port can become a trunk (switch-switch not supported on routers), it may also be able to trunk automatically, and in some cases even negotiate the type of trunk (ISL/802.1Q). This is where DTP comes in to provide the negotiation of the trunking method with the neighbour device.
There are however requirements for DTP the main one being support for ISL or 802.1Q on both ends of the trunk (Switch A and Switch B must support and be configured with one or the other) so that DTP can do its job.
This can be expanded slightly where the switch platform does or doesn’t provide support for ISL but does support 802.1Q trunking and supports DTP like the Catalyst 4500/4000 (CatOS), which includes 2948G/2980G/4912G also the Catalyst 2950/2955/2940 series. This simply means all trunking will be done using 802.1Q.
Lastly where both ISL and 802.1Q is supported but DTP is not like the Catalyst 2900XL/3500XL/2948G-L3/4908G-L3/4840G/8500 Series.
Trunk Link Resolution
Trunk Negotiation is managed by DTP, which is Cisco proprietary, and is a point-to-point protocol (see any problems with this yet) when using DTP make sure that both ends of the link are in the same VTP Domain otherwise it wont work. Secondly because it is Cisco proprietary certain network devices wont support DTP which could cause misconfiguration cross-brands (when configuring on an interface that is connected so something non-cisco turn off DTP). Find some more information here that’s doesn’t assume you know something about DTP before jumping right in and also covers some other topics in the same post.
The correct way then to configure a port to either trunk or not would be for access ports swtich(config-if)#switchport mode access for trunking without DTP swtich(config-if)#switchport mode trunk then finally for encapsulation type on the trunk port
swtich(config-if)#switchport mode nonegotiateswtich(config-if)#switchport trunk encapsulation dot1q. Keeping in mind that dot1q is cross-vendor and isl is also Cisco proprietary.
swtich(config-if)#switchport trunk encapsulation isl
VTP Problems
| Problem | Possible Causes |
| Updates not received as expected |
|
| Missing VLANs |
|
| Too many VLANs |
|
The VTP Resolution and best practices are dealt with in a previous post
Trunk and VLAN Specific
Sometimes it is needed to only carry specific/certain VLANs accross trunk links. You will remember from the CCNA that by default all VLANs are allowed across a trunk link when it is created unless specifically told otherwise. This will mean that VLAN 1 through x will traverse a trunk unless you as Admin say otherwise. In some situations having all vlans moving across trunks is not the desired sitatuation.
As an example if you have VLAN 1 through 10, assume 1,3,6, and 9 is actively used on one Switch 1 and 2,4,6,8 and 10 on Switch 2.
There is no “active” users for VLANs 2,4,6,8, and 10 on Switch 1 and no active users for VLaN 1,3,6, and 9 on Switch 2 why then send these VLANs all over the place when this will be wasteful? To change this situation one can use any one of these commands:
Switch(config-if)switchport trunk allowed vlan remove/except/add x,x,x
Using either the remove 2,4,6,8 and 10, except 2,4,6,8,10 or add 1,3,6,9 command will have the same end result of allowing only 1,3,6, and 9 across the trunk link.
Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.
Configuring VTP is as easy as one two three, literary 
- VTP Domain
- VTP mode
- VTP password
All switches in the same VTP domain will share the VTP domain and VTP password (if a password is configured for use). It is good practice to set the VTP mode to client if switches are being added to an existing switched network that uses VTP (use it don’t use it, for more look at the next section below the configuration for the steps involved) this is unless you want all your VLAN information going missing which means you have to re-load all your VLANs for large enterprise networks this could take many hours.
Configuration
switch>enable
switch#show vlan brief
Displays a list of VLANS Configured on Switch this list will replace all other VLAN information on the network if this is to be VTP Server
switch#configure terminal
switch(config)#vtp password my_password
switch(config)#vtp domain my_domain
switch(config)#vtp version 1/2
switch(config)#vtp mode client/server/transparent
switch(config)#exit
switch#show vlan brief
Now either you will see the same VLANs or other VLANs that were advertised from the VTP Server if this is a VTP Client
Verification:
In this output, Configuration last modified by specifies the IP address of the switch that last updated the VLAN database of this switch.
switch#show vtp status
In the next output this verifies if VTP updates are being sent and received.
switch#show vtp counters
Things to keep in mind
VTP has small nuances that make it a pain to work with, the most obvious and the one I stress overly much is that VTP can create lots of work for you by deleting the entire enterprise VLAN database in a matter of seconds if you aren’t careful. This is something that you have to respect about VTP as it is a great time safer with respect to admin intense vlan creation but can also cause you headache.
Other small things being that there are 2 mainstream versions of VTP available and they are not interoperable (There is a version 3 available on big switch platforms). The default setting for VTP is Version 1 even if the switch platform supports Version 2, this is because of the interoperability issue. To use Version 2 explicitly set the server mode to Version 2 and the change will be propagated. Changes between Version 1 and Version 2 include
- Version-dependant transparent mode where Version 1 matches VTP version and domain name before forwarding information to other switches. Version 2 forwards without checing the version number.
- Consistency Checks are performed on VTP and VLAN parameters entered in the command line interface (CLI) or by simple network management protocol (SNMP). This prevents errors in vlan numbers and names from being propagated to other switches.
- Token Ring support
- Unrecognized Type-Lenght-Value (TLV) support will propagate received configuation changes even if the switch supervisor engine cannot parese of understand the message.
The VTP Domain name is case sensitive this is important and can only contain a maximum of 32 characters. If there is connectivity between two switches, there is no VTP password set and VTP is not propagating check that the CaSe is identical in the domain. For more in setting up VTP
The other final small thing is that VTP uses the configuration revision number to determine in the VTP domain whether it will accept or reject VTP advertisements. If the domain name is the same of the client or server then it checks the configuration revision number to see if it is going to update the vlan database. If the revision number of an update received on a client or server VTP switch is higher than the previous revision, then the new configuration is applied. Otherwise, the configuration is ignored. This comes back to being very careful as to the switches you just simply add to the network.
Adding a switch to VTP Network
Adding a new switch to an existing network can create a lot of work for you if you are not careful, follow these steps to make sure you aren’t shooting yourself in the foot.
This assumes that there is a “NEW” switch and an existing network to which the NEW switch is to be connected. The term “NEW” can either be right out the box brand spanking “NEW” from Cisco or “NEW” from ebay.
- Make 110% sure that there is no network connectivity with the NEW switch and the existing network; then power on the switch.
- Change the switch VTP mode to transparent on the NEW switch.
- Delete vlan.dat on the NEW Switch.
- Change the VTP domain name to something unconventional that is not in use on the network, and change the mode to client on the NEW Switch.
- Reload or power cycle the switch NEW Switch.
- Verify the switch VTP mode, VTP domain name, and vlan.dat configuration.
- Configure the switch with the existing network settings and a valid VTP domain name and password.
- Connect the NEW switch to the network.
- Verify the VLAN database has propagated.
There are furthermore some other best practices concerning VTP Configuration when it comes to the ECNM:
- The ECNM gives boundaries for VTP Domains. Not all switches need information on all VLANs (end-to-end). In the ECNM VTP Domains should be restricted to redundant distribution layer switches and access layer switches.
- Have only one or two switches configured as VTP Servers and the remainder as clients.
- Configure a password for the VTP Domain to increase security and not make more work for yourself should someone try and add a VTP switch (in sever mode) to the domain without your knowledge.
I know of a network where a a lab switch (old network switch) used during training added to the lab network deleted the VLAN database of the enterprise network. *shrug*
- Manually configure the VTP domain name on all switches that are installed in the network so that the mode can be specified and the default mode of the server on all switches can be overwritten (see above for why)
- When you are setting up a new domain configure VTP clients switches first so that they participate passively; then configure servers to update client devices after the fact.
- In an existing domain, when performing clean-up, configure passwords on the servers first. clients may need to maintain current LAN information until the server contains a complete VLAN database. After the VLAN database on the server is verified as complete, client passwords can be configured to the server passwords to propagate the VLAN Database.
Some Asides that I wondered about
Doing some final revision and asking the Google about some weird questions CCIE Pursuit came up with the asnwers, this one has happened to me IRL where the switch came back up as Server. Also a question about the MD5 and VTP was neatly answered all in one visit.
Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.
CCIE Magazine Launches
So Arden Packeer has been a busy guy it seems what with passing his CCIE Routing and Switching recently and starting off on the road towards another CCIE (Voice).
Tweeted this morning (for me at least) Arden launched CCIE Magazine and has the inauguration post up. Head on over and support a Networker in his endeavours; leave a comment, subscribe to the RSS feed, Digg, Delicious, and StumbleUpon the content and maybe even take out an ad if you are looking for some exposure for your own product or service (consider the exposure for recruiting advertising and the target audience for CCIE Magazine, thinking about yesterdays post).
It’s early days over at CCIE Magazine but it’s sure to grow into something grand.