Hi,i've got two switches connected on stack for production and another for a test network,i connected a crossover cable on port g0/9 of testswich to port g0/46 of NS2.
When i do sh arp on testswitch i can see and ping all ips of the other network but i am finding out that i cannot ping from inside host to host on the other network (specially i need to do remote control). i post configs.
The ports you mentioned have no configuration on them, which means they are access ports on VLAN1 on both switches.
You should configure these ports to be trunk ports like below at each end
switchport trunk encapsulation dot1q
switchport mode trunk
This should get it working however looking at your configs you need to draw out your switch topology and decide on how you want to design your spanning tree and core/access layer.
Which switches are your core? If they are ns1 and ns2 then you should move the VLAN30 interface up to those switches, configure HSRP and have your new switch as a layer 2 switch only. ALso set your spanning-tree root bridge.
As soon as i entered that config , i lost access to the switch and i noticed all ports had changed their led color to orange... why?
>> When i do sh arp on testswitch i can see and ping all ips of the other network but i am finding out that i cannot ping from inside host to host on the other network (specially i need to do remote control). i post configs.
hosts in Vlan30 are in a different ip subnet you need to enable an ip routing protocol or to use static routes in all routers to allow a ping echo reply to be sent back to an host in vlan30
for example you can use EIGRP
on all three switches use
router eigrp 100
you can keep the current design with access ports
you can use the suggestions in the other post but you need to verify if vlan 30 as a l2 object is present in ns1 and ns2 vlan database
sh vlan id 30
on ns1 and ns2 to verify this fact
About the problems after configuring the links as trunk :
by configuring the ports as trunks you have joined the VTP databases and this can have had disruptive results
you should define only ns1 and ns2 as vtp servers and you need also to define a VTP domain name.
nstest can be configured as VTP client and with the same VTP name.
Hope to help
Ip routing is enable on all switches, but if you look closely to the config there is a static route to 192.168.165.1 which is the firewall internal interface, and the firewall has a route on this internal interface 192.168.167.0 0.0.0.0 192.168.165.61 1 which is an ip configured on nstest but belongs to vlan1 not to vlan30, maybe i should change that route to point vlan 30.
about the configuration of vtp domain,which benefits am i going to get? can i do that during production? is there a step by step documentation?
by the way..
i did the sh vlan id 30 on ns1 and ns2 and is there active.
i still have problems doing pings from hosts on vlan30 to vlan1 (ns1 and ns2) and remote desktop connection doesnt work either.
ok there is another device that is the FW
the VTP domain can be useful or not, the possible issue is that default configuration VTP is vtp domain name null and mode vtp server.
I was trying to guess what could cause the problem when you enabled the trunk links
Hope to help
I checked vtp status using show vtp status on the 3 switches.
There is a vtp domain name and all three are set as servers.
this is good news so let's stop to think of vtp.
focusing back on the connectivity issue:
you have a FW in the middle have you enabled / modified the ACLs to permit traffic between vlan30 and vlan1.
the question is that with this configuration all switches point to the FW even if they could bypass it with specific static routes
if you add on a specific static route for the subnet on ns1 and ns2 with next point nstest ip address in vlan1 the FW is bypassed.
I would perform this test to see if the trouble is the FW.
Hope to help
I dont see any ACL's that could be denying this traffic but i post FW config, the only thing i see is that there is route on the FW that forwards traffic to 167.0 network to the vlan1 interface on testswitch and i think thats ok.
I've looking at the FW syslog, and i saw consistent message becouse this server on the vlan30 is trying to connect to the other server on vlan1.
The msg says Deny TCP (no connection) from 192.168.167.64/1433 to 192.168.167.8071795 flag SYN ACK on internal interface.
So that means the FW is blocking the tcp connections i guess.
Now i have to find out the correct rule to give access.
on firewalls we need to provide routing configuration but also to take care of security.
even without an ACL applied the level of trust counts:
so default behavior is to allow TCP connections started from a more trusted interface to a less trusted interface
and to deny a TCP connection starting from a less trusted interface to a more trusted
Hope to help