Open MintLife619 opened 1 year ago
Supplement: After adding L1 devices, except for loopback address, the interface address also cannot be announced to L2. Basically, if all routers are configured with L1-2 or L2, they can be connected.
Can you capture the routing table for each of the routers?
Of course, the following is the routing table of all routers:
AR1:
AR1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
I>* 0.0.0.0/0 [115/10] via 12.1.1.2, eth0, weight 1, 00:08:03
C>* 1.1.1.1/32 is directly connected, lo, 00:08:34
I>* 2.2.2.2/32 [115/20] via 12.1.1.2, eth0, weight 1, 00:08:03
I 12.1.1.0/24 [115/20] via 12.1.1.2, eth0 inactive, weight 1, 00:08:03
C>* 12.1.1.0/24 is directly connected, eth0, 00:08:36
I>* 23.1.1.0/24 [115/20] via 12.1.1.2, eth0, weight 1, 00:08:03
AR2:
AR2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
I>* 1.1.1.1/32 [115/20] via 12.1.1.1, eth0, weight 1, 00:09:07
C>* 2.2.2.2/32 is directly connected, lo, 00:09:37
I>* 3.3.3.3/32 [115/20] via 23.1.1.2, eth1, weight 1, 00:09:07
I>* 4.4.4.4/32 [115/30] via 23.1.1.2, eth1, weight 1, 00:09:06
I 12.1.1.0/24 [115/20] via 12.1.1.1, eth0 inactive, weight 1, 00:09:07
C>* 12.1.1.0/24 is directly connected, eth0, 00:09:38
C>* 23.1.1.0/24 is directly connected, eth1, 00:09:38
I>* 34.1.1.0/24 [115/20] via 23.1.1.2, eth1, weight 1, 00:09:07
I>* 45.1.1.0/24 [115/30] via 23.1.1.2, eth1, weight 1, 00:09:06
AR3:
AR3# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
I>* 2.2.2.2/32 [115/20] via 23.1.1.1, eth0, weight 1, 00:10:10
C>* 3.3.3.3/32 is directly connected, lo, 00:10:41
I>* 4.4.4.4/32 [115/20] via 34.1.1.2, eth1, weight 1, 00:10:10
I>* 12.1.1.0/24 [115/20] via 23.1.1.1, eth0, weight 1, 00:10:10
I 23.1.1.0/24 [115/20] via 23.1.1.1, eth0 inactive, weight 1, 00:10:10
C>* 23.1.1.0/24 is directly connected, eth0, 00:10:42
I 34.1.1.0/24 [115/20] via 34.1.1.2, eth1 inactive, weight 1, 00:10:10
C>* 34.1.1.0/24 is directly connected, eth1, 00:10:42
I>* 45.1.1.0/24 [115/20] via 34.1.1.2, eth1, weight 1, 00:10:10
AR4:
AR4# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
I>* 2.2.2.2/32 [115/30] via 34.1.1.1, eth0, weight 1, 00:10:43
I>* 3.3.3.3/32 [115/20] via 34.1.1.1, eth0, weight 1, 00:10:43
C>* 4.4.4.4/32 is directly connected, lo, 00:11:14
I>* 5.5.5.5/32 [115/20] via 45.1.1.2, eth1, weight 1, 00:10:43
I>* 12.1.1.0/24 [115/30] via 34.1.1.1, eth0, weight 1, 00:10:43
I>* 23.1.1.0/24 [115/20] via 34.1.1.1, eth0, weight 1, 00:10:43
C>* 34.1.1.0/24 is directly connected, eth0, 00:11:16
I 45.1.1.0/24 [115/20] via 45.1.1.2, eth1 inactive, weight 1, 00:10:43
C>* 45.1.1.0/24 is directly connected, eth1, 00:11:16
AR5:
AR5# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
I>* 0.0.0.0/0 [115/10] via 45.1.1.1, eth0, weight 1, 00:11:14
I>* 4.4.4.4/32 [115/20] via 45.1.1.1, eth0, weight 1, 00:11:15
C>* 5.5.5.5/32 is directly connected, lo, 00:11:45
I>* 34.1.1.0/24 [115/20] via 45.1.1.1, eth0, weight 1, 00:11:15
I 45.1.1.0/24 [115/20] via 45.1.1.1, eth0 inactive, weight 1, 00:11:15
C>* 45.1.1.0/24 is directly connected, eth0, 00:11:47
Hi,
I'm not sure that IS-IS within FRR supports this configuration i.e. L1 to L2 redistribution and vis versa even if it is possible as per RFCs.
Olivier
Hi, thanks for the reply. I don't seem to find the instructions for the isis protocol redistribution in the official documentation, but this is available on other vendors' devices such as Cisco.
Same issue & same comments
I have seen this too. Duplicated the issue of L1 PDU information not being imported into L2 PDUs. Here's the link under VyOS showing the topology. In there we have an end user showing it, and my own testing in my own lab showing it too.
https://forum.vyos.io/t/is-is-no-network-migration-from-level-1-to-level-2-database/11990
here there is another case related this wrong behavior :
ISIS L1-2 router with FRR installed cannot advertise the route from Level-1 to Level-2
[√] Did you check if this is a duplicate issue? [√] Did you test it on the latest FRRouting/frr master branch?
To Reproduce Steps to reproduce the behavior:
1. Virtual bridges are used to connect containers with frr to form a network. 2. Open the ISIS daemon in the container (router) where the ISIS protocol needs to be deployed. 3. Configure the protocol. The interface connected with L1 domain is set as "isis circuit-type level-1" and the interface connected with L2 domain is set as "isis circuit-type level-2". 4. Perform connectivity test.
Expected behavior Different ISIS regions should be able to connect with each other.
Versions
Additional context The Network topology diagram: AR1(L1) --- AR2(L1/2) --- AR3(L2) --- AR4(L1/2) --- AR5(L1)
logs and captures show running-config: AR1:
AR2:
AR3:
AR4 and AR5 are similar to AR1 and AR2.
show isis databases: AR1 database:
AR2 database:
AR3 database:
AR4 database:
AR5 database:
Problem: