Hi Gongyayu,
Thanks for checking this. Correct! those are know as LSA type 1 or Router LSA's. however the expectation is to see those 3 LSA's (identified by red box in your comment) only after sham-link is turned up in the instance. this is not the case in my lab. I do see similar LSA's before and after the change. the only diff I notice is the "Len" column changes from 48 to 72 for these 4 LSA's.
BEFORE sham-link:
root@R8# run show ospf database instance C1
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.30.5.17 172.30.5.17 0x80000009 732 0x22 0x118 48
Router 172.30.5.21 172.30.5.21 0x80000009 733 0x22 0x798b 48
Router 172.30.5.29 172.30.5.29 0x80000008 736 0x22 0xcc09 48
Router *172.30.5.37 172.30.5.37 0x80000011 370 0x22 0xabf8 48
AFTER shan-link:
root@R8# run show ospf database instance C1
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.30.5.17 172.30.5.17 0x8000000c 28 0x22 0x70b7 72
Router 172.30.5.21 172.30.5.21 0x8000000d 25 0x22 0x36e4 72
Router 172.30.5.29 172.30.5.29 0x8000000d 28 0x22 0x203e 72
Router *172.30.5.37 172.30.5.37 0x80000016 27 0x22 0xdc60 72
here is an extensive output of the LSA shown above, generated by the same router (R8).
I see the difference but I dont think I quite understand it.
root@R8# run show ospf database instance C1 router advertising-router 172.30.5.37 extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.30.5.37 172.30.5.37 0x80000017 200 0x22 0x9ffe 48
bits 0x1, link count 2
id 192.168.0.94, data 192.168.0.93, Type Transit (2)
Topology count: 0, Default metric: 1
id 172.30.5.37, data 255.255.255.255, Type Stub (3)
Topology count: 0, Default metric: 0
Topology default (ID 0)
Type: Transit, Node ID: 192.168.0.94
Metric: 1, Bidirectional
Gen timer 00:46:40
Aging timer 00:56:40
Installed 00:03:20 ago, expires in 00:56:40, sent 00:03:20 ago
Last changed 00:03:20 ago, Change count: 15, Ours
[edit]
root@R8# commit
commit complete
[edit]
root@R8# run show ospf database instance C1 router advertising-router 172.30.5.37 extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.30.5.37 172.30.5.37 0x8000001c 46 0x22 0xd066 72
bits 0x1, link count 4
id 192.168.0.94, data 192.168.0.93, Type Transit (2)
Topology count: 0, Default metric: 1
id 172.30.5.17, data 128.1.0.0, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.30.5.21, data 128.1.0.1, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.30.5.29, data 128.1.0.2, Type PointToPoint (1)
Topology count: 0, Default metric: 1
Topology default (ID 0)
Type: PointToPoint, Node ID: 172.30.5.29
Metric: 1, Bidirectional
Type: PointToPoint, Node ID: 172.30.5.21
Metric: 1, Bidirectional
Type: PointToPoint, Node ID: 172.30.5.17
Metric: 1, Bidirectional
Type: Transit, Node ID: 192.168.0.94
Metric: 1, Bidirectional
Gen timer 00:49:14
Aging timer 00:59:14
Installed 00:00:46 ago, expires in 00:59:14, sent 00:00:46 ago
Last changed 00:00:46 ago, Change count: 19, Ours
Original Message:
Sent: 06-18-2021 17:16
From: Unknown User
Subject: OSPF Sham-link in L3VPN
I think the following inside the red is what Type 1 refers to. Am I right ?
If you remove the sham-link, those three lines should be gone. I think.
If you configure super area 0, those entries should be type 3, or you have to export from bgp to ospf to get type 5. I might be wrong. Hopefully someone else can help to clarify for us.
thanks !!
Original Message:
Sent: 06-16-2021 09:11
From: Unknown User
Subject: OSPF Sham-link in L3VPN
Hello! I am following JNCIE-SP self study bundle and one of the task requirements in L3VPN chapter states "Make sure that the customer C1 OSPF area 0 appears as a contiguous area without ABRs." this indirectly hinting inter-area traffic vs intra-area and I understand that. the solution provided by workbook is the sham-link within L3VPN, no issues so far. here is my confusion, why dont I see any change in ospf db when this change is made?
self-study workbook shows difference when comparing databases from before and after the change. the difference is the far end lo0.1 IPs not being present in database before establishing sham-links. when checking my lab I dont see that behavior, I see some differences but I dont think I fully understand them.
This lab is running on vMX 20.1. I basically want to understand if Im doing something wrong, or if this behavior is expected on junos 20.x?
Quick background for those who dont have access to the bundle: there are 4 PE routers handling L3VPN with OSPF as PE-CE. below is a snapshot of one of those routers which shows database before the change, the change I committed and database after the change.
after this change, the workbook indicates issue is fixed by this statement: "The LSA Type 1 from other PEs are now present in the OSPF database via the sham links. " but we see LSA type 1 prior to this change as well. what am I missing?
can someone clarify this for me please? Thanks in advance
#####DATABASE BEFORE CHANGE#####root@R8# run show ospf database instance C1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.30.5.17 172.30.5.17 0x80000024 19 0x22 0xca33 48Router 172.30.5.21 172.30.5.21 0x8000001e 21 0x22 0x4fa0 48Router 172.30.5.29 172.30.5.29 0x80000020 23 0x22 0x9c21 48Router *172.30.5.37 172.30.5.37 0x80000029 17 0x22 0x7b11 48Router 172.31.63.1 172.31.63.1 0x80000038 50 0x22 0xaa62 72Router 172.31.63.2 172.31.63.2 0x80000039 49 0x22 0xb91d 120Router 172.31.63.3 172.31.63.3 0x8000003e 60 0x22 0xf6a5 120Router 172.31.63.4 172.31.63.4 0x8000003d 62 0x22 0x7f6d 72Router 172.31.63.5 172.31.63.5 0x80000031 1925 0x22 0xe47c 84Network 192.168.0.70 172.31.63.2 0x80000001 49 0x22 0x4f43 32Network 192.168.0.74 172.31.63.3 0x80000001 60 0x22 0x6325 32Network 192.168.0.86 172.31.63.4 0x80000001 62 0x22 0x5f13 32Network 192.168.0.94 172.31.63.1 0x80000001 50 0x22 0x73f4 32##### ABOUT TO COMMIT THIS CHANGE########## .37 is lo0.1 which is part of C1 instance########## other IPs are lo0.1 on other PE routers#####root@R8# show | compare [edit routing-instances C1 protocols ospf area 0.0.0.0]+ sham-link-remote 172.30.5.17;+ sham-link-remote 172.30.5.21;+ sham-link-remote 172.30.5.29;[edit routing-instances C1 protocols ospf]+ sham-link local 172.30.5.37;#####Current local ospf peer#####root@R8# run show ospf neighbor instance C1 Address Interface State ID Pri Dead192.168.0.94 ge-0/0/5.324 Full 172.31.63.1 128 30[edit]root@R8# commit commit complete[edit]root@R8# run show ospf neighbor instance C1 Address Interface State ID Pri Dead192.168.0.94 ge-0/0/5.324 Full 172.31.63.1 128 37172.30.5.17 shamlink.0 Full 172.30.5.17 0 31172.30.5.21 shamlink.1 Full 172.30.5.21 0 30172.30.5.29 shamlink.2 Full 172.30.5.29 0 38[edit]root@R8# run show ospf database instance C1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.30.5.17 172.30.5.17 0x80000028 11 0x22 0x38d3 72Router 172.30.5.21 172.30.5.21 0x80000022 14 0x22 0xcf9 72Router 172.30.5.29 172.30.5.29 0x80000024 13 0x22 0xf155 72Router *172.30.5.37 172.30.5.37 0x8000002e 7 0x22 0xac78 72Router 172.31.63.1 172.31.63.1 0x80000038 253 0x22 0xaa62 72Router 172.31.63.2 172.31.63.2 0x80000039 252 0x22 0xb91d 120Router 172.31.63.3 172.31.63.3 0x8000003e 263 0x22 0xf6a5 120Router 172.31.63.4 172.31.63.4 0x8000003d 265 0x22 0x7f6d 72Router 172.31.63.5 172.31.63.5 0x80000031 2128 0x22 0xe47c 84Network 192.168.0.70 172.31.63.2 0x80000001 252 0x22 0x4f43 32Network 192.168.0.74 172.31.63.3 0x80000001 263 0x22 0x6325 32Network 192.168.0.86 172.31.63.4 0x80000001 265 0x22 0x5f13 32Network 192.168.0.94 172.31.63.1 0x80000001 253 0x22 0x73f4 32[edit]root@R8# #####Copy of the instance for refrence#####root@R8# show routing-instances C1 protocols { ospf { area 0.0.0.0 { sham-link-remote 172.30.5.17; sham-link-remote 172.30.5.21; sham-link-remote 172.30.5.29; interface all; } sham-link local 172.30.5.37; }}instance-type vrf;interface ge-0/0/5.324;interface lo0.1;vrf-target target:54591:100;