It's a pleasure Oscar!

oscarhernandezgil · ‎03-22-2017

Hello guys, i'll try to be as clear as possible with that issue.

We have the next network (simplified just with affected device):

c2960 ----conected to-----c4500 (as CORE)-----conected to----ASA

Users/Management network: 192.168.123.0 /24 (vlan 1)

c2960: 192.168.123.5

c4500: 192.168.123.8

ASA: 192.168.123.200

I can't access by ssh/telnet to the c2960

The funny thing is:

ping from c2960 to c4500 --> SUCCESS

ping from c4500 to c2960 --> FAIL

ping from ASA to c2960 --> SUCCESS

The issue seems to be at the c4500 for some reason.

Also, i added in the c2960 another vlan used by the c4500 and then, from c4500 i can ssh to the c2960 through that new added vlan.

If it helps i attach the config of both devices (i erase the interface part in the CORE, so long, and the interface between switches is a trunk):

########### c2960 #############

hostname sw-c2960-01
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
clock timezone UTC 1
clock summer-time UTC recurring last Sun Mar 2:00 last Sun Oct 3:00
switch 1 provision ws-c2960s-24ts-l
!
!
!
!
crypto pki trustpoint TP-self-signed-3169374848
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-3169374848
revocation-check none
rsakeypair TP-self-signed-3169374848
!
spanning-tree mode pvst
spanning-tree extend system-id
!
!
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0
no ip address
!
interface GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/2
!
interface GigabitEthernet1/0/3
!
interface GigabitEthernet1/0/4
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
!
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
interface GigabitEthernet1/0/14
!
interface GigabitEthernet1/0/15
!
interface GigabitEthernet1/0/16
!
interface GigabitEthernet1/0/17
!
interface GigabitEthernet1/0/18
!
interface GigabitEthernet1/0/19
!
interface GigabitEthernet1/0/20
!
interface GigabitEthernet1/0/21
!
interface GigabitEthernet1/0/22
!
interface GigabitEthernet1/0/23
description Catalyst 4506 R01
!
interface GigabitEthernet1/0/24
description Catalyst 4506 R01
!
interface GigabitEthernet1/0/25
!
interface GigabitEthernet1/0/26
!
interface GigabitEthernet1/0/27
!
interface GigabitEthernet1/0/28
!
interface Vlan1
ip address 192.168.123.5 255.255.255.0
!
ip default-gateway 192.168.123.8
ip http server
ip http secure-server
!

########### c4500 #############

hostname Sw4506E.StAndreu
!
boot-start-marker
boot system flash cat4500e-entservicesk9-mz.122-54.SG.bin
boot-end-marker
!
logging buffered 65565
!
username nscglobal privilege 15 secret 5 $1$Xyzm$YTAr3ZsVF2u6KBfgvrv7v1
username ocortes privilege 15 secret 5 $1$qINd$zPFpLwNiOpaqe6vWhgInZ0
!
!
no aaa new-model
ip subnet-zero
no ip domain-lookup
ip domain-name blackprint.local
ip vrf mgmtVrf
!
ip vrf vrf_inside
rd 192.168.123.8:1
!
!
!

archive
log config
logging enable
logging size 1000
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
ip ssh logging events
ip ssh version 2
!
!
interface FastEthernet1
ip vrf forwarding mgmtVrf
no ip address
speed auto
duplex auto
!

