dhcp without rules...

what is important with the dhcp server if you happen to put it in a different subnet other than where the client lives, is that it supports the vlan where you want the address to be delivered with ip helper...

r4 is the dhcp server...

if you make r4 the default router of the pool, that will give the client THAT address as it's gateway...

R4#sh run | b dhcp pool cisco
ip dhcp pool cisco
 network 10.2.1.0 255.255.255.0
 default-router 10.1.4.5

note also there is no matching domain name, irrelevant...

R4#sh ip domain
lab.local

dsw1#sh ip domain                                                             
cisco         

r4 holds the binding for the pc off asw1...

R4#sh ip dhcp bind
Bindings from all pools not associated with VRF:
IP address      Client-ID/         Lease expiration     Type       State      Interface
        Hardware address/
        User name
10.2.1.3        01e8.9a8f.98a7.03       Feb 06 2013 08:19 AM    Automatic  Active     Unknown

ip helper must support the svi, however...

dsw1#sh run int vlan 10                                                       
Building configuration...                                                     
                                                                              
Current configuration : 158 bytes                                             
!                                                                             
interface Vlan10                                                              
 ip address 10.2.1.1 255.255.255.0                                            
 ip helper-address 10.1.4.5                                                   
 standby 10 ip 10.2.1.254                                                     
 standby 10 priority 110                                                      
 standby 10 preempt                                                           
end                         

for my money, i'd rather have the gateway for the pc as the virtual ip of the vlan it belongs to regardless of the router which is governing it... as long as ip helper can get to it, you're done...

R4#sh run | b dhcp
ip dhcp pool cisco
 network 10.2.1.0 255.255.255.0
 default-router 10.2.1.254

the client has as its gateway the hsrp virtual address and it can ping across to the far end...

if the ip helper points to it from the correct vlan on the switch, you can put the dhcp server in any domain, on any device... but for your own sanity, use the hsrp ip because that's it's reason for being...

R4#debug ip dhcp serv pack
DHCP server packet debugging is on.
R4#
*Feb  5 08:44:01.173: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:01.177: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:01.181: DHCPD: client's VPN is .
*Feb  5 08:44:01.181: DHCPD: DHCPRELEASE message received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:01.189: DHCPD: removing ARP entry (10.2.1.3 vrf default).
R4#
*Feb  5 08:44:09.773: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:09.773: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:09.773: DHCPD: client's VPN is .
*Feb  5 08:44:09.773: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:44:09.781: DHCPD: Saving workspace (ID=0x40000007)
*Feb  5 08:44:09.781: DHCPD: New packet workspace 0x6956B57C (ID=0xE5000008)
R4#
*Feb  5 08:44:11.781: DHCPD: Reprocessing saved workspace (ID=0x40000007)
*Feb  5 08:44:11.785: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:44:11.785: DHCPD: Sending DHCPOFFER to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:11.785: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
*Feb  5 08:44:11.785: DHCPD: Freeing saved workspace (ID=0x40000007)
*Feb  5 08:44:11.801: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:11.801: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:11.801: DHCPD: client's VPN is .
R4#
*Feb  5 08:44:11.801: DHCPD: DHCPREQUEST received from client 01e8.9a8f.98a7.03.
*Feb  5 08:44:11.801: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:11.801: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:44:15.317: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:44:15.321: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:44:15.325: DHCPD: client's VPN is .
*Feb  5 08:44:15.325: DHCPD: DHCPINFORM received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:15.325: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:44:15.325: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:45:28.553: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:28.553: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:28.553: DHCPD: client's VPN is .
*Feb  5 08:45:28.557: DHCPD: DHCPRELEASE message received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:28.557: DHCPD: removing ARP entry (10.2.1.3 vrf default).
R4#
*Feb  5 08:45:33.733: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:33.737: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:33.737: DHCPD: client's VPN is .
*Feb  5 08:45:33.737: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:45:33.737: DHCPD: Saving workspace (ID=0xE5000008)
*Feb  5 08:45:33.741: DHCPD: New packet workspace 0x67EA1BDC (ID=0xA6000009)
R4#
*Feb  5 08:45:35.745: DHCPD: Reprocessing saved workspace (ID=0xE5000008)
*Feb  5 08:45:35.745: DHCPD: DHCPDISCOVER received from client 01e8.9a8f.98a7.03 through relay 10.2.1.1.
*Feb  5 08:45:35.745: DHCPD: Sending DHCPOFFER to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:35.745: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
*Feb  5 08:45:35.745: DHCPD: Freeing saved workspace (ID=0xE5000008)
*Feb  5 08:45:35.765: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:35.765: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:35.765: DHCPD: client's VPN is .
R4#
*Feb  5 08:45:35.765: DHCPD: DHCPREQUEST received from client 01e8.9a8f.98a7.03.
*Feb  5 08:45:35.765: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:35.765: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.
R4#
*Feb  5 08:45:39.293: DHCPD: Reload workspace interface FastEthernet0/0 tableid 0.
*Feb  5 08:45:39.297: DHCPD: tableid for 10.1.4.5 on FastEthernet0/0 is 0
*Feb  5 08:45:39.301: DHCPD: client's VPN is .
*Feb  5 08:45:39.305: DHCPD: DHCPINFORM received from client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:39.305: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.2.1.3).
*Feb  5 08:45:39.309: DHCPD: unicasting BOOTREPLY for client e89a.8f98.a703 to relay 10.2.1.1.

