Last time I had to understand how Cisco EtherSwitch Service Module like NME-16ES-1G-P (SM) communicates with the ISR Platform.
Once you installed the SM on the router you will have GigabitEthernet1/0 interface recognised by the IOS. First of all you have to configure the Gi1/0 interface with IP and no shut it to make a console connection over router to the SM.
You have to issue the following command to make a connection and you are already loged to module:
Router#service-module gigabitEthernet 1/0 session

If SM module or PCs connected to the SM need to communicate with the network outside of router, the SM’s Gi1/0/2 needs to be configured to communicate with the router itself.

Once I have configured the SM G1/0/2 like below:
interface GigabitEthernet1/0/2
description Trunk connection to Router
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
I have started expierenced issue with the PoE on SM.
You can display the PoE statistics of the SM on the router, this is what I have got:
ROUTER#service-module gigabitEthernet 1/0 status
Service Module is Cisco GigabitEthernet1/0
Service Module supports session via TTY line 66
Service Module is failed
Service Module reset on error is disabled
Service Module status is not available

Hmm, SM is failed 🙂 why? PoE statistics are going over the CDP so maybe we have issue here I wondered. On the other side CDP by default is going over Native VLAN 1 but VLAN 1 is allowed over trunk. I have removed the switchport trunk allowed vlan just in case, and here what I got again :):
ROUTER#service-module gigabitEthernet 1/0 status
Service Module is Cisco GigabitEthernet1/0
Service Module supports session via TTY line 66
Service Module is in Steady state
Service Module reset on error is disabled
Getting status from the Service Module, please wait..
EtherSwitch Service Module with 16 PoE FE ports and 1 GE port
System name = SWITCH
Model string = NME-16ES-1G-P
System board ID = 0x18
Base MAC addr = 0017.5aa5.c480
Switch number = 1
System uptime = 0 days, 14 hours, 11 minutes, 21 seconds
Software Details:
Operating System = Cisco C3750 IOS Software
Vesrion = 12.2(44)SE6
Major version = 1
Minor Vesrion = 38
Image path = flash:c3750-ipbasek9-mz.122-44.SE6.bin
wow, is working fine now. Once I’ve configured trunk in the below manner it is working fine two. If you have any thougths about it or you have reference ID for this bug let me know please :). Enjoy!
interface GigabitEthernet1/0/2
description Trunk connection to Router
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport trunk allowed vlan 10,20
switchport mode trunk

It’s very important to understand the Native VLAN and VLAN 1 concept and what impact for Layer 2 protocol communication.
Cisco switch uses some of Layer 2 protocols like CDP/VTP/DTP/PAgP/UDLD/BPDU are using by default VLAN 1 to communicates with the other switches. Switch sends it to reserverd 01:00:0C:CC:CC:CC MAC address it’s a kind of Layer 2 multicast group so all Cisco switches are looking for these frames. What is a connection with VLAN 1 and native VLAN. By default VLAN 1 is Native VLAN what is means is that is not taged at all. I’ve done a small test to figure it out VLAN 1, Native VLAN and protocols relationship. I have connected the PC with Wireshark directly to the Cisco 3550 switch and configure interface fa0/24 as below:
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable 1

What I get on Wireshark is STP, CDP, DTP and PAgP protocols, so all is working fine. Let’s add the switchport trunk allowed vlan 10 command and see the capture:
interface FastEthernet0/24
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10
switchport mode trunk
channel-group 1 mode desirable 1

As we see nothing has changed. All layer protocols are transmited. It’s important to understand here what switchport trunk allowed vlan command exactly do. Command Reference says that it „sets the list of allowed VLANs that transmit traffic from this interface in tagged format when in trunking mode”. OK so what about vlan 1? Is it allowed or not. As VLAN 1 by default is not tagged so it will not be filtered out what capture has confirmed. Let’s make last test and change the native vlan to different on, for example VLAN 10:
interface FastEthernet0/24
switchport trunk encapsulation dot1q
swtchport trunk native vlan 10
switchport trunk allowed vlan 10
switchport mode trunk
channel-group 1 mode desirable 1
Thanks to this we have changed the Native VLAN from 1 to VLAN 10 so now VLAN 1 is tagged but due to command switchport trunk allowed vlan 10 is filtered out. So let’s see what we have in capture now.

