Hi Rob, you haven't turn off the icmp blocking below NAT in vpn0 ge0/0. But you still able to ping 1.2.3.4 from IOS13 RTR. You have turned that option Off in next video.
Hi Rob, thanks for this video it's been very useful. I've got a question if you don't mind please, this isn't strictly relevant to your topology however As the static NAT routes on edges cannot be redistributed into OMP (I really wish they could), how would you go about advertising a default route in a service VPN if you weren't learning it via routing protocol (I'm assuming your connection to ASA from edge 1&2 is in VPN1 not VPN0)? As it doesn't allow you to have both a default NAT route as well as a default static route to null0 which can be redistributed into OMP. I've managed to get it working with data policies but not convinced it's the best way (match RFC1918 address and route normally, then for everything else forward via VPN0)
The comment you make regarding the time for the connected default route to drop from the routing table has been a topic of similar lab efforts. And BFD is detecting the failure and we see removal of the impacted OMP routes well before the connected route is gone sending traffic over the available OMP route. Any thoughts on variables in play to speed this process e.g. timers or IP SLA? You mentioned it was “faster” but didnt mention the actual time which I’ve seen testing from 60 sec to 5 minutes.
No, not really. Not sure why it is so slow, interface drivers are either really slow to detect loss of carrier or vEdges aren't a good platform to test on. But that isn't an exhaustive list of reasons, likely more.
Hello Rob, Might this is a stupid question, But could you answer me, OMP peer established over transport vpn0, How OMP is able to exchanges routes in VPN 1 as these are different VRFs.