troubleshooting, from the horse's mouth...

there are a number of links that provide troubleshooting flow charts at cisco.com

eigrp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094613.shtml

ospf
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800949f7.shtml

bgp
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009478a.shtml

naturally, for just about any technology, you will find more of the same there...

native vlan and control traffic...

i got involved in a thread on cln here:

https://learningnetwork.cisco.com/message/279101#279101

on that link you can download a packet capture that i attached...

i've read recently some conflicting ideas about the tagging of control traffic when vlan 1 is not present... my original thought sided with marko that l2 control traffic belonged to the switch.. here is marko's post:

http://blog.ipexpert.com/2011/01/19/old-ccie-myths-vlan-1/

he explores this idea at length, but this idea is incorrect...

this idea is refuted here:

http://www.fragmentationneeded.net/2011/01/revisiting-vlan-1-myth-again.html

and from the horse's mouth here:

(from Cisco Lan Switching Fundamentals)

It is important to understand the significance of VLAN 1. By default, all switch ports are part of VLAN 1. VLAN 1 contains control plane traffic and can contain user traffic. It is recommended that user traffic be configured on VLANs other than VLAN 1, primarily to prevent unnecessary user broadcast and multicast traffic from being processed by the Network Management Processor (NMP) of the supervisor. Although VLAN 1 user traffic can be pruned from a trunk, it is not the case with control plane traffic. In fact, in older Cisco Catalyst Software versions (5.4 or earlier), VLAN 1 could not be removed at all from a trunk. Control plane traffic such as VTP, CDP, and PAgP protocols are tagged with VLAN 1 information and are forwarded on a trunk regardless if the trunk has pruned VLAN 1.


naturally, i wanted to do my own testing, but my caps never showed tagging... i was using a dhcp windows client for monitoring and in the back of my mind my thought was that i'd never see dot1q tags because my windows nic simply didn't support tagging, therefore wouldn't show in the cap...  well, breaking my current working topology was an annoying idea simply to prove that so i moved on with what i was currently working at the time...

this morning, of course, it was nagging me so i had to be sure... turns out that is correct... dot1q tags don't show up in my windows box caps, but they do with the linux caps...

note on dsw1 in the below output that vlan 1 is not included in trunking...

dsw1#sh int trunk                                                              
                                                                               
Port        Mode             Encapsulation  Status        Native vlan          
Po1         on               802.1q         trunking      200                  
Po2         on               802.1q         trunking      200                  
                                                                               
Port        Vlans allowed on trunk                                             
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans allowed and active in management domain                      
Po1         10,20,200                                                          
Po2         10,20,200                                                          
                                                                               
Port        Vlans in spanning tree forwarding state and not pruned             
Po1         10,20,200                                                          
Po2         10,20,200               

