RE: PortFast Question
From: David Gillett (gillettdavid_at_fhda.edu)
Date: 09/28/04
- Previous message: Strcpy: "Re: Where does ICF store it`s ACL ?"
- In reply to: LordInfidel_at_directionweb.com: "RE: PortFast Question"
- Next in thread: John R. Morris: "Re: PortFast Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: <LordInfidel@directionweb.com>, "'Josh Sukol'" <secnews@gmail.com>, <security-basics@securityfocus.com> Date: Tue, 28 Sep 2004 08:35:59 -0700
That is neither how autonegotiate works, nor is it what
PortFast does.
Autonegotiate can be broken into two subsections: speed
and duplex. 100Mbps includes a kind of "carrier" signal that
is absent from 10Mbps, so a device set to autonegotiate speed
will, when the link comes up, transmit that carrier for a few
seconds and see if it receives it from the other end. If each
sees the carrier, they'll stay at 100; if either does not, it
will drop back to 10 (which means it stops sending the carrier,
and so the other end drops back as well).
Autonegotiate of duplex is much more difficult; each side
needs to transmit and determine if a collision occurs (and, if
so, alter its transmission to appear to be a collision so the
other end can see it). Full duplex is available if there is no
detected collision, and so collision detection can be turned off.
Unfortunately, different vendors read the specifications slightly
differently, and so autonegotiation may not correctly settle on
full duplex even in cases where it would work. And some vendors
do not fully turn off autonegotiation when configured to a static
setting, so *occasionally* one finds systems which can autonegotiate
a working full-duplex connection, but which throttle down to a
trickle when statically configured. While one would generally
prefer static configuration, it's not guaranteed to be the best
choice in every instance.
Bridges/switches maintain a topology by exchanging and distributing
BPDU frames. Once the exchange of these packets has led to election
of some device as the root bridge, the Spanning Tree algorithm (and
additional BPDUs as necessary) is used to identify switch-to-switch
links and to shut down redundant links to avoid loops in the topology.
This state is then maintained by periodic BPDUs from the root. When
a switch acquires a new link to another switch, or fails to receive
a scheduled BPDU from the root, the process is repeated to rebuild the
topology.
This process can easily take 30 seconds or more, during which no
traffic can safely be delivered -- which can be a really long time in
the case of some network applications. So Cisco offers several options
to speed up reconvergence.
PortFast is one of these options. It's a way for an admin to tell
the switch that specified ports are used by individual hosts and so
there's no need to listen for BPDUs arriving on those ports; they can
transition back to normal data operations almost immediately when a
topology reconvergence occurs. There are similar options (with
slightly different implications) for inter-switch link ports, depending
on whether they are or are not expected to become this switch's link
towards the root device.
My hunch is that in the case under discussion, the third-party device
is putting out something that looks a bit like a BPDU. With portfast
BPDUguard, this bogus noise gets dropped. Without it, the port transitions
to a spanning-tree state where it's ignoring everything except real BPDUs --
and there aren't any.
David Gillett
> -----Original Message-----
> From: LordInfidel@directionweb.com
> [mailto:LordInfidel@directionweb.com]
> Sent: Monday, September 27, 2004 7:16 AM
> To: 'Josh Sukol'; security-basics@securityfocus.com
> Subject: RE: PortFast Question
>
>
> If I had to guess..... the proprietary hardware box is
> having a hard time
> using auto-negotiation.
>
> Here's what happens when you connect a device to a
> switch/hub, and both
> sides are set to auto-negotiate.
>
> The connecting device will try to connect at it's maximum
> speed and duplex.
> If the other side(in this case the switch) can understand the
> connecting
> device and hence agree at the speed and duplex, the
> connection is made. If
> it can not understand the connecting device, it says Hey I
> can't understand
> that connection request, try another...
>
> And they both go back and forth until a connection is made.
> Now there are
> times when a connection, "appears" to be made but you can not
> ping or it
> seems like the connection is really slow. That is because there are
> transmission errors due to the way each connection is
> expecting to receive
> the data.
>
> Now with portfast, you are removing auto-negotiation from the
> switch and you
> are telling the switch port "Do not attempt to
> auto-negotiate, assume the
> port is 100/Full and bring the port up as such".
>
> As far as protecting that port, you can lock that port down to the MAC
> address of the connecting device.
>
> Typically, for any static network device that you are using, (servers,
> routers, firewalls, etc), the network adapter on the device should be
> manually set for speed/duplex. Never leave it set to auto.
>
>
> -----Original Message-----
> From: Josh Sukol [mailto:secnews@gmail.com]
> Sent: Friday, September 24, 2004 10:05 AM
> To: security-basics@securityfocus.com
> Subject: PortFast Question
>
>
> I am running a small network using four Cisco Catalyst 2950 switches.
> I am in the process of configuring a new software package that uses
> some proprietary hardware that connects to the network via Ethernet.
> When plugged into the network the device would connect for a minute or
> two and than connectivity would drop (i.e. ping would fail, and the
> light on the switch would turn from green to amber) This pattern
> continued for as long as the device was plugged into the network. The
> cabling was checked and tested with other equipment and there were no
> other problems.
>
> After trying several other things I eventually started changing the
> ethernet port settings on the switch itself and found that by enabling
> portfast the device functioned fine. I have found very little
> information about port fast security issues. I was able to find and
> did read up on PortFast BPDU guard and potential DoS using malformed
> packets. Are there any other security issues that effect me enabling
> Portfast on specific ports that connect back to a single device? Are
> there any other ways to solve this problem that might allow me to
> sidestep this potential security issues all together?
>
> - Slightly Off Topic -
> If anyone knows why this behavior occurs and why enabling portfast
> fixes the connectivity issue I would be very interested to a hear an
> explanation.
>
>
> Thanks in advance for the wisdom!
>
> --------------------------------------------------------------
> -------------
> Computer Forensics Training at the InfoSec Institute. All of
> our class sizes
> are guaranteed to be 12 students or less to facilitate one-on-one
> interaction with one of our expert instructors. Gain the
> in-demand skills of
> a certified computer examiner, learn to recover trace data
> left behind by
> fraud, theft, and cybercrime perpetrators. Discover the
> source of computer
> crime and abuse so that it never happens again.
>
> http://www.infosecinstitute.com/courses/computer_forensics_tra
ining.html
----------------------------------------------------------------------------
- Previous message: Strcpy: "Re: Where does ICF store it`s ACL ?"
- In reply to: LordInfidel_at_directionweb.com: "RE: PortFast Question"
- Next in thread: John R. Morris: "Re: PortFast Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
