Solved: Re: OSP betweeen ASA security context 5555 and core switch 4500

ehsanpoureshagh · ‎09-09-2019

OSPF works fine between switches 4500, and also with ASA physical

but it seems although i can see OSPF neighbor in ASA-context1 and on core switch

i cant see destination IP in my routing table, but it shows in database, which could be because next hop IP is not reachable, which is not because what ever comes from ASA virtual context are un reachable,

destination interface is on security level.

(source) A--------4500-----------------ASA------------------4500------(destination)B

(source) A--------4500--------------80-ASA-100--------------4500------(destination)B

both A and B can see destinations IP in Database

A can see all destination subnets is Routing table, but cant ping them,

B cant see any destination Subnet in routing table at all

"access-list permit any any" on ASA

=======================================================

core switch:

interface Loopback23
description **MGT P2P OSPF LOOPBACK**
ip vrf forwarding HW_CLOUDS
ip address 192.168.78.23 255.255.255.255
!
interface Vlan996
description ** AWS Primary link **
ip vrf forwarding HW_CLOUDS
ip address 192.168.192.9 255.255.255.252
!
interface Vlan997
description ** AWS Secondary link **
ip vrf forwarding HW_CLOUDS
ip address 192.168.192.13 255.255.255.252
!
interface Vlan998
description ** Azure Primary link **
ip vrf forwarding HW_CLOUDS
ip address 192.168.192.1 255.255.255.252
!
interface Vlan999
description ** Azure Secondary link **
ip vrf forwarding HW_CLOUDS
ip address 192.168.192.5 255.255.255.252
!
interface Vlan2011
description **COPR_CLOUD P2P TO ASA5555 - DC1P-NETASAPR10**
ip vrf forwarding HW_CLOUDS
ip address 192.168.65.91 255.255.255.248
!
router ospf 21 vrf HW_CLOUDS
router-id 192.168.78.23
redistribute static subnets
network 192.168.78.23 0.0.0.0 area 0

network 192.168.65.88 0.0.0.7 area 0
!
!
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.10
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.14 5
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.2
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.6 5
end

=======================================================

ASA:

Interface Name Security
Port-channel1 outside 0
Port-channel2.2001       dmz                             50
Port-channel2.2002      hw_adv          100
Port-channel2.2003      hw_commercial            100
Port-channel2.2004      hw_dev                        100
Port-channel2.2005      hw_emp_comms         100
Port-channel2.2006      hw_resourcing             100
Port-channel2.2007      hw_servers                  100
Port-channel2.2011      hw_cloud                     100         (A is here)
Port-channel3.910        wan_inet                       80           (B is here)

router ospf 1
router-id 192.168.78.12
network 192.168.0.0 255.255.0.0 area 0
area 0
log-adj-changes detail
redistribute static

DC1P-NETASAPR010/cntx1# sho ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.78.23 1 FULL/BDR 0:00:35 192.168.65.91 hw_cloud
192.168.78.100 1 FULL/DR 0:00:36 192.168.68.62 wan_inet

=================================

any idea why ASA behaving like this?

Regards,

ehsanpoureshagh · ‎09-12-2019

Issue has been fixed by adding static mac address to interface on Security context

not sure why, because virtual interfaces were using same physical link, had diffrent mac address, but as soon as i assigned manual mac address, OSPF came up

as i said config on physical firewall and Security context were the same, and OSPF V2 is supported by virtual context, only mac address issue

many thanks for every comments here

View solution in original post

Jaime Valencia · ‎09-09-2019

Might want to move this, you're posting in the UC area.

HTH

java

if this helps, please rate

Georg Pauwen · ‎09-09-2019

Hello,

I cannot tell from what you have posted if you use the same physical interfaces in both contexts; if so, OSPF doesn't work in that configuration.

Post the full running config of your ASA...

ehsanpoureshagh · ‎09-10-2019

Hi

Yes all interfaces in context are
Portchannel2.2011
Portchannel2.2012
Portchannel2.2013

But connection back to "B" is via portchannel3.900

But they are all part of ospf area 0

I tried same model on physical firewall. With same portchannel config and
it works fine.

Not sure why security context cause issue

Georg Pauwen · ‎09-10-2019

I think the problem is that with the same physical interfaces in multiple contexts, multicast traffic (which is used by OSPF) is not being passed.

What if you use a different physical interface in each context ?

ehsanpoureshagh · ‎09-10-2019

This could be the issue . But pease see my lat comment

ehsanpoureshagh · ‎09-10-2019

: Hardware: ASA5555
:
ASA Version 9.10(1) <context>

