Re: [c-nsp] ospf with vrf
Right you might treat the site on the left as partitioned backbone area scenario and use virtual link to connect the two parts of Area 0 (area0 and sbb) together over Area 1 (if area1 is not stub) -I have never tried this Regarding the site on the right You can't span virtual-link over 2 areas -because when hello packet is received the area ID of the receiving interface must match the area configured as transit in the virtual link command adam -Original Message- From: Aaron [mailto:aar...@gvtc.com] Sent: Tuesday, June 19, 2012 7:02 PM To: 'adam vitkovsky'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] ospf with vrf 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 area0and 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-1CE-1-2-CE-1-3---PE--PECE-1 -1---CE-1-2CE-1-3--- Area3|Area0|--Area1--|--Superbackbone--|--Area2--|-- Area3|Area0|--Area1--|--Superbackbone--|--Area2--|Area 3|Area0|--Area1--|--Superbackbone--|--Area2--|--Area0--- 3|Area0|--Area1--|--Superbackbone--|--Area2--| |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. O, I think I just realized what you meantif 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 itfyi 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 formatperhaps 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
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-1CE-1-2-CE-1-3---PE--PE CE-1-1---CE-1-2CE-1-3--- Area3|Area0|--Area1--|--Superbackbone--|--Area2--|Ar ea0---|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. O, I think I just realized what you meantif 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 itfyi 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 formatperhaps 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 picked678. 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
Re: [c-nsp] ospf with vrf
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 area0and 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-1CE-1-2-CE-1-3---PE--PECE-1 -1---CE-1-2CE-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. O, I think I just realized what you meantif 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 itfyi 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 formatperhaps 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 picked678. 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
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/
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. O, I think I just realized what you meantif 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 itfyi 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 formatperhaps 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 picked678. 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
Re: [c-nsp] ospf with vrf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron wrote: 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. It has something to do with this: http://www.networkworld.com/community/node/19293 - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/dn80ACgkQE1XcgMgrtyZ17wCff7EZaor5ST9To8tjgZdVd/qR Cp4AmwSZGnkp/n0fMDa2Ri8NgYyTeJly =xSfy -END PGP SIGNATURE- ___ 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/
[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/
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/
[c-nsp] OSPF inside VRF - Cisco Juniper Interoperability
Hi, I am caught up in what seems to be a Juniper Cisco interoperability issue. I am running OSPF with customer inside VRF. Topology is something like the following: CE1 ---[Area 0]--- PE1 P1 --- P2 --- PE2 ---[Area 6]--- CE2 The two P routers are acting as route reflectors. CE1, CE2 and PE1 are Cisco devices while rest are Juniper M-series routers. The problem I am facing is that CE1 routes received at CE2 are Inter-area which is what is required (no redistribution into OSPF is done on CE1 and CE2). However, CE2 routes received by CE1 are Type 5 (E1). The documentation states that inorder to preserve the route types, domain IDs should be same on both PE routers. I have set domain ID to be 1.1.1.1:512, this was done on cisco via the command: domain-id type 0105 value 010101010200 and on juniper as: domain-id 1.1.1.1:512 in the OSPF configuration inside the VRF. Also on Juniper the domain-id was added into the ospf routes when redistributing them into MBGP. The problem seems to be with the Cisco PE1 router that can't seem to interpret the route-type attribute generated by Juniper (seen in the output as 0x306:0:393472): PE1#sh ip bgp vpnv4 all 10.254.20.254 BGP routing table entry for 1:103:10.254.20.254/32, version 550 Paths: (1 available, best #1, table VPN_OSPF) Not advertised to any peer Local PE2_Loopback_IP (metric 4) from P1_Loopback_IP (P1_Loopback_IP) Origin IGP, metric 2, localpref 100, valid, internal, best Extended Community: RT:1:103 OSPF DOMAIN ID:0x0105:0x010101010200 0x306:0:393472 10.254.20.254/32 is advertised by CE2 (assigned on one of its loopback interfaces). Now the domain ID is fine but it seems that Cisco is unable to interpret the route-type attribute. 393472 translates to 60100 where 6 is the area ID, 01 says that it is type 1 LSA and and last two bytes are options are not used in this case. Upon receiving this route via MBPG, PE1 injects a type 5 LSA towards CE1 (confirmed on CE1 by enabling debugging) where it should inject have injected type 3: OSPF: Ack Type 5, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 5, seq 0x8001 If I replace the Juniper PE2 with a Cisco then on PE1 seems to interpret the route-type attribute correctly (OSPF RT:0.0.0.6:2:0) and inject type 3 LSA towards CE1 and CE1 receive the routes as inter-area: PE1#sh ip bgp vpnv4 all 10.254.20.254 BGP routing table entry for 1:103:10.254.20.254/32, version 676 Paths: (1 available, best #1, table VPN_OSPF) Not advertised to any peer Local PE2_Loopback_IP (metric 2) from P1_Loopback_IP (P1_Loopback_IP) Origin incomplete, metric 2, localpref 100, valid, internal, best Extended Community: RT:1:103 OSPF DOMAIN ID:0x0005:0x010101010200 OSPF RT:0.0.0.6:2:0 OSPF ROUTER ID:10.254.2.1:512 Debug output: OSPF: Ack Type 3, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 1, seq 0x8001 Any idea what is causing this behavior? Any solution? Will appreciate any help. Regards, Junaid ___ 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/
Re: [c-nsp] OSPF inside VRF - Cisco Juniper Interoperability
Junaid wrote on Wednesday, August 27, 2008 11:12 AM: Hi, I am caught up in what seems to be a Juniper Cisco interoperability issue. I am running OSPF with customer inside VRF. Topology is something like the following: CE1 ---[Area 0]--- PE1 P1 --- P2 --- PE2 ---[Area 6]--- CE2 The two P routers are acting as route reflectors. CE1, CE2 and PE1 are Cisco devices while rest are Juniper M-series routers. The problem I am facing is that CE1 routes received at CE2 are Inter-area which is what is required (no redistribution into OSPF is done on CE1 and CE2). However, CE2 routes received by CE1 are Type 5 (E1). The documentation states that inorder to preserve the route types, domain IDs should be same on both PE routers. I have set domain ID to be 1.1.1.1:512, this was done on cisco via the command: domain-id type 0105 value 010101010200 and on juniper as: domain-id 1.1.1.1:512 in the OSPF configuration inside the VRF. Also on Juniper the domain-id was added into the ospf routes when redistributing them into MBGP. The problem seems to be with the Cisco PE1 router that can't seem to interpret the route-type attribute generated by Juniper (seen in the output as 0x306:0:393472): [...] Any idea what is causing this behavior? Any solution? Will appreciate any help. which release are you using on he PE1? You might be hitting CSCsg42488 (Juniper - Cisco PE incorrect extended community for OSPF). oli ___ 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/
Re: [c-nsp] OSPF inside VRF - Cisco Juniper Interoperability
Hi, Just want to share my findings: The problem as suspected was a bug on Cisco side - CSCsg42488 as pointed out by Oliver Boehmer. The work around employed was to use the knob: route-type-community vendor for the OSPF instance inside the VRF on Juniper PE. Thanks once again Oliver for the solution. Now CE1 is also getting Type 3 LSAs from CE2. Regards, Junaid On Wed, Aug 27, 2008 at 3:12 PM, Junaid [EMAIL PROTECTED] wrote: Hi, I am caught up in what seems to be a Juniper Cisco interoperability issue. I am running OSPF with customer inside VRF. Topology is something like the following: CE1 ---[Area 0]--- PE1 P1 --- P2 --- PE2 ---[Area 6]--- CE2 The two P routers are acting as route reflectors. CE1, CE2 and PE1 are Cisco devices while rest are Juniper M-series routers. The problem I am facing is that CE1 routes received at CE2 are Inter-area which is what is required (no redistribution into OSPF is done on CE1 and CE2). However, CE2 routes received by CE1 are Type 5 (E1). The documentation states that inorder to preserve the route types, domain IDs should be same on both PE routers. I have set domain ID to be 1.1.1.1:512, this was done on cisco via the command: domain-id type 0105 value 010101010200 and on juniper as: domain-id 1.1.1.1:512 in the OSPF configuration inside the VRF. Also on Juniper the domain-id was added into the ospf routes when redistributing them into MBGP. The problem seems to be with the Cisco PE1 router that can't seem to interpret the route-type attribute generated by Juniper (seen in the output as 0x306:0:393472): PE1#sh ip bgp vpnv4 all 10.254.20.254 BGP routing table entry for 1:103:10.254.20.254/32, version 550 Paths: (1 available, best #1, table VPN_OSPF) Not advertised to any peer Local PE2_Loopback_IP (metric 4) from P1_Loopback_IP (P1_Loopback_IP) Origin IGP, metric 2, localpref 100, valid, internal, best Extended Community: RT:1:103 OSPF DOMAIN ID:0x0105:0x010101010200 0x306:0:393472 10.254.20.254/32 is advertised by CE2 (assigned on one of its loopback interfaces). Now the domain ID is fine but it seems that Cisco is unable to interpret the route-type attribute. 393472 translates to 60100 where 6 is the area ID, 01 says that it is type 1 LSA and and last two bytes are options are not used in this case. Upon receiving this route via MBPG, PE1 injects a type 5 LSA towards CE1 (confirmed on CE1 by enabling debugging) where it should inject have injected type 3: OSPF: Ack Type 5, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 5, seq 0x8001 If I replace the Juniper PE2 with a Cisco then on PE1 seems to interpret the route-type attribute correctly (OSPF RT:0.0.0.6:2:0) and inject type 3 LSA towards CE1 and CE1 receive the routes as inter-area: PE1#sh ip bgp vpnv4 all 10.254.20.254 BGP routing table entry for 1:103:10.254.20.254/32, version 676 Paths: (1 available, best #1, table VPN_OSPF) Not advertised to any peer Local PE2_Loopback_IP (metric 2) from P1_Loopback_IP (P1_Loopback_IP) Origin incomplete, metric 2, localpref 100, valid, internal, best Extended Community: RT:1:103 OSPF DOMAIN ID:0x0005:0x010101010200 OSPF RT:0.0.0.6:2:0 OSPF ROUTER ID:10.254.2.1:512 Debug output: OSPF: Ack Type 3, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 1, seq 0x8001 Any idea what is causing this behavior? Any solution? Will appreciate any help. Regards, Junaid ___ 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/
