Gday Antonio, Using the network statement under BGP as opposed to redistribute connected did indeed result in the same issue you described.
I can see how it would be expected that either method should work however given your experience and a somewhat similar one I had as I explained in an earlier email has caused me to think of it like this. When we use the network statement in BGP and then redist BGP into OSPF, the network advertised is a candidate for redistribution. If we use the redist connected, then we have explicitly defined this and broken any implied redistribution that could occur. For example if we have say BGP running (like we do) and redist connected loopback into BGP. Then we decide to redist BGP into OSPF - in order to get this loopback into OSPF, we need to explicitly redistribute it into OSPF as well, otherwise it won't appear. This is my understanding anyhow. I think it is this functionality that protects the sham link end points under normal conditions. Anyhow I'm glad we were able to re-create the problem nonetheless. Cheers, Con. On Tue, Jul 28, 2009 at 10:58 PM, Antonio Soares<[email protected]> wrote: > Hello Con, > > I finally know what it is. When i made this lab i used the network command > instead of the redistribute connected under BGP in order > to announce the sham-link. This causes a problem because both routers will > inject the sham-link end point into the OSPF DB. When i > noticed the problem, i changed from network command to redistribute connected > and the problem was still there. Now i know this is > because the duplicate entries remained in R3 and R9 OSPF databases and this > information was sent again to R1 and R8. > > The documentation is not very clear about the way the sham-link should be > advertised: > > http://www.cisco.com/en/US/partner/docs/ios/iproute/configuration/guide/irp_ospf_sham_link.html > > I always thought that using the network command or the redistribute command > would give us the same results. It seems this is not > true. This can be a corner case since we have an Inter-AS scenario with RR's. > > Well, at least i learned that the domain-tag command can be very helpful in a > situation like this. > > I'm sorry for the confusion i may have created here. > > It would be nice to see the problem replicated in your side :) > > > Regards, > > Antonio Soares, CCIE #18473 (R&S) > [email protected] > > -----Original Message----- > From: Con Spathas [mailto:[email protected]] > Sent: terça-feira, 28 de Julho de 2009 21:38 > To: Antonio Soares > Cc: [email protected] > Subject: Re: [OSL | CCIE_SP] VOL2 - Section 1 - Task 8.2 > > Gday Antonio. > > This is truly strange. > > I copied your configs verbatim into my routers and I still can't manage to > re-create the problem. > > R1#sh ip ospf neighbor 8.8.8.8 | inc Neigh|up Neighbor 8.8.8.8, interface > address 8.8.8.8 > Neighbor priority is 0, State is FULL, 6 state changes > Neighbor is up for 00:07:51 > > The Sham Link is stable. > > I'm keen to get to the bottom of it in case it happens in a lab! > > Let's take this offline and report back to the group if we figure it out? > > Con. > > On Tue, Jul 28, 2009 at 7:02 PM, Antonio Soares<[email protected]> wrote: >> Hello Con, >> >> I was able to reproduce the problem: >> >> ++++++++++++++++++++++++++++ >> R1#sh ip route vrf VPNB 8.8.8.8 >> Routing entry for 8.8.8.8/32 >> Known via "bgp 125", distance 200, metric 0 >> Tag 678, type internal >> Redistributing via ospf 39 >> Advertised by ospf 39 subnets >> Last update from 6.7.8.8 00:00:23 ago >> Routing Descriptor Blocks: >> * 6.7.8.8 (Default-IP-Routing-Table), from 125.125.125.2, 00:00:23 >> ago >> Route metric is 0, traffic share count is 1 >> AS Hops 1 >> Route tag 678 >> MPLS Required >> >> R1# >> 01:04:03: %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 8.8.8.8 Routing entry for 8.8.8.8/32 >> Known via "ospf 39", distance 110, metric 1 >> Tag Complete, Path Length == 1, AS 678, , type extern 2, forward >> metric 1 >> Redistributing via bgp 125 >> Last update from 6.7.8.8 00:00:05 ago >> Routing Descriptor Blocks: >> * 6.7.8.8 (Default-IP-Routing-Table), from 8.8.8.8, 00:00:05 ago >> Route metric is 1, traffic share count is 1 >> Route tag 3489661606 >> >> R1# >> R1# >> 01:04:16: %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 8.8.8.8 >> Routing entry for 8.8.8.8/32 >> Known via "bgp 125", distance 200, metric 0 >> Tag 678, type internal >> Redistributing via ospf 39 >> Advertised by ospf 39 subnets >> Last update from 6.7.8.8 00:00:11 ago >> Routing Descriptor Blocks: >> * 6.7.8.8 (Default-IP-Routing-Table), from 125.125.125.2, 00:00:11 >> ago >> Route metric is 0, traffic share count is 1 >> AS Hops 1 >> Route tag 678 >> MPLS Required >> >> R1# >> ++++++++++++++++++++++++++++ >> >> The link between R3 and R9 is shutdown. >> >> I am using 12.2(25)S13 in all routers in this lab. >> >> The relevant configs: >> >> R1: >> ! >> interface Loopback1000 >> ip vrf forwarding VPNB >> ip address 1.1.1.1 255.255.255.255 >> no clns route-cache >> ! >> router ospf 39 vrf VPNB >> log-adjacency-changes >> area 0 sham-link 1.1.1.1 8.8.8.8 >> redistribute bgp 125 subnets >> network 31.3.1.1 0.0.0.0 area 0 >> ! >> router bgp 125 >> bgp router-id 125.125.125.1 >> bgp always-compare-med >> no bgp default ipv4-unicast >> bgp log-neighbor-changes >> neighbor 125.8.1.8 remote-as 678 >> neighbor 125.125.125.2 remote-as 125 >> neighbor 125.125.125.2 update-source Loopback0 >> neighbor 125.125.125.5 remote-as 125 >> neighbor 125.125.125.5 update-source Loopback0 >> ! >> address-family ipv4 vrf VPNB >> redistribute connected >> redistribute ospf 39 vrf VPNB match internal external 1 external 2 >> route-map ospf2bgp >> no auto-summary >> no synchronization >> exit-address-family >> ! >> route-map ospf2bgp permit 10 >> set origin egp 1 >> ! >> >> R8: >> ! >> interface Loopback1000 >> ip vrf forwarding VPNB >> ip address 8.8.8.8 255.255.255.255 >> no clns route-cache >> ! >> ! >> router ospf 39 vrf VPNB >> log-adjacency-changes >> area 0 sham-link 8.8.8.8 1.1.1.1 >> redistribute bgp 678 subnets >> network 98.9.8.8 0.0.0.0 area 0 >> ! >> router bgp 678 >> bgp router-id 6.7.8.8 >> bgp always-compare-med >> no bgp default ipv4-unicast >> bgp log-neighbor-changes >> neighbor as678 peer-group >> neighbor as678 remote-as 678 >> neighbor as678 password ipexpert >> neighbor as678 update-source Loopback0 >> neighbor 6.7.8.6 peer-group as678 >> neighbor 6.7.8.7 peer-group as678 >> neighbor 125.8.1.1 remote-as 125 >> ! >> address-family ipv4 vrf VPNB >> redistribute connected >> redistribute ospf 39 vrf VPNB match internal external 1 external 2 >> no auto-summary >> no synchronization >> exit-address-family >> ! >> >> I don't remember very well but i think i also loaded R1 and R8 with 12.0S >> and 12.4 and got the same results. >> >> And i'm using the same process id in R1 and R8. But even with different >> process ids, the problem still happens. >> >> >> Regards, >> >> Antonio Soares, CCIE #18473 (R&S) >> [email protected] >> >> -----Original Message----- >> From: Con Spathas [mailto:[email protected]] >> Sent: domingo, 26 de Julho de 2009 9:29 >> To: Antonio Soares; [email protected] >> Subject: Re: [OSL | CCIE_SP] VOL2 - Section 1 - Task 8.2 >> >> 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