in the cap below note that the control traffic is tagged with vlan 1...

in fact all of the control traffic in the cap is tagged 1... but see for yourself, download the cap from the link and draw your own conclusions... also note that the cap is from the tshoot topology, which means that all supported protocols are represented as they would appear in cisco's topology...  naturally it is my representation of that topology; it is not gospel...

have fun...

note about topology: vlan's 4 and 8 support the gns3 environment onto the switched network... so don't let those qinq's confuse you...

archive..

set up your tftp server and automatically archive configs...

simple enough

R2#sh run | b archive
archive
 path tftp://10.2.1.3/$h
 write-memory
 time-period 720

$h gets replaced by the hostname... write-memory will cause an archive to occur upon copy run start and the time period is minutes (1440 would be once a day)

R2#sh archive
The maximum archive configurations allowed is 10.
The next archive file will be named tftp://10.2.1.3/R2--1
 Archive #  Name
   1        tftp://10.2.1.3/R2Feb--3-07-54-52.616-0 <- most="" recent="" span="">
   2        
   3        
   4        
   5        
   6        
   7        
   8        
   9        
   10       

happy backupping...

more enterprise tshoot...

i added hostnames...

dsw1#sh run | b ip host                                                         
ip host ASW2 192.168.1.132                                                      
ip host ASW1 192.168.1.131                                                      
ip host DSW2 10.2.1.2 10.2.2.1 192.168.1.130                                    
ip host DSW1 10.2.1.1 10.2.2.2 192.168.1.129                                    
ip host R4 10.1.1.10 10.1.4.5 10.1.4.10                                         
ip host R3 10.1.1.6 10.1.1.9                                                    
ip host R2 10.1.1.2 10.1.1.5                                                    
ip host R1 10.1.1.1 209.65.200.225

asw1#trace 209.65.200.241                                                       
                                                                                
Type escape sequence to abort.                                                  
Tracing the route to 209.65.200.241                                             
                                                                                
  1 DSW1 (192.168.1.129) 8 msec 4 msec 4 msec                                   
  2 R4 (10.1.4.5) 20 msec 8 msec 8 msec                                         
  3 R3 (10.1.1.9) 28 msec 28 msec 32 msec                                       
  4 R2 (10.1.1.5) 48 msec 48 msec 52 msec                                       
  5 R1 (10.1.1.1) 68 msec 68 msec 72 msec                                       
  6 209.65.200.226 88 msec 84 msec 80 msec                                      
  7 209.65.200.241 100 msec 104 msec *      

and hsrp for the three vlans...

dsw1#sh stand brie                                                              
                     P indicates configured to preempt.                         
                     |                                                          
Interface   Grp  Pri P State   Active          Standby         Virtual IP       
Vl10        10   110 P Active  local           10.2.1.2        10.2.1.254       
Vl20        20   90  P Standby 10.2.2.1        local           10.2.2.254       
Vl200       200  110 P Active  local           192.168.1.130   192.168.1.134

i mixed the etherchannels up a bit, routed between the dsw's, lacp and ON...

dsw1#sh etherch summ | b Group                                                  
Group  Port-channel  Protocol    Ports                                          
------+-------------+-----------+-----------------------------------------------
1      Po1(SU)          -        Fa0/19(P)   Fa0/20(P)                          
2      Po2(SU)         LACP      Fa0/21(P)   Fa0/22(P)                          
3      Po3(RU)         LACP      Fa0/23(P)   Fa0/24(P) 

i made r1 the ntp server...

asw1#debug ntp pack                                                             
NTP packets debugging is on                                                     
asw1#sh ntp assoc                                                               
                                                                                
      address         ref clock     st  when  poll reach  delay  offset    disp 
*~10.1.1.1         127.127.1.1       3    50    64  377    59.8  -14.50     3.2 
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

