• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

General

Link Layer Discovery Protocol (LLDP)

02/12/2013 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Cisco Network Academy students, Cisco certified folks, and network professionals know what Cisco Discovery Protocol (CDP) is. Ask them what LLDP is then there’s a good chance that majority of them will say “what’s that?”. For simplicity’s sake, Link Layer Discovery Protocol (LLDP) is an IEEE standard discovery protocol that is similar to Cisco Discovery Protocol (CDP). Need to learn more about it? Please head over to Cisco’s documentation and here’s one that I found.

Usage

For the most part, I think you’re going to see more of CDP than LLDP. However, if you work in an organization that has multivendor network devices then you may be solely going to use LLDP. Some of organizations that do have multivendor network devices run both of CDP and LLDP concurrently. I’d tell you this much though, out of the three organizations I work(ed) for, my current employer is the only one that is running LLDP for majority of the network devices.

Configuration

Configuring LLDP is pretty much exactly the same as CDP. You just need to change the cdp part to lldp of the commands. While CDP is enabled by default, LLDP is not – at least that’s what it says on Cisco’s documentation. When I tried it on a Catalyst 3750, the LLDP was globally enabled by default. It doesn’t really matter if it is globally enabled or not. Entering the command twice doesn’t affect anything. If you are really curious what’s going to happen when it is not globally enabled then it should look like the one shown below.

         --- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: no
Would you like to terminate autoinstall? [yes]: yes
Switch>sho lldp neigh
% LLDP is not enabled

As you can see, it is pretty much exactly the same as the CDP equivalent command in the verification standpoint. As mentioned, the configuration part is pretty much the same as well, as shown below.

Switch2(config)#lldp ?
  holdtime    Specify the holdtime (in sec) to be sent in packets
  reinit      Delay (in sec) for LLDP initialization on any interface
  run         Enable LLDP
  timer       Specify the rate at which LLDP packets are sent (in sec)
  tlv-select  Selection of LLDP TLVs to send
Switch2(config)#lldp run
Switch2(config)#end

Verification

Once LLDP is running, you can now do some show commands. Again, the commands are pretty much the same as the CDP, so whatever you can think of the commands that you use with CDP just replace the “cdp” to “lldp”. While the commands are pretty much the same, the output is slightly different. One interesting field is the capability column. With LLDP, it doesn’t say what type of a device and/or platform that is connected to the local switch, unlike CDP. If you are really curious about what type the device is connected to the local switch then you can always use the show lldp neighbor with the detail keyword as shown below. With the detail keyword, the system capability is now listed.

Switch2#sh lldp neigh
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Switch1             Fa1/0/48       120                        Gi4/0/48
Switch2#sh cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
Switch1          Gig 4/0/48        123           S I      WS-C3750- Fas 1/0/48
Switch5>sh lldp neigh g1/0/7 d
Chassis id: 0000.1111.2222
Port id: Gi0/1
Port Description: GigabitEthernet0/1
System Name: Switch3
System Description: 
Cisco IOS Software, C3560 Software (C3560-IPBASEK9-M), Version 12.2(37)SE1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 05-Jul-07 22:22 by antonino
Time remaining: 115 seconds
System Capabilities: B,R
Enabled Capabilities - not advertised
Management Addresses:
    IP: 192.168.0.55
Auto Negotiation - supported, enabled
Physical media capabilities:
    Other/unknown
Media Attachment Unit type: 22
---------------------------------------------
Total entries displayed: 1

Here’s another show lldp neighbor output on a different switch that is in production (changed hostname and other information to protect the innocent) with Juniper switch connected to it.

Cisco>sh lldp neigh
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Cisco-switch-1      Gi1/0/7        120                        Gi0/1
Juniper-switch1     Gi2/0/1        120        B,R             666
Juniper-switch1     Gi1/0/1        120        B,R             531
Total entries displayed: 3
Cisco>sh lldp neigh g2/0/1 d
Chassis id: 1234.1234.1234
Port id: 666
Port Description:
System Name: Juniper-switch1
System Description: 
Juniper Networks, Inc. ex4200-24f , version 10.4R5.5 Build date: 2011-06-14 04:09:33 UTC 
Time remaining: 111 seconds
System Capabilities: B,R
Enabled Capabilities: B,R
Management Addresses:
    IP: 192.168.1.100
    OID:
        01 03 06 01 02 01 1F 01 01 01 01 24
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseX(FD)
    1000baseT(FD)
