l3vpn question

rossonieri#1

hi guys,

i'm a bit confused here trying to lab the l3vpn,
reading the JNCIS study guide book part (unfortunately at this particular l3vpn section, it has a little unclear explanation), and this reference :
Simple VPN Configuration Summarized by Router - JUNOS 9.0 VPNs Configuration Guide

i'd just dont get the corelation between :
quoted from the juniper software guide, between 2 PEs

Routing Instance for VPN-A

routing-instance {

VPN-A-Paris-Munich {
instance-type vrf;
interface so-6/0/0.0;
interface so-6/0/1.0;
route-distinguisher 65535:0; ---> this part on PE1
route-distinguisher 65535:1; ---> this part on PE2
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}

}

...

community VPN-A members target:65535:4; ---> and this part
community VPN-B members target:65535:5;

if you have any idea how can i relate these 2 parts,
very appreciated, thank you.

i've tried to translate the command using cisco's vrf analogy, but i'd still a little bit confuse.

zoidberg

The route-distinqusiher (RD) and route-target (RT) are two seperate things and don't need to match.

RD is used to allow for overlapping IP space in the providers network. If Customer A and Customer B both have IPs 1.1.1.1 in their network, the provider's network needs to understand which 1.1.1.1 belongs to Customer A and which to B. So, if A has RD 65412:100 and B has RD 64512:200, the IP VPN IPs become uniquie, something kinda like 65412:100:1.1.1.1 and 64512:200:1.1.1.1.

The RT export tags your VPN routes, and the import allows you pick which routes you want to import into your VPN. Lets go with A has RT 65535:900 and B has 65535:800. VPN A can be set to import and export just routes from his VPN sites using 65535:900. B however, needs to know it's routes, but wants to get A's routes as well. B can export 65535:800 and import 65535:800, but it can also import A's routes by importing 65535:900 as well.

RD, make IP's unique in the SP network.
RT, pick and choose which routes to import into the VPN and where.

rossonieri#1

hi zoidberg,

for that RD and RT part, i think i start to understand - even though i have to translate it over and over againts IOS config. thank you for the big assistance

what a mess,
3 days in the battle - just to fix that BGP hidden route, so that it can route the VRF.

no go ...

i just cant believe, how the that directly connected network didnt get installed on both PEs. i'll take a break for a moment, a cup of coffee looks good

rossonieri#1

update #2

ok, its been 5 days now & Thank God, after the long, hard & winding road in adopting IOS config to junos - the l3vpn - it is finally working.

the same scenario from the previous link on above post,
i've got the route, the rsvp up & running, the lsp-path etc.

but i need some enhancement on testing the link, need to read some more docs for troubleshooting.

ce1 --- r1 --- r2 --- r3 --- ce2

next-step is lab verifications :
zoidberg, aldur - how is my l3vpn lab? do you spot any misconfiguration and the like?
your input is much appreciated, thank you

rossonieri#1

update #3

ok, today - i continue to do basic l3vpn using 9 LRs with ospf multi-area 2 - 0 - 1,
another issue came up which is my rsvp cant established between 1 area and the other. should be another good troubleshooting experience

Aldur

rossonieri#1 wrote: »

update #3

ok, today - i continue to do basic l3vpn using 9 LRs with ospf multi-area 2 - 0 - 1,
another issue came up which is my rsvp cant established between 1 area and the other. should be another good troubleshooting experience

What do you mean by "rsvp can't establish"? Are you just not seeing any rsvp neighbors? This might be normal since you'll only see rsvp neighbors if you have an rsvp tunnel running through that interface that you're expecting to see rsvp neighbors on.

Aldur

rossonieri#1 wrote: »

zoidberg, aldur - how is my l3vpn lab? do you spot any misconfiguration and the like?
your input is much appreciated, thank you

All the outputs look great, it appears that you are passing L3vpn bgp routes as expected. Being able to ping across is a nice plus too

rossonieri#1

aldur,

thanks for the input

What do you mean by "rsvp can't establish"?

i dont know if i have missed something here on my study,
but AFAIK, inter-area OSPF wont show one area topology to another area - say from area 1 will not be shown to area 2 and the routes will use the area 0 instead, hence the rsvp cant be established just like in a single area.

