OSPF External routes on directly connected VRF interfaces

wintermute000 · January 12, 2015, 05:58:45 PM

Topology is here

http://skaffen.planetexpress.com.au/JNCIS-SP-LAB.pdf

MPLS-VPN topology using OSPF as PE-CE (routing-instance / VRF of vpn-b)

NOTE: BACKDOOR LINK IS DOWN FOR PURPOSES OF THIS

I am trying to understand how/why the routes for directly attached PE-CE interfaces in vpn-b are being sent as Type 5 routes via MP-BGP.
Where do I see the OSPF Extended attributes in the Route Reflector? I can see it clearly on the Last Hop PE but I can't see it in the Route Reflector. And how did it go from a Type 2 to a Type 5? I have NOT set a domain-id which according to Juniper doco means it should come through as a Type 3 summary (which is what I was expecting).

Note that routes coming from the CE e.g. loopbacks are coming through has Type 3 as expected.

Here is a trace of all the route states from the CE way back to the advertising PE.

1.) CE3 ROUTER SEES THESE ROUTES 172.17.1.0/30 AS TYPE 5 EXTERNAL COMING FROM PE3.

!!!!!!! CE ROUTER OSPF ROUTES

loj001@CUSTOMER-B-CE3> show route protocol ospf

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.17.1.0/30 *[OSPF/150] 03:17:13, metric 0, tag 3489726463
> to 172.17.3.1 via ge-0/0/5.0
172.17.1.128/30 *[OSPF/10] 03:17:13, metric 3
> to 172.17.3.1 via ge-0/0/5.0
172.17.2.0/30 *[OSPF/150] 03:17:13, metric 0, tag 3489726463
> to 172.17.3.1 via ge-0/0/5.0
192.168.17.1/32 *[OSPF/10] 03:17:13, metric 2
> to 172.17.3.1 via ge-0/0/5.0
192.168.17.2/32 *[OSPF/10] 03:17:13, metric 2
> to 172.17.3.1 via ge-0/0/5.0
224.0.0.5/32 *[OSPF/10] 03:17:47, metric 1
MultiRecv

loj001@CUSTOMER-B-CE3> show ospf database

OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.17.3.1 172.17.3.1 0x80000007 2839 0x22 0x4ad8 36
Router *192.168.17.3 192.168.17.3 0x80000008 2823 0x22 0x32ec 48
Network 172.17.3.1 172.17.3.1 0x80000005 1124 0x22 0xb1c4 32
Summary 172.17.1.128 172.17.3.1 0x80000005 2410 0xa2 0xa414 28
Summary 192.168.17.1 172.17.3.1 0x80000005 1982 0xa2 0xd6a3 28
Summary 192.168.17.2 172.17.3.1 0x80000005 696 0xa2 0xccac 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 172.17.1.0 172.17.3.1 0x80000005 1553 0xa2 0x4996 36
Extern 172.17.2.0 172.17.3.1 0x80000005 267 0xa2 0x3ea0 36

loj001@CUSTOMER-B-CE3>

2.) PE3 ROUTER RECEIVED THIS FROM THE ROUTE REFLECTOR AS A MP-BGP ROUTE WITH EXTENDED COMMUNITY OF TYPE 5 LSA. "OSPF area : 0.0.0.0, LSA ID : 172.17.1.0, LSA type : Extern"

!!!!!!!!!!! PE ROUTE FACING CE
loj001@SP-LAB-PE3> show route 172.17.1.0 extensive