Media Attachment Unit type - not advertised
MED Information:
    MED Codes:
          (NP) Network Policy, (LI) Location Identification
          (PS) Power Source Entity, (PD) Power Device
          (IN) Inventory
    Inventory information - not advertised
    Capabilities: NP, LI, PS
    Device type: Network connectivity
    Network Policies - not advertised
    Power requirements - not advertised
---------------------------------------------
Total entries displayed: 1

This time, the capability column did include B (Bridge) and R (Router) for a non-Cisco device on show lldp neighbor output. If you need to know the model of the device connected to the local switch, then you need to issue the detail command also shown above.

LLDP is also useful when you’re running non-Cisco IP phones in a Cisco switched environment. This would’ve been perfect in my old employer since the switches were Cisco and the IP phones were Avaya. Even though we run mostly Cisco switches and IP phones in my current employer, the devices are generally not using CDP but LLDP.

Thoughts

Some network professionals would be tempted to run both CDP and LLDP concurrently, I do not recommend it. I’d say just stick with one protocol so you’re not starting another service that may be vulnerable with exploits. Most Information Security folks are not so fond of people just turning services just for the heck of it. That being said, pick one that is suitable with your environment and stick with it. If you need to add devices in the future that is not Cisco then I’d suggest to explore turning LLDP globally and disabling CDP globally.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

System Time And Log Time

08/07/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

As pointed out in my previous blog post, I don’t like seeing wrong time. I especially do not like seeing two different time on show log and show clock output. I’ve seen this happened several times on Cisco routers and switches and it really annoys me whenever I need to know when a specific event happened and also how long ago it happened. Having said that, I try to create a config template for every router and switches I deploy. Also, I try to go back to all the routers and switches already deployed so everything is standardized. If you have thousands of routers and switches, it’ll be a pain in the neck to do it manually so tools such as AlterPoint Device Authority or SolarWinds’ Network Configuration Manager are there to help. These products also keep backups of all your configurations also so it’s a great tool to have in an enterprise.

Below is to show an example of a router with NTP and timezone properly configured but log timestamp doesn’t match the system time.

Router#sho clock
10:39:06.730 PST Tue Jul 31 2012
Router#conf t
Router (config)#int f0/0
Router (config-if)#no shut
Jul 31 15:52:39:  %SYS-5-CONFIG_I: Configured from console by networkjutsu on console
Jul 31 15:52:39:  %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
Jul 31 15:53:39:  %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

To fix this, issue the command below.

Router(config)# service timestamps log datetime localtime msec
Router#show clock
10:40:30.360 PST Tue Jul 31 2012
Router#conf t
Router (config)#int f0/0
Router (config-if)#shut
Jul 31 10:39:53.280: %SYS-5-CONFIG_I: Configured from networkjutsu by console
Jul 31 10:39:54.280: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
Jul 31 10:39:54.580: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down

As you can see above, the log timestamp is now synchronized with the system time clock. Now, it’s time for you to send this config to all routers and switches in your network.

Hope this has been helpful and thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Cisco router and/or switch timezone

07/18/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I don’t know about you but I like having the right time in my Cisco routers and/or switches. Having the right time is important especially when you need to find time sensitive information like when did a certain interface went down or did the router’s ACL block a certain traffic at a specific time. A lot of organizations have NTP servers that are stratum 1. Companies such as EndRun Technologies sell stratum 1 NTP servers which are normally synchronized over GPS, CDMA, or WWV. That being said, take advantage of that NTP server and point all of your nodes that are capable of running NTP to that server.

The issue that I have with Cisco routers/switches is that they default to UTC and even if you have a stratum 1 NTP server, when you issue show clock it will still show you the UTC time. I may be wrong to assume that not a lot of people know their UTC offset value for their timezone so when they see that UTC time, they’ll most likely go to Google and do a search. Fortunately, Cisco routers and switches have the capability of changing the UTC offset value. Now, you do not have to “google” the UTC equivalent for your timezone. Without further ado, here are the commands that you need to issue to change your Cisco router/switch’s timezone.

Router#sho clock
23:32:28.465 UTC Wed Jul 1 2012
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router (config)#clock timezone PST -8
Router (config)#do show clock
15:33:06.549 PST Wed Jul 1 2012
Router (config)#clock summer-time PST recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Router (config)#do sho clock
16:34:15.462 PST Wed Jul 1 2012