the scenario - just like on figure 5.1 JNCIP study guide.
r1, r2 area 2
r3, r4, r5 area 0
r6, r7 area 1

the output just like here, r6 on area 1 :

rsvp has been set up correctly,
lsp's has been all established.

ok, from the output - because i dont have the LSP set up correctly, this also be the cause i dont have the BGP route from r1, r2, r3 on r6 and r7. it got hidden.

lsp's has been up,
no more BGP hidden routes.

if i have set the LSP up correctly - i'll have the BGP route installed on r6 and r7. i have this experience when i was working on my previous lab just yesterday : no LSP/rsvp no BGP (of course, aside from the route policy). *i think*

so, the workaround is to use the expand-loose-hop like described here :
Enabling Inter-Area Traffic Engineering

and one more thing that will also be some great experience, that i have some load balanced equal cost on the scenario. this should be a good learning curve i need to read more & more docs, and the coffee gets cold

its may 26 now, hows your preparation aldur? are you ready to rumble?

Aldur

Your assumption is correct on that the routes will be hidden if LSP is not up. This is because you need to have the BGP next hop in the inet.3 table for resolution to happen inside the L3vpn.

What does your LSP look like, do you have the "no-cspf" knob enabled? If you don't the LSP will fail every time since the TED will never be consistent across multiple OSPF areas.

Could also be as simple as forgetting to enable RSVP on one interface in the path. That one would trip me up from time to time

Well, the prep for the IE is going.... Services still tend to be a weak point for me. There's just so much crap that can happen in a failure scenario that it's mind bogling. Then at what is an acceptable amount of time for a fail over to completely converge?? It really gets fun when you mix all the services together.... nothing spells out a good night of cussing at my monitor then throwing in a mix of ipsec-over-gre, sfw, nat, and then mixing the different types of service sets....

Needless to say I'm looking forward to failing the test the first go around

rossonieri#1

What does your LSP look like, do you have the "no-cspf" knob enabled? If you don't the LSP will fail every time since the TED will never be consistent across multiple OSPF areas.

bingo!!! that no-cspf, thanks

Could also be as simple as forgetting to enable RSVP on one interface in the path. That one would trip me up from time to time

hahaha, another one ... double bingo!!!
nope, i've octa-checked that

Well, the prep for the IE is going.... Services still tend to be a weak point for me. There's just so much crap that can happen in a failure scenario that it's mind bogling. Then at what is an acceptable amount of time for a fail over to completely converge?? It really gets fun when you mix all the services together.... nothing spells out a good night of cussing at my monitor then throwing in a mix of ipsec-over-gre, sfw, nat, and then mixing the different types of service sets....

should i say : welcome to Enterprise Routing my friend where all things mixed up and you have to do that seamlessly

anyway, good luck as always!

Aldur

Sweet, good to hear that fixed the problem

rossonieri#1 wrote: »

should i say : welcome to Enterprise Routing my friend where all things mixed up and you have to do that seamlessly

anyway, good luck as always!

Seriously, ER routing is a pain compared to core routing. There's just to much crap that is going on... Then again I might just feel this way since my experience lies in core routing and not ER

But thanks for the well wishes, it'll take a miracle to pull this one out of a hat

rossonieri#1

update #3a

ok, so no-cspf did help to establish LSPs between PEs.
got the LSPs up & running, and the BGP routes.

solved.

but, another problem yet to be solved : multipath OSPF, and when BGP routes mean nothing - as simple as it just doesnt work

here for examples :

solved.

some possible cause has been detected, and their troubleshooting approaches.
but, decided to let the lab alone for a while - taking a coffee break now

Aldur

ah hah! I know your problem and it's a quirk that is specific to olives only. You'll need to enable the vrf-table-lable knob in your vrf's on each PE to get pings to go from one end of the vrf to the next.

I, nor anybody I've ever talked to, know's why this fixes the problem with olives, vrf-table-lable is used to tell the router to send the vpn labled packet back through the PFE after it's pop'd the vpn label. This allows FWF to be able to happen on traffic that is destined for the local PE's vrf interface.

