cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15168
Views
0
Helpful
18
Replies

Can't ping host from switch

Fabri_Fabri
Level 1
Level 1

(I started a previous discussion but somehow many replies were deleted, I please ask to some moderator to give a look, it was

"Some interfaces/VLAn are not trunking" )

I inherited a Catalyst 3560 (SW1) with many VLANs onto it.

SW1 is connected to a firewall through a trunk port.

I have problems in connecting a host to a particular VLAN.

One working host is connected to this VLAN.

I want to add another host in that VLAN. I configured another interface for that and I connected the new host.

These 2 hosts, same VLAN, can ping each other with no problem.

1° problem: from inside the switch I can't succesfully ping the new host:

switch01#ping 10.1.2.10 <-- WORKING HOST

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.2.10, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

switch01#ping 10.1.2.11 <-- THE NEW ATTACHED HOST

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.2.10, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

What could be the problem ?

Thanks for help.

2 Accepted Solutions

Accepted Solutions

So we see from the output that your switch has a SVI only on the 10.6.0.0 network and NOT on the 10.1.2.0 network. So the traffic must flow through a gateway (router or routed port on a firewall or layer 3 switch) and for it to be routed symmetrically, it should be the same gateway as the PCs use.

Yes, adding an layer 3 interface (or indeed any configuration modification) is a config mode command.

View solution in original post

So your pings from the switch should go into the firewall. I would expect the firewall has a 10.1.2.1 interface for the PCs to use as their gateway and that both are setup thus.

If that is the case, then you need to capture the flow through the firewall or use the  ASA packet-tracer tool.

On the ASA, from enable mode:

     packet-tracer input icmp 10.6.0.10 1 1 10.1.2.11 detailed

The output will indicate if the flow is allowed.

View solution in original post

18 Replies 18

Marvin Rhoads
Hall of Fame
Hall of Fame

Is the firewall between the switch and the hosts?

Working host and not-working host are connected each to a SW1 interface and so is the ASA (trunk).

HOST1---SW1--HOST2 (not working)

                  |

              ASA FW

We need to follow the expected flow of traffic. Does the switch have a layer 3 SVI on the VLAN that server the 10.1.2.0 network or is traffic from the switch to PCs going via the firewall?

Marvin Rhoads wrote:

Does the switch have a layer 3 SVI on the VLAN that server the 10.1.2.0 network

     Sorry, what do you mean layer 3 "SVI" ?

Marvin Rhoads wrote:

or is traffic from the switch to PCs going via the firewall?

(Above ping output are from a telnet session coming from another pc/network 10.6.1.1, I don't know if it can help)

I guess that traffic goes through FW trunk port to route for the ip 10.1.2.11. (I am confused also about layer3 functionality in this case ..)

The strange is that pinging 10.1.2.10 works well.

SVI = switched virtual interface. We can see them most easily on the switch by providing output from:

shw ip int br | ex una

If the gateway for the 10.1.2.0 network (most commonly 10.1.2.1) is on the firewall, it most likely has a rule restricting which address may be accessed via it. If that is the case, you can either:

a. change that rule or

b. change the flow of traffic from switch to host so as to not need to go via the firewall.

the latter step would be via adding a SVI for that network on the switch itself. e.g.:

interface vlan

ip address 10.1.2.

(Substituting the field in brackets with actual values)

Marvin Rhoads wrote:

SVI = switched virtual interface. We can see them most easily on the switch by providing output from:

shw ip int br | ex una

Interface              IP-Address      OK? Method Status                Protocol

Vlanxx                10.6.0.10       YES NVRAM  up                    up

Marvin Rhoads wrote:

If the gateway for the 10.1.2.0 network (most commonly 10.1.2.1) is on the firewall, it most likely has a rule restricting which address may be accessed via it. If that is the case, you can either:

a. change that rule or

I am quite sure that firewall has no rule restricting hosts.

Marvin Rhoads wrote:

b. change the flow of traffic from switch to host so as to not need to go via the firewall.

the latter step would be via adding a SVI for that network on the switch itself. e.g.:

interface vlan

ip address 10.1.2.

"interface vlan xx" returns me an error. Do I have to do it in config-mode ?

Thanks

So we see from the output that your switch has a SVI only on the 10.6.0.0 network and NOT on the 10.1.2.0 network. So the traffic must flow through a gateway (router or routed port on a firewall or layer 3 switch) and for it to be routed symmetrically, it should be the same gateway as the PCs use.

Yes, adding an layer 3 interface (or indeed any configuration modification) is a config mode command.

Marvin Rhoads wrote:

So we see from the output that your switch has a SVI only on the 10.6.0.0 network and NOT on the 10.1.2.0 network. So the traffic must flow through a gateway (router or routed port on a firewall or layer 3 switch) and for it to be routed symmetrically, it should be the same gateway as the PCs use.

Could the traffic flows through the trunk port actually connected to the firewall ?

This is the output:

switch01#sh int fa0/xx switchport

Name: Fa0/xx

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk private VLANs: none

Operational private-vlan: none

Trunking VLANs Enabled: 1-10,20

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

Marvin Rhoads wrote:

Yes, adding an layer 3 interface (or indeed any configuration modification) is a config mode command.

I would avoid to create another SVI, also because the other host (same network) works well.

Thanks

Since you are going to a network that's not locally connected (at layer 3), your traffic will flow according to the switch's routing table:

     show ip route

That is where you would need to check to troubleshoot further.

Marvin Rhoads wrote:

Since you are going to a network that's not locally connected (at layer 3), your traffic will flow according to the switch's routing table:

     show ip route

Default gateway is 10.8.0.1

Host               Gateway           Last Use    Total Uses  Interface

ICMP redirect cache is empty

That IP is the firewall; now what ?

Thanks.

So your pings from the switch should go into the firewall. I would expect the firewall has a 10.1.2.1 interface for the PCs to use as their gateway and that both are setup thus.

If that is the case, then you need to capture the flow through the firewall or use the  ASA packet-tracer tool.

On the ASA, from enable mode:

     packet-tracer input icmp 10.6.0.10 1 1 10.1.2.11 detailed

The output will indicate if the flow is allowed.

Marvin Rhoads wrote:

     packet-tracer input icmp 10.6.0.10 1 1 10.1.2.11 detailed

This is the result:

FW01# packet-tracer input EXTERNAL icmp 10.6.0.10 1 1 10.1.2.11 detailed

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   10.1.2.0        255.255.255.0   vlan12

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: DROP

Config:

access-group acl-EXTERNAL-in in interface EXTERNAL

access-list acl-EXTERNAL-in extended deny ip any object-group internal-network

object-group network internal-network

network-object 10.6.0.0 255.255.0.0

network-object 10.1.2.0 255.255.255.0

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd54f3718, priority=12, domain=permit, deny=true

        hits=3, user_data=0xd54f36d8, cs_id=0x0, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=10.1.2.0, mask=255.255.255.0, port=0

Result:

input-interface: EXTERNAL

input-status: up

input-line-status: up

output-interface: vlan12

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

However, I tried to execute a similar packet tracer for the working host and it gives the same DROP result (but it works).

This is a puzzle ?? !! ??

Fabri_Fabri
Level 1
Level 1

I am so sorry: the default gateway of the new host was wrong.

It now works as expected.

Probably the host never presented himself to the firewall (gateway).

Sorry Marvin to have wasted your time and thanks for help.

Regards.

Good to hear that you have figured it out.

Note my:

9:51 response "...it should be the same gateway as the PCs use."

10:44 response "... both are setup thus".

Please rate any useful replies and mark your question as answered if it is.

Best Regards,

- Marvin