interface Vlan1
ip vrf forwarding vrf_inside
ip address 192.168.123.8 255.255.255.0
!
interface Vlan4
description Outside ASA
ip address 192.168.101.8 255.255.255.0
ip policy route-map map_servicios
!
interface Vlan6
description usuarios
ip vrf forwarding vrf_inside
ip address 192.168.124.1 255.255.255.0
!
interface Vlan8
description Outside a los proveedores
ip address 192.168.100.200 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.101.154
ip route 10.0.0.0 255.0.0.0 192.168.101.254
ip route 172.16.10.0 255.255.255.0 192.168.101.254
ip route 192.168.50.0 255.255.255.0 192.168.101.200
ip route vrf vrf_inside 0.0.0.0 0.0.0.0 192.168.123.200
ip route vrf vrf_inside 192.168.1.0 255.255.255.0 192.168.123.200
ip route vrf vrf_inside 192.168.11.0 255.255.255.0 192.168.123.200
ip route vrf vrf_inside 192.168.22.0 255.255.255.0 192.168.123.200
ip route vrf vrf_inside 192.168.122.0 255.255.255.0 192.168.123.1
ip route vrf vrf_inside 192.168.222.0 255.255.254.0 192.168.123.200
ip http server
ip http authentication local
ip http secure-server
ip http secure-port 4443
!
!
ip access-list extended acl_FTP
permit tcp host 192.168.101.2 eq ftp any
permit tcp host 192.168.101.2 eq ftp-data any
permit tcp host 192.168.101.2 range 45000 45050 any
ip access-list extended acl_HTTP
permit tcp host 192.168.101.2 eq www any
ip access-list extended acl_SMTP
permit tcp any any eq smtp
permit tcp host 192.168.101.224 eq smtp any
permit tcp host 192.168.101.224 eq 443 any
ip access-list extended acl_VPN
permit udp host 192.168.101.200 eq isakmp any
permit udp host 192.168.101.200 eq non500-isakmp any
permit esp host 192.168.101.200 any
permit ahp host 192.168.101.200 any
ip access-list extended acl_WS
permit tcp host 192.168.101.229 eq 8008 any
ip access-list extended acl_prueba
permit icmp host 192.168.101.200 host 213.229.183.231
!
logging trap debugging
!
route-map map_servicios permit 10
match ip address acl_FTP
set ip next-hop 192.168.100.211
!
route-map map_servicios permit 20
match ip address acl_HTTP
set ip next-hop 192.168.100.211
!
route-map map_servicios permit 30
match ip address acl_SMTP
set ip next-hop 192.168.100.211
!
route-map map_servicios permit 40
match ip address acl_VPN
set ip next-hop 192.168.100.211
!
route-map map_servicios permit 50
match ip address acl_WS
set ip next-hop 192.168.100.211
!
!

ntp clock-period 17180016
ntp source Vlan1
ntp master 10
ntp server vrf vrf_inside 150.214.94.5
end

########################################

Thanks guys!

ismiller · ‎03-22-2017

Hi Oscar,

I attempted to recreate your issue and was able to reach the 2960 just fine as long as I ping via vrf_inside on the 4500 with the command ping vrf_inside 192.168.123.5.

I am also able to SSH in with ssh -l cisco -vrf vrf_inside 192.168.123.5.

When you were experiencing the issue were you ensuring you were sourcing your traffic from the respective VRF as well?

Thanks!

oscarhernandezgil · ‎03-23-2017

Hello Miller and thanks for your reply

As you spotted, the issue seems to be around VRF

For some reason the "ip route vrf vrf_inside 192.168.123.0 255.255.255.0 192.168.123.200" statement is missing. I must admit that i'm not used with the VRF commands, so maybe that's a point here too hehe

That must be the thing here, becouse the 2960 device is working as expected, normally as allways, and is the 4500 the one that is processing the petitions from the 192.168.123.0 network in a different way.

Let me thank you again for your help.

ismiller · ‎03-23-2017

It's a pleasure Oscar! Collaborating with one another is the best way to learn.

I might be misunderstanding your issue but my understanding is you're unable to ping the 2960 VLAN 1 SVI address, which is on the same subnet as your VLAN1 SVI on the 4500.

Since this exist on the same subnet, you shouldn't need to have a static route installed for reachability to the 2960.

My concern was when the ping command was issued form the 4500, the vrf keyword wasn't included. Since VRF essentially creates a seperate routing table instance on your box, there is a need to inform the ping command to reference the VRF so the originated traffic knows which routing table to use in order to find its destination.

Just to be sure reachability should be possible, would you mind showing me the output of show ip arp vrf vrf_inside on the 4500?

