Posted by Tres
Tue, 12 Sep 2006 04:12:02 GMT
Setting up time is a two step process. First you’ll need to set up a couple of NTP servers that you have access to, then you’ll need to set up your timezone.
To set up the NTP servers using hostnames, you’ll of course need to set up nameservers on the switch or router. That’s another story. If you haven’t already set up name resolution on IOS, no worries; IOS stores the NTP servers as IP addresses anyway, so you can just look up the addresses for the time servers you’re authorized to access, then configure IOS like this:
ntp server 131.107.1.10
ntp server 202.152.74.200 prefer
Not surprisingly, the prefer sets your preferred time server.
To set up the timezone, you’ll need to figure out your offset from UTC. Unlike Unix, the string representation of timezone is meaningless to IOS. The numerical offset is the only thing that IOS is concerned about. The string is to be friendly to you and anyone else that needs to use the switch or router.
clock timezone PST -8
clock summer-time PDT recurring
Posted in Cisco | Tags cisco, clock, ntp, server, time, timezone | no comments
Posted by Tres
Mon, 11 Sep 2006 05:04:25 GMT
A while back I had an article on setting up port security on a 12.1 IOS switch.
12.0 switches are a little bit diferent.
switchport mode access
switchport access vlan XXX
port security
port security aging time 2
switchport priority override
Finally, in order to lock things down to a single mac address, you’ve got to exit from the switchport configuration, back into general configuration mode, and then give the mac address and port that you want to lock down.
exit
mac-address-table secure DEAD.BEEF.DEAF FastEthernet 0/X vlan XXX
Posted in Cisco | Tags 0, 12, cisco, ios | no comments
Posted by Tres
Mon, 03 Jul 2006 18:55:00 GMT
I’ve found that sometimes, especially with newer NICs on older switches, the host’s DHCP client times out before the port initialization completes. The switch flashes an orange light while the DHCP client keeps trying to send advertisements. This isn’t so bad when you’re just trying to get a DHCP address, most modern operating systems will eventually keep trying until they get one. This really gets frustrating when you’re trying to use BOOTP for PXE booting. You can’t do the install because the system never gets an IP address.
To me this seemed like some kind of port speed or duplex negotiation problem. But even when I turned off auto-negotiation and set all port speed and duplex parameters manually, it still didn’t fix the problem. That’s because the problem isn’t port negotiation, it’s STP (Spanning Tree Protocol).
STP is what Cisco uses to allow for redundant pathways between switches. STP will put a switchport into one of two normal operating states: forwarding or blocking. Because any switchport could potentially cause a loop if the port were suddenly switched from the blocking state to forwarding state, STP uses two other intermediate states to ensure that a loop will not occur: listening and learning.
In the listening state, the port ensures that there doesn’t already exist a better pathway. In learning state, the switch learns MAC addresses for connected devices without allowing a loop to occur. Once the switchport has passed through these two modes, then it will finally be in the forwarding state, where it will forward DHCP broadcasts.
So, to make a long story short, in order to get switchports up and running quickly, use:
spanning-tree portfast
when configuring ports.
For the most part, this is safe to use, but if it gets set up on an uplink port to another layer 2 device, it can cause loops – things will stop working in a hurry. So like IOS says, “Use with CAUTION.”
Posted in Cisco | Tags BOOTP, DHCP, PXE, timeout | no comments
Posted by Tres
Mon, 03 Jul 2006 08:54:00 GMT
In a school or business setting it is a good idea to secure switchports so that only certain MAC addresses will work.
This is, of course not foolproof, but it does make it so that a policy of “company only” computers is easier to enforce on the network. If a nefarious employee or student decides to, they can still gain access to the network. But with physical access to machines, if there’s a will there’s always a way.
interface FastEthernet0/5
switchport mode access
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
switchport port-security aging type inactivity
switchport port-security mac-address 000d.565d.000c
mls qos cos override
macro description cisco-desktop
spanning-tree portfast
spanning-tree bpduguard enable
Posted in Cisco | Tags network, ports, Secure | no comments
Posted by Tres
Mon, 03 Jul 2006 07:45:00 GMT
Normally on Cisco switches, MAC addresses are learned once per a port; however, if the same MAC address is seen on two different ports, it will cause an ADDR_FLAP error to be printed to the log. This normally happens one of two ways. If there is a port anywhere in the switched intranet that’s looped back to itself, addresses will jump between the real port and the port that’s in the path to the looped port. Or, if there is a problem with a redundant PF CARP firewall which causes both routers to be in MASTER mode for a given CARP port.
When this happens, the error reads:
ADDR_FLAP, RTD, LOG_ALERT, 0, "%s relearning %d addrs per min
Which is nice to know, but while Cisco Switches may tell you that there’s someone causing problems, it won’t tell you who it is unless you turn on debugging output.
In order to get the MAC address of the host causing the problems, do a:
debug ethernet-controller addr
And when you’re finished, you’ll need a:
no debug ethernet-controller addr
to turn debugging off.
Posted in Cisco | Tags ADDR_FLAP, CARP, looped | no comments