asw1#                                                                           
Feb  2 19:27:26: NTP: xmit packet to 10.1.1.1:                                  
Feb  2 19:27:26:  leap 0, mode 3, version 3, stratum 4, ppoll 64                
Feb  2 19:27:26:  rtdel 0F4D (59.769), rtdsp 04A7 (18.173), refid 0A010101 (10.1)
Feb  2 19:27:26:  ref D4B7E6DE.4DA05C2A (14:26:22.303 est Sat Feb 2 2013)       
Feb  2 19:27:26:  org D4B7E6DE.4266B18C (14:26:22.259 est Sat Feb 2 2013)       
Feb  2 19:27:26:  rec D4B7E6DE.4DA05C2A (14:26:22.303 est Sat Feb 2 2013)       
Feb  2 19:27:26:  xmt D4B7E71E.3AE43F2B (14:27:26.230 est Sat Feb 2 2013)       
Feb  2 19:27:26: NTP: rcv packet from 10.1.1.1 to 192.168.1.131 on Vlan200:     
Feb  2 19:27:26:  leap 0, mode 4, version 3, stratum 3, ppoll 64                
asw1#                                                                           
Feb  2 19:27:26:  rtdel 0000 (0.000), rtdsp 001D (0.443), refid 7F7F0101 (127.12)
Feb  2 19:27:26:  ref D4B7E70F.8C1D3D25 (14:27:11.547 est Sat Feb 2 2013)       
Feb  2 19:27:26:  org D4B7E71E.3AE43F2B (14:27:26.230 est Sat Feb 2 2013)       
Feb  2 19:27:26:  rec D4B7E71E.3F56E7AF (14:27:26.247 est Sat Feb 2 2013)       
Feb  2 19:27:26:  xmt D4B7E71E.40559F25 (14:27:26.251 est Sat Feb 2 2013)       
Feb  2 19:27:26:  inp D4B7E71E.4C71E8A4 (14:27:26.298 est Sat Feb 2 2013) 

 added  syslog on a dhcp client...

it never stops...

cisco tshoot topo...

back to it... reminder, this is mixed gns3 and switches... i turned the net acad lab off...

R4(tcl)#foreach address {
+>(tcl)#209.65.200.241
+>(tcl)#209.65.200.226
+>(tcl)#209.65.200.225
+>(tcl)#10.1.1.1
+>(tcl)#10.1.1.2
+>(tcl)#10.1.1.5
+>(tcl)#10.1.1.6
+>(tcl)#10.1.1.9
+>(tcl)#10.1.1.10
+>(tcl)#10.1.4.5
+>(tcl)#10.1.4.6
+>(tcl)#10.1.4.9
+>(tcl)#10.1.4.10
+>(tcl)#10.2.1.1
+>(tcl)#10.2.1.2
+>(tcl)#10.2.1.3
+>(tcl)#10.2.1.254
+>(tcl)#10.2.2.1
+>(tcl)#10.2.2.2
+>(tcl)#192.168.1.129
+>(tcl)#192.168.1.130
+>(tcl)#192.168.1.131
+>(tcl)#192.168.1.132
+>(tcl)#} { ping $address
+>(tcl)#}

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/89/116 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.226, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/64/76 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.225, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/64/84 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/68 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/31/48 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/31/40 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/20 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/18/24 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/39/40 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.129, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.130, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.132, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/12 ms
R4(tcl)#

there's some yummy goodness... 10.2.1.3 is a dhcp client...

quote of the day, karl solie...

just because it's old, doesn't mean it doesn't count... just weed out what's no longer useful... this from ccie practical studies volume 2...

go get em karl:

If the BGP peers are not able to reach each other using TCP port 179, you can use a number of TCP troubleshooting commands to troubleshoot the connection. As a best practice (that will save you many a headache), however, it is better to verify the router configuration for inaccuracies before troubleshooting a problem that might end up being a typo.

• Verify that the local BGP ASN is entered correctly.
• Verify that the remote peer's BGP ASN and IP address are entered correctly.
• Verify that the interfaces connecting the two peers are up and operational.
• If the peers are not directly connected, verify that they have a valid route (to and from) to reach each other.
• Check routers along the path between the peers for access lists or route policies that might be dropping or rerouting BGP traffic.
• Check logs for interface instabilities. Are routes flapping along the route between the BGP peers? Are any of the interfaces heavily congested or dropping packets? Keep in mind that BGP uses rather small packets for OPEN and KEEPALIVE messages. These packets are delayed if other larger packets are monopolizing a congested interface.
• If something has changed in the path between the two BGP peers, verify that it is not affecting the BGP session—for example, a new switch configuration, new access lists, a firewall, new routing policies, and so on.

