Ya got me on that one....Cisco didn't really say why and I didn't think to
ask them either....
--Danny
Danny,
The interface status should be independent of
the swithcing path. I've never seen the line
state be affected by the switching mechanism
(although I have seen the opposite).
Can you email me the case# you had so I can take
a look?
rodney
Now that I think about it, I was given somewhat of an explanation of what
was happening.....I didn't remember until now though.
Basically the MSFCs act as the route processors for the 6509s. A simple
description of what these do is inter-VLAN routing. If you look at show
trunk off of the Supervisor engine on a 6509, you see that there is an ISL
trunk from the supervisor to the MSFC. In an ethernet-only environment,
this is no big deal and is fairly straight-forward. In the case of the
FlexWAN modules, the switch creates a "hidden" VLAN- that is a VLAN numbered
outside the allowed range for VLAN ids. If for some reason this VLAN cannot
be created and associated with the serial (or other interface off of the
FlexWAN), the circuit shows as being up/down when it should be up/up because
the communication between the FlexWAN module and MSFC isn't happening
correctly.
With IOS 12.1.3aE4 (also earlier versions, but I'm not sure how much
earlier) on the MSFC, cef is enabled and cannot be turned off. Again, this
does not present a problem for an ethernet network. With the FlexWAN,
distributed cef must be enabled for the hidden VLAN to be created correctly.
There are debugging commands to see what is going on with the hidden VLANs,
but you cannot get information about these through non-debugging commands.
Once the hidden VLAN is created correctly, the interface can go up/up since
communication between the FlexWAN and MSFC is then allowed to happen.
I didn't ask for details as to what specifically happens with distributed
cef turned vs. having it turned off, and I was really suprised that not
having *one* global configuration command was causing all of my problems....
That's everything I can recall about this....hope that helps.
--Danny
Danny,
You are correct.
In later code you cannot disable dCEF either.
hth,
rodney
Danny,
The interface status should be independent of
the swithcing path. I've never seen the line
state be affected by the switching mechanism
(although I have seen the opposite).Can you email me the case# you had so I can take
a look?
I have, because the line state can be controlled by the keepalive.
If the keepalive don't get through because of the switching path .....
>
> Danny,
>
> The interface status should be independent of
> the swithcing path. I've never seen the line
> state be affected by the switching mechanism
> (although I have seen the opposite).
>
> Can you email me the case# you had so I can take
> a look?I have, because the line state can be controlled by the keepalive.
If the keepalive don't get through because of the switching path .....
Typically we refer to fast, optimum, autonomous, cef as switching
paths through the box. Keepalives are generated at process level
(yeah..I can see the argument that process level switching is
a valid switching path but definitely not the fastest).
This problem was not a *direct* result of the switching path preventing
the keeaplive from being switched to the wire. As Danny stated,
it was an issue with the flexwan not being able to communicate with
the MSFC.