search

ipspace / netlab

Making virtual networking labs suck less
https://netlab.tools
Other
455 stars 68 forks source link

[BUG] Dell OS10: Route leaking BGP<->OSPF is not working #1135

Open ssasso opened 6 months ago

ssasso commented 6 months ago 
core1# show running-configuration
!
[cut]
!
ip vrf blue
 ip route-export 65000:2
 ip route-import 65000:2
 ip route-import 65000:1
!
ip vrf common
 ip route-export 65000:1
 ip route-import 65000:3
 ip route-import 65000:2
 ip route-import 65000:1
!
ip vrf red
 ip route-export 65000:3
 ip route-import 65000:3
 ip route-import 65000:1
!
[cut]
!
router ospf 102 vrf red
 redistribute bgp 65000
 redistribute connected
 router-id 10.0.0.1
!
[cut]
!
router bgp 65000
 router-id 10.0.0.1
 !
 address-family ipv4 unicast
  network 10.0.0.1/32
 !
 template unnumbered_ebgp
 !
 vrf blue
  router-id 10.0.0.1
  !
  address-family ipv4 unicast
   redistribute connected
  !
  neighbor 10.1.0.5
   description aggr2
   remote-as 65111
   send-community standard
   no shutdown
   !
   address-family ipv4 unicast
    soft-reconfiguration inbound
   !
   address-family ipv6 unicast
 !
 vrf common
  router-id 10.0.0.1
  !
  address-family ipv4 unicast
   redistribute connected
 !
 vrf red
  router-id 10.0.0.1
  !
  address-family ipv4 unicast
   redistribute connected
   redistribute ospf 102

BUT

core1# show ip route vrf common
Codes: C - connected
       S - static
       B - BGP, IN - internal BGP, EX - external BGP, EV - EVPN BGP
       O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
       E2 - OSPF external type 2, * - candidate default,
       + - summary route, > - non-active route
Gateway of last resort is not set
  Destination                 Gateway                                        Dist/Metric       Last Change
----------------------------------------------------------------------------------------------------------
  B  EX 10.0.0.3/32         via 10.1.0.5,blue                                20/0              00:10:04
  C     10.1.0.0/30         via 10.1.0.2,red         ethernet1/1/1           0/0               00:10:38
  C     10.1.0.4/30         via 10.1.0.6,blue        ethernet1/1/2           0/0               00:10:42
  B  EX 100.64.0.0/24       via 10.1.0.5,blue                                20/0              00:10:04
  B  EX 172.16.1.0/24       via 10.1.0.5,blue                                20/0              00:10:04
  C     172.16.2.0/24       via 172.16.2.1           ethernet1/1/3           0/0               00:11:00
core1# show ip route vrf red
Codes: C - connected
       S - static
       B - BGP, IN - internal BGP, EX - external BGP, EV - EVPN BGP
       O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
       E2 - OSPF external type 2, * - candidate default,
       + - summary route, > - non-active route
Gateway of last resort is not set
  Destination                 Gateway                                        Dist/Metric       Last Change
----------------------------------------------------------------------------------------------------------
  O     10.0.0.2/32         via 10.1.0.1             ethernet1/1/1           110/5             00:10:04
  C     10.1.0.0/30         via 10.1.0.2             ethernet1/1/1           0/0               00:11:08
  O     172.16.0.0/24       via 10.1.0.1             ethernet1/1/1           110/26            00:10:04
  C     172.16.2.0/24       via 172.16.2.1,common    ethernet1/1/3           0/0               00:10:45

Need to understand if it's a device limitation, or a configuration issue.

ssasso commented 6 months ago

From OS10 manual:

OS10 supports leaking routes for static and dynamic routes. The leaked routes retain the type of the route, whether they are
static, OSPF, BGP, or connected routes in the destination VRF. For example, leaked OSPF routes from one VRF are imported as
OSPF routes in the destination VRF.

and