So, give the vrf-table-lable a shot, should fix the problem for you.

rossonieri#1

hi aldur,

vrf-table-lable is used to tell the router to send the vpn labled packet back through the PFE after it's pop'd the vpn label. This allows FWF to be able to happen on traffic that is destined for the local PE's vrf interface.

a nice one, vrf-table-label,
unfortunately i have configured that knob since my first l3vpn lab and to make the lab works. but this time, it didnt help - at least a plain vrf-table-label didnt work i havent tried using some extended vrf-table-label yet.

i think the problem lies on the topology.

if we observe that figure 5.1 on the JNCIS study guide book, i have created these schema based on it :
PEs : r1, r2, r3, r6 and r7
CEs :
- subnet 10.0.5.0/24 behind r1 & r2
- subnet 172.16.0.12/30 behind r3
- subnet 172.16.40.0/30 behind r6
- subnet 172.16.40.4/30 behing r7

and its a full-meshed, so hubs & spokes topology.

quoted from here :
Configuring VPN Routing Instances on the Hub-and-Spoke PE Routers - JUNOS 9.2 VPNs Configuration Guide

this figure 5.1 small lab turned out to be a huge one to be solved
and some of CEs destinations are multipath.
eg. : from CE behind r3 it will have a multipath to 10.0.5.0/24 net using PE r1 & r2 and so forth.

so, each PEs needs to have separate vrf-import policies to be able to differentiate from which PEs any traffic came from. *i think*, that is why a plain vrf-table-label didnt help much.

a little break once more

Aldur

damn, to bad on the magic bullet fix of vrf-table-label. And there's no extended version of it so if you're using it and it doesn't work then thats not the problem.

Are you connecting all CE's into one L3vpn? If so try using the vrf-target knob instead of vrf-import/vrf-export.

Although this should have the same effect as having vrf-import and vrf-export as the exact same on all routers, minus route-filter syntax within the actually policies.

If that doesn't work post your problem PE routing-instance and vrf policy configs here.

rossonieri#1

hi aldur,

thanks for replying

are those switches behind vrf-table-label are not an extended config? seem to me they could be?

yes, i'm connecting all CEs under 1 L3vpn. vrf-target : did that, but havent do any good so far, still exploring any possibilities.

general routing-instances on my PEs look like this (sorry, i'm not in front of my console) :

routing-instances cust_a
instances-type vrf
interface fxpa.b
route-distinguisher 65330:11
vrf-import cust_a_import
vrf-export cust_a_export
vrf-target target:65530:1000
vrf-table-label

under logical-router p1
set pol community cust_a members target:65530:1000

i've set that same config on every PEs, except for some config like route-distinguisher and the like.

should be lab them up again tomorrow,
i've got very exhausted today

Aldur

get rid of the vrf-import/export commands, these will supersede the vrf-target and then make sure each routing-instance has vrf-target target:65530:1000 in it. Might help things

rossonieri#1

update #3b

hi aldur, sorry for this very late update

get rid of the vrf-import/export commands

here we go,

solved.

yet, still no good
BGP routes are all there on every PEs - no hidden routes.

do you have any other clue?

i debug the "MPLS all" on r1 also - but the output seems very strange that it has no traffic using it?

Aldur

rossonieri#1 wrote: »

update #3b

hi aldur, sorry for this very late update



here we go,

solved.

yet, still no good
BGP routes are all there on every PEs - no hidden routes.

do you have any other clue?

i debug the "MPLS all" on r1 also - but the output seems very strange that it has no traffic using it?

sorry for the late update here too, been crazy busy at work lately.

So I see that you changed the output to solved? Is it working now? If so what did you do to get it to work?

rossonieri#1

hi aldur,

hey its ok, duties come first buddy

about the work? ouch, i dont even want to remember how i did it,
lets say it was a huge SP overhaul :LOL:

way too many efforts, and i think it was a non strategic move for a production network
so, i'd still consider it was a false positif study result.

still has many to read, to lab & to grasp the concept even it was a basic one

its funny though, i'm on the ER track studying M :LOL:

simple, i like MPLS