Thank you!

oscarhernandezgil · ‎03-24-2017

Hello again Miller,

Let me show some of the output i obtained:

#show ip arp vrf vrf_inside
Protocol Address          Age (min) Hardware Addr   Type   Interface
Internet 192.168.123.22          7   3c4a.92b2.3658 ARPA   Vlan1
Internet 192.168.123.21          1   b8ca.3a81.7967 ARPA   Vlan1
Internet 192.168.123.31        179   f4ce.4623.314b ARPA   Vlan1
Internet 192.168.123.30          4   082e.5f00.5c42 ARPA   Vlan1
Internet 192.168.123.1          55   0013.c3e7.8938 ARPA   Vlan1
Internet 192.168.124.1           -   503d.e50e.dcbf ARPA   Vlan6
Internet 192.168.123.5          46   c07b.bce8.d2c0 ARPA   Vlan1 <-- 2960
Internet 192.168.123.8           -   503d.e50e.dcbf ARPA   Vlan1 <-- 4500
Internet 192.168.123.15          2   00d0.b80c.016c ARPA   Vlan1
Internet 192.168.123.13          0   0018.0ada.5370 ARPA   Vlan1
Internet 192.168.123.51          0   6c62.6da6.7d6c ARPA   Vlan1
Internet 192.168.123.50          0   a0d3.c12f.adb1 ARPA   Vlan1
Internet 192.168.123.49         96   78e7.d1b2.fadb ARPA   Vlan1

So the device is (directly) connected, the 4500 "see" it, it is shown too as a neighbor...but can't access.

Thanks again for your support :)

ismiller · ‎03-24-2017

You're very welcome :)

This is good news. This means there is address resolution taking place and you should have communications with the switch.

If you're trying to SSH into the 2960 from the 4500, you'll need to use the command:

ssh-l <your username> -vrf vrf_inside 192.168.123.5

To ping the 2960 from the 4500 you'll need this command:

ping vrf vrf_inside 192.168.123.5

If you are trying to access these devices for managment from a host plugged into the 4500, the physical interface will need to be in VLAN1. This is because the address resolution for the management IP address you have given to the 2960 exists in the 4500s ARP table associated to the VRF you made.

___________________________________________________________________

When I bring a brand new router out of the box, I have one routing table (RIB), one ARP table, and one CEF Table on the device (Assuming CEF is enabled, which it always should be).

When I enact a VRF instance, I am essentially creating a new RIB, ARP, and CEF table to act independently from the default RIB, ARP, and CEF table. I can then assign interfaces, both virtual and physical, to this separate instance. When I type ping 192.168.123.5 I am attempting to use the default RIB, ARP, and CEF tables to send that traffic. However, since your VLAN1 is in a VRF, the ARP information for that IP address sits in the vrf instance, not the default instance. Therefore, I need to tell the router to initiate the ping from that VRF instance. This is why you need to type ping vrf vrf_inside 192.168.123.5. This is telling the device to look into the tables that are associated to that VRF for the forwarding information. Does that make sense?

I hope this helps. Please let me know if you have any further questions. :)

oscarhernandezgil · ‎03-24-2017

Wow, you clarified that concept pretty much. All clear now.

Let me ask you one more question. Let's suppose that instead of a 2960 we have a SG500. Cisco SG series are prepared for web management, and really user friendly. In the same scenario, could an user access via web to the device?

Now i realize that 2960 series are accesible via web too (never accessed that way i must say)

Your help has been really valuable in that issue. Thanks Miller! :)

ismiller · ‎03-24-2017

I'm glad the issue is clear now! :)

I don't have any experience with SG500s, but VRF is a packet forwarding concept. As long VLAN1 traffic can pass over the trunk from the SG500 to the 4500, and you have the SVI for VLAN1 configured with an IP address in the management subnet on the SG500, it should work in the same way. VRF doesn't care about the connected device, it's merely a means of having more than one instance of forwarding tables on a router.

I hope that clarifies things for you!

Can't access L2 switch