RE: Bridging on isl trunks

From: ccie2be (ccie2be@nyc.rr.com)
Date: Sat May 21 2005 - 12:03:04 GMT-3


Hi Simon,

Try debug spanning-tree bpdu

see
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225se/3550cr/deb
ug.htm#wp1011690

For other 3550 debug commands, see

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225se/3550cr/deb
ug.htm

Unfortunately, the info provided for these debug commands is nearly useless
- Cisco doesn't tell you any details about what's actually being captured by
these debugs or how to interpret the debug output.

So, these debugs may not actually be so helpful but there's only one way to
find out.

HTH, Tim

-----Original Message-----
From: simon hart [mailto:simon.hart@btinternet.com]
Sent: Saturday, May 21, 2005 10:07 AM
To: ccie2be; 'Andrew B. Caslow'; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Hi all,

Looks like I may have started a lively debate on this topic. I am
interested as to why this is not working as I would expect.

Bruce, in answer to you point on the R6 Fa1/0 and 0.1 and 0.4 interfaces,
none of them have ip address assigned. 0.1 and 0.4 are participating in
bridge-group 1, R6 is configured with Bridge irb. So to my mind they are
not layer 3 forwarding. Also nonegotiate is configured on the switch.

In fact I can get this exact same scenario to work if I change the trunking
type from isl to dot1q. So I feel that there is a perhaps an issue here
with ISL (or my config??).

Tim,

Is R6 sending and recieving BPDU's? Well it would appear so. I have pasted
below the output of the show spanning 1 on R6, you will see at the end that
BPDU's are being sent and recieved, what does seem strange is that each port
has sent twice as many BPDU's than that received. As the Hello time on R6
and the Switch are both set to 2 sec's, I would have expected equilibirium.

Rack1R6#sh spanning 1

 Bridge group 1 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 0, address 0005.9bc5.fad0
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag not set, detected flag not set
  Number of topology changes 5 last change occurred 02:48:21 ago
          from FastEthernet1/0.1
  Times: hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0, aging 300

 Port 16 (FastEthernet1/0.1) of Bridge group 1 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.16.
   Designated root has priority 0, address 0005.9bc5.fad0
   Designated bridge has priority 0, address 0005.9bc5.fad0
   Designated port id is 128.16, designated path cost 0 Hello is pending
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 10141, received 5071

 Port 17 (FastEthernet1/0.4) of Bridge group 1 is forwarding
   Port path cost 19, Port priority 128, Port Identifier 128.17.
   Designated root has priority 0, address 0005.9bc5.fad0
   Designated bridge has priority 0, address 0005.9bc5.fad0
   Designated port id is 128.17, designated path cost 0 Hello is pending
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   BPDU: sent 10145, received 5071

Without running a SPAN session and a protocol analyser is there a debug
command on either the router or the switch I can use, in order to get a
better picture of what maybe going on.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
ccie2be
Sent: 21 May 2005 14:04
To: 'Andrew B. Caslow'; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Thanks Bruce.

I appreciate hearing back from you.

But how is it that the sub-int's are L3 devices on R6? They don't have a L3
address configured on them and both sub-int's are part of bridge-group 1.
From the router's point of view, why aren't the sub-int's just L2 entities?

bridge irb
bridge 1 protocol ieee

int fa1/0.1
encaps isl 1
bridge 1

int fa1/0.4
encaps isl 4
bridge 1

Also, doesn't R6 generate BPDU's for bridge 1? If so, over what interfaces
are they sent? Shouldn't R6 be sending and receiving BPDU's over both
sub-int's for bridge 1? If not, is that because R6 thinks it doesn't have
any L2 interfaces over which to send out the BPDU's for bridge 1?

And, isn't the switch sending BPDU's for vlan 1 and vlan 4 over the trunk
connection to R6? IF so, what does R6 do with these BPDU's?

Sorry for all the questions but it just seems to me that the trunking issue
is or should be independent of the STP and BPDU issues as long as the trunk
is working. I accept the fact that nonegotiate has to be configured on the
switch for trunking to work properly but once the trunk is working properly,
I'd like to understand what role STP plays when bridging two different
vlan's together.

Thanks again. I really appreciate your trying to explain this to me.

Tim

-----Original Message-----
From: Andrew B. Caslow [mailto:abcaslow@netmasterclass.net]
Sent: Saturday, May 21, 2005 8:35 AM
To: 'ccie2be'; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Good questions.

In Simon's particular configuration, he is attempting to trunk what appears
to be two VLAN's for Layer 3 forwarding on router R6 while using ISL as the
trunk protocol between the router and the switch. If this is the case, the
routers FastEthernet subinterfaces are not participating in spanning tree.
They are configured as Layer 3 devices.

HTH,

-Bruce

-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Saturday, May 21, 2005 8:24 AM
To: 'Andrew B. Caslow'; 'simon hart'; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Hi Bruce,

By any chance, do you know why the method of trunk creation (negotiated on
hard-coded) would have any bearing on Simon's problem?

Also, could you comment on STP and bpdu aspect of this problem? In
particular, I'm wondering about how root bridge elections and STP traffic
are handled when the router is bridging traffic from vlan 1 and vlan 4.

