From: Andrew B. Caslow (abcaslow@netmasterclass.net)
Date: Sat May 21 2005 - 09:34:35 GMT-3
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.18Here 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:11:59 GMT-3