Don't spend time troubleshooting BGP when it is not the problem! Establish a general layered troubleshooting methodology; it will be the number one troubleshooting tool and your best friend when you encounter a problem.

1. Layer 1

   - Check your cabling; verify that all cables are connected and that the interface is in a line up and protocol up state. Don't spend time troubleshooting BGP when you have a Layer 1 problem.

   - If you are using a serial link, make sure that you have set the correct clock rate. If you are using a channel service unit/data service unit (CSU/DSU), make sure it is properly configured and the line is up.

   - If you are using an Ethernet interface, make sure that the speed and duplex are set correctly on the router and switch.

   - Check the router and switch interfaces for errors; if there are errors, fix the error and then proceed with your troubleshooting. If you are using a Token Ring interface, make sure the router is configured to use the right ring speed, and that it has a good connection to the multistation access unit (MSAU) or switch.
   (note: I supported a 16mbps token ring network from '94 to '97)

2. Layer 2

   - If you are using an Ethernet connection, make sure that the switch port has been assigned to the proper VLAN.

   - Make sure that the VLAN is properly configured, and that there are no spanning-tree topology problems on the switch.

   - On an ATM interface, verify that the maximum transmission unit (MTU) is properly configured on both sides of the connection.

   - Verify that you are using the correct virtual path identifier/virtual channel identifier (VPI/VCI) pair, and that you have configured a valid ATM map for Layer 2 to Layer 3 connectivity. On a Frame Relay connection, verify that your local and remote data-link connection identifiers (DLCIs) and Local Management Interface (LMI) type are correctly set to match the values generated on the switch.

   - Verify that LMI is up and that the interface is not flapping.

   - If you are making a PPP connection, make sure PPP is configured on both sides of the connection.

   - Before proceeding to the next step, verify that your interface is not in a line up protocol down state.

3. Layer 3

   - Verify that you have configured the right IP address and subnet mask on the interface, check the other side of the connection, and verify that it is on the same subnet (if directly connected) or that it is what you think it is.

   - Make sure there is a valid route to reach your destination in the IP routing table. Trace the connection through any routers along the path, and verify that they have a path to and from each of the routers that they must reach for packets to reach your source and destination networks.

   - Check static routes for typos; make sure that any redistributed routes are actually being properly propagated.

   - If multiple paths are in use, verify that there are no routing loops.

   - If authentication is in use by any routing protocols, make sure that they are both using the correct passwords.

   - On nonbroadcast multiaccess (NBMA) networks, such as ATM or Frame Relay, make sure that you have proper support for Layer 2 to Layer 3 mappings, and that protocols such as Open Shortest Path First (OSPF) are configured for the proper network type.

   - Before proceeding to the next step, verify that you are able to reach the destination network from the source network and vice versa.

4. Layer 4

   - Check for any access lists or firewalls that might be dropping TCP packets.

   - Verify that you have connectivity on TCP port 179. One BGP speaker, the passive TCP host, will receive a TCP request on port 179, and the other speaker, the active TCP host, will use a random TCP source port (beginning at 11,000) to initiate the TCP session.

   - Check for retransmissions, out-of-order packets, or other TCP symptoms that might be pointing to network congestion or invalid configurations.

After verifying that all the prior conditions are not affecting the BGP session, use TCP show and debug commands to help narrow down the culprit.

TCP Command	Command Description
show tcp	This command displays detailed information on each TCP session that the local router has formed with a remote peer. It can be used with BGP to show whether the local and remote BGP peers have formed an established TCP session, and show details about that session.
show tcp [brief][all] [| include 179]	This command displays a brief status of each of the TCP sessions that the local router has formed with a remote router. This is a basic summary command that you can use as another tool to verify the BGP TCP connection between peers.
debug ip tcp transactions	This command, which should be used with caution on a production router, displays information about TCP session changes. It enables you to troubleshoot a BGP TCP session, displaying information about TCP retransmissions or state changes.
debug ip tcp packet [in | out | address IP-address | port port-number]	This command displays detailed information about TCP packets. It can be used with the in, out, address, or port arguments to specify particular traffic, and must be used with extreme caution on a production router. With this command, you can monitor TCP packets sent and received by the local router. This information enables you to determine the cause of an unstable BGP TCP session and resolve route flapping or general connectivity issues.

