I've come to the conclusion lately that what is documented isn't always how it really should be - especially in cases involving MPLS.
Ho hum. Good to have these experiences before the lab than during. On Thu, Jul 30, 2009 at 12:41 PM, Antonio Soares<[email protected]> wrote: > Hello Con, > > I found that the example shown in the Implementing Cisco MPLS Student Guide > is using the network command. > > Funny, isn't it ? > > > > Regards, > > Antonio Soares, CCIE #18473 (R&S) > [email protected] > > -----Original Message----- > From: Con Spathas [mailto:[email protected]] > Sent: quarta-feira, 29 de Julho de 2009 11:27 > To: Antonio Soares > Cc: [email protected] > Subject: Re: [OSL | CCIE_SP] VOL2 - Section 1 - Task 8.2 > > 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/guid >> e/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