vpn-b.inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
172.17.1.0/30 (1 entry, 1 announced)
TSI:
OSPF area : 0.0.0.0, LSA ID : 172.17.1.0, LSA type : Extern
KRT in-kernel 172.17.1.0/30 -> {indirect(262144)}
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.7:2
Next hop type: Indirect
Address: 0x934d720
Next-hop reference count: 9
Source: 10.0.0.1
Next hop type: Router, Next hop index: 633
Next hop: 10.2.2.1 via ge-0/0/1.0, selected
Label operation: Push 299888, Push 299856(top)
Label TTL action: prop-ttl, prop-ttl(top)
Protocol next hop: 10.0.0.7
Push 299888
Indirect next hop: 95283a0 262144
State: <Secondary Active Int Ext>
Local AS: 65535 Peer AS: 65535
Age: 3:18:19 Metric2: 1
Task: BGP_65535.10.0.0.1+56399
Announcement bits (2): 0-vpn-b-OSPF 1-KRT
AS path: I (Originator) Cluster list: 10.0.0.1
AS path: Originator ID: 10.0.0.7
Communities: target:2:2
Import Accepted
VPN Label: 299888
Localpref: 100
Router ID: 10.0.0.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.0.7 Metric: 1
Push 299888
Indirect next hop: 95283a0 262144
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.2.2.1 via ge-0/0/1.0
10.0.0.7/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.2.2.1 via ge-0/0/1.0

3.) ROUTE REFLECTOR RECEIVED IT AS A MP-BGP ROUTE FROM PE1. HOW DO I CONFIRM THE OSPF EXTENDED ATTRIBUTES?
!!!!!!!!!!!!!! ROUTE REFLECTOR

loj001@SP-LAB-P1> show route 172.17.1.0/30 extensive

bgp.l3vpn.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
10.0.0.7:2:172.17.1.0/30 (1 entry, 1 announced)
TSI:
RTF { 2:2/64 }
Page 0 idx 0 Type 1 val 9381bc8
Nexthop: 10.0.0.7
Localpref: 100
AS path: [65535] I
Communities: target:2:2
Cluster ID: 10.0.0.1
Originator ID: 10.0.0.7
Advertise: 00000006
Path 10.0.0.7:2:172.17.1.0 from 10.0.0.7 Vector len 4. Val: 0
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.7:2
Next hop type: Indirect
Address: 0x934d840
Next-hop reference count: 3
Source: 10.0.0.7
Protocol next hop: 10.0.0.7
Push 299888
Indirect next hop: 2 no-forward
State: <Active Int Ext>
Local AS: 65535 Peer AS: 65535
Age: 3:35:12 Metric2: 1
Task: BGP_65535.10.0.0.7+179
Announcement bits (2): 0-BGP Route Target 1-BGP_RT_Background
AS path: I
Communities: target:2:2
Accepted
VPN Label: 299888
Localpref: 100
Router ID: 10.0.0.7
Indirect next hops: 1
Protocol next hop: 10.0.0.7 Metric: 1
Push 299888
Indirect next hop: 2 no-forward
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.8.8.2 via ge-0/0/3.0
10.0.0.7/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.8.8.2 via ge-0/0/3.0

4.) PE1 HAS THIS INTERFACE IN OSPF AS A TYPE 2 LSA.... how is it entering BGP as a Type 5? Config below

!!!!!!!!! PE ROUTER ADVERTISING ITS LOCAL INTERFACE ON 172.17.1.0/30 INTO VRF

loj001@SP-LAB-PE1> show ospf database instance vpn-b network detail

OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Network *172.17.1.1 172.17.1.1 0x80000005 2642 0x22 0xa7d6 32
mask 255.255.255.252
attached router 172.17.1.1
attached router 192.168.17.1
Topology default (ID 0)
Type: Transit, Node ID: 192.168.17.1
Metric: 0, Bidirectional
Type: Transit, Node ID: 172.17.1.1
Metric: 0, Bidirectional

loj001@SP-LAB-PE1> show ospf interface instance vpn-b
Interface State Area DR ID BDR ID Nbrs
ge-0/0/5.0 DR 0.0.0.0 172.17.1.1 192.168.17.1 1

loj001@SP-LAB-PE1> show configuration protocols bgp
group SP-LAB {
type internal;
local-address 10.0.0.7;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
family route-target;
peer-as 65535;
bfd-liveness-detection {
minimum-interval 1000;
}
neighbor 10.0.0.1;
}

