Re: PortFast Question
From: Maarten Claes (maarten.claes_at_gmail.com)
Date: 09/29/04
- Previous message: Furutani, Curtis Y Mr TAMC: "Remote Control"
- In reply to: JGrimshaw_at_ASAP.com: "RE: PortFast Question"
- Next in thread: Sec News: "Re: PortFast Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Sep 2004 11:56:54 +0200 To: "jgrimshaw@asap.com" <jgrimshaw@asap.com>
This is indeed what portfast does. For example, when trying to boot
off a PXE enabled NIC, the switch port hasnt yet come online due to
the learning phase of STP. Result is that the PXE program's timer
times out. Portfast solves this issue.
Maarten.
On Tue, 28 Sep 2004 09:44:29 -0500, jgrimshaw@asap.com
<jgrimshaw@asap.com> wrote:
> I don't think that's what Port Fast is.
>
> My impression of PortFast was to reduce the time that the Spanning Tree
> Protocol (STP) takes to bring a specific port online. One would utilize
> portfast for ports that have only hosts attached them (that is,
> destinations)--not switches and hubs. PortFast significantly reduces the
> delay of STP by not going through listening and learning steps--it goes
> straight to forwarding. The concept is that there is no reason to
> determine if a port block is required, because the port has been
> statically configured to expect a host to be connected to it. Thus the
> name Port Fast--it has nothing to do with the speed of the port, it has to
> do with the speed of the port coming online--it can reduce the time from
> 45 seconds to 15 seconds or less.
>
> Port speed negotiation would occur before the STP process began. Speed
> negotiation is taking place at layer 1, while the STP (and port fast) kick
> in at layer 2. It will be dynamic unless the hardware is set otherwise,
> and both ends need to be set the same way--dynamic or at a specific speed
> and duplex.
>
> Personally, I prefer to use statically defined speeds and duplexes for
> infrastructure equipment, and let the end user PCs sort it out for
> themselves dynamically. While there may be some issues with an auto
> setting, most users wouldn't notice the difference.
>
> LordInfidel@directionweb.com
> 09/27/2004 09:16 AM
>
> To
> 'Josh Sukol' <secnews@gmail.com>, security-basics@securityfocus.com
> cc
>
> 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_training.html
> ----------------------------------------------------------------------------
>
>
-- Maarten Claes ------------------------------------------- Flying is easy; just throw yourself at the ground and miss
- Previous message: Furutani, Curtis Y Mr TAMC: "Remote Control"
- In reply to: JGrimshaw_at_ASAP.com: "RE: PortFast Question"
- Next in thread: Sec News: "Re: PortFast Question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