!
interface Port-channel1
description TO INTERNET FEED
nameif outside
security-level 0
ip address ***************************
!
interface Port-channel2.2001
description TO DMZ CORE VRF
shutdown
nameif dmz
security-level 50
ip address 192.168.65.1 255.255.255.248 standby 192.168.65.2
!
interface Port-channel2.2002
description TO HW_ADVISORY CORE VRF
shutdown
nameif hw_advisory
security-level 100
ip address 192.168.65.9 255.255.255.248 standby 192.168.65.10
!
interface Port-channel2.2003
description TO HW_COMMERCIAL CORE VRF
shutdown
nameif hw_commercial
security-level 100
ip address 192.168.65.17 255.255.255.248 standby 192.168.65.18
!
interface Port-channel2.2004
description TO HW_DEV CORE VRF
shutdown
nameif hw_dev
security-level 100
ip address 192.168.65.25 255.255.255.248 standby 192.168.65.26
!
interface Port-channel2.2005
description TO HW_EMP_COMMS CORE VRF
shutdown
nameif hw_emp_comms
security-level 100
ip address 192.168.65.33 255.255.255.248 standby 192.168.65.34
!
interface Port-channel2.2006
description TO HW_RESOURCING CORE VRF
shutdown
nameif hw_resourcing
security-level 100
ip address 192.168.65.41 255.255.255.248 standby 192.168.65.42
!
interface Port-channel2.2007
description TO HW_SERVERS CORE VRF
shutdown
nameif hw_servers
security-level 100
ip address 192.168.65.49 255.255.255.248 standby 192.168.65.50
!
interface Port-channel2.2011
description TO HW_CLOUD CORE VRF
shutdown
nameif hw_cloud
security-level 100
ip address 192.168.65.89 255.255.255.248 standby 192.168.65.90
!
interface Port-channel2.2090
description TO SECURITY_MGT in GLOBAL CORE VRF
shutdown
nameif sec_management
security-level 100
ip address 192.168.66.1 255.255.255.248 standby 192.168.66.2
!
interface Port-channel2.2097
description TO CLIENTS FW
shutdown
nameif hw_clients_fw_transit
security-level 100
ip address 192.168.67.1 255.255.255.248 standby 192.168.67.2
!
interface Port-channel3.910
nameif wan_inet
security-level 80
ip address 192.168.68.35 255.255.255.224 standby 192.168.68.36
!

access-list wan_inet extended permit ip any any
access-list wan_inet extended permit icmp any any
access-list dmz extended permit ip any any
access-list dmz extended permit icmp any any
access-list hw_advisory extended permit ip any any
access-list hw_advisory extended permit icmp any any
access-list hw_commercial extended permit ip any any
access-list hw_commercial extended permit icmp any any
access-list hw_dev extended permit ip any any
access-list hw_dev extended permit icmp any any
access-list hw_emp_comms extended permit ip any any
access-list hw_emp_comms extended permit icmp any any
access-list security_management extended permit ip any any
access-list security_management extended permit icmp any any
access-list hw_resourcing extended permit icmp any any
access-list hw_resourcing extended permit ip any any
access-list hw_servers extended permit icmp any any
access-list hw_servers extended permit ip any any
access-list hw_clients_fw_transit extended permit icmp any any
access-list hw_clients_fw_transit extended permit ip any any
access-list ISE_POSTURE_REDIRECT extended deny ip any object-group ISE_SERVERS
access-list ISE_POSTURE_REDIRECT extended deny ip any object-group DNS_SERVERS
access-list ISE_POSTURE_REDIRECT extended permit ip any any
access-list SFR_REDIRECT remark DENY ZERTO TRAFFIC TO SFR
access-list SFR_REDIRECT extended deny ip object-group ZERTO any
access-list SFR_REDIRECT extended deny ip object-group ZERTO_REMOTE any
access-list SFR_REDIRECT remark PERMIT ALL OTHER TRAFFIC TO SFR
access-list SFR_REDIRECT remark DENY ZERTO TRAFFIC TO SFR
access-list SFR_REDIRECT remark PERMIT ALL OTHER TRAFFIC TO SFR
access-list TCP_STATE_BYPASS extended permit tcp host 10.130.0.254 192.168.66.0 255.255.255.240
access-list RATE_LIMIT_ZERTO extended permit ip object-group ZERTO_REMOTE any
access-list outside_in

access-list hw_cloud_in extended permit ip any any
access-list hw_cloud_in extended permit icmp any any