^
loj001@SP-LAB-PE1> show configuration routing-instances vpn-b
instance-type vrf;
interface ge-0/0/5.0;
route-distinguisher 10.0.0.7:2;
vrf-target target:2:2;
protocols {
ospf {
export policy-export-customer-b;
area 0.0.0.0 {
interface ge-0/0/5.0;
}
}
}

loj001@SP-LAB-PE1> show configuration policy-options
policy-statement policy-export-customer-b {
term bgp-networks {
from protocol bgp;
then accept;
}
}

Seittit · January 12, 2015, 08:27:14 PM

404 error on your link, but it sounds like you know what you're talking about

wintermute000 · January 12, 2015, 10:50:30 PM

a.) Fixed the link, thx
b.) Does this line in the Route Reflector indicate that the Type 2 LSA (the :2:) has been preserved @ this point? i.e. it is the egress PE that is choosing to send it into OSPF as a Type 5?

"10.0.0.7:2:172.17.1.0/30"

ScottF · January 13, 2015, 02:06:48 AM

I think if you look into OSPF superbackbone it might be what your looking for.

Your issue sounds similar to something I was taught on a course and that was the answer, whether your issue is the same I don't know.

wintermute000 · January 13, 2015, 02:42:19 AM

Yes the OSPF forms the superbackbone.

All Type 1, 2 and 3 LSAs will enter MP-BGP, then be re-advertised as Type 3 if the domain ID matches (or is missing). If the domain ID mismatches, it always gets sent as a Type 5.

The issue I have is: I don't have a domain ID set, which should default to null, which should result in Type 3s.
Routes advertised into OSPF by the CEs DO get the 'correct' treatment.
Its the /30s that are the PE VRF interface subnets that do not.... which doesn't add up in theory.

Also I am not 100% sure I am reading the RR vpnv4 routes correctly, can someone confirm whether this line in JunOS is the OSPF extended community? (Its a lot clearer in IOS).
10.0.0.7:2:172.17.1.0/30 <--- with the :2: being LSA type 2?

Reggle · January 13, 2015, 06:53:08 AM

Are you sure the domain-id defaults to null? I thought it didn't on a PE router...

that1guy15 · January 13, 2015, 08:10:51 AM

That looks like the RD to me but Im not familiar with JUNOS so Im going on my general knowledge.

Your correct on the the instance-ID must match for it to pass as type-3. For shiggles did you try setting an instance-ID?

Also are you running the same area between all three VPN-B routers? do both routes in question sit in the same area?

Where is Mellowd when we need him?

wintermute000 · January 14, 2015, 02:25:05 AM

Good pickup That1guy, it is the RD. In the bgp.l3vpn table (i.e. show ip bgp vpnv4) that's pretty clear

Quotebgp.l3vpn.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.0.7:1:172.16.1.0/30
*[BGP/170] 00:14:08, localpref 100, from 10.0.0.7
AS path: I
> to 10.8.8.2 via ge-0/0/3.0, Push 16, Push 299824(top)

Same OSPF area 0. I was actually going to lab up sham-link, but I got sidetracked on this goodie. Its certainly given me good practice crawling the various MPLS/VRF layers the JunOS way. I'm still struggling to see the OSPF extended community in the BGP info, where its so clear and obvious in IOS.

I did try to set the instance-ID but I'm afraid my Juniper import/export knowledge is not as good as I thought! That's what I'm working on now.

lol yeah Mellow would probably know this in a snap, that crazy double CCIE/JNCIE-SP!!!! I've actually been using his Juniper SP articles.

wintermute000 · January 14, 2015, 03:18:28 AM

It gets worse.
I moved from using vrf-target (the auto import/export way) to manual import/export policies (which I had to lab anyway later lol so I could practice VRF route leaking).
Using manual policies I was able to set the domain ID and have it clearly visible... but its still coming through my CEs as External. I guess this is because I'm explicitly exporting the route?

It would also appear that export policies don't work if using vrf-target method.

Thanks JNCIS-SP textbook for mentioning this!!!

Finally, another side effect of NOT using vrf-target is that ethernet interfaces do not get advertised into routing and you have to explicitly export them in policy and use a special command vrf-table-label.....

