Isn't ospf ban an ABR to flood lsa3 to a non-backbone area?
hi community, I got some confused of ospf lsa3. topology: h1 -- r1 --a12-- r2 --a0-- r3 --a34-- r4 -- h4 | | +---a23 ---+ I am using mininet to emulate the above environment. Here are the topo desc: area 12: r1(intf:r1r2) and r2(intf:r2r1) , connected network: 10.0.12.0/30 area 0: r2(intf:r20r30) and r3(intf:r30r20), connected network: 10.0.23.0/30 area 23: r2(intf:r2r3) and r3(intf:r3r2), connected network: 10.0.23.4/30 area 34: r3(intf:r3r4) and r4(intf:r4r3), connected network: 10.0.34.0/30 r1 has a stub net: 10.0.1.0/254, connected to a host, h1 r4 has a stub net: 10.0.4.0/254, connected to a host, h4 my question is: why r2/r3 generated lsa3 and advertise on area 23, isn't it prohibited ABR to flood lsa3 to non-backbone area? r2 ``` # show ip ospf database Summary Link States (Area 0.0.0.23) Link ID ADV Router Age Seq# CkSum Route 10.0.0.1 10.0.0.2 448 0x80000001 0xdc5f 10.0.0.1/32 10.0.0.1 10.0.0.3 449 0x80000001 0x3bf5 10.0.0.1/32 10.0.0.2 10.0.0.2 498 0x80000001 0x6ed6 10.0.0.2/32 10.0.0.2 10.0.0.3 449 0x80000001 0xcc6d 10.0.0.2/32 10.0.0.3 10.0.0.2 448 0x80000001 0xc871 10.0.0.3/32 10.0.0.3 10.0.0.3 498 0x80000001 0x5ee4 10.0.0.3/32 10.0.0.4 10.0.0.2 128 0x80000001 0x230c 10.0.0.4/32 10.0.0.4 10.0.0.3 129 0x80000001 0xb87f 10.0.0.4/32 10.0.1.0 10.0.0.2 448 0x80000001 0x40f1 10.0.1.0/24 10.0.1.0 10.0.0.3 449 0x80000001 0x9e88 10.0.1.0/24 10.0.4.0 10.0.0.2 128 0x80000001 0x83a1 10.0.4.0/24 10.0.4.0 10.0.0.3 129 0x80000001 0x1915 10.0.4.0/24 10.0.12.0 10.0.0.2 498 0x80000001 0x50e3 10.0.12.0/30 10.0.12.0 10.0.0.3 449 0x80000001 0xae7a 10.0.12.0/30 10.0.23.0 10.0.0.2 498 0x80000001 0xd652 10.0.23.0/30 10.0.23.0 10.0.0.3 498 0x80000001 0xd057 10.0.23.0/30 10.0.34.0 10.0.0.2 448 0x80000001 0xc152 10.0.34.0/30 10.0.34.0 10.0.0.3 498 0x80000001 0x57c5 10.0.34.0/30 ``` any idea?
Alfie, See inline.
On May 7, 2024, at 18:25, chan alfie <zlinuxboy@outlook.com> wrote:
hi community,
I got some confused of ospf lsa3.
topology:
h1 -- r1 --a12-- r2 --a0-- r3 --a34-- r4 -- h4 | | +---a23 ---+
I am using mininet to emulate the above environment. Here are the topo desc:
area 12: r1(intf:r1r2) and r2(intf:r2r1) , connected network: 10.0.12.0/30
area 0: r2(intf:r20r30) and r3(intf:r30r20), connected network: 10.0.23.0/30
area 23: r2(intf:r2r3) and r3(intf:r3r2), connected network: 10.0.23.4/30
area 34: r3(intf:r3r4) and r4(intf:r4r3), connected network: 10.0.34.0/30
r1 has a stub net: 10.0.1.0/254, connected to a host, h1 r4 has a stub net: 10.0.4.0/254, connected to a host, h4
my question is:
why r2/r3 generated lsa3 and advertise on area 23, isn't it prohibited ABR to flood lsa3 to non-backbone areas.
No - the ABRs only use the summaries in the backbone area to calculate inter-area routes (although FRR OSPF does support alternate ABR behavior but you have to configure it). ABRs will originate summaries for reachable routes into all areas EXCEPT the area where the route is learned. In this case, the stub network routes are either leaned via an attached area or the backbone - note area 23. Refer to RFC 2328 Section 12.4.3. Hope this helps, Acee
r2 ``` # show ip ospf database
Summary Link States (Area 0.0.0.23)
Link ID ADV Router Age Seq# CkSum Route 10.0.0.1 10.0.0.2 448 0x80000001 0xdc5f 10.0.0.1/32 10.0.0.1 10.0.0.3 449 0x80000001 0x3bf5 10.0.0.1/32 10.0.0.2 10.0.0.2 498 0x80000001 0x6ed6 10.0.0.2/32 10.0.0.2 10.0.0.3 449 0x80000001 0xcc6d 10.0.0.2/32 10.0.0.3 10.0.0.2 448 0x80000001 0xc871 10.0.0.3/32 10.0.0.3 10.0.0.3 498 0x80000001 0x5ee4 10.0.0.3/32 10.0.0.4 10.0.0.2 128 0x80000001 0x230c 10.0.0.4/32 10.0.0.4 10.0.0.3 129 0x80000001 0xb87f 10.0.0.4/32 10.0.1.0 10.0.0.2 448 0x80000001 0x40f1 10.0.1.0/24 10.0.1.0 10.0.0.3 449 0x80000001 0x9e88 10.0.1.0/24 10.0.4.0 10.0.0.2 128 0x80000001 0x83a1 10.0.4.0/24 10.0.4.0 10.0.0.3 129 0x80000001 0x1915 10.0.4.0/24 10.0.12.0 10.0.0.2 498 0x80000001 0x50e3 10.0.12.0/30 10.0.12.0 10.0.0.3 449 0x80000001 0xae7a 10.0.12.0/30 10.0.23.0 10.0.0.2 498 0x80000001 0xd652 10.0.23.0/30 10.0.23.0 10.0.0.3 498 0x80000001 0xd057 10.0.23.0/30 10.0.34.0 10.0.0.2 448 0x80000001 0xc152 10.0.34.0/30 10.0.34.0 10.0.0.3 498 0x80000001 0x57c5 10.0.34.0/30 ```
any idea? _______________________________________________ frog mailing list frog@lists.frrouting.org <mailto:frog@lists.frrouting.org> https://lists.frrouting.org/listinfo/frog
Thank you sir. Your explanation help me a lot. ________________________________ 发件人: Acee Lindem <acee.lindem@gmail.com> 发送时间: 2024年5月8日 7:43 收件人: chan alfie <zlinuxboy@outlook.com> 抄送: frog@lists.frrouting.org <frog@lists.frrouting.org> 主题: Re: [FROG] Isn't ospf ban an ABR to flood lsa3 to a non-backbone area? Alfie, See inline. On May 7, 2024, at 18:25, chan alfie <zlinuxboy@outlook.com> wrote: hi community, I got some confused of ospf lsa3. topology: h1 -- r1 --a12-- r2 --a0-- r3 --a34-- r4 -- h4 | | +---a23 ---+ I am using mininet to emulate the above environment. Here are the topo desc: area 12: r1(intf:r1r2) and r2(intf:r2r1) , connected network: 10.0.12.0/30 area 0: r2(intf:r20r30) and r3(intf:r30r20), connected network: 10.0.23.0/30 area 23: r2(intf:r2r3) and r3(intf:r3r2), connected network: 10.0.23.4/30 area 34: r3(intf:r3r4) and r4(intf:r4r3), connected network: 10.0.34.0/30 r1 has a stub net: 10.0.1.0/254, connected to a host, h1 r4 has a stub net: 10.0.4.0/254, connected to a host, h4 my question is: why r2/r3 generated lsa3 and advertise on area 23, isn't it prohibited ABR to flood lsa3 to non-backbone areas. No - the ABRs only use the summaries in the backbone area to calculate inter-area routes (although FRR OSPF does support alternate ABR behavior but you have to configure it). ABRs will originate summaries for reachable routes into all areas EXCEPT the area where the route is learned. In this case, the stub network routes are either leaned via an attached area or the backbone - note area 23. Refer to RFC 2328 Section 12.4.3. Hope this helps, Acee r2 ``` # show ip ospf database Summary Link States (Area 0.0.0.23) Link ID ADV Router Age Seq# CkSum Route 10.0.0.1 10.0.0.2 448 0x80000001 0xdc5f 10.0.0.1/32 10.0.0.1 10.0.0.3 449 0x80000001 0x3bf5 10.0.0.1/32 10.0.0.2 10.0.0.2 498 0x80000001 0x6ed6 10.0.0.2/32 10.0.0.2 10.0.0.3 449 0x80000001 0xcc6d 10.0.0.2/32 10.0.0.3 10.0.0.2 448 0x80000001 0xc871 10.0.0.3/32 10.0.0.3 10.0.0.3 498 0x80000001 0x5ee4 10.0.0.3/32 10.0.0.4 10.0.0.2 128 0x80000001 0x230c 10.0.0.4/32 10.0.0.4 10.0.0.3 129 0x80000001 0xb87f 10.0.0.4/32 10.0.1.0 10.0.0.2 448 0x80000001 0x40f1 10.0.1.0/24 10.0.1.0 10.0.0.3 449 0x80000001 0x9e88 10.0.1.0/24 10.0.4.0 10.0.0.2 128 0x80000001 0x83a1 10.0.4.0/24 10.0.4.0 10.0.0.3 129 0x80000001 0x1915 10.0.4.0/24 10.0.12.0 10.0.0.2 498 0x80000001 0x50e3 10.0.12.0/30 10.0.12.0 10.0.0.3 449 0x80000001 0xae7a 10.0.12.0/30 10.0.23.0 10.0.0.2 498 0x80000001 0xd652 10.0.23.0/30 10.0.23.0 10.0.0.3 498 0x80000001 0xd057 10.0.23.0/30 10.0.34.0 10.0.0.2 448 0x80000001 0xc152 10.0.34.0/30 10.0.34.0 10.0.0.3 498 0x80000001 0x57c5 10.0.34.0/30 ``` any idea? _______________________________________________ frog mailing list frog@lists.frrouting.org<mailto:frog@lists.frrouting.org> https://lists.frrouting.org/listinfo/frog
participants (2)
-
Acee Lindem -
chan alfie