Comware Based
1753943 Members
9288 Online
108811 Solutions
New Discussion

Re: VLANs on trunks explanantion

 
johnnym57
Occasional Advisor

VLANs on trunks explanantion

I have a problem with creating a trunk link between a 5130 edge switch and the core 5900 that needs to pass more than native VLAN 1.

The core no longer sees the IP of the edge switch on VLAN1  when I connect up this link but connect a laptop to the edge switch and I can ping the IP address of the edge switch on VLAN1 but not the core or anything beyond.

Relevant sections of the configs. The VLANs are already created on each switch and the link is seemingly up.

a). core:

 interface Ten-GigabitEthernet2/0/28

 port link-type trunk

 port trunk permit vlan 1 200 341

b).

interface Ten-GigabitEthernet1/0/51

port link-type trunk

port trunk permit vlan 1 200 341

Someone tells me that I may need to use the line on each port at each end of the link:

stp edge-port enable

but I would really appreciate an explanation of why this link doesn't work as it stands and what the command above might do to resolve this. The link was working fine before I tried to config the vlan and changed the link to a trunk so I know the hardware and basic config is OK. Thank you.

5 REPLIES 5
parnassus
Honored Contributor

Re: VLANs on trunks explanantion

Those 10GBase-T ports (on core: 2/0/28, on edge: 1/0/51) - considering their function: be Switch-to-Switch uplink ports - shouldn't be considered (nor configured) as edge ports [*] (also, by default, think that all ports of a Switch are set as non-edge ports)...so what should be the reason to you use the stp edged-port enable command on those uplink interfaces?

Will be interesting to go further and analyse logs and diagnose vlan/trunk status (on both ends concurrently).

[*] from Documentation: "If a port directly connects to a user terminal rather than another device or a shared LAN segment, this port is regarded as an edge port. When network topology change occurs, an edge port will not cause a temporary loop. Because a device does not determine whether a port is directly connected to a terminal, you must manually configure the port as an edge port. After that, the port can rapidly transit from the blocked state to the forwarding state."


I'm not an HPE Employee
Kudos and Accepted Solution banner
johnnym57
Occasional Advisor

Re: VLANs on trunks explanantion

Thank you. I was trying to setup a Voice VLAN and the edge port command came to me from someone else with a generic setup which may have been used on other switches. Unless I understand what commands do then I won't input them. The instructions also suggest the trunk from core to edge switch should also have "undo jumbo frame enable" set on this. link but again I don't understand why. In this case VLAN 341 will be the voice vlan and 1 is the native VLAN.

I have looked at the ports below, they appear to be connected as there are statistics., are there any other ways I can harvest information on what might be happenning here?

1. CORE

Ten-GigabitEthernet2/0/28 current state: UP
Line protocol current state: UP
IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: bcea-fa02-47ae
Description: Ten-GigabitEthernet2/0/28 Interface

Loopback is not set

Media type is optical fiber,Port hardware type is 1000_BASE_SX_SFP

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

The Maximum Frame Length is 10000

Allow jumbo frame to pass

Broadcast MAX-ratio: 100%

Multicast MAX-ratio: 100%

Unicast MAX-ratio: 100%

PVID: 1

Port link-type: trunk

 VLAN Passing:   1(default vlan), 200, 341,

 VLAN permitted: 1(default vlan), 200, 341,

 Trunk port encapsulation: IEEE 802.1q

Port priority: 0

Last clearing of counters: Never

Peak value of input: 9977 bytes/sec, at 2013-03-03 00:18:06

Peak value of output: 37304 bytes/sec, at 2013-03-06 02:24:06

Last 300 seconds input:  0 packets/sec 11 bytes/sec 0%

Last 300 seconds output:  135 packets/sec 12913 bytes/sec 0%

Input (total):  278275 packets, 29219670 bytes

21801 unicasts, 240284 broadcasts, 16190 multicasts, 0 pauses

Input (normal):  278275 packets, - bytes

21801 unicasts, 240284 broadcasts, 16190 multicasts, 0 pauses

Input:  0 input errors, 0 runts, 0 giants, 0 throttles

0 CRC, 0 frame, - overruns, 0 aborts

ignored, - parity errors

Output (total): 60776149 packets, 6263724553 bytes

234455 unicasts, 50968186 broadcasts, 9573508 multicasts, 0 pauses

Output (normal): 60776149 packets, - bytes

234455 unicasts, 50968186 broadcasts, 9573508 multicasts, 0 pauses

Output: 0 output errors, - underruns, - buffer failures

0 aborts, 0 deferred, 0 collisions, 0 late collisions

0 lost carrier, - no carrier
[Core]

[Core]display bvlan 200

 VLAN ID: 200

 VLAN type: Static

 Route interface: Not configured

 Description: Z

 Name: Z

 Tagged ports:  

Ten-GigabitEthernet2/0/28

Untagged ports:

Ten-GigabitEthernet2/0/35

[Core]display vlan 200341

 VLAN ID: 341

 VLAN type: Static

 Route interface: Not configured

 Description: C

 Name: C

 Tagged ports:  

Ten-GigabitEthernet2/0/28

 Untagged ports:

Ten-GigabitEthernet2/0/36

2. Edge Switch  Trunk Port to Core
Ten-GigabitEthernet1/0/51

Current state: UP

Line protocol state: UP

IP packet frame type: Ethernet II, hardware address: bcea-fa0b-7c23

Description: Ten-GigabitEthernet1/0/51 Interface

Bandwidth: 1000000 kbps

Loopback is not set

Media type is optical fiber, Port hardware type is 1000_BASE_SX_SFP

1000Mbps-speed mode, full-duplex mode

Link speed type is autonegotiation, link duplex type is autonegotiation

Flow-control is not enabled

Maximum frame length: 9216

Allow jumbo frames to pass

Broadcast max-ratio: 100%

Multicast max-ratio: 100%

Unicast max-ratio: 100%

PVID: 1

MDI type: Automdix

Port link-type: Trunk

 VLAN Passing:   1(default vlan), 200, 341

 VLAN permitted: 1(default vlan), 200, 341

 Trunk port encapsulation: IEEE 802.1q

Port priority: 0

Last clearing of counters: Never

Peak input rate: 39048 bytes/sec, at 2013-01-01 21:41:47

Peak output rate: 16 bytes/sec, at 2013-01-01 17:25:35

Last 300 second input: 101 packets/sec 10086 bytes/sec 0%

Last 300 second output: 0 packets/sec 11 bytes/sec 0%

Input (total):  51444919 packets, 5271670745 bytes

16342 unicasts, 43201159 broadcasts, 7866310 multicasts, 0 pauses

Input (normal):  51083811 packets, - bytes

16342 unicasts, 43201159 broadcasts, 7866310 multicasts, 0 pauses

Input:  0 input errors, 0 runts, 0 giants, 0 throttles

0 CRC, 0 frame, - overruns, 0 aborts

ignored, - parity errors

Output (total): 14346 packets, 5091676 bytes

 0 unicasts, 0 broadcasts, 14346 multicasts, 0 pauses

Output (normal): 14346 packets, - bytes

 0 unicasts, 0 broadcasts, 14346 multicasts, 0 pauses

Output: 0 output errors, - underruns, - buffer failures

 0 aborts, 0 deferred, 0 collisions, 0 late collisions

0 lost carrier, - no carrier        

I've omitted details on VLAN1 for clarity but the two ports above are listed under VLAN1 untagged.. Core 2/0/28 and edge 1/0/50.

parnassus
Honored Contributor

Re: VLANs on trunks explanantion

I've no time now to look deeply but, at first sight, a thing I immediately noticed is a maximum frame length (MTU) mismatch (9216 on edge versus 10000 on core) if I've read it correctly (and you let Jumbo Frames to pass)...would also be interesting to see statistics refreshed (cleared), so you can figure out about any traffic issue starting with fresh and cleared statistic buffers on both ends.

Passing/Permitted VLAN(s) and Trunk encapsulation look OK to me (at first sight)...


I'm not an HPE Employee
Kudos and Accepted Solution banner
johnnym57
Occasional Advisor

Re: VLANs on trunks explanantion

I also found these bits in the diagnostic file which may help.

===============================================================
  ===============display stp abnormal-port=============== 
 MST ID   Blocked Port                        Reason

 0        Ten-GigabitEthernet1/0/51           Disputed

and

----[Port51(Ten-GigabitEthernet1/0/51)][DISCARDING]----

 Port protocol       : Enabled

 Port role           : Root Port (Boundary)

 Port ID             : 128.51

 Port cost(Legacy)   : Config=auto, Active=20

 Desg.bridge/port    : 32768.08bd-4376-0689, 128.16

 Port edged          : Config=disabled, Active=disabled

 Point-to-Point      : Config=auto, Active=true

 Transmit limit      : 10 packets/hello-time

 TC-Restriction      : Disabled

 Role-Restriction    : Disabled

 Protection type     : Config=none, Active=none

 MST BPDU format     : Config=auto, Active=legacy

 Port Config-

 Digest-Snooping     : Disabled

 Rapid transition    : True

 Num of VLANs mapped : 3

 Port times          : Hello 2s MaxAge 20s FwdDelay 15s MsgAge 0s RemHops 20

 BPDU sent           : 5

          TCN: 0, Config: 0, RST: 0, MST: 5

 BPDU received       : 469346

          TCN: 0, Config: 0, RST: 459633, MST: 9713

parnassus
Honored Contributor

Re: VLANs on trunks explanantion

Probably you have some STP inconsistency running on (the interface 1/0/51 is disputed)...check with display stp abnormal-port CLI command, just to start with.

I don't believe you had a cable problem (let me say: unidirectional traffic) since you initially wrote "The core no longer sees the IP of the edge switch on VLAN1" so you meant that - before - the core saw the IP of the edge switch on VLAN1...but it did with or without the uplink you're now testing and that it is failing?

If the core saw the IP of the edge switch on VLAN1 without the actual failing uplink it means between your Core and your Edge there is an uplink YET and so you're probably (on/for VLAN1) creating a nasty loop which is bad.


I'm not an HPE Employee
Kudos and Accepted Solution banner