We have got just STP and DTP.

Conclusion:
STP and DTP frames have no relation to VLAN, so are always transmited over Native VLAN.
CDP/VTP/PAgP/UDLD are always transmited over VLAN 1, if Native VLAN is 1 then will be transmited in untagged form, if VLAN 1 is tagged (Native VLAN is other VLAN then 1), protocols will be tagged with 1.

I hope this has clarified the concept.

MAC Address Spoofing is a kind of Man-in-the-Middle Attack where attacker tries to redirect frames destined for authorized host to the attacker PC instead. To redirect traffic attacker needs to overwrite CAM table entry with actual true destination host’s MAC address. Be aware that is is not possible to have two the same MAC addresses in the CAM table on the switch, once switch detects this kind of strange behaviour will log the following error on the console:
*Mar 1 00:30:41: %SW_MATM-4-MACFLAP_NOTIF: Host 0000.1111.1111 in vlan 10 is flapping between port Fa0/1 and port Fa0/2

Another way to spoof MAC address is to use Address Resolution Protocol (ARP). When host sends a broadcast ARP request to figure out a MAC address of target host’s MAC address, target host response thru ARP reply.

Once the CAM table will be overwritten, packets to the true destination PC will be redirected to the attacker PC. If the true PC sends traffic once again CAM table will be rewritten again, moving the traffic back to the true PC’s port.

DHCP snooping feature is one of the method of mitigating IP Address Spoofing Attacks but with additional fetures like IP Source Guard and Dynamic ARP Inspection can fight with MAC Address Spoofing.

Using DHCP server attacker can prevent normal communications for the hosts or simply redirect the traffic to own PC. The plan is simple: connect DHCP server to the network and assign IP addresses to the clients without default gateway IP address what will successful prevent hosts to communicate with oustside world or just define default gateway’s or DNS server IP of hacker own PC. We can prevent this with DHCP Snooping. Here we are configuration step by step to configure the feature.

First we need to enable DHCP Snooping feature globally on the switch, next enable for specific VLAN, then configure trusted port where DHCP server will be connected or expected traffic from the DHCP server will be received like over trunk interfaces:
SW(config)#ip dhcp snooping
SW(config)#ip dhcp snooping vlan 10
SW(config)#int fa0/5
SW(config-if)#description DHCP-Server
SW(config-if)#ip dhcp snooping trust

Let’s see what we have configured already:

SW#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3
Interfaces:Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/5 yes unlimited

So we enable globaly and for VLAN 10 DHCP Snooping feature, additionaly we have configured Fa0/5 as trust interface, so DHCP server will be connected here. In case you will not trust any interface once switch gets DHCP Discover message it will drop the frame and log the following error on console:
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 01:32:06: DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.

Let’s see what we have now on the switch, we will debug DHCP Snooping process with above configuration:
SW#debug ip dhcp snooping
*Mar 1 00:12:44: DHCP_SNOOPING: received new DHCP packet from input interface (FastEthernet0/1)
*Mar 1 00:12:44: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Fa0/1, MAC da: ffff.ffff.ffff, MAC sa: 0000.1111.1111, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0000.1111.1111
*Mar 1 00:12:44: DHCP_SNOOPING: add relay information option.
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format
*Mar 1 00:12:44: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
*Mar 1 00:12:44: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xA 0x0 0x0 0x2 0x8 0x0 0x6 0x0 0xB 0x5F 0x7E 0x7A 0x80
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 1 00:12:44: DHCP_SNOOPING_SW: bridge packet send packet to port: FastEthernet0/5, vlan 10.
One important note, once you enabled IP DHCP Snooping feature Cisco switch by default add to the DHCP Discover packet DHCP Option 82 and is working as kind of relay agent, we can observe it on the console, the begining is DHCP_SNOOPING: add relay information option.
What exactly the 82 options is?
Options 82 has two suboptions: Remote-ID suboption is the switch’s MAC address and Circuit-ID suboption is the port identifier so exactly interface where client is connected to . The idea is simple, switch adds this option and thanks to this DHCP server assign proper IP address, so it’s a kind of client’s distinction mechanism. We can observe a related issue to this switch’s feature if we have DHCP server configured on the router:

