Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

[This is now Fixed]

I have a Cisco Catalyst 2950 running IOS 12.1(22) that sits behind a Watchguard Router / Firewall. I've just turned this on for the first time today, and it is coming off of a fresh / default factory settings.

The Catalyst is able to ping itself (10.1.200.2), but is unable to ping the router or anything on the outside. The router, on the other hand, is able to ping the switch.

The Watchguard is providing the DHCP to the network where this Catalyst sits, and has an IP address of 10.1.200.1. On the Catalyst, I've given the native vlan1 an IP address of 10.1.200.2.

There's two GigEth ports on the 2950, and I've configured the 1st (gig0/1) to act as the trunk port:

!
interface GigabitEthernet0/1
 switchport trunk allowed vlan 1
 switchport mode trunk
 spanning-tree portfast disable
!

Further config options for the switch (including int vlan1 settings):

!
interface Vlan1
 ip address 10.1.200.2 255.255.255.0
 no ip route-cache
!
ip default-gateway 10.1.200.1
ip http server
!

I can't figure out if there's anything additional that I'm missing to get this thing up and running. I also have a Cisco SG-200 (much newer, obviously) that works flawlessly on the same network.

Is there anything I'm missing to get this switch initially talking to the outside?

[EDIT] I should have clarified, too, that I tried setting these switchports to mode access, which didn't work either. Per the recent answer, here's what the running-config looks like after I just reverted the settings again to switchport mode access:

ip subnet-zero
!
vtp mode transparent
!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
!
!
!
!
interface FastEthernet0/1
 switchport mode access
!

{ snip }

interface FastEthernet0/24
 switchport mode access
!
interface GigabitEthernet0/1
 switchport mode access
!
interface GigabitEthernet0/2
 switchport mode access
!
interface Vlan1
 ip address 10.1.200.2 255.255.255.0
 no ip route-cache
!
ip default-gateway 10.1.200.1
ip http server
!
line con 0
line vty 0 4
 login
line vty 5 15
 login
!
!
end
share|improve this question
    
The Trusted int is set to 10.1.10.0/24 (not connected to this switch). This particular int is set to 10.1.200.0/24, but I have firewall policies in place to allow pings coming from 10.1.200.0/24 to communicate within the .200.0/24 network as well as to the outside. Obviously its a completely separate subnet from the "Trusted" int, and this is by design, as the 200.0 network is a student lab. –  David W Sep 5 '13 at 21:13
add comment

1 Answer

up vote 3 down vote accepted
  1. The switch is up and running. It does not need ip address settings nor does it need to be able to ping any other host for it to function as a layer 2 switch, which is what it is. Assigning an ip address to the VLAN1 interface allows you to manage the switch by connecting to that ip address, nothing more. It has no bearing on it's functionality as a layer 2 switch. If you plug a correctly configured host into one of the switch ports you'll find, undoubtedly, that the host has proper network connectivity.

  2. Unless you are connecting this switch to another switch and you plan on having multiple VLAN's configured between both switches, there's no need to configure any ports as trunk ports.

  3. The Watchguard firewall is not a router, it is a firewall.

  4. Reconfigure the trunk ports as access ports and see if that resolves the issue.

  5. Make sure you have the correct subnet mask configured on the switch. You should be using the same subnet mask that you're using in the rest of your network.

share|improve this answer
    
Thanks for clarification re: management IP address for VLAN1. Makes sense. I tried setting everything to switchport mode access (which I failed to mention), although I've reverted trunk port back to access port. I've updated the question w/ more exhaustive output of sh running-config, although the problem is resolved. As of now, the switch itself (when using a console cable) is still unable to ping the outside. I didn't even think to test PCs from the switch, as I assumed since it couldn't ping outside, no one would be able to. Curious why the switch itself isn't able to ping the outside. –  David W Sep 5 '13 at 21:05
    
When you say "outside" do you mean an ip address outside the firewall, as in 8.8.8.8 or something similar? If so, what happens when you run a trace route from the switch to an outside ip address? Is the switch now able to ping the Watchguard? –  joeqwerty Sep 5 '13 at 21:11
    
Currently, the switch is unable to ping the Watchguard at 10.1.200.1 OR at the Trusted int of 10.1.10.1. However, PCs behind the Catalyst on the 10.1.200.0/24 network are getting DHCP and are working just fine. As far as pinging an "outside" address, duh! I was trying to ping host names, which weren't resolving. As soon as I (just tried to) ping 8.8.8.8, it worked like a charm. –  David W Sep 5 '13 at 21:20
    
OK, that makes sense and it just dawned on me that the Watchguard requires a rule to allow pings TO the Watchguard, IIRC. I'm assuming that other internal hosts are also unable to ping the Watchguard, correct? If so, then it sounds like things are working normally. One more thing... in order for the switch to resolve names you'll need to configure DNS settings in the switch. –  joeqwerty Sep 5 '13 at 21:30
    
That makes sense. Thanks again for the help on this! –  David W Sep 5 '13 at 22:30
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.