On a side note - I have seen a similar behavior with unstable ShamLink adjacencies - however this was when I had created the loopback using say a 10.10.x.x/32 address and had a network statement in OSPF along the lines of 'net 10.10.0.0 0.0.255.255 area 0' - which caused the problem.
Despite my advertising the loopback using BGP - I was creating a loop by also inadvertantly advertising them into OSPF and causing what looked like a recursive routing issue. Cheers. On Sun, Jul 26, 2009 at 9:29 AM, Con Spathas<[email protected]> wrote: > Gday Antonio, > > I've tried to re-create the issue you described below with no luck: > > 10.10.18.1/32 is the R1 loopback interface for the Sham > 10.10.18.8/32 is the R8 loopback interface for the Sham > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R1#sh ip ospf neighbor 98.9.8.8 | inc Neighbor|interface > Neighbor 98.9.8.8, interface address 10.10.18.8 > In the area 0 via interface OSPF_SL0 > Neighbor priority is 0, State is FULL, 6 state changes > Neighbor is up for 00:21:00 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R1#sh ip ospf database | beg Type-5 > Type-5 AS External Link States > > Link ID ADV Router Age Seq# Checksum Tag > 4.0.0.4 31.3.1.1 1325 0x80000001 0x009E9A 3489661053 > 10.10.18.1 98.9.8.8 1282 0x80000001 0x004D4A 3489661606 > 10.10.18.8 31.3.1.1 1279 0x80000001 0x00E82A 3489661053 > 11.0.0.11 31.3.1.1 1279 0x80000001 0x00FC2E 3489661053 > 54.5.4.0 31.3.1.1 1325 0x80000001 0x00D130 3489661053 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R1#sh ip route vrf VPNB 10.10.18.8 > Routing entry for 10.10.18.8/32 > Known via "bgp 125", distance 200, metric 0 > Tag 678, type internal > Redistributing via ospf 125 > Advertised by ospf 125 subnets > Last update from 6.7.8.8 00:21:34 ago > Routing Descriptor Blocks: > * 6.7.8.8 (Default-IP-Routing-Table), from 125.125.125.2, 00:21:34 ago > Route metric is 0, traffic share count is 1 > AS Hops 1 > Route tag 678 > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R8# > R8#sh ip ospf neighbor 31.3.1.1 | inc Neigh|inter > Neighbor 31.3.1.1, interface address 10.10.18.1 > In the area 0 via interface OSPF_SL0 > Neighbor priority is 0, State is FULL, 6 state changes > Neighbor is up for 00:22:02 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R8#sh ip ospf data | beg Type-5 > Type-5 AS External Link States > > Link ID ADV Router Age Seq# Checksum Tag > 4.0.0.4 31.3.1.1 1386 0x80000001 0x009E9A 3489661053 > 10.10.18.1 98.9.8.8 1338 0x80000001 0x004D4A 3489661606 > 10.10.18.8 31.3.1.1 1341 0x80000001 0x00E82A 3489661053 > 11.0.0.11 31.3.1.1 1 (DNA) 0x80000001 0x00FC2E 3489661053 > 54.5.4.0 31.3.1.1 1386 0x80000001 0x00D130 3489661053 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > R8#sh ip route vrf VPNB 10.10.18.1 > Routing entry for 10.10.18.1/32 > Known via "bgp 678", distance 200, metric 0 > Tag 125, type internal > Redistributing via ospf 678 > Advertised by ospf 678 subnets > Last update from 125.125.125.1 00:22:34 ago > Routing Descriptor Blocks: > * 125.125.125.1 (Default-IP-Routing-Table), from 6.7.8.7, 00:22:34 ago > Route metric is 0, traffic share count is 1 > AS Hops 1 > Route tag 125 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > As you can see the Sham-Link is stable, however I have not manipulated > the Domain-Tag as shown in the OSPF database. > > Tag 3489661606 = 11010000000000000000001010100110 > 1010100110 = AS 678 > > Tag 3489661053 = 11010000000000000000000001111101 > 1111101 = AS 125 > > I tried this with 12.0S and 12.4Mainline code. > > Cheers, > Con. > > >>I found the solution to this problem ! >> >>When we have a sham-link inside the same AS, there's no issues with routing >>loops with the sham-links because the external LSA will >>have the same route-tag. >> >>When we have a sham-link between two AS's, and the sham-links are advertised >>by >>eBGP, there's no problem because the eBGP AD is >>lower than OSPF. >> >>But when we have a sham-link between two AS's and the sham-links are >>advertised >>by iBGP, there's a routing loop. The routers will >>prefer the OSPF learned route instead of the iBGP because of lower AD. >> >>So the solution is to use the same "domain-tag" under the OSPF process in both >>PE's. >> >> >> >> >>Regards, >> >>Antonio Soares, CCIE #18473 (R&S) >>[email protected] >> >>-----Original Message----- >>From: [email protected] >>[mailto:[email protected]] On Behalf Of Antonio Soares >>Sent: segunda-feira, 8 de Junho de 2009 19:08 >>To: [email protected] >>Subject: [OSL | CCIE_SP] VOL2 - Section 1 - Task 8.2 >> >>My sham-link is flaping. As soon as the sham-link comes up, R1 and R8 start >>prefering the OSPF route instead of the iBGP route. I >>never saw this problem in regular MPLS VPNs inside one AS. In this because we >>have an Inter-AS MPLS VPN scenario ? >> >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>R1# >>00:03:31: %OSPF-5-ADJCHG: Process 39, Nbr 8.8.8.8 on OSPF_SL0 from LOADING to >>FULL, Loading Done >>R1# >>R1#sh ip route vrf VPNB | inc 8.8.8.8 >>B 8.8.8.8 [200/0] via 6.7.8.8, 00:00:14 >>R1# >>R1# >>00:03:47: %OSPF-5-ADJCHG: Process 39, Nbr 8.8.8.8 on OSPF_SL0 from FULL to >>DOWN, Neighbor Down: Interface down or detached >>R1# >>R1#sh ip route vrf VPNB | inc 8.8.8.8 >>O E2 8.8.8.8 [110/1] via 6.7.8.8, 00:00:00 >>R1# >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>R8# >>00:06:28: %OSPF-5-ADJCHG: Process 39, Nbr 1.1.1.1 on OSPF_SL0 from LOADING to >>FULL, Loading Done >>R8# >>R8#sh ip route vrf VPNB | inc 1.1.1.1 >>B 1.1.1.1 [200/0] via 125.125.125.1, 00:00:13 >>R8# >>R8# >>00:06:44: %OSPF-5-ADJCHG: Process 39, Nbr 1.1.1.1 on OSPF_SL0 from FULL to >>DOWN, Neighbor Down: Interface down or detached >>R8# >>R8#sh ip route vrf VPNB | inc 1.1.1.1 >>O E2 1.1.1.1 [110/1] via 125.125.125.1, 00:00:02 >>R8# >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >>After a few hours trying to understand why this was happening, i was able to >>make it work tweaking the OSPF AD for the External >>routes in R1 and R8. >> >>Anyone saw this problem in this lab ? >> >>And why in the PG we don't see the sham-link interfaces in R3 and R9 ? >> >> >>Regards, >> >>Antonio Soares, CCIE #18473 (R&S) >>[email protected] >> > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
