Unable to redistribute BGP into OSPF at one site

[Dieselboy]

I have 3 sites, site 2 has the problem.

Site 1 - main. Has an ASA 5515 and internal nexus 3k switch
Site 2 - secondary site. Has an ASA 5516 and a core Cisco 3650 IOS-XE switch with lan base
Site 3 - remote site. Has a 2901 router as it's edge device and a 2960X lan switch

I run Ipsec VTI tunnels between all the sites and their ISP connections. On top of this I run iBGP. At the main site I run ospf internally and redistribute between ospf and bgp.

I am working on adding an Azure cloud network into the mix as a 4th site. I will be setting up BGP there to peer with site 1 and 2 and maybe site 3.

The problem that I have at the moment is that at site 2, I am unable to get bgp routes in ospf on the switch. Config is:

ASA:

Code Select Expand

router bgp 65000
bgp log-neighbor-changes
bgp router-id 192.168.48.2
address-family ipv4 unicast
  neighbor 192.168.49.4 remote-as 65000
  neighbor 192.168.49.4 timers 5 15
  neighbor 192.168.49.4 activate
  neighbor 192.168.49.4 next-hop-self
  network 192.168.48.0 mask 255.255.240.0
  redistribute ospf 1 metric 115 match internal external 2
  no auto-summary
  no synchronization
exit-address-family

Code Select Expand

router ospf 1
router-id 192.168.48.2
network 192.168.48.0 255.255.255.0 area 0
area 0
log-adj-changes
redistribute bgp 65000 metric 115 subnets

Switch:

Code Select Expand

router ospf 1
router-id 192.168.48.1
passive-interface default
no passive-interface Vlan48
network 192.168.48.0 0.0.15.255 area 0



My issue is, adding / removing this command on the ASA appears to do nothing at all

Code Select Expand

router ospf 1
redistribute bgp 65000 metric 115 subnets

I've tried variations of the command, such as removing "subnets" and removing the metric, or adding a metric-type. At the same time I ran a wireshark capture and I can see no update from the ASA to include any BGP-learned nets.

As another test, I told the ASA to redistribute static routes into ospf. The switch learns them immediately and I can see them in the packet capture being sent to the switch in the LSA.

It's a puzzle, as I have an asa5515-x doing this exact setup albeit with a nexus 3k on the inside. I copied the working config initially...

I did have an issue at the start.. OSPF wouldnt come up and the ASA was logging bad TLV. To fix this I had to configure the IOS-XE switch with "ip ospf lls disable" on the interface that connects to the ASA.

Has anyone come across this? This threw me.

[icecream-guy]

code version differences?

[deanwebb]

code version differences?

That's what I'm coming up with. What are the versions on the ASAs? I'd also blame java, but this is all CLI stuff, so no go on that...

[Dieselboy]

I had the same thought, so I installed the same ASA version but no change, same issue. 

[icecream-guy]

what version of code?   
did you check for bugs @ cisco.com?
are there bgp routes on the firewall?
maybe a route-map ?

Code Select Expand


route-map Connected permit 1
match ip address prefix-list blah-blah-blah
match interface outside
!
!
router ospf 1
router-id 1.2.3.4.5.6
network 1.2.3.4.5.0 255.255.255.240 area 0
log-adj-changes
redistribute static metric 1 subnets route-map Connected


[Dieselboy]

I've tried ASA 9.8.2 and 9.8.3 on this 5516-X.

No I didnt check for bugs yet, although I should have done this last week.

Yes - BGP is up on the ASA:

Code Select Expand

5516-1# sh bgp sum
BGP router identifier 192.168.48.2, local AS number 65000
BGP table version is 80, main routing table version 80
20 network entries using 4000 bytes of memory
20 path entries using 1600 bytes of memory
7/7 BGP path/bestpath attribute entries using 1456 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7080 total bytes of memory
BGP activity 20/0 prefixes, 49/29 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.49.4    4        65000 11909   11868         80    0    0 16:52:13  17
192.168.50.4    4        65000 0       0              1    0    0 never  Idle