If the show tcp command output for the peer IP address used for the BGP session is anything other than ESTAB, troubleshoot the TCP connection.

a monster...

rrrrrrrrrrrrrrrrrr...

look at this thing... it uses nm-esw16's of course...

you can find it here... there's 20 labs there...

http://certcana.ca/tshoot/

it'll peg your cpu's, count on it... but if you adjust the topology.net file with known good idle values, you'll be ok...

it's very exciting...

unfortunately, i can't suffer the behavior of the routers as switches... and since i have 3560's, i'm not interested... have fun with that...

quote of the day... ospf auth...

you have been warned...

NOTE 
OSPF authentication is a good place for tricky CCIE lab questions—ones that can be solved in a few minutes if you know all the intricacies.

of course...  authentication can create havoc with routing protocols... and yes, the configuration for eigrp, ospf and bgp are unique to each routing protocol...

so what's the plan... you hate it so much that you love it... like frame relay, dtp, vtp, or whatever your particular hateful protocol might be...

bring the hate and you will find the love...

the devil's in the details, baby...

tshoot lab manual...

i thought i'd avoid much commentary about the tshoot net acad lab manual, but this is worth a mention...

look at this:

DLS1#sh run int f0/5
Building configuration...

Current configuration : 163 bytes
!
interface FastEthernet0/5
 description FE to R1
 no switchport
 ip address 10.1.2.1 255.255.255.252
 speed 100
 duplex full
 spanning-tree bpduguard enable
end

note this is a distribution switch... note it is connected to a router... it is a routed port and it has bpduguard on it...  i remember a long time ago watching an anthony sequiera (sic) video where he demonstrates how to errdisable a switchport using a router... about a week ago i was watching jeremy cioara vids on tshoot, where he had to troubleshoot a situation just like this...

like chucky says to the interviewers in Good Will Hunting, "you're suspect..."

DLS1#sh int f0/5 sw
Name: Fa0/5
Switchport: Disabled

DLS1#sh spann int f0/5
no spanning tree info available for FastEthernet0/5

DLS1#sh int f0/5
FastEthernet0/5 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.c706.96c2 (bia 0016.c706.96c2)
  Description: FE to R1
  Internet address is 10.1.2.1/30
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     26086 packets input, 2944859 bytes, 0 no buffer
     Received 10943 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 10899 multicast, 0 pause input
     0 input packets with dribble condition detected
     23227 packets output, 2507991 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

i hate to say it but sh run int f0/5 is your only detection...

this is how you do it...

R1(config)#bridge 1 protocol ieee
R1(config)#int f0/0
R1(config-if)#bridge-group 1

DLS1#sh int f0/5
FastEthernet0/5 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.c706.96c2 (bia 0016.c706.96c2)
  Description: FE to R1

DLS1(config)#int f0/5
DLS1(config-if)#sw
DLS1(config-if)#
.Jan 22 16:48:07.180: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
DLS1(config-if)#do
.Jan 22 16:48:09.202: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to up
.Jan 22 16:48:10.208: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to up
DLS1(config-if)#do
.Jan 22 16:48:10.619: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/5 with BPDU Guard enabled. Disabling port.
DLS1(config-if)#do
.Jan 22 16:48:10.619: %PM-4-ERR_DISABLE: bpduguard error detected on Fa0/5, putting Fa0/5 in err-disable state
DLS1(config-if)#do
.Jan 22 16:48:11.634: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5, changed state to down
DLS1(config-if)#do
.Jan 22 16:48:12.632: %LINK-3-UPDOWN: Interface FastEthernet0/5, changed state to down