And just when I was loving the JunOS way they start hammering me with these WTF curveballs....

Oh well, at least IRL, nobody allows OSPF PE-CE peering... I've only ever seen it once in production. BGP or GTFO (So looking forwards to having to learn EIGRP PE-CE quirks for CCIEv5 syllabus!)

mellowd · January 14, 2015, 08:49:16 AM

What extended communities do you actually see on the MP-BGP routes?

mellowd · January 14, 2015, 08:55:54 AM

All all devices in the network Juniper btw?

wintermute000 · January 14, 2015, 03:44:30 PM

Hiya Mellow!

All vSRXs in ESXi.

Question for you SP expertise - given that Juniper doesn't auto export the VRF interfaces if multi-access (FE/GE), and that you need to explicitly export the directly connected interface even with vrf-table-label - whats standard practice in SP land? Do you guys also explicitly export the protocol direct in your export maps?

Also was wondering how the eff does it work if you DON'T export the direct protocol? As in Next Hop resolution once it gets to the egress PE??? (I'm going to turn off the directly connected exports now and see) EDIT It appears that the ingress PE router is using next hop self - when I examine a CE1 router /32 loopback advertised into PE1 vpn-a, the route in the bgp.l3vpn table has the PE1 RID as the next hop - is this something I missed during my reading?

Quote

loj001@SP-LAB-P1> show route 192.168.16.1/32 detail

bgp.l3vpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
10.0.0.7:1:192.168.16.1/32 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.7:1
Next hop type: Indirect
Address: 0x934d2a0
Next-hop reference count: 2
Source: 10.0.0.7
Protocol next hop: 10.0.0.7
Push 16
Indirect next hop: 2 no-forward
State: <Active Int Ext>
Local AS: 65535 Peer AS: 65535
Age: 1:28:39 Metric2: 1
Task: BGP_65535.10.0.0.7+179
Announcement bits (2): 0-BGP Route Target 1-BGP_RT_Background
AS path: 1 I
Communities: target:1:1
Accepted
VPN Label: 16
Localpref: 100
Router ID: 10.0.0.7

loj001@SP-LAB-P1>

here is the exact route for PE1's PE-CE /30 coming into the egress PE3 now that I'm using vrf import/export and adding domain-id community.

Note everything pings and traces as expected, its just understanding why I'm getting the OSPF Type 5 instead of the 3 as expected. LIke I said I do suspect in this configuration it is because the interface route is being explicitly exported into OSPF.

l

Quote

oj001@SP-LAB-PE3> show route 172.17.1.0/30 extensive

vpn-b.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
172.17.1.0/30 (1 entry, 1 announced)
TSI:
OSPF area : 0.0.0.0, LSA ID : 172.17.1.0, LSA type : Extern
KRT in-kernel 172.17.1.0/30 -> {indirect(262144)}
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.7:2
Next hop type: Indirect
Address: 0x934d768
Next-hop reference count: 3
Source: 10.0.0.1
Next hop type: Router, Next hop index: 632
Next hop: 10.2.2.1 via ge-0/0/1.0, selected
Label operation: Push 17, Push 299824(top)
Label TTL action: prop-ttl, prop-ttl(top)
Protocol next hop: 10.0.0.7
Push 17
Indirect next hop: 95243a0 262144
State: <Secondary Active Int Ext>
Local AS: 65535 Peer AS: 65535
Age: 1:10:20 Metric2: 1
Task: BGP_65535.10.0.0.1+52741
Announcement bits (2): 0-vpn-b-OSPF 1-KRT
AS path: I (Originator) Cluster list: 10.0.0.1
AS path: Originator ID: 10.0.0.7
Communities: target:2:2 domain-id:17.17.17.17:0
Import Accepted
VPN Label: 17
Localpref: 100
Router ID: 10.0.0.1
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: 10.0.0.7 Metric: 1
Push 17
Indirect next hop: 95243a0 262144
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.2.2.1 via ge-0/0/1.0
10.0.0.7/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.2.2.1 via ge-0/0/1.0

bgp.l3vpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)

