So if you have something like this.... Area3-----(R1)----Area0----(R2)-----Area1----(R3)-----Superbackbone----(R4)- ----Area2-----(R5)------Area3----(R6)----Area0--------
Would it be workable to add virtual link to connect area 0 on left side to sbb via area1. But this seems strange for the right side. Would I need 2 vl's ? one to get area 2 connected via area 3 to native area0....and another vl to get native area 0 connected to sbb ? Aaron -----Original Message----- From: adam vitkovsky [mailto:adam.vitkov...@swan.sk] Sent: Tuesday, June 19, 2012 5:58 AM To: 'Aaron'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ospf with vrf > Domain-tag 1 didn't work Please mind the difference between Domain-tag and Domain-id Domain-tag -won't help you with the process id discrepancy as it's a loop prevention mechanism for certain types of LSAs As you could see later in your trials - Domain-id did the trick -and allowed you to propagate type-3 LSAs through the mpls backbone correctly(unchanged to type-5) Also I see you are using Area1 on one site and Area2 on the other site Please note when connecting non-backbone areas to OSPF superbackbone (MPLS cloud) -the OSPF area 0 rule applies here as well (all areas have to be connected directly to area 0) When you are connecting non-backbone areas (other than area 0) to the MPLS/OSPF superbackbone (link between PE and CE is not in area 0) -the OSPF superbackbone assumes area0 properties/functionality allowing the non-zero areas to exchange LSAs and pass traffic However if you later decide to create other OSPF areas in any of your sites that are connected to mpls via non-backbone area -traffic from the additional areas will not be passed across This setup will not work: ----CE-1-1----CE-1-2-----CE-1-3-------PE----------------------PE--------CE-1 -1---CE-1-2----CE-1-3--- Area3|--------Area0--------|--Area1--|--Superbackbone--|--Area2--|------Area 3|--------Area0--------|--Area1--|--Superbackbone--|--Area2--|--Area0------- |Area4---- -anything beyond Area1 or Area2 would not be able to communicate across the MPLS So the superbackbone can bound sites of different areas together however it can't link other areas on these sites Even though the site's routes appear in PE's VRF LSDB -they will not have the routing-bit set => won't appear in the VRF table => they are not going to be inserted into MP-BGP Thus it's always better to consider the superbackbone as an extension to the area0 that spreads across mpls to all sites In other words to have all sites connected to MPLS via links in area 0 adam -----Original Message----- From: Aaron [mailto:aar...@gvtc.com] Sent: Monday, June 18, 2012 6:30 PM To: 'adam vitkovsky'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ospf with vrf Thanks adam... I just tested the following.... ------------ospf/bgp then bgp/ospf advertisement flow------------------------> Ce1---(area1)-----(ospf process id 1)pe1------p-------pe2(ospf process id 1)----(area2)-----ce2 During the above scenario I see IA routes in CE2, learned from CE1. Then when I change pe2's ospf process ID to "2" ce2 rib sees them as E2. I didn't have to use the domain-ID trick. Ohhhh, I think I just realized what you meant....if I want to ensure that the routes continue to be seen as IA in ce2's rib, then I WOULD need the domain-id thing.... I just tested it....fyi R2 is pe2. Domain-tag 1 didn't work. Routes remained learned as E2 in ce2. Domain-id 0.0.0.1 worked. Ce2's rib now shows ospf learned routes from ce1 as IA again. Apparently this domain-id thing has to be entered in dotted quad notation , but the ospf process id is 1-65535. Not sure how I would match up any and every ospf proc id to domain-id dotted dec format....perhaps it's just a decimal conversion on the domain-id to match the exact ospf process id number. Ok fine, I'll test it. See below... R2(config-router)#no domain-tag 1 R2(config-router)#do sh run | sec router ospf router ospf 2 vrf one router-id 10.10.10.2 log-adjacency-changes redistribute bgp 1 subnets network 2.2.2.1 0.0.0.0 area 1 network 10.10.10.2 0.0.0.0 area 1 R2(config-router)# R2(config-router)#domain R2(config-router)#domain-? domain-id domain-tag R2(config-router)#domain-id ? A.B.C.D OSPF domain ID in IP address format Null Null Domain-ID type OSPF domain ID type in Hex format R2(config-router)#domain-id t R2(config-router)#domain-id type ? 0005 Type 0x0005 0105 Type 0x0105 0205 Type 0x0205 8005 Type 0x8005 R2(config-router)#domain-id 0.0.0.1 ? secondary Secondary Domain-ID <cr> R2(config-router)#domain-id 0.0.0.1 R2(config-router)# Yep, I just changed pe1's ospf proc ID to a random number I picked....678. Then saw again, E2 in Ce2 rib. I changed pe2's ospf domain-id to 0.0.2.166 and BANG, IA's in ce2 rib. Nice, thanks adam. Aaron -----Original Message----- From: adam vitkovsky [mailto:adam.vitkov...@swan.sk] Sent: Monday, June 18, 2012 6:35 AM To: 'Aaron'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ospf with vrf Domain-id is not a loop prevention mechanism -it simply tells the egress PE how to insert the LSA into local VRF LSDB By default Domain-id is set to VRF OSPF Process-id # of the originating PE that redistributed the route into MP-BGP When egress PE redistributes routes form MP-BGP into VRF OSPF process the PE compares the local VRF OSPF Process-id with the Domain-id associated with the MP-BGP route -if the two match the LSA is inserted as Type-3 LSA into local VRF LSDB -if the two do not match the LSA is inserted as Type-5 LSA into local VRF LSDB -the value can be set manually in case you can't use the same ospf process id on each PE serving the particular customer site Domain-tag and the down-bit are loop prevention mechanisms Down-bit is used on LSA-3 Domain-tag is used on LSA Type-5 and Type-7 (simply because these LSA types do not have down-bit in the LSA header) Down-bit is set to Downward (set to 1) by egress PE when redistributing Type-3 routes from MP-BGP down to VRF OSPF process Domain-tag is set to MP-BGP-AS# by originating PE when redistributing Type-5 routes from OSPF up to MP-BGP process Each PE that has VRF OSPF process checks the Type-3 LSAs coming from CE for down-bit If the Type-3 LSA has a down bit set to Downward the PE doesn't set the Routing-Bit on this LSA and doesn't consider it during the SPF computation (If the routing bit is not set on the LSA the LSA is not added into the routing table -thus is not redistributed into MP-BGP) When type-3 LSA from particular area reaches PE router with a down-bit set -the PE knows that this LSA must have already been redistributed from MPLS into this area by some other PE router -thus redistributing it back to MPLS would cause a routing information loop Each PE that has VRF OSPF process checks the Type-5 LSAs coming from CE and compares whether the domain-tag set equals to the PE MP-BGP-AS# If yes the PE will not set the routing-bit on this LSA thus the LSA will not get into the routing table -this it will not be redistributed to MP-BGP -the value can be set manually in cases where you operate mpls domain that spans multiple autonomous systems and customer site connected to one AS# has a backhaul link to site connected to another AS# -in this case the common domain tag has to be manually set on all PEs providing OSPF routing for this particular customer adam -----Original Message----- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Sunday, June 17, 2012 5:34 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ospf with vrf I think I found the answer, although I don't fully understand it all yet. I have heard about this before and recall some of it. This seemed to do the trick...under, router ospf vrf testvrf "capability vrf-lite" I read this. https://supportforums.cisco.com/thread/202402 Apparently it has something to do with loop prevention and "pe checks" of domain id and down bit or something like that to keep pe from adding anything other than type 1 and 2's to rib. Aaron -----Original Message----- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Saturday, June 16, 2012 10:16 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ospf with vrf why does my pe lose the ability to add type 3 (summary) routes, learned from ce, to its rib AFTER I convert its ospf process to vrf ? in other words, when my pe's ospf process does not have vrf config I see the IA routes to other areas, but as soon as I change my ospf process to vrf I lose my IA routes. They are still in the ospf db though, but just not being added to the RIB. Aaron _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/