| Computers Forum Index » Computer - DCOM - Cisco » Testing UDLD on copper interfaces... |
|
Page 1 of 1 |
|
| Author |
Message |
| ango... |
 Posted: Tue Oct 27, 2009 2:40 pm |
|
|
|
Guest
|
Hi all,
I have to verify the correct working of UDLD protocol on copper
interfaces.
In my lab two 6509 Catalysts are connected betweeen them with
4x10/100/1000 links, taken form a WS-X6148A-GE-TX port adapter. An
Etherchannel is used to combine these links into one logical channel.
Autonegotiation is already enabled on the involved interfaces and
Rapid Spanning Tree is configured.
I'm planning to enable aggressive UDLD on all these interfaces with
the "udld port aggressive" command; I'm looking a way to test if it
works. I think the most critical point would be how to simulate an
unidirectional link.
Any idea how to implement it? I''ve read on a forum about one possible
strategy: to put a non-Cisco L2 device between the two Catalysts and
unplug one side after the UDLD peers have been created.
Has anyone tested it successfully? Any other suggestion about
alternative ways to have an unidirectional link on copper interfaces?
Thanks
Alessandro |
|
|
| Back to top |
|
|
|
| Stephen... |
| Posted: Wed Oct 28, 2009 3:20 am |
|
|
|
Guest
|
On Tue, 27 Oct 2009 07:40:21 -0700 (PDT), ango
<ale.andreotti at (no spam) gmail.com> wrote:
Quote: Hi all,
I have to verify the correct working of UDLD protocol on copper
interfaces.
In my lab two 6509 Catalysts are connected betweeen them with
4x10/100/1000 links, taken form a WS-X6148A-GE-TX port adapter. An
Etherchannel is used to combine these links into one logical channel.
Autonegotiation is already enabled on the involved interfaces and
Rapid Spanning Tree is configured.
please note these blades are contended and not designed for trunk
pipes.
a set of 6 or 8 ports shares 1 chip, and a single GigE internal
connection.
if you must build an Etherchannel, make sure you combine ports from
different "sets" or you are going to be limited to 1 Gbps anyway.
Quote:
I'm planning to enable aggressive UDLD on all these interfaces with
the "udld port aggressive" command; I'm looking a way to test if it
works. I think the most critical point would be how to simulate an
unidirectional link.
Any idea how to implement it? I''ve read on a forum about one possible
strategy: to put a non-Cisco L2 device between the two Catalysts and
unplug one side after the UDLD peers have been created.
Has anyone tested it successfully? Any other suggestion about
alternative ways to have an unidirectional link on copper interfaces?
Thanks
Alessandro
--
Regards
stephen_hope at (no spam) xyzworld.com - replace xyz with ntl |
|
|
| Back to top |
|
|
|
| Tosh... |
| Posted: Wed Oct 28, 2009 4:44 am |
|
|
|
Guest
|
Quote: Any idea how to implement it? I''ve read on a forum about one possible
strategy: to put a non-Cisco L2 device between the two Catalysts and
unplug one side after the UDLD peers have been created.
Maybe I miss something but it doesn't seem to me an effective way to test
udld, as far as I know the most flexible way is to build a link with a
couple of fiber media converters and plug/unplug each simplex fiber
connector in order to close/open the link in any direction you like.
Bye,
Tosh. |
|
|
| Back to top |
|
|
|
| bod43... |
| Posted: Wed Oct 28, 2009 10:31 am |
|
|
|
Guest
|
On 28 Oct, 00:44, "Tosh" <cheba... at (no spam) gmail.com> wrote:
Quote: Any idea how to implement it? I''ve read on a forum about one possible
strategy: to put a non-Cisco L2 device between the two Catalysts and
unplug one side after the UDLD peers have been created.
Maybe I miss something but it doesn't seem to me an effective way to test
udld, as far as I know the most flexible way is to build a link with a
couple of fiber media converters and plug/unplug each simplex fiber
connector in order to close/open the link in any direction you like.
Bye,
Tosh.
Maybe you can block the UDLD packets with a mac access-list?
UDLD uses the same destination mac as CDP.
If that does not work maybe a non-cisco intermediate switch
that supported mac ACLs might work.
Remember too that GBE already protects against
unidirectional links. I am not sure of the details but my
understanding is that there is a physical layer
protocol within GBE that ensures that neither
port will up come unless both come up. Maybe
worth reading the GBE standard which may be free
from the IEEE. |
|
|
| Back to top |
|
|
|
| Stephen... |
| Posted: Fri Oct 30, 2009 12:21 am |
|
|
|
Guest
|
On Wed, 28 Oct 2009 03:31:18 -0700 (PDT), bod43 <Bod43 at (no spam) hotmail.co.uk>
wrote:
Quote: On 28 Oct, 00:44, "Tosh" <cheba... at (no spam) gmail.com> wrote:
Any idea how to implement it? I''ve read on a forum about one possible
strategy: to put a non-Cisco L2 device between the two Catalysts and
unplug one side after the UDLD peers have been created.
Maybe I miss something but it doesn't seem to me an effective way to test
udld, as far as I know the most flexible way is to build a link with a
couple of fiber media converters and plug/unplug each simplex fiber
connector in order to close/open the link in any direction you like.
Bye,
Tosh.
Maybe you can block the UDLD packets with a mac access-list?
UDLD uses the same destination mac as CDP.
If that does not work maybe a non-cisco intermediate switch
that supported mac ACLs might work.
Remember too that GBE already protects against
unidirectional links. I am not sure of the details but my
understanding is that there is a physical layer
protocol within GBE that ensures that neither
port will up come unless both come up. Maybe
worth reading the GBE standard which may be free
from the IEEE.
GigE includes negotiation which should sort out a local 1 way link
issue. If you have just fibre between the 2 ciscos then that should be
it.
It doesnt tend to work if there are intermediate devices mucking
around with the bit stream since the negoiation is interface to
adjacent interface.
I stumbled over this with a GigE over SDH module in a Marconi /
Ericsson mux.
FWIW 802.1q link aggregation should also detect "break" style faults
since the protocol involves exchanging hello packets on each link.
You may want to see what you get with a marginal fault where some
proportion of the traffic gets trashed - these kinds of issue seem
harder to find and troubleshoot, esp where you use load balancing
across Ethernet links.
--
Regards
stephen_hope at (no spam) xyzworld.com - replace xyz with ntl |
|
|
| Back to top |
|
|
|
|