An active OSPF session
is not required to
honor the leaked OSPF
routes in the child VRF.
Configuration of OSPFv2
instance in the child VRF
is sufficient for the route
leaking feature to install
the routes in RTM.

(and the same for OSPFv3)

So, it seems I need a workaround to configure OSPF (v2 or v3) instances on the destination VRFs even if there is no OSPF sessions.

ssasso commented 6 months ago

Confirmed - adding:

router ospf 100 vrf common
 redistribute bgp 65000
 redistribute connected

will result in:

core1# show ip route vrf common
Codes: C - connected
       S - static
       B - BGP, IN - internal BGP, EX - external BGP, EV - EVPN BGP
       O - OSPF, IA - OSPF inter area, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
       E2 - OSPF external type 2, * - candidate default,
       + - summary route, > - non-active route
Gateway of last resort is not set
  Destination                 Gateway                                        Dist/Metric       Last Change
----------------------------------------------------------------------------------------------------------
  O     10.0.0.2/32         via 10.1.0.1,red         ethernet1/1/1           110/5             00:01:47
  B  EX 10.0.0.3/32         via 10.1.0.5,blue                                20/0              00:09:26
  C     10.1.0.0/30         via 10.1.0.2,red         ethernet1/1/1           0/0               00:10:00
  C     10.1.0.4/30         via 10.1.0.6,blue        ethernet1/1/2           0/0               00:10:05
  B  EX 100.64.0.0/24       via 10.1.0.5,blue                                20/0              00:09:26
  O     172.16.0.0/24       via 10.1.0.1,red         ethernet1/1/1           110/26            00:01:47
  B  EX 172.16.1.0/24       via 10.1.0.5,blue                                20/0              00:09:26
  C     172.16.2.0/24       via 172.16.2.1           ethernet1/1/3           0/0               00:10:22
ipspace commented 6 months ago

The "ingenuity" of software developers is infinite 🤦‍♂️

I guess that only applies to routes within the same device, right? We could add a device quirk to figure out what information is leaked so you wouldn't have to do that in a template, or we could call it a caveat and move on ;) I'd vote for the latter approach ;))

ssasso commented 6 months ago

The "ingenuity" of software developers is infinite 🤦‍♂️

I guess that only applies to routes within the same device, right?

And the "creativity" never ends. From the manual:

After you configure the system to leak routes from one VRF instance to another VRF instance, you can redistribute the leaked
routes to the same routing protocol. The following lists the commands that you use for redistribution of leaked routes:
● Redistribute leaked BGP routes to BGP—Use the redistribute imported-bgp-routes vrf vrf-name command.
● Redistribute leaked OSPF routes to OSPF—Use the redistribute imported-ospf-routes command.

We could add a device quirk to figure out what information is leaked so you wouldn't have to do that in a template, or we could call it a caveat and move on ;) I'd vote for the latter approach ;))

I will try to write a device quirk to handle all the cases as an exercise. If I see that this will require me too much time, I'll give up and declare the caveat ;)

ssasso commented 6 months ago

(Note to myself)

Given this topology:

---
defaults:
  device: dellos10

vrfs:
  common:
    import: [ red, blue, common ]
  blue:
    import: [ blue, common ]
  red:
    import: [ red, common ]

nodes:
  core1:
    module: [ bgp, ospf, vrf ]
    bgp.as: 65000
    id: 10
  comm1:
    module: [ ospf ]
    id: 1
  comm2:
    module: [ bgp ]
    bgp.as: 65001
    bgp.originate: [ 100.64.2.0/24 ]
    id: 2
  aggr1:
    module: [ ospf ]
    id: 11
  aggr2:
    module: [ bgp ]
    bgp.as: 65111
    bgp.originate: [ 100.64.12.0/24 ]
    id: 12

links:
- core1: { vrf: red }
  aggr1:
- core1: { vrf: blue }
  aggr2:
- core1: { vrf: common }
  comm1:
  ospf.cost: 6
- core1: { vrf: common }
  comm2:

This is what I need to configure:

