Re: encapsulation failed? forus FALSE? sendself FALSE? Huh?

Acadamy Lab 3. Good stuff.

Give me a few minutes and I'll post relevant output.

-Hammer

On Wed, Jul 8, 2009 at 1:06 PM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:

> What lab is this? Spanning-tree topology shouldn't matter since only
> redundant paths are blocked. If there was a misconfiguration with MST,
> perhaps it could be an issue. Can you post relevant parts of the configs
> (SVIs, trunk ports, MST config), "sho interface trunk".
>
>
> On Wed, Jul 8, 2009 at 11:42 AM, Hammer <bhmccie_at_gmail.com> wrote:
>
>> I'm using a proctorlabs rack. S1 is a 3550. Everything is using SVIs.
>>
>> 3550 - 12.2.(44)
>> and
>> 3560s - 12.2.(25r)SEC
>>
>> The tasks of the lab require one instance of spanning tree (MST 0) so all
>> my
>> vlans are going from S2 to S1. If I tamper with the cost of the interface,
>> I
>> can bring up the S2 to S4 leg but I kill the S2 to S1 leg. So I can make
>> it
>> work but only by sacrificing another path.
>>
>> -Hammer
>>
>>
>> On Wed, Jul 8, 2009 at 12:34 PM, Ryan West <rwest_at_zyedge.com> wrote:
>>
>> > Hi,
>> >
>> > Do you have a 3550 in the mix with a physical interface that has an IP
>> > address assigned to it or is everything using SVIs? If that is the
>> case,
>> > just move the address to an SVI. Verify your VLAN allow list and check
>> your
>> > trunk links to make sure the VLAN you're trying to reach is showing up
>> in
>> > the list.
>> >
>> > The first issue that I mentioned is detailed in this post:
>> >
>> >
>> >
>> http://forum.internetworkexpert.com/ubbthreads.php/ubb/showflat/Number/14757/page/1#Post14757
>> >
>> > -ryan
>> >
>> > -----Original Message-----
>> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> > Hammer
>> > Sent: Wednesday, July 08, 2009 1:15 PM
>> > To: ccielab_at_groupstudy.com
>> > Subject: encapsulation failed? forus FALSE? sendself FALSE? Huh?
>> >
>> > I am trying to bring up ip over a VLAN between two switches. It's a
>> typical
>> > vendor lab with 4 switches and way too many connections.
>> >
>> > 1X = 1 wire trunking all vlans
>> > 2X = 2 wires trunking all vlans
>> > EC = EtherChannel trunking all vlans
>> >
>> > S1---------1x-----------S2
>> > | \ / |
>> > | \ / |
>> > | \ / |
>> > | \ / |
>> > 2x EC EC 2x
>> > | \ / |
>> > | \ / |
>> > | \ / |
>> > | \ / |
>> > | \ / |
>> > | X |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > | / \ |
>> > S3-------1X-----------S4
>> >
>> > So I need OSPF in this little party but IP first. I can ping east/west
>> > (from
>> > 1-2 and from 3-4) and I can ping north/south (from 1-3) but I cannot
>> ping
>> > from 2-4. The vlan they need is active. The vlan interface is up/up on
>> each
>> > of the switches. But I can't reach the other side of the VLAN. So first
>> I
>> > see that spanning tree is preferring my EC links. No problem. Jack up
>> the
>> > cost to oblivion and move on. Nope. Still no love. On a debug ip packet,
>> I
>> > come up with the below:
>> >
>> > BLAH BLAH BLAH, routed via FIB
>> > BLAH BLAH BLAH sending
>> > BLAH BLAH BLAH output feature, Check hwidb(63), rtype 1, forus FALSE,
>> > sendself FALSE, mtu 0
>> > BLAH BLAH BLAH encapsulation failed
>> >
>> > I only found two links on google and none for cco for the forus FALSE
>> > sendself FALSE. Both links were questions with no answers. Has anyone
>> seen
>> > this before? Is this part of my encapsulation failure? Or am I barking
>> up
>> > the wrong tree? My logic was that if I was dealing with a spanning tree
>> > issue the traffic would still exit the switch....
>> >
>> > Help?
>> >
>> >
>> >
>> > -Hammer
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com

Blogs and organic groups at http://www.ccie.net
Received on Wed Jul 08 2009 - 13:09:15 ART