Attributes that have to match to successful establish FULL neighbor adjacency

1. Area ID
2. Authentication
3. Subnet/Subnet Mask
4. Hello/Dead Interval
5. Stub area flag

 Note: FULL neighbor adjacency state doesn’t mean that LS exchange will take place. There is one additional condition that needs to be met. You can mix network types until they will match DR/BDR election process. So you can mix broadcast and non-broadcast because both network types require DR/BDR election but once you mix broadcast with p2p adjacency will come up but LS exchange will not take place.

 Multicast IPs

AllSPFRouters – 224.0.0.5 (0100.5e00.0005)

AllDRouters – 224.0.0.6 (0100.5e00.0006)

Router ID Election

1. Router-id command
2. Highest IP address on loopback interface
3. Highest IP address on other interfaces

 DR, BDR Election

1. The highest priority (255 highest, 0 doesn’t take part in election process)
2. If tie, highest Router ID

DRothers – established adjacency only with DR, BDR, between DRothers<>DRothers is 2WAY/DRothers

 Interface State Machine

• Down
• P2P
• Waiting
• DR
• Backup
• DRothers
• Loopback

 Neighbor State Machine

• Down
• Attempt (only on NBMA where neighbors are manually configured)
• Init – Hello has been received but router does not see its own RID in the hello yet
• 2-Way – router has seen its own RID in the neighbor’s field hello packet (bidirectional)
• ExStart – neighbor establish master/slave relationship and determine the initial DBD seq number, router with highest RID is master
• Exchange – router sends DBD packets describing its entire LSDB (LSA Headers), may sends LS Request, requesting more recent LSAs to neighbors
• Loading – router sends LS Request, requesting more recent LSAs that have been discovered in the Exchange state but have not been received
• Full – neighbors are fully adjacent

 Building an Adjacency

• Hello (type 1)
• DBD (type 2)
  • Just description of LSAs (header is sent)
    • receiving router decides whether it has the latest copy of the LSA in its own DB
  • Flag is sent
    • I bit – first DBD packet sent
    • M bit (more bit) – not last DBD packet, will be more
    • MS bit (Master/Slave bit) – set in DBD packet originated by the Master
    • LS Request (type 3)
    • LS Update (type 4)

 Exstart and Exchange process

1. Both neighbors claim to me the master
   • sending DD with MS bit set to 1
   • own random strange DB sequence number
2. Router with lower RID will be slave and replay with DD
   • MS bit = 0
   • DD sequence number set to master’s sequence number
   • Its first (I bit) packet with LSA summaries
3. Exstart process completed
4. Exchange process starts
5. If neighbor (router A) receives LSA that
   • Is not in its own database
   • Or remote neighbor has a more recent copy of known LS
   • The router A place the LSA on the Link State Request List
6. Router A sends LS Request packet asking for complete copy of the LSA from the List
7. Remote B router sends LSA Update and adds LSA on Link State Retransmission list
8. Router A sends back LS ACK acknowledged LSA that received
9. Router B removes acknowledged LSA from the Link State Retransmission list
10. Next state
    • If A or B have still entries in Link State Request List > Loading state (Master sends M bit set to zero, Slave ACK with the same sync number and M bit zero)
11. If A or B have no entries in Link State Request List > Full state

Master controls synchronization process and ensure that only one DD packet is outstanding at a time.

When slave receives DD packet, acknowledges the packet by sending a DD packet with the same sequence number.

If master does not receive acknowledgement within Retransmission Interval, then sends new copy.

Sequence Number – all routers must have an identical sequence number

Age

• Starts from 1
• MaxAgeDiff – Maximum Age Difference (15 minutes)
• Router receives multiple copies of the same LSA with identical Sequence Number but with different age
• If difference in the age < MaxAgeDiff – original LSA is retained (no flooding)
• If difference in the age > MaxAgeDiff – new LSA recorded and flooded
• MaxAge – (60 minutes/3600 sec) – after this time LSA is flushed out from LSD
• LSARefreshTime (30 minutes/1800 sec) – flooding all LSA to reset MaxAge

Area notation example

Area 271 = Area 0.0.1.15  = 00000000.00000000.00000001.00001111=100001111=271

LSA Types

LSA 1 – O, Router LSA (contain all Link IDs – network),

• Generated by every router and is local to the area
• Describes all router interfaces + cost
• “Routing bit set on this LSA” means that the route to this destination is in RIB
• show ip ospf database router <router-id>

LSA 2 – O, Network LSA (contain all routers attached to the segment)

• Generated by DR and is local to the area
• Lists all attached routers (router ID) including DR
• show ip ospf database network <IP address of DR>

LSA 3 – O IA, Network Summary LSA (describes network from another Area)

• Generated by ABR and is propagated between areas
• Include cost from ABR to network
• show ip ospf database summary <network_IP>

 LSA 4 – O IA, Summary ASB Link States

• Generated by the ABR and is propagated between areas
• Describes RID of the ASBR
• show ip ospf database asbr-summary

 LSA 5 – O E1, O E2, External Link States

• Generated by ASBR and is propagated between areas
• Describes links that are external to the AS
• show ip ospf database external
• E1 cost consist of:
  • External metric > show ip ospf database external <Link state ID>
  • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
• E2 cost = External metric > show ip ospf database external <Link state ID>

LSA 7 – O N1, O N2, NSSA External Link States