R5-DHCP#debug ip dhcp server packet
*Mar 1 00:30:55.545: DHCPD: inconsistent relay information.
*Mar 1 00:30:55.545: DHCPD: relay information option exists, but giaddr is zero

So what exactly this error means? Router sees inconsistent information, why? What is exactly happening when relay agent like router with ip helper-address options gets DHCP Discover packet from the client and sends it forward to the DHCP server. We have to look in to the DHCP Discover packet. Router gets DHCP Discover (broadcast) from client and based on it generates new DHCP Discover (unicast) packets with LAN IP as source and DHCP Server IP as destiantion, additionaly modifies giaddr field known as Relay agent IP address in the BOOTP packet from 0.0.0.0 to own IP (the same like source IP = LAN IP). What about the switch? Problem is that switch by default adds kind of relay option to the packet but doesn’t change the giaddr field so routers treats it as inconsistent information and drops packet.

We have two options to work around this issue:
first one – disable adding of DHCP Option 82 on the switch:
SW(config)#no ip dhcp snooping information option
second one – allow DHCP server (on the router) receives DHCP packets that contain relay info option with zero giaddr:
R5-DHCP(config)#ip dhcp relay information trust-all

Let’s back to snooping. Switch watches two-way DHCP address allocation process and learns about IP address that has been assigned to the client, switch builds IP DHCP Snooping Binding table where adds MAC address of the client, IP that has been assigned by the server, lease time, vlan where clients resides and interface where is connected to:
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 83572 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1

Based on the sh ip dhcp snooping output IP DHCP Snooping verify only the MAC address based on the binding table (Verification of hwaddr field is enabled). Really? What about Cisco Configuration Guide says:

„When a switch receives a packet on an untrusted interface and the interface belongs to a VLAN in which DHCP snooping is enabled, the switch compares the source MAC address and the DHCP client hardware address. If the addresses match (the default), the switch forwards the packet. If the addresses do not match, the switch drops the packet.”

I don’ agree with it. Let’s make a small test to proof it. We have two routers R1 and R3 connected to the same switch (second one is DHCP server that has assigned the IP address 10.0.1.1 to R1’s MAC: 00:00:00:11:11:11). We can ping R3 from R1:
R1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.0.1.1 YES DHCP up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
R1#
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
good, is working fine as expected :), let disconnect the R1 from the switch and see how the binding table looks like:
SW#
*Mar 1 01:37:50: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:00:11:11:11:11 10.0.1.1 86290 dhcp-snooping 10 FastEthernet0/1
Total number of bindings: 1
nothing changed, switch remembers binding even if we disconnected R1, nice. So lets connect the R1 back but before we do it we change R1’s IP to 10.0.1.2, then we ping R3 again:
R1(config-if)#int fa0/0
R1(config-if)#ip add 10.0.1.2 255.255.255.0
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

no issue with ping, working fine even if we have changed IP, so let’s changed the MAC now to different one for example 00:00:00:22:22:22

R1(config)#int fa0/0
R1(config-if)#mac-address 0000.2222.2222
R1#ping 10.0.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms LOL, we can still ping even if we have changed IP and MAC. So where is a issue. As we have see in the simplest form DHCP Snooping just filter unwanted DHCP Offer packets, to let the switch filter traffic based on the MAC or IP that’s resides in the DHCP Snooping binding table we have to employ other fetures like IP Source Guard (to filter based on the IP) or IP Source Guard with Port Security to filter based on the MAC and IP. We will discusse about it in one of the future post.

It will be just overview about the Dynamic Host Configuration Protocol (DHCP) and background for post about DHCP snooping feature that will be posted soon. DHCP is the probably the most popular way of dynamic IP address assignment and other options like lease time, gateway and DNS IPs or domain name for the hosts in the PC enviroment.  DHCP works in a client – server architecture and the basic process of address assignments is depicted on the below figure.