10.0.0.7:2:172.17.1.0/30 (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.7:2
Next hop type: Indirect
Address: 0x934d768
Next-hop reference count: 3
Source: 10.0.0.1
Next hop type: Router, Next hop index: 632
Next hop: 10.2.2.1 via ge-0/0/1.0, selected
Label operation: Push 17, Push 299824(top)
Label TTL action: prop-ttl, prop-ttl(top)
Protocol next hop: 10.0.0.7
Push 17
Indirect next hop: 95243a0 262144
State: <Active Int Ext>
Local AS: 65535 Peer AS: 65535
Age: 1:10:21 Metric2: 1
Task: BGP_65535.10.0.0.1+52741
AS path: I (Originator) Cluster list: 10.0.0.1
AS path: Originator ID: 10.0.0.7
Communities: target:2:2 domain-id:17.17.17.17:0
Import Accepted
VPN Label: 17
Localpref: 100
Router ID: 10.0.0.1
Secondary Tables: vpn-b.inet.0
Indirect next hops: 1
Protocol next hop: 10.0.0.7 Metric: 1
Push 17
Indirect next hop: 95243a0 262144
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.2.2.1 via ge-0/0/1.0
10.0.0.7/32 Originating RIB: inet.3
Metric: 1 Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.2.2.1 via ge-0/0/1.0

my relevant PE config is here, all 3 are the same more or less. Note vpn-a is using standard PE-CE BGP which his working hunky dory.

Quote

protocols {
mpls {
icmp-tunneling;
interface all;
interface ge-0/0/0.0 {
disable;
}
interface ge-0/0/4.0 {
disable;
}
interface ge-0/0/5.0 {
disable;
}
}
bgp {
group SP-LAB {
type internal;
local-address 10.0.0.9;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
family route-target;
peer-as 65535;
bfd-liveness-detection {
minimum-interval 1000;
}
neighbor 10.0.0.1;
}
}
isis {
traceoptions {
file debug-isis size 65535 files 10;
flag general;
flag normal;
flag error;
flag policy;
flag ldp-synchronization;
}
interface ge-0/0/1.0 {
level 1 disable;
level 2 {
enable;
metric 5;
}
}
interface ge-0/0/2.0 {
level 1 disable;
level 2 enable;
}
interface lo0.0 {
passive;
level 1 disable;
}
}
ldp {
interface all;
}
}
policy-options {
policy-statement policy-export-customer-b {
term bgp-networks {
from protocol bgp;
then {
community add domain-b;
accept;
}
}
term end {
then reject;
}
}
policy-statement policy-export-vpn-a {
term export-bgp {
from protocol bgp;
then {
community add vpn-a;
accept;
}
}
term export-direct {
from protocol direct;
then {
community add vpn-a;
accept;
}
}
term end {
then reject;
}
}
policy-statement policy-export-vpn-b {
term export-ospf {
from protocol ospf;
then {
community add vpn-b;
community add domain-b;
accept;
}
}
term export-direct {
from protocol direct;
then {
community add vpn-b;
community add domain-b;
accept;
}
}
term end {
then reject;
}
}
policy-statement policy-import-vpn-a {
term import-bgp {
from {
protocol bgp;
community vpn-a;
}
then accept;
}
term end {
then reject;
}
}
policy-statement policy-import-vpn-b {
term import-bgp {
from {
protocol bgp;
community vpn-b;
}
then accept;
}
term end {
then reject;
}
}
community domain-b members domain-id:17.17.17.17:0;
community vpn-a members target:1:1;
community vpn-b members target:2:2;
}

routing-instances {
vpn-a {
instance-type vrf;
interface ge-0/0/4.0;
route-distinguisher 10.0.0.9:1;
vrf-import policy-import-vpn-a;
vrf-export policy-export-vpn-a;
vrf-table-label;
protocols {
bgp {
group customer-a {
type external;
peer-as 1;
as-override;
neighbor 172.16.3.2;
}
}
}
}
vpn-b {
instance-type vrf;
interface ge-0/0/5.0;
route-distinguisher 10.0.0.9:2;
vrf-import policy-import-vpn-b;
vrf-export policy-export-vpn-b;
vrf-table-label;
protocols {
ospf {
domain-id 17.17.17.17;
export policy-export-customer-b;
area 0.0.0.0 {
interface ge-0/0/5.0;
}
}
}
}
}

mellowd · January 15, 2015, 02:51:36 AM

It's certainly a quirk in Juniper land.

With IOS, you redistribute from OSPF into BGP and vice-versa. If you use the command vrf-target, Junos is doing some automatic redistribution for you. It's not entirely clear how it does it though, i.e. there are no knobs to turn.

But take a look at this. I labbed it up myself and I'm using 1.1.1.1/32 and 2.2.2.2/32 as loopbacks on the CE kit. I'm using the 10/8 range as the PE-CE links. If I look at the routes on the RR, there is something specific I see. Note the CE's database first:

Code Select

root@VJX0> show ospf database

Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x80000021   812  0x22 0xdf02  48
Router   10.0.0.1         10.0.0.1         0x8000000e   813  0x22 0xba3c  36
Network  10.0.0.1         10.0.0.1         0x80000007   813  0x22 0x23ec  32
Summary  2.2.2.2          10.0.0.1         0x80000001   280  0xa2 0x4f59  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   10.0.0.2         10.0.0.1         0x80000001  1178  0xa2 0xca7f  36

Here the router sees it's own type1 as well as the PE's type1. There is also a type2 for the segment and a type3 to get to 2.2.2.2/32 - Like you, I also see the remote pe-ce link as external.

I go over it a bit over here (https://mellowd.co.uk/ccie/?p=4697) but there is more than just one thing that is checked. Specifically non-matching domain ids will convert all internal and summaries to type5. However existing type5s remain as type5s.

But how does an MP-BGP router know what type a prefix is to begin with? There is another field that determines that, and that's where I see the difference.

Back on the route-reflector checking both vpnv4 routes check the difference here:

Code Select

1:1:2.2.2.2/32 (1 entry, 0 announced)
Communities: target:1:1 rte-type:0.0.0.0:1:0

Code Select

1:1:10.0.0.2/31 (1 entry, 0 announced)
Communities: target:1:1

Junos ensures 2.2.2.2/32 is advertised as a 'type1 lsa'. 10.0.0.2/31 has no such community. Seems to me that Junos makes no assumptions here and absence of that community means don't assume it's internal.

The annoying thing is that the vrt-target command gives you no options to add or subtract stuff when using it. It's an 'automatic' knob.

As you rightly stated, if you export directly connected, Junos assumes you're redistributing an external route and it becomes a type5. In IOS, redistributing OSPF ensures the pe-ce OSPF link is in MP-BGP, not so in Junos.

As for how I do this with customers, the last carrier I worked for we only did managed solutions. i.e. we controlled the CE as well. For this reason we didn't bother putting the pe-ce link inside the customers network. We used that for p2p testing only. The prefixes that sat behind the router were the only ones redistributed into the VPN

Seittit · January 15, 2015, 03:26:47 AM

Good God, we've missed posts from mellowd

wintermute000 · January 15, 2015, 04:08:37 AM

Awesome, thanks for confirming. So ruling out vrf-target due to lack of options, say we're manually importing/exporting, what are out options?

I tried to manually tag that rte-type community but its rejected. Morever that's a terrible solution, you'd need to match only Type 1/2/3, manually specify the area etc... is this just a limitation of doing OSPF PE-CE on JunOS?

BTW been reading your articles including that one, thanks for taking the time! Going for JNCIS-SP shortly and your articles (and explanation above!) have always been a great help.

loj001@SP-LAB-PE1# set policy-options community domain-b members rte-type:0.0.0.0:1:0

[edit]
loj001@SP-LAB-PE1# commit
[edit policy-options community domain-b members]
'rte-type:0.0.0.0:1:0'
Unknown extended community type
error: configuration check-out failed

OSPF External routes on directly connected VRF interfaces

Seittit

Seittit