I just read the found at the link you posted but that info doesn't shed any
light on this STP and BPDU issue.

TIA, Tim

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Andrew B. Caslow
Sent: Saturday, May 21, 2005 7:47 AM
To: 'simon hart'; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Simon,

As Bob mentioned, experiment with disabling setting the trunk mode to
"nonegotiate". Here is a snippet from the NetMasterClass technical library
on this very subject. You can find out more on this subject and related
issues in the NMC technical library by performing a full-text search on DTP
or its predecessor DISL.

HTH,

-Bruce

>From the NMC Technical Library:

Issue Spotting Advice: Tech Note "Configuring ISL Trunks on Cisco Routers",
the recommended practice is stated as follows: "Cisco routers cannot
negotiate DTP or DISL. Therefore, you must configure the trunk mode to be
"nonegotiate" on the switch side". Reference:
http://www.cisco.com/warp/customer/473/24.shtml

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Saturday, May 21, 2005 6:30 AM
To: simon hart; ccielab@groupstudy.com
Subject: RE: Bridging on isl trunks

Further to the scenario below, it appears that I can get this scenario to
work if I change the trunking encapsulation to Dot1q. However it will not
function as ISL. Any pointers much appreciated

Simon

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of simon
hart
Sent: 21 May 2005 08:39
To: ccielab@groupstudy.com
Subject: Bridging on isl trunks

Hi all,

I am having a problem bridging across two isl trunks on a router. My set up
is like this

13.13.23.1 13.13.23.5
Rtr 1 Rtr 5
  | |
vlan 4 vlan 1
  \ /
   \ /
    \ /
     \ /
         Switch 1
             |
             |
          isl trunk
fa0/0.1 fa0/0.4
vl1 vl4
        Rtr6

I am attempting to have Rtr 1 speak to Rtr 5 by bridging on Rtr6. At first
sight I would see this as pretty straightforward, however I a cannot seem to
get it working.

My config on Rtr 6 looks like this

bridge irb
bridge 1 protocol ieee

int fa1/0.1
encaps isl 1
bridge 1

int fa1/0.4
encaps isl 4
bridge 1

My mac table for Bridge 1 on Rtr 6 looks like this

Rack1R6#sh bridge 1

Total of 300 station blocks, 297 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address Action Interface Age RX count TX count
0000.0c0a.2804 forward Fa1/0.4 1 1 0
Rtr 1
0003.6b37.c981 forward Fa1/0.1 0 4 0
Rtr 5
000e.381f.d106 forward Fa1/0.1 0 35 0
Int Vlan 1

I can confirm that the mac addresses for each are those that I would expect
from Rtr 1, Rtr 5 and my Interface Vlan 1 on Switch 1.

Now I cannot ping between the two, I get no response. It appears that the
Routers (either 1 or 5) send out an ARP but gets no reply. On each arp the
RX count increases by one on Rtr6, but the Tx Count does not go up. This
leads me to believe that bridge 1 on Rtr 6 is not forwarding the frames
recieved on one vlan to the other

SPANNING TREE

I have noticed that there maybe some inconsisitency with spanning tree. Here
is the output of SPT on Rtr 6 ( I attempted to make R6 the root by using
bridge priority 0)

Bridge group 1
  Spanning tree enabled protocol ieee
  Root ID Priority 0
             Address 0005.9bc5.fad0
             This bridge is the root
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

  Bridge ID Priority 0
             Address 0005.9bc5.fad0
             Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
             Aging Time 300

Interface Designated
Name Port ID Prio Cost Sts Cost Bridge ID Port
ID
-------------------- ------- ---- ----- --- ----- -------------------- -----

--
FastEthernet1/0.1    128.17   128    19 FWD     0     0 0005.9bc5.fad0
128.17
FastEthernet1/0.4    128.18   128    19 FWD     0     0 0005.9bc5.fad0
128.18

Here is the output from Switch 1 for both Vlan 4 and Vlan 1

VLAN0004 Spanning tree enabled protocol ieee Root ID Priority 32772 Address 000e.381f.d100 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32772 (priority 32768 sys-id-ext 4) Address 000e.381f.d100 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300

Interface Port ID Designated Port ID Name Prio.Nbr Cost Sts Cost Bridge ID Prio.Nbr ---------------- -------- --------- --- --------- -------------------- ----- --- Fa0/1 128.1 100 FWD 0 32772 000e.381f.d100 128.1 Fa0/6 128.6 19 FWD 0 32772 000e.381f.d100 128.6

VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000e.381f.d100 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 000e.381f.d100 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15

Interface Port ID Designated Port ID Name Prio.Nbr Cost Sts Cost Bridge ID Prio.Nbr ---------------- -------- --------- --- --------- -------------------- ----- --- Fa0/5 128.5 100 FWD 0 32769 000e.381f.d100 128.5 Fa0/6 128.6 19 FWD 0 32769 000e.381f.d100 128.6

So it seems that both the switch and Rtr 6 think they are the roots for both spanning trees!!

Does anyone have any idea why this should be occurring, or any other useful debug tools that I could use to determine the underlying cause of this problem.

TIA

Simon

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.322 / Virus Database: 266.11.13 - Release Date: 19/05/2005



This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:00 GMT-3