Since my timezone is Pacific Standard Time (PST), I used -8 for my UTC offset value. Obviously, you need to change the offset value that is equivalent to your area’s timezone. The second command below is for countries that observe Daylight Savings Time (DST) rule. The new DST rule (2007 changes) observed here in the USA is that it begins at 2:00 a.m. on the second Sunday of March and ends at 2:00 a.m. on the first Sunday of November.

Now that you know how to change the timezone in Cisco IOS, it’s time for you to send out the changes to all of your routers and switches.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Cisco Live 2012 Schedule

05/25/2012 By Andrew Roderos Leave a Comment

Here’s my schedule for the Cisco Live 2012 San Diego.

Since I am taking the CCIE R&S Written at Cisco Live, I am including this as well.

As you can see, the schedule for my written overlaps with the FCoE for the IP Network Engineer session since the written is a two-hour exam. Hopefully, I won’t miss the good stuff since I am really new to the data center realm. The Cisco UCS that we’re bringing in should be a good experience once it has been deployed since I’ll be involved with that. It’ll also give me hands on experience with Nexus 1000V since we bought it with the Cisco UCS bundle. That’s the reason why I am taking some sessions about Nexus as well. I have very limited exposure with NX-OS since my previous employer had other network engineers that were in charge of the data center. There were only several instances that I had to log in to those routers since most of the projects that I handled and daily tasks were away from the data center part of the network.

Anyway, if you’re in the same session as I am, please feel free to say hi.

Two Port T1/E1 Voice/WAN Interface Card

02/16/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

I like using VWIC-2MFT-T1 card since it gives me the ability to save WIC slots on smaller routers, like Cisco 1841. If you’re also in a budget, it is quite useful to combine voice and data T1 with this card. Though, you may want to separate them so it won’t be a single point of failure.

The first time I’ve installed this on a 2821 router, I didn’t see any serial interfaces at all in the show ip int br output, as shown below. Second thing I checked was, if the card was being recognized using show diag and show ver, as shown below.

Router#show ip int br
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         unassigned      YES unset  administratively down down
Router#show ver | i T1
2 Channelized (E1 or T1)/PRI ports
Router#show diag | i VWIC
        VWIC2-2MFT-T1/E1 - 2-Port RJ-48 Multiflex Trunk - T1/E1
        Product (FRU) Number     : VWIC2-2MFT-T1/E1

Looking at the output, the card was being recognized so I asked myself why was not seeing the serial interfaces. Upon reading Cisco’s documentation, I discovered that I needed to issue commands to enable them and show up as serial interfaces. Though, this may vary router/IOS to router/IOS. When I installed it on a Cisco 1841, I didn’t have to use card type command. In this particular scenario, I am using a Cisco 2901 router with IOS version 15. Normally, you can determine this by doing a show run to see if card type command is needed, as shown below.

Router#sh run
Building configuration...
Current configuration : 880 bytes
!
! No configuration change since last restart
!
version 15.0
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
! card type command needed for slot/vwic-slot 0/0
! card type command needed for slot/vwic-slot 0/1
! card type command needed for slot/vwic-slot 0/2
!
no aaa new-model
! Output omitted for brevity

As you can see from above, there’s a message that you need to issue the card type command. The commands you need to enable the VWIC-2MFT-T1 or VWIC2-2MFT-T1 are shown below.

Router(config)#card type t1 0 0
Router(config)#controller t1 0/0/0:0
Router(config-controller)#framing esf
Router(config-controller)#linecode b8zs
Router(config-controller)#channel-group 1 timeslots 1-24
Router(config-controller)#
Feb 17 01:07:29.255: %LINK-3-UPDOWN: Interface Serial0/0/0:1, changed state to down
Feb 17 01:07:30.255: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0:1, changed state to down
Router(config-controller)#controller t1 0/0/0:1
Router(config-controller)#channel-group 1 timeslots 1-24
Router(config-controller)#
Feb 17 01:08:01.031: %LINK-3-UPDOWN: Interface Serial0/0/1:1, changed state to down
Feb 17 01:08:02.031: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1:1, changed state to down
Router(config-controller)#do sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         unassigned      YES unset  administratively down down
GigabitEthernet0/1         unassigned      YES unset  administratively down down
Serial0/0/0:1              unassigned      YES unset  down                  down
Serial0/0/1:1              unassigned      YES unset  down                  down

Again, this may not be a good idea if you’re concern about single point of failure. However, I find these cards pretty reliable and I have not seen them fail. They’re best if you’re concern with WIC/VWIC slot density, especially when you start using more than two bonded T1s.

I hope this has been helpful and thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email
  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use