! Version 10.5.6.1
! Last configuration change at May  01 08:26:51 2024
!
ip vrf blue
 ip route-export 65000:2
 ip route-import 65000:2
 ip route-import 65000:1
!
ip vrf common
 ip route-export 65000:1
 ip route-import 65000:3
 ip route-import 65000:2
 ip route-import 65000:1
!
ip vrf red
 ip route-export 65000:3
 ip route-import 65000:3
 ip route-import 65000:1
!
interface ethernet1/1/1
 description "core1 -> aggr1"
 no shutdown
 no switchport
 ip vrf forwarding red
 ip address 10.1.0.2/30
 ip ospf 102 area 0.0.0.0
 ip ospf network point-to-point
!
interface ethernet1/1/2
 description "core1 -> aggr2 [external]"
 no shutdown
 no switchport
 ip vrf forwarding blue
 ip address 10.1.0.6/30
!
interface ethernet1/1/3
 description "core1 -> comm1"
 no shutdown
 no switchport
 ip vrf forwarding common
 ip address 10.1.0.10/30
 ip ospf 100 area 0.0.0.0
 ip ospf cost 6
 ip ospf network point-to-point
!
interface ethernet1/1/4
 description "core1 -> comm2 [external]"
 no shutdown
 no switchport
 ip vrf forwarding common
 ip address 10.1.0.14/30
!
router ospf 100 vrf common
 redistribute bgp 65000
 redistribute connected
 redistribute imported-ospf-routes
 router-id 10.0.0.10
!
router ospf 102 vrf red
 redistribute bgp 65000
 redistribute connected
 redistribute imported-ospf-routes
 router-id 10.0.0.10
!
router ospf 101 vrf blue
 redistribute bgp 65000
 redistribute connected
 router-id 10.0.0.10
!
router bgp 65000
 router-id 10.0.0.10
 !
 vrf blue
  router-id 10.0.0.10
  !
  address-family ipv4 unicast
   redistribute imported-bgp-routes vrf common
   redistribute connected
   redistribute ospf 101
  !
  neighbor 10.1.0.5
   description aggr2
   remote-as 65111
   send-community standard
   no shutdown
   !
   address-family ipv4 unicast
    soft-reconfiguration inbound
   !
   address-family ipv6 unicast
 !
 vrf common
  router-id 10.0.0.10
  !
  address-family ipv4 unicast
   redistribute imported-bgp-routes vrf blue
   redistribute connected
   redistribute ospf 100
  !
  neighbor 10.1.0.13
   description comm2
   remote-as 65001
   send-community standard
   no shutdown
   !
   address-family ipv4 unicast
    soft-reconfiguration inbound
   !
   address-family ipv6 unicast
 !
 vrf red
  router-id 10.0.0.10
  !
  address-family ipv4 unicast
   redistribute connected
   redistribute ospf 102
ipspace commented 6 months ago

Can you do 'redistribute imported-ospf-routes' into BGP (and vice versa)? That would neatly solve the issue.

ssasso commented 6 months ago

Can you do 'redistribute imported-ospf-routes' into BGP (and vice versa)? That would neatly solve the issue.

nope :D

jbemmel commented 1 month ago

(Note to myself)

Given this topology:

This is what I need to configure:

! Version 10.5.6.1
! Last configuration change at May  01 08:26:51 2024
!
...
!
router ospf 100 vrf common
 redistribute bgp 65000
 redistribute connected
 redistribute imported-ospf-routes
 router-id 10.0.0.10
!
router ospf 102 vrf red
 redistribute bgp 65000
 redistribute connected
 redistribute imported-ospf-routes
 router-id 10.0.0.10
!
router ospf 101 vrf blue
 redistribute bgp 65000
 redistribute connected
 router-id 10.0.0.10
!
router bgp 65000
 router-id 10.0.0.10
 !
 vrf blue
  router-id 10.0.0.10
  !
...
 !
 vrf common
  router-id 10.0.0.10
  !

Do you really need to specify the same router-id that many times?