Ingest routing table with multiple default gateway entries

[dainok]

Originally opened by @andyb2000

Spotted this one throwing up an error. In this case it's in a vrf but don't think that's relevant to the bug. The routing table has multiple default gateways via different paths (learnt via OSPF) and so it throws an exception due to duplicate key failure:

May 03 10:03:44 srvr-0040b606 NetBox[50802]: level=ERROR,logger=netbox.scripts.NetDoc.Ingest,msg=An exception occurred: `IntegrityError: duplicate key value violates unique constraint "netdoc_routetableentry_device_id_destination_di_7aa5e45e_uniq" DETAIL: Key (device_id, destination, distance, metric, protocol, vrf_id)=(1026, 0.0.0.0/0, 110, 1, oia, 143) already exists.

Output from routing table (Cisco IOS): Gateway of last resort is 192.168.1.251 to network 0.0.0.0

O*E2 0.0.0.0/0 [110/1] via 192.168.1.251, 7w0d, GigabitEthernet0/0/0.513 [110/1] via 192.168.1.250, 7w0d, GigabitEthernet0/0/0.513 10.0.0.0/8 is variably subnetted, 23 subnets, 3 masks O E2 10.0.0.0/22 [110/20] via 192.168.1.251, 7w0d, GigabitEthernet0/0/0.513 [110/20] via 192.168.1.250, 7w0d, GigabitEthernet0/0/0.513 O E2 10.0.8.0/22

In this case because there are multiple paths (2 edge routers running an hsrp default gateway into 2 switches) which then ospf talk to a router providing the default gateway (default originate) that means each router has multiple paths to the same gateway.

router1 --> switch1 --> customer device router2 --> switch2 --> customer device (same customer device) Customer device announces a default route back to router1 and router2.

Actually, now I think about it, I think this quirk is only possible in OSPF where there are two equal cost paths to the two gateways.

[dainok]

We should add nexthop_if and nexthop_ip to the unique keys. Hope it works because one or both are ussually null.

[dainok]

I'm ingesting the following without issues:

      77.0.0.0/24 is subnetted, 1 subnets
S        77.77.77.0 [1/0] via 172.2.2.72
                    [1/0] via 172.2.2.71

[dainok]

Also this seems fine:

S        77.77.77.0 [1/0] via 172.2.2.72, GigabitEthernet1/3
                    [1/0] via 172.2.2.71, GigabitEthernet1/3

@andyb2000 please could you check again?

[Lurick73]

I had a similar issue the other day but after updating to 0.10.10 release this seems to be addressed.

[dainok]

Thank you @Lurick73 (closing)