Layer 2 Switching connectivity question

Hello Everyone,

It was my understanding that when a device is "up up" the first up is for layer 1 and the 2nd is layer 2. Well I've come upon some devices where they show up/up status but do not communicate and show no mac address. How is this possible? From what I understood the device should be in an up/down status. I'm trying to get a clear picture on exactly what denotes up/up status, a signal? an unbroken cable plugged into something turned on even if its not communicating?

Some command output below lines edited for brevity.

Switch#sh mac add int gi0/12
Mac Address Table

Switch#sh ip int b
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/12 unassigned YES unset up up

Switch#clear counters gi0/12
Clear "show interface" counters on this interface [confirm]
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#int gi0/12
Switch(config-if)#shut
Switch(config-if)#no shut
Switch(config-if)#end
Switch#sh int gi0/12
GigabitEthernet0/12 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 40f4.ec4c.f70c (bia 40f4.ec4c.f70c)
Description: DEVICE
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:00:49
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
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
46 packets output, 4024 bytes, 0 underruns
0 output errors, 0 collisions, 2 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

Switch#sh mac add int gi0/12
Mac Address Table

Switch#sh ip int b
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/12 unassigned YES unset up up

Thanks for your interest!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

networker050184

What's hooked into the port? Its not going to show any MACs if nothing is sending anything onto the interface. Whats the config look like?

The first up is physical the second is data link layer. So up/up should get you going.

pham0329

Is this an actual switch or is it Packet Tracer?

chilu

Check whats connected to the other side of the cable. You can also check if keepalive is enabled or not on the other end.

CiscoCerts

This is from a production network and the end device is something like an ATM. This is the config, i believe it to be irrelevent to my question:

interface GigabitEthernet0/12
description DEVICE
switchport access vlan 34
switchport mode access
switchport nonegotiate
speed auto 10 100
spanning-tree portfast
spanning-tree bpduguard enable
end

I just want to be clear that I am not trying to troubleshoot this - I'm just wondering what constitutes 'up/up' if its not mac address connectivity

Thanks

networker050184

Is the ATM sending any traffic? If not, you won't see any MACs on there.

CiscoCerts

What constitutes up/up networker050184?

networker050184

networker050184 wrote: »

The first up is physical the second is data link layer. So up/up should get you going.

Miss that part?

If you don't want assistance then don't post questions.

CiscoCerts

networker050184 wrote: »

Miss that part?

If you don't want assistance then don't post questions.

No, I did not miss that part, nor any part. However you seemed to miss my original question completely:

CiscoCerts wrote:

It was my understanding that when a device is "up up" the first up is for layer 1 and the 2nd is layer 2. Well I've come upon some devices where they show up/up status but do not communicate and show no mac address. How is this possible?

networker050184

How are we supposed to answer that if you don't want to provide the relevant info?

wrwarwick

The line protocol up is determined by Ethernet frames sent to itself on the interface, ie keepalives. If the keepalives don't fail it assumes the line is okay for normal traffic.

TCPmag.com | Q and A: The Immortality of Keepalive Frames

techie2012

CiscoCerts wrote: »

No, I did not miss that part, nor any part. However you seemed to miss my original question completely:

If you are going to ask questions on a forum, it makes sense to provide details necessary to determine the cause of the issue. The up/up status on the port indicates all is well. We would need to know details about the ATM or whatever the switch is connected to. Bottom line, being rude is going to get you nowhere and that's not just forums, its life in general....

CiscoCerts

wrwarwick wrote: »

The line protocol up is determined by Ethernet frames sent to itself on the interface, ie keepalives. If the keepalives don't fail it assumes the line is okay for normal traffic.

TCPmag.com | Q and A: The Immortality of Keepalive Frames

This was what I was looking for, thank you.

CiscoCerts

I have put a sniffer (wireshark) on communication from a pc to a cisco switch and no keepalives from the switch are showing up. I'm trying to get a mental picture of how these keepalives work...

Quotes from the link wrwarwick posted:

"The keepalives are layer 2 frames TO and FROM the local MAC address. You're also correct that the router won't get the frame back usually."

"As long as no framing errors, no encapsulation errors, or rejections from the switch (or connected device if not Ethernet), then the transmission is a success."

So does this mean that the switch is sending out a frame - not receiving anything back and because of that assumes the line is ok? To me that seems counter-intuitive.

networker050184

No, the frame should be received back. From Cisco's website:

Cisco wrote:

[h=3]Ethernet Keepalives[/h] On broadcast media like an Ethernet, keepalives are slightly different. Since there are many possible neighbors on the Ethernet, the keepalive is not designed to determine if the path to any one particular neighbor on the wire is available. It is only designed to check that the local system has read and write access to the Ethernet wire itself. The router produces an Ethernet packet with itself as the source and destination MAC-address and a special Ethernet type code of 0x9000. The Ethernet hardware sends this packet onto the Ethernet wire and then immediately receives this packet back again. This checks the sending and receiving hardware on the Ethernet adapter and the basic integrity of the wire.

CiscoCerts

Am I understanding this correctly? Switch sends the special keepalive frame out its send pair, it traverses the wire goes into the end device's nic comes right back out that devices send pair back to the switch's receive pair with its own send/receive destination mac untouched?

wrwarwick

CiscoCerts wrote: »

Am I understanding this correctly? Switch sends the special keepalive frame out its send pair, it traverses the wire goes into the end device's nic comes right back out that devices send pair back to the switch's receive pair with its own send/receive destination mac untouched?

It doesn't sound like it sends the frame to any device at all, but just to itself. Because Ethernet is not a point to point protocol there won't always be a single device to send frames to, like your ATM. The switch (or router, or whatever device) is just checking its own capability to use Ethernet.

And just to add this - maybe your initial question wasn't understood correctly, thus the confusing responses to it. No need to be a jerk about it. All I did was use Google anyway. (The question was interesting to me, so it has been fun to figure this out with you)

CiscoCerts

How could it check its own capability to use ethernet if the signal doesn't traverse the wire? It doesn't make sense to just test as a loopback short would. Does it?

wrwarwick

CiscoCerts wrote: »

How could it check its own capability to use ethernet if the signal doesn't traverse the wire? It doesn't make sense to just test as a loopback short would. Does it?

It almost sounds like the keepalives are a product of the early days of Ethernet. At its core, Ethernet is a basic bus topology; if keepalives were used in the early days to check connectivity to a specific host it would eat up bandwidth on the wire. Thus, the keepalives test the device's ability to use the wire, not necessarily connectivity to a host. Maybe the second "up" is not saying, "I can reach the device at the other end," but rather, "I can successfully use the Ethernet bus."

From another forum post:

If you were to do "no keepalive" the ports would all show as "up/up" since you lost your ability to determine whether it was REALLY functional or not.

I'm no Ethernet engineer, so I may be completely off on all this, but it has been a good topic to think about.