Code Select Expand

5516-1# show route bgp

Gateway of last resort is 115.70.192.124 to network 0.0.0.0

B        192.168.2.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.3.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.4.0 255.255.255.0 [200/0] via 192.168.49.4, 16:51:43
B        192.168.5.0 255.255.255.0 [200/0] via 192.168.49.4, 16:51:43
B        192.168.7.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.8.0 255.255.255.0 [200/0] via 192.168.49.4, 16:51:43
B        192.168.10.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.11.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.12.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.15.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.16.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.20.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.22.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.27.0 255.255.255.0 [200/115] via 192.168.49.4, 16:51:43
B        192.168.96.0 255.255.240.0 [200/0] via 192.168.49.4, 00:05:47
B        192.168.112.0 255.255.254.0 [200/0] via 192.168.49.4, 16:51:44



I did have the idea to allow the routes through a route-map, but I understood that the function of the route-map is to restrict routes. So I didnt try it..

[deanwebb]

Do you have a router at the 5516 site that you can test with? If the router sets things up properly, then the issue is the ASA somewhere. If it doesn't, then there's something in the last mile, possibly, that's interfering with the traffic.

That being said, can you manually send traffic on the correct ports to the 5516? If it doesn't get through, maybe you don't need that test router, you have your answer in the last mile somewhere.

[icecream-guy]

probbly needs to nat that TCP/179 traffic to protocol OSPFIGP/224.0.0.5 on the firewall

[Dieselboy]

Thanks for your help on this. I had only done this once before and must have forgotten that I needed to tell BGP on the ASA not to block redistribution. The command I needed was:

Code Select Expand

router bgp 65000
bgp log-neighbor-changes
address-family ipv4 unicast
bgp redistribute-internal  <-------this

I have this set on the main site ASA and it was missing on the other ASA. As soon as I put this in, redistribution worked as expected.

probbly needs to nat that TCP/179 traffic to protocol OSPFIGP/224.0.0.5 on the firewall

🙈🙈 I was going to make another post the other week. I was labbing / trying to use NAT to allow me to have a duplicate subnet at the DR site and allow it to function for internet access at least. My goal was to allow this /24 subnet at the remote site, but avoid the routing issue that occurs because the network will try to route locally to the local subnet, but the real subnet should be reached over a VPN tunnel. I almost got it working but fell on the last hurdle To try and explain it:

1. main site configured with 192.168.7.0/24 on the LAN
2. remote site configured with 192.168.7.0/24 on the LAN within a VRF
3. both sites have an ASA for the VPN (ie no VRF aware)
4. at the remote site, when the system at 192.168.7.100 tries to reach the internet 1.1.1.1, I configured this to happen: (beware it's messy but I Wanted to see if it would work)
- packet arrives at ASA with source: 192.168.7.100 and dest. 1.1.1.1
- ASA has route-map to redirect the source of 192.168.7.0/24 to through the "next hop" back to the LAN switch in the VRF
-- ASA simultaneously NATs source to 192.168.57.100.
- packet arrives back at the switch with source: 192.168.57.100 and dest 1.1.1.1
- switch goes WTF and sends it back to the ASA based on 1.1.1.1 routing
- packet arrives back at the ASA again with the new source and the packet gets routed out to the internet.
-- ASA PATs the traffic and the source is natted again to the public IP. Source 115.x.x.x and dest 1.1.1.1
- 1.1.1.1 replies and the traffic arrives back at the ASA,
- ASA matches the flow and the destination is NATted: source 1.1.1.1 dest. 192.168.57.100

... I can't remember exactly what I did here at this point, but the final hurdle was the packet being on the ASA with a destination of 192.168.7.100 and the ASA logging "failed to locate egress interface for 192.168.7.100". Was a fun experience.