[c-nsp] ospf with vrf
adam vitkovsky
adam.vitkovsky at swan.sk
Wed Jun 20 03:00:54 EDT 2012
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:aaron1 at gvtc.com]
Sent: Tuesday, June 19, 2012 7:02 PM
To: 'adam vitkovsky'; cisco-nsp at 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 area0....and another vl to get
native area 0 connected to sbb ?
Aaron
-----Original Message-----
From: adam vitkovsky [mailto:adam.vitkovsky at swan.sk]
Sent: Tuesday, June 19, 2012 5:58 AM
To: 'Aaron'; cisco-nsp at 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--|------
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:aaron1 at gvtc.com]
Sent: Monday, June 18, 2012 6:30 PM
To: 'adam vitkovsky'; cisco-nsp at 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.vitkovsky at swan.sk]
Sent: Monday, June 18, 2012 6:35 AM
To: 'Aaron'; cisco-nsp at 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-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron
Sent: Sunday, June 17, 2012 5:34 AM
To: cisco-nsp at 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-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron
Sent: Saturday, June 16, 2012 10:16 PM
To: cisco-nsp at 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 at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list