pager lines 24
logging enable
logging standby
logging list Webvpn_debug level debugging class webvpn
logging monitor debugging
logging buffered notifications
logging trap notifications
logging history informational
logging asdm debugging
logging from-address RG1P-NETASAPR01@huntswood.com
logging recipient-address itteam@huntswood.com level errors
logging host wan_inet 10.130.0.42
mtu outside 1500
mtu dmz 1500
mtu hw_advisory 1500
mtu hw_commercial 1500
mtu hw_dev 1500
mtu hw_emp_comms 1500
mtu hw_resourcing 1500
mtu hw_servers 1500
mtu sec_management 1500
mtu hw_clients_fw_transit 1500
mtu wan_inet 1500
mtu hw_cloud 1500
no monitor-interface dmz
no monitor-interface hw_advisory
monitor-interface hw_commercial
monitor-interface hw_dev
monitor-interface hw_emp_comms
monitor-interface hw_resourcing
monitor-interface hw_servers
monitor-interface sec_management
monitor-interface hw_clients_fw_transit
no monitor-interface wan_inet
no monitor-interface hw_cloud
no monitor-interface service-module
icmp unreachable rate-limit 1 burst-size 1
icmp permit any hw_commercial
icmp permit any hw_dev
icmp permit any hw_emp_comms
icmp permit any hw_resourcing
icmp permit any hw_servers
icmp permit any sec_management
icmp permit any hw_clients_fw_transit
no asdm history enable
arp timeout 14400
access-group outside_in in interface outside
access-group hw_commercial in interface hw_commercial
access-group hw_dev in interface hw_dev
access-group hw_emp_comms in interface hw_emp_comms
access-group hw_resourcing in interface hw_resourcing
access-group hw_servers in interface hw_servers
access-group security_management in interface sec_management
access-group hw_clients_fw_transit in interface hw_clients_fw_transit
access-group hw_cloud_in in interface hw_cloud
!
prefix-list VPN_POOL seq 10 permit 172.16.200.0/22 le 32
prefix-list VPN_POOL seq 20 permit 172.16.204.0/22 le 32

!
router ospf 1
router-id 192.168.78.12
network 192.168.0.0 255.255.0.0 area 0
area 0
log-adj-changes detail
redistribute static
!
route outside 0.0.0.0 0.0.0.0 213.86.114.62 1
route sec_management 10.130.8.0 255.255.255.0 192.168.66.3 1
route sec_management 10.130.9.0 255.255.255.0 192.168.66.3 1
route hw_cloud 10.140.0.0 255.255.0.0 192.168.65.91 1
route hw_cloud 10.150.0.0 255.255.0.0 192.168.65.91 1

policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect icmp
inspect icmp error
!
service-policy global_policy global
Cryptochecksum:2311ffb4b784cd6b5fe3148130f00a9e
: end

Giuseppe Larosa · ‎09-10-2019

Hello ehsanpoureshagh,

I have used OSPF in multiple contexts on ASA with SW version 9.2.6 with good results

>>

DC1P-NETASAPR010/cntx1# sho ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.78.23 1 FULL/BDR 0:00:35 192.168.65.91 hw_cloud
192.168.78.100 1 FULL/DR 0:00:36 192.168.68.62 wan_inet

both interfaces are in the same context cntx1 from the device prompt.

Note:

for successful installation of redistributed static routes in OSPF the static route next-hops must be advertised as internal routes using network commands and eventually passive interface.

The devices will look at the forwarding address field in the LSA type 5, if set to a value different from 0.0.0.0 (that would mean OSPF RID of ASBR node) they look for an internal route.

On the C4500 you should use network commands in OSPF covering all the next-hops

>>

router ospf 21 vrf HW_CLOUDS
router-id 192.168.78.23
redistribute static subnets
network 192.168.78.23 0.0.0.0 area 0

network 192.168.65.88 0.0.0.7 area 0
!
!
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.10
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.14 5
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.2
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.6 5

I think you need a network statement to cover all the 192.168.192.x next-hops in vrf HW_CLOUDS.

This may be a general issue with OSPF not related to ASA or ASA with contexts.

Hope to help

Giuseppe

ehsanpoureshagh · ‎09-10-2019

hello and thanks for your reply

All interfaces are in same context but using same physival interface to go out

we have OSPF area 0 on all ASA interfaces

OSPF neighbor is up for sure

A----- B has following confih hop by hop, and its fine whith phisical ASA, but as soon as i copy same config to context1 it doesnt work, All routes will be in OSPF database but wont get to routing table on B side.