DLS1#sh int f0/5
FastEthernet0/5 is down, line protocol is down (err-disabled)
  Hardware is Fast Ethernet, address is 0016.c706.9687 (bia 0016.c706.9687)
  Description: FE to R1

that ain't nice...

tshoot net acad lab man...

that was impressive, tedious, very time consuming, but worth it...

33 labs in about two weeks... you will be amazed what you take away from the experience of this... i haven't posted much about these labs, and i'm glad i refrained... another great point is there are no answer sheets... this thing is all about discovery... you owe this to yourself...

if you are going through tshoot, you don't want to forget about this one... this is essential... in fact if you are going through ccnp, you should do each section's lab manual, switch and route included, no question...

you've seen the tshoot topologies; you can bet your ass their guts are based on this... the last lab is a very pleasant surprise by the way... i was actually moved by it... if you go through this you will understand what i'm talking about...

rest assured, i'll be doing these in the near future:

we'll see what ole marty brings...

port channel and interfaces...

this is a bit of a repeat from an earlier post, but it bears repeating... so i'm gonna repeat... and i don't care if you care... so there...

if you make a change to the hardware interfaces that are members of a portchannel they will fall out, or rather, get suspended...

it is too bad that the show interfaces command on a physical interface does not mention which portchannel they are members of... the show interfaces command on a port channel, however does show the member interfaces...

DLS2#sh int f0/2
FastEthernet0/2 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0016.479e.5f84 (bia 0016.479e.5f84)
  Description: Channel to ALS1
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:43, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     4685 packets input, 563671 bytes, 0 no buffer
     Received 2721 broadcasts (2465 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 2465 multicast, 0 pause input
     0 input packets with dribble condition detected
     17440 packets output, 1375217 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

see it anywhere? no... good...

DLS2#sh int po10
Port-channel10 is up, line protocol is up (connected)
  Hardware is EtherChannel, address is 0016.479e.5f85 (bia 0016.479e.5f85)
  Description: Channel to DLS1
  MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, link type is auto, media type is unknown
  input flow-control is off, output flow-control is unsupported
  Members in this channel: Fa0/3 Fa0/4
  ARP type: ARPA, ARP Timeout 04:00:00

can't have everything...   sh int trunk and etherchann summ is your antidote...

you love them...

DLS2#sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Po2         on               802.1q         trunking      900
Po10        on               802.1q         trunking      900

Port        Vlans allowed on trunk
Po2         10,20,30,100
Po10        10,20,30,50,100,200

Port        Vlans allowed and active in management domain
Po2         10,20,30,100
Po10        10,20,30,50,100,200

Port        Vlans in spanning tree forwarding state and not pruned
Po2         10,20,30,100
Po10        10,20,30,50,100,200
DLS2#sh etherch summ
Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

        M - not in use, minimum links not met
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port


Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SU)         -        Fa0/3(P)    Fa0/4(P)

some bozack issued the command:

DLS2(config)#int rang f0/3 - 4
DLS2(config-if-range)#no sw noneg
DLS2(config-if-range)#end
DLS2#sh int trunk

Port        Mode             Encapsulation  Status        Native vlan
Po2         on               802.1q         trunking      900

Port        Vlans allowed on trunk
Po2         10,20,30,100

Port        Vlans allowed and active in management domain
Po2         10,20,30,100

Port        Vlans in spanning tree forwarding state and not pruned
Po2         10,20,30,100

that didn't sit too well with po10, so it bounced them...

DLS2#sh etherch summ

Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SD)         -        Fa0/3(s)    Fa0/4(s) 

he wasn't finished...

DLS2#sh int f0/3 sw
Name: Fa0/3
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down (suspended member of bundle Po10)
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 999 (UNUSED)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: 10,20,30,50,100,200
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

the quick fix is to set everything good on the portchannel... that will insure uniformity across the interfaces...

DLS2(config)#int po10
DLS2(config-if)#sw trunk encap dot1q
DLS2(config-if)#sw mode trunk
DLS2(config-if)#sw trunk native vlan 900
DLS2(config-if)#sw noneg
DLS2(config-if)#end
DLS2#sh etherch summ