We have 4-step process. First clients sends the DHCP Discovery request to the server. Because the client doesn’t have any idea what is a IP address of the server even more client doesn’t have IP address configured yet and it’s what is looking for, it sends layer 2 broadcast address with own MAC address as source and FFFF:FFFF:FFFF as destination MAC address. From the layer 3 perspecctive 0.0.0.0 is placed as IP source and 255.255.255.255 as destination broadcast. Server responds to the client with the DHCP Offer packet that includes client IP address proposition and with other options. Clients responds to the server with DHCP Request (request for IP address that is has been just offered to the client), and server confirm IP address assignment via DHCP ACK packet.

Above example was based on the LAN enviroment where client and server resides on the same subnet. What about if we have clients PC in the branch office and DHCP server in out data center HQ. The solution for this is DHCP Relay Agent feature needs to be configured on the LAN interface of the gateway router. Below diagram shows the process flow for the Relay Agent. 

From the client perspective nothing changed, this process is transparent and client doesn’t know even that traffic is going thru the WAN cloud to the data center on the other side of the world. By default
all subnet broadcast (255.255.255.255) is not forwarded unles ip helper-address is confgured.  Once the router gets the broadcast address with bootp on board and ip helper IP address is configured, router will encapsulate the DHCP Discover and sends it as unicast to the configured IP address in the ip helper-address command (it have to be DHCP server IP).

Beginning on May 10, OEQ for CCIE RS and Voice lab exam will not include the four Open Ended Core Knowledge Questions. Cisco introduced 4 questions to the CCIE R&S lab exam on February 2009 to eliminate cheating and stop fast growing rate of R&S numbers. They have achieved just partially the target for short period time. Next, on October 2009 Cisco decided to introduce the CCIE R&S v4.0 Blueprint with 2 hour troubleshooting section that cause that fast CCIE certificate numbers grow stopped and in next stage even decline the numbers in R&S.

The total lab time will remain the same – 8 hours with 2 hours troubleshooting section at the beginning of the exam.

As Cisco has explained OEQ will be removed because troubleshooting section is enough to take care about cheating.

The last day of the security bootcamp. We had a chance to take of adavntage some of security fetures in practice. 8+  mock lab with just a pice of material. We have tested ASA with basic failover with firewall contexts, DMVPN over FR and more. It kind of brainstorm with the lead of the bootcamp. It is always the best to learn fast and remeber conclusions based on the wrong answers.

It was hard week with a ton of material. Sorry but my posts were just a high overview what we have done this time. I have 3 days off so I will back next week to post you some nice fetures that I have learned thru these days. I will keep you updated.
In case you will have any further question just drop me mail.

It was the borest day I think almost all good known technologies: Securing the Control Plane, Securing the Management Plane, Securing the Data Plane and Advanced L2 Security. To be honest it was just overview and we didn’t cover all fetures (planed fetures based on Piotr’s plan). There is huge homework to do. You have to keep in mind that all of these stuff is important and required on the exam. Short question from the large pool and good answer = 2 more points to be a winner of the game.

Today was IPS, ACS, 802.1x. Tones of material in very short time. ACS with 802.1x it will be the hardest thing on the exam I think, why 🙂 ? you will answer this question once you figure out ACS configuration. Good luck.

BTW – Good news for all that would attend Security and Service Provider bootcamp in Warsaw in near future. New dates just have been posted on the Micronics Networking & Training Inc.

It was really good stuff 😉 all VPN technologies in one day, I will have to drill GET VPN more :).

As I’ve promised you, here you are first day feedback.

We have started at 10 am from basic firewall stuff and went thru all ASA fetures like: NAT, MPF, Advanced protocol inspection, contexts, failover, QoS until ASA troubleshooting. Additionally at the end of the day we had nice short overview about basic and advanced IOS data plane security fetures like CBAC or ZPF.

What about trainer? Piotr has started calmly and secure his class. Some nice diagram draw on whitebord with slides were enough to understand the clue. Knowlede justified  by his practical experience on real deployments is what all students are looking for on training and what is always nice to see and hear. Unfortunately Piotr has completely opposite teach manner compared to Narbik what has impact on the way how he pass knowledge to students. 

Tomorrow the most important and interesting day I think – all VPN technologies.