• Generated by ASBR into Not-So-Stubby (NSSA) area
• Describes links that are external to the AS in the NSSA area
• ABR swap the LSA type 7 to LSA type 5 when sends from NSSA into Area 0
• show ip ospf database nssa-external
• N1 cost consist of:
  • External metric show ip ospf database nssa-external <Link state ID>
  • Metric to ASBR (Advertising Router=RID) > show ip ospf border-routers
• N2 cost = External metric > show ip ospf database nssa-external <Link state ID>

Route selection proces based on the LSA type

O>O IA>O E1>O E2>O N1>O N2

As I have promised here you are next post from the PKI scope. Following example presents way of communication between user A and B with digital certificates. It will be one way communication example so user A sends data to user B. The same process takes place in opposite direction. It’s not easy and smooth but rather hardcore and kiler theme 😉 so it’s good to have fresh and open mind to read it. Are you read? Please go ahead.

The following process diagram will be very helpfull to understand the clue, step by step description below:

1. User has own keys pair (public/private keys). Public key A (related to private key A) has been signed and authorized by the CA before (certificate enrolment process that is has been described Public Key Infrastructure – certificate enrolment post).
2. User A uses public key B and encrypts Message that will be sent to the user B. Public key B has been taken from B’s certificate.
3. Additionally, user A takes the same clear Message as input and does SHA (or MD5) hash function – Message# is output of this algorithm.
4. Message# is then encrypted by the Private key A. Digital Signature of the user A Message is output of this process.
5. The Digital Signature is added to the encrypted message.
6. Above decrypted message and User A Certificate is send to the User B. User B gets a encrypted message and start decryption and authentication process. First user needs to be sure that Public key A that will be used for user’s A message authentication is true Public key of user A.
7. To verify it, User B takes the Public key CA from the CA Certificate (that has signed User A’s Data, CA has issued the User A Certificate during certificate enrolment process) and decrypt the Digital Signature CA that is embedded into User A Certificate, Data# A is output of this process. Additionally user B downloads most up to date Certificate Revocation List (CRL) from CA to verify if User A Certificate has not been canceled and is still valid.  
8. User B takes User A Certificate a does the same hash function (like CA has done for User A Data), Data# A is output of this process. User B takes this output and compares with Data# A (that has been produced in point 7) to confirm User A identity. If the hash outputs are the same it means that User A Certificates is real so Public key A is confirmed and can be use for communication.
9. User B takes Public key A and decrypts Encrypted Message that has received. Clear, unencrypted message is output.
10. To confirm that Message is real and has not been changed on way, User B does the same hash function (encryption and authentication functions have been negotiated at the beginning of the communications process, for example in case of IPsec it takes place in Phase 2 of IKE negotiation), so unencrypted Message is a input and Message# is output of this process.
11. Then User B takes own Private key B and decrypts Digital Signature of the Message that has been added by the User A. Message# is output of this process.
12. Message# from point 10 and Message# from point 11 is compare and if are the same then User B is sure that Message has not been changed and is exactly the same like User A has sent.

Some time ago when I was learning about PKI (Public Key Infrastructure) I searched for any process diagram that shows and visualyze step by step ceriticate enrolment process by CA or other encryption or authentication steps in the PKI enviroment in simple and detail manner. Because I have not found any have decided to draw it and explain the process, hope will help to understand the issue.

Before we will discuss the ceriticate enrolment process we have to explain the background shortly. OK so let’s start.

The base of the PKI is the concept of Asynchronous Keys. Asynchronous Keys is the encryption algorithm that can be use to secure transport data over unsecure connectivity, additonaly due to the nature of algorithm authenticate identity.
The idea of algorithm is based on two differtent keys (public and private key) that are mathematical related to each other, where private key derived from the public key. Message encrypted by recipient’s public key can only be decrypted by the corresponding private key (we can encrypt the message only by related key), and vice-versa, message encrypted by the owner’s private key can be only decrypted by the owner’s public key that is commonly available. Based on first case we achive data intergrity and confidential because only owener of private key will be able to decrypt the message and properly read the data, based on second one, reciver of the message can authenticate the sender because once decrypt the message and properly read a data, he knows that data have been sent by proper source (owner of private key). Above algorithm has revolutionized the encryption and authentication way. The only one problem was a public key distribution, this what the PKI is about.

Once we generate public/private key pair, we have to make the private key public available and the get global authority confirmation that the private key belong to as (at least it’s good to have confirmation from globally trusted source). Here Certificate Authority (CA) comes in to play. We have a lot of nice institution like VeriSign or GlobalSign and others that we can trust. The primary task of them is to confirm that generated public key belongs to us so can be used to exchange message in secure way.

Ceriticate enrolment process
I will explain the process based on the following example with user A (instead of user we can have any device: router or server, simple end point that will physically encrypt data).

1. User A generates pair of keys: public key A and private key A.
2. User A sends to the CA, own public key A with additional details that will identify user A like name, surname, departament city, country, e-mail address etc.
3. CA verifies user A data, next takes user A data and public key A as input and do SHA (or MD5) hash function – Data# A is output of this alghorith.
4. CA then uses own Private key CA and encrypts Data# A, Digital signature of the CA is output of this process.
5. User A Data, Public key of A, Digital signature of the CA, and specific details assigned by the CA like certificate serial number, issued and valid date, point of CRL distribution (and many more) creates User A Certificates.
6. Users A can get certificate and start use it to encrypt and authenticate data.

I hope this post will helpfull and clarify certificate enrolment process. If you have any comments please let me know. In next post I will discuss the encryption and authentication based on the digital certificate.

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.