Number of channel-groups in use: 2
Number of aggregators:           2

Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
2      Po2(SU)          -        Fa0/1(P)    Fa0/2(P)   
10     Po10(SU)         -        Fa0/3(P)    Fa0/4(P)   

you can use the interface range command with portchannels too...

dhcp snooping...

below is a brief article i wrote some time ago about trust...


http://insearchofthecert.blogspot.com/2012/05/snoop-dog.html

here is a link to a series of great articles from petr lapukhov from INE about option 82...

http://blog.ine.com/2009/07/22/understanding-dhcp-option-82/

As you know, DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool.

option 82 sometimes gets in the way...  the question is can it be safely removed?

in this scenario, we have just this dilemma...

DLS1#debug ip dhcp serv pack
DHCP server packet debugging is on.
DLS1#
Jul 26 18:04:54.059: DHCPD: Reload workspace interface Vlan10 tableid 0.
Jul 26 18:04:54.059: DHCPD: tableid for 10.1.10.252 on Vlan10 is 0
Jul 26 18:04:54.059: DHCPD: client's VPN is .
Jul 26 18:04:54.059: DHCPD: inconsistent relay information.
Jul 26 18:04:54.059: DHCPD: relay information option exists, but giaddr is zero.

the topology is from the net acad tshoot manual:

we see dhcp snooping is not enabled for the vlan in question, vlan 10, but option 82 is enabled...

DLS1#sh ip dhcp snoop
Switch DHCP snooping is disabled
DHCP snooping is configured on following VLANs:
none
DHCP snooping is operational on following VLANs:
none
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled
   circuit-id default format: vlan-mod-port
   remote-id: 0016.c706.9680 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

Interface                  Trusted    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------  

giaddr means gateway ip address switched by relay...

from the doccd: http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_dhcp/configuration/12-4t/config-dhcp-server.html#GUID-AB964011-EADA-4888-BCD1-E52E91F3AA49

Automatic DHCP address allocation is typically based on an IP address, whether it be the gateway address (giaddr field of the DHCP packet) or the incoming interface IP address. In some networks, it is necessary to use additional information to further determine which IP addresses to allocate. By using option 82, the Cisco IOS relay agent has long been able to include additional information about itself when forwarding client-originated DHCP packets to a DHCP server. The Cisco IOS DHCP server can also use option 82 as a means to provide additional information to properly allocate IP addresses to DHCP clients. 

when ip dhcp snooping is enabled, and also enabled for vlan 10:

DLS1#sh run | b ip dhcp snoop
ip dhcp snooping vlan 10
ip dhcp snooping

option 82 is not automatic for the requesting device:

DLS1#sh ip dhcp snoop
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 default format: vlan-mod-port
   remote-id: 0016.c706.9680 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:

when we try to renew from the client on als1:

DLS1#
Jul 26 18:32:32.136: %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82

so it wants option 82...

but this is funny...

if you try to follow the rules by using the hostname argument:

DLS1(config)#ip dhcp snoop info option format remote-id hostn
DLS1(config)#
Jul 26 18:52:15.845: %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giadd

shit out of luck...

but if you allow all untrusted, bingo:

DLS1(config)#ip dhcp snoop inform option all
DLS1(config)#
Jul 26 18:54:46.258: DHCPD: Reload workspace interface Vlan10 tableid 0.
Jul 26 18:54:46.258: DHCPD: tableid for 10.1.10.252 on Vlan10 is 0
Jul 26 18:54:46.258: DHCPD: client's VPN is .
Jul 26 18:54:46.258: DHCPD: DHCPREQUEST received from client 01e8.9a8f.98a7.03.
Jul 26 18:54:46.258: DHCPD: Sending DHCPACK to client 01e8.9a8f.98a7.03 (10.1.10.1).
Jul 26 18:54:46.258: DHCPD: no option 125
Jul 26 18:54:46.258: DHCPD: unicasting BOOTREPLY to client e89a.8f98.a703 (10.1.10.1).
Jul 26 18:54:46.258: D
DLS1(config)#HCPD: no option 125

you figure it out... just trust everything and it works... some feature that...