I've two cisco ASA configured in active/active HA. ASA is connected to switch with port-channel. Switch configuration:

interface Port-channel47
 description ASA2
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpdufilter enable
interface Port-channel48
 description ASA1
 switchport mode trunk
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpdufilter enable

Context system configuration:

interface GigabitEthernet0/0
 channel-group 1 mode on
interface GigabitEthernet0/1
 channel-group 1 mode on
interface Port-channel1
 lacp max-bundle 8
interface Port-channel1.99
 description Aggregation
 vlan 99
interface Port-channel1.300
 description 300
 vlan 300
interface Port-channel1.302
 description 302
 vlan 302

context CTX1
  allocate-interface Port-channel1.99
  allocate-interface Port-channel1.302
  config-url disk0:/CTX1
  join-failover-group 1

context CTX2
  allocate-interface Port-channel1.99
  allocate-interface Port-channel1.300
  config-url disk0:/CTX2
  join-failover-group 1

failover group 1
  preempt 100
failover group 2
  preempt 100


ospf configuration
interface Port-channel1.302
 nameif 302
 security-level 50
 ip address x.x.x.1 standby x.x.x.2
interface Port-channel1.99
 nameif 99
 security-level 0
 ip address y.y.y.1 standby y.y.y.2

router ospf 1
 network y.y.y.0 area 0


interface Port-channel1.300
 nameif servers
 security-level 60
 ip address z.z.z.1 standby z.z.z.2
interface Port-channel1.99
 nameif outside
 security-level 0
 ip address y.y.y.3 standby y.y.y.4

router ospf 1
 network y.y.y.0 area 0

Issue I've encountered is that they won't become neighbours. I can ping CTX2 from CTX1:

CTX-FW(config)# ping y.y.y.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to y.y.y.2, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

show ospf 1

 Routing Process "ospf 1" with ID y.y.y.1
 Start time: 1d22h, Time elapsed: 00:04:24.090
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Event-log enabled, Maximum number of events: 1000, Mode: cyclic
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x0
 Number of opaque AS LSA 0. Checksum Sum 0x0
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0) (Inactive)
        Number of interfaces in this area is 1
        Area has no authentication
        SPF algorithm last executed 00:04:00.600 ago
        SPF algorithm executed 1 times
        Area ranges are
        Number of LSA 1. Checksum Sum 0x6099
        Number of opaque link LSA 0. Checksum Sum 0x0
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

debug ospf showing that hello being sent but other side won't receive it.

show ospf interface outside

outside is up, line protocol is up
  Internet Address y.y.y.1 mask, Area 0
  Process ID 1, Router ID y.y.y.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) y.y.y.1, Interface address y.y.y.1
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 0:00:06
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

Weird thing is that other context has not receiving any hellos as per show ospf traffic:

    OSPF packets received/sent

  Type          Packets              Bytes
  RX Invalid                       0 0
  RX Hello                         0 0
  RX DB des                        0 0
  RX LS req                        0 0
  RX LS upd                        0 0
  RX LS ack                        0 0
  RX Total                         0 0

  TX Failed                        0 0
  TX Hello                        71 3976
  TX DB des                        0 0
  TX LS req                        0 0
  TX LS upd                        0 0
  TX LS ack                        0 0
  TX Total                        71 3976

I've added access-group and access-list allowing ospf traffic:

access-list OUTSIDE extended permit ospf any4 any4
access-list OUTSIDE extended permit ip any4 any4
access-group OUTSIDE in interface outside

Is there any limitation with OSPF on Cisco ASA contexts? Any idea why multicast has not been received by other context?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Dec 25, 2018 at 9:15
  • Ron unfortunately there wasn't any correct answer. Feb 19, 2019 at 9:45

2 Answers 2


First, a quick possible typo. In the ping results above, I think you pinged the standby unit rather than the other context.

Second, there doesn't seem to be any logical reason (based upon what you posted) why there are two contexts. The interface they both share is the lowest security interface. So, a person might assume that the default route on both points to some vlan 99 gateway. Why aren't these two contexts just merged into one unified config? Role-based access? Resource classes?

Regardless of those two things, when an ASA is put into multi-context mode, there's a thing called the Packet Classifier that is responsible for taking incoming packets and assigning them to the appropriate context, as well as forwarding packets between contexts. There are limitations on what the Packet Classifier can do, and multicast is a challenge.

OSPF uses multicast. You can establish OSPF neighborships with a context of an ASA in multi-context mode, but I suspect you can not establish a context-to-context OSPF neighborship because of a limitation. What most likely happens in this scenario (i can't find documentation to prove it) is that the Classifier sends the packets to the upstream device. The upstream device (a switch) sees that the packets are multicast (based upon the destination MAC) and treats them as broadcasts. Switches never broadcast frames out the same port at which they arrived. So, the ASA never gets the multicast packets back again. The Packet Classifier would normally replicate multicast packets to both contexts.

One you thing you could attempt is to manually assign MAC addresses to the contexts. This is something I do every time, but it's not required. I can't think of a scenario where it's better not to do this. I don't expect this to solve your issue, it's just something to try.

I see you have two failover groups, but both contexts are assigned to the same group. Another troubleshooting idea to try would be to see if the behavior changes when CTX1 is active on the A-side firewall while CTX2 is active on the B-side firewall. Technically, this would mean the multicast frames would at least make it between the two. If this does fix the problem, you know what the issue is, but you shouldn't leave it that way unless you want OSPF to break when you have a failover.

  • That's a very interesting and good explanation, unfortunately, we have re-design the setup and not being able to resolve this issue. I'll hand you bounty! :) May 17 at 11:42

You'll need to unicast the OSPF hellos instead of multicasting them. Multicast doesn't work inter-context.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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