so issue should not be OSPF config should be something with virtual context, at the moment i have only one context using OSPF, other contexes are using static route

============================================

C4500:

router ospf 21 vrf HW_CLOUDS
router-id 192.168.78.23
redistribute static subnets
network 192.168.65.88 0.0.0.7 area 0
network 192.168.78.23 0.0.0.0 area 0
network 192.168.192.0 0.0.0.15 area 0
!
!
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.10
ip route vrf HW_CLOUDS 10.140.0.0 255.255.0.0 192.168.192.14 5
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.2
ip route vrf HW_CLOUDS 10.150.0.0 255.255.0.0 192.168.192.6 5
end

===================================================

ASA (Physical):

router ospf 1
router-id 192.168.78.12
network 192.168.0.0 255.255.0.0 area 0
area 0
log-adj-changes detail

DC1P-NETASAPR01# sho ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.78.23 1 FULL/DR 0:00:36 192.168.65.91 hw_cloud
192.168.78.100 1 FULL/DR 0:00:38 192.168.68.3 wan_inet
192.168.78.14 1 FULL/BDR 0:00:33 192.168.67.4 hw_clients_fw_transit
192.168.78.13 1 FULL/DR 0:00:39 192.168.65.51 hw_servers
192.168.78.11 1 FULL/DR 0:00:34 192.168.65.43 hw_resourcing
192.168.78.9 1 FULL/DR 0:00:39 192.168.65.35 hw_emp_comms
192.168.78.7 1 FULL/DR 0:00:31 192.168.65.27 hw_dev
192.168.78.5 1 FULL/DR 0:00:35 192.168.65.19 hw_commercial
192.168.78.3 1 FULL/DR 0:00:36 192.168.65.11 hw_advisory
192.168.78.1 1 FULL/DR 0:00:35 192.168.65.3 dmz

========================================================

C4500:

interface Vlan908
description **WAN_P2P TO ASA5555 - physical**
ip vrf forwarding WAN-INET
ip address 192.168.68.3 255.255.255.248
!

interface Vlan910
description **WAN_P2P TO ASA5555 - context1**
ip vrf forwarding WAN-INET
ip address 192.168.68.62 255.255.255.224
!

router ospf 100 vrf WAN-INET
router-id 192.168.78.100
redistribute static subnets
network 192.168.68.0 0.0.0.255 area 0
network 192.168.69.0 0.0.0.255 area 0
network 192.168.70.0 0.0.0.255 area 0
network 192.168.78.100 0.0.0.0 area 0
default-information originate always
!

DC1P-NETCOREPR01#sho ip ospf 100 neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.78.12 1 FULL/BDR 00:00:32 192.168.68.35 Vlan910
192.168.78.107 1 FULL/DR 00:00:32 192.168.70.10 Port-channel40
192.168.78.14 1 FULL/BDR 00:00:33 192.168.69.1 Vlan909
192.168.78.105 1 FULL/DR 00:00:37 192.168.69.10 Port-channel20
192.168.78.12 1 FULL/BDR 00:00:35 192.168.68.1 Vlan908
192.168.78.103 1 FULL/DR 00:00:34 192.168.68.10 Port-channel30
DC1P-NETCOREPR01#

router ospf 100 vrf WAN-INET
router-id 192.168.78.100
redistribute static subnets
network 192.168.68.0 0.0.0.255 area 0
network 192.168.69.0 0.0.0.255 area 0
network 192.168.70.0 0.0.0.255 area 0
network 192.168.78.100 0.0.0.0 area 0
default-information originate always
!

ehsanpoureshagh · ‎09-12-2019

Issue has been fixed by adding static mac address to interface on Security context

not sure why, because virtual interfaces were using same physical link, had diffrent mac address, but as soon as i assigned manual mac address, OSPF came up

as i said config on physical firewall and Security context were the same, and OSPF V2 is supported by virtual context, only mac address issue

many thanks for every comments here

Giuseppe Larosa · ‎09-12-2019

Hello ehsanpoureshagh,

thanks for your feedback.

>> not sure why, because virtual interfaces were using same physical link, had diffrent mac address, but as soon as i assigned manual mac address, OSPF came up

I had to this in the past on on C6500 at SVI level when building an EIGRP neighborship between two different SVIs in different VRFs going trough a transparent FW contxt in FWSM blade. But in my case SVIs were trying to use the same MAC address so we needed to change it on one of them.

Best Regards

Giuseppe

Georg Pauwen · ‎09-12-2019

I wonder if assigning the static MAC address sort of 'tricks' the ASA into thinking it is actually a different physical interface...