Description
Bgp multipath test failed because the routing entries required for the test haven't injected into VM in t1-lag VMs simulating TOR.
Steps to reproduce the issue:
- Deploy the testbed in t1-lag topo.
- Run bgp-multipath test.
Describe the results you received:
Test failed:
Saturday 18 April 2020 20:31:47 +0000 (0:00:00.647) 0:00:58.724 ********
Using module file /root/mars/workspace/sonic-mgmt/ansible/library/bgp_route.py
Pipelining is enabled.
<r-tigris-13> ESTABLISH SSH CONNECTION FOR USER: admin
<r-tigris-13> SSH: EXEC sshpass -d12 ssh -o ControlMaster=auto -o ControlPersist=120s -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o StrictHostKeyChecking=no -o 'User="admin"' -o ConnectTimeout=30 -o ControlPath=/root/.ansible/cp/fe26bceb9b r-tigris-13 '/bin/sh -c '"'"'/usr/bin/python && sleep 0'"'"''
<r-tigris-13> (0, '\n{"invocation": {"module_args": {"direction": null, "prefix": "200.0.1.0/26", "neighbor": null}}, "ansible_facts": {"bgp_route": {"200.0.1.0/26": {"found": false}}}}\n', '')
ok: [r-tigris-13-t1-lag] => {
"ansible_facts": {
"bgp_route": {
"200.0.1.0/26": {
"found": false
}
}
},
"changed": false,
"invocation": {
"module_args": {
"direction": null,
"neighbor": null,
"prefix": "200.0.1.0/26"
}
}
}
This is because the routing entry 200.0.1.0/26 hasn't been injected on VM simulating TORs.
On a test bed where the testcase passes, we see:
ARISTA01T0#show ip route 200.0.1.0/26
VRF name: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service
S 200.0.1.0/26 [1/0] via 10.10.246.100, Ethernet5
ARISTA01T0#show ip bgp 200.0.1.0/26
BGP routing table information for VRF default
Router identifier 100.1.0.17, local AS number 64001
BGP routing table entry for 200.0.1.0/26
Paths: 2 available
64700
- from - (100.1.0.17)
Origin INCOMPLETE, metric 0, localpref 0, weight -, valid, local, best, redistributed (Static)
65100 64003 64700
10.0.0.32 from 10.0.0.32 (10.1.0.32)
Origin INCOMPLETE, metric 0, localpref 100, weight 0, valid, external
But on a testbed where the test fails, we see
ARISTA01T0#show ip route 200.0.1.0/26
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian
Gateway of last resort:
B E 0.0.0.0/0 [200/0] via 10.0.0.32, Ethernet1
ARISTA01T0#show ip bgp 200.0.1.0/26
BGP routing table information for VRF default
Router identifier 100.1.0.17, local AS number 64001
ARISTA01T0#
This route entry is configured by the following command
ip prefix-list test_vip_1 seq 11 permit 200.0.1.0/26
!
route-map PREPENDAS permit 21
match ip address prefix-list test_vip_1
set as-path prepend 64700
!
router bgp 64001
...
redistribute static route-map PREPENDAS
...
I see the above configuration was removed from t1-lag-spine.j2 and t1-lag-tor.j2.
Should they be added back or there should be some other way to advertise the route entry?
Describe the results you expected:
The route entry should be learnt by VM.
Additional information you deem important:
**Output of `show version`:**
```
(paste your output here)
```
**Attach debug file `sudo generate_dump`:**
```
(paste your output here)
```
Description
Bgp multipath test failed because the routing entries required for the test haven't injected into VM in t1-lag VMs simulating TOR.
Steps to reproduce the issue:
Describe the results you received:
Test failed:
This is because the routing entry 200.0.1.0/26 hasn't been injected on VM simulating TORs.
On a test bed where the testcase passes, we see:
But on a testbed where the test fails, we see
This route entry is configured by the following command
I see the above configuration was removed from
t1-lag-spine.j2andt1-lag-tor.j2.Should they be added back or there should be some other way to advertise the route entry?
Describe the results you expected:
The route entry should be learnt by VM.
Additional information you deem important: