I wonder what can cause that the first line output of the command "show interfaces" will be: "fastEthernet is up, line protocol is down".
Cisco ethernet interfaces are normally down / down if they don't have a link. If you're seeing up / down, the most likely causes are:
- Cable fault
- Speed mismatch (I personally haven't seen a duplex mismatch bring an intf up / down)
- is cable that connected to the local interface, but not connected to the far end switch, will cause that situation?
If the cable is bad...
- is good cable that connected to both switches, but one switch had it's interface in "administratively down" state, will cause that situation?
I haven't seen that recently. For example, I have a c3560c in my lab and shutdown fa0/12... then I connected a good cable between the fa0/11 and fa0/12 ports...
sw1#sh ip int brief | i 0/1[1-9]
FastEthernet0/11 unassigned YES unset down down
FastEthernet0/12 unassigned YES unset administratively down down
sw1#
That said, I do have vague memories of seeing up / down when the remote interface was shut on other platforms in the past, but I don't remember seeing it recently
If the cable is faulty, it could cause up / down status
Testing your cabling:
If you have a Cisco switch, you can test your cabling on the up / down interface like this... the following is good tdr output for the command when nothing is connected to the other end of the cable.
sw1#test cable-diagnostic tdr interface Fa0/6
TDR test started on interface Fa0/6
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
sw1#
sw1#show cable-diagnostics tdr interface fa0/6
TDR test last run on: February 12 04:45:37
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Fa0/6 auto Pair A 31 +/- 1 meters N/A Open
Pair B 31 +/- 1 meters N/A Open
Pair C N/A N/A Not Supported
Pair D N/A N/A Not Supported
sw1#
Note: FastEthernet interfaces by-definition can only test two of the four pairs. GigabitEthernet interfaces can test all four pairs.
Older switches don't have a tdr function... you'd have to test the cabling manually.
The basic process is as follows:
Configure your VLANs
set vlans v100-INTERNAL1 vlan-id 100
set vlans v101-INTERNAL2 vlan-id 101
set vlans v102-EXTERNAL vlan-id 102
Attach VLANs to switch ports
set interfaces fe-0/0/0 unit 0 family ethernet-switching vlan-members v100-INTERNAL1
set interfaces fe-0/0/1 unit 0 family ethernet-switching vlan-members v101-INTERNAL2
set interfaces fe-0/0/2 unit 0 family ethernet-switching vlan-members v102-EXTERNAL
Configure IP Interfaces
set interfaces vlan unit 100 family inet address 192.168.100.1/24
set interfaces vlan unit 101 family inet address 192.168.101.1/24
set interfaces vlan unit 102 family inet address 192.168.102.1/24
Attach IP interfaces to VLANs
set vlans v100-INTERNAL1 l3-interface vlan.100
set vlans v101-INTERNAL2 l3-interface vlan.101
set vlans v102-EXTERNAL l3-interface vlan.102
Configure a default route
set routing-options static route 0.0.0.0/0 next-hop 192.168.102.254
Create Security Zones
set security zones security-zone INTERNAL host-inbound-traffic system-services all
set security zones security-zone EXTERNAL host-inbound-traffic ping
Attach IP Interfaces to Security Zones
set security zones security-zone EXTERNAL interfaces vlan.102
set security zones security-zone INTERNAL interfaces vlan.100
set security zones security-zone INTERNAL interfaces vlan.101
Create security policies
set security policies from-zone INTERNAL to-zone EXTERNAL policy PERMIT-OUTBOUND match source-address any destination-address any application any
set security policies from-zone INTERNAL to-zone EXTERNAL policy PERMIT-OUTBOUND then permit
set security policies from-zone INTERNAL to-zone INTERNAL policy PERMIT-INTERNAL match source-address any destination-address any application any
set security policies from-zone INTERNAL to-zone INTERNAL policy PERMIT-INTERNAL then permit
Hopefully the topology is fairly self-explanatory - just substitute the IP Addresses you wish to use.
If you are connecting to the Internet on the EXTERNAL network, I would recommend tightening up the security policies to only allow specific subnets out, and specific applications
Best Answer
Unknown VLANs are the primary cause of Input Discards (
ifInDiscards) in my environment; usually from inappropriate VLANs spanning a trunk port. Depending on the services active in the VLAN in question, those counters can increase exponentially over short periods of time.Keep in mind that Input Discards are the result of valid frames being dropped due to an internal forwarding issue. Another thing to note: Input Discards encompass a drastically smaller amount of issues, most everything else results in an interface error.