Hub and spoke VPN with 2 interfaces

Hi I am doing this lab following the JUNOS8.5 SW config guide:

ce2---pe2---\___pe1=====ce1
ce3---pe3---/

the strange thing is pe1 just refused to announce ce2&3 routes back to ce2&3, even if I config AS loops 1. As a result, ce2 does not have ce3 routes, and ce3 does not have ce2 routes. Only ce1 has both.

The guide says ce1 should receive all routes from one of its ce-pe interfaces and announce all routes through another via ospf. But the problem is pe1 will prefer bgp routes to ce2&3, so redistributing ospf to bgp on pe1 will not announce ce2&3 at all. I think there is error on the guide, but I could not figure out how to make it work.

Can anyone lend a hand on this? Thanks!

Find more posts tagged with

Comments

Ezlite

Hmm .. do not have "JUNOS8.5 SW config guide" handy or where in it you are looking .. can you give a few general details on the topology

Aldur

It sounds like your breaking the full mesh BGP requirement. If this is whats happening enable a full mesh or throw a route reflector in there.

Then use rsvp lsp's to traffic engineer the network to do what you want.

yren

Ezlite wrote: »

Hmm .. do not have "JUNOS8.5 SW config guide" handy or where in it you are looking .. can you give a few general details on the topology

Sorry for that. The guide is:
JUNOS 8.5 VPNs Configuration Guide
Then select Layer3 VPN configuration example->Configuring Hub-and-Spoke VPN Topologies: Two Interfaces

pe1 announces ce2&3 routes (200.200/16, 203.203/16) from its vrf (name: in) to ce1 via the first ce-pe interface. And ce1 does announce these back to pe1 vrf (name: out) through the second ce-pe interface. But for some reason, pe1 vrf "out" install these lsa in the database as inactive, that's why redistributing ospf does not announce them to pe2/pe3. I still have no idea...

lab@jncie# run show ospf database logical-router r2 instance out

OSPF link state database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 12.12.12.2 12.12.12.2 0x8000001a 1289 0x22 0xc8b6 36
Router *21.21.21.2 21.21.21.2 0x80000018 1282 0x22 0xc650 36
Router 100.100.0.1 100.100.0.1 0x80000022 1283 0x22 0xfdc9 60
Network 12.12.12.1 100.100.0.1 0x8000000a 1288 0x22 0xda77 32
Network 21.21.21.1 100.100.0.1 0x8000000e 1283 0x22 0xd245 32
Summary 200.200.0.1 12.12.12.2 0x80000005 613 0xa2 0x31cd 28
Summary 203.203.0.1 12.12.12.2 0x80000004 1483 0xa2 0xe712 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 100.100.0.0 100.100.0.1 0x80000009 870 0x22 0x72a5 36
Extern 100.100.1.0 100.100.0.1 0x80000009 570 0x22 0x67af 36
Extern 100.100.2.0 100.100.0.1 0x80000009 270 0x22 0x5cb9 36
Extern 100.100.3.0 100.100.0.1 0x80000007 1298 0x22 0x55c1 36
Extern 200.200.0.0 12.12.12.2 0x80000005 583 0xa2 0xf34d 36
Extern 200.200.1.0 12.12.12.2 0x80000005 313 0xa2 0xe857 36
Extern 200.200.2.0 12.12.12.2 0x80000005 283 0xa2 0xdd61 36
Extern 200.200.3.0 12.12.12.2 0x80000005 13 0xa2 0xd26b 36
Extern 203.203.0.0 12.12.12.2 0x80000004 1213 0xa2 0xaa91 36
Extern 203.203.1.0 12.12.12.2 0x80000004 1183 0xa2 0x9f9b 36
Extern 203.203.2.0 12.12.12.2 0x80000004 913 0xa2 0x94a5 36
Extern 203.203.3.0 12.12.12.2 0x80000004 883 0xa2 0x89af 36

yren

Aldur wrote: »

It sounds like your breaking the full mesh BGP requirement. If this is whats happening enable a full mesh or throw a route reflector in there.

Then use rsvp lsp's to traffic engineer the network to do what you want.

The lab scenario is if ce2 wants to reach ce3, it will follow:
ce2->pe2->pe1->ce1->pe1->pe3->ce3, it looks not optimal, but this is what "hub and spoke" stand for. Let me know if I am wrong.

there is no bgp full mesh nor RR, there are 2 vrfs on pe1, one for inbound traffic from ce2/3 to ce1, and the other is for outbound from ce1, all 3 ces are in same VPN

Hope I have explained the problem clearly, thanks.

hoogen82

Post your configs..

Aldur

yren wrote: »

The lab scenario is if ce2 wants to reach ce3, it will follow:
ce2->pe2->pe1->ce1->pe1->pe3->ce3, it looks not optimal, but this is what "hub and spoke" stand for. Let me know if I am wrong.

Yup, you got the concept right, that's what hub and spoke is all about.

yren wrote: »

there is no bgp full mesh nor RR, there are 2 vrfs on pe1, one for inbound traffic from ce2/3 to ce1, and the other is for outbound from ce1, all 3 ces are in same VPN

Sorry about that, misread your question. Yea, shouldn't need a full mesh to do what you're trying to do.

I agree with hoogen, lets see some configs, might be something funny going on in there.

yren

hoogen82 wrote: »

Post your configs..

r1=ce1, r2=pe1, r3=pe2, r4=ce2, r5=pe3, r6=ce3

lab@jncie# show
## Last changed: 2010-03-26 05:45:14 UTC
version 8.5R1.14;
system {
host-name jncie;
root-authentication {
encrypted-password "$1$ZGNS2NlL$i6XzgDxf3P1tmv/8cAPYg0"; ## SECRET-DATA
}
login {
user lab {
uid 2004;
class super-user;
authentication {
encrypted-password "$1$7k1tRBs4$fKmfaPEJbDmL94ohFbVbc1"; ## SECRET-DATA
}
}
}
services {
ftp;
telnet;
}
}
logical-routers {
r1 {
interfaces {
em1 {
unit 12 {
vlan-id 12;
family inet {
address 12.12.12.1/24;
}
}
unit 21 {
vlan-id 21;
family inet {
address 21.21.21.1/24;
}
}
}
lo0 {
unit 1 {
family inet {
address 100.100.0.1/32;
}
}
}
}
protocols {
ospf {
export static;
area 0.0.0.0 {
interface lo0.1;
interface em1.12;
interface em1.21;
}
}
}
policy-options {
policy-statement static {
term 1 {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 100.100.0.0/24 reject;
route 100.100.1.0/24 reject;
route 100.100.2.0/24 reject;
route 100.100.3.0/24 reject;
}
autonomous-system 1;
}
}
r2 {
interfaces {
em2 {
unit 12 {
vlan-id 12;
family inet {
address 12.12.12.2/24;
}
}
unit 21 {
vlan-id 21;
family inet {
address 21.21.21.2/24;
}
}
unit 23 {
vlan-id 23;
family inet {
address 23.23.23.1/24;
}
family iso;
family mpls;
}
unit 25 {
vlan-id 25;
family inet {
address 25.25.25.1/24;
}
family iso;
family mpls;
}
}
lo0 {
unit 2 {
family inet {
address 2.2.2.2/32;
}
family iso {
address 49.0001.2222.2222.2222.00;
}
}
}
}
protocols {
mpls {
interface all;
}
bgp {
group 1 {
type internal;
local-address 2.2.2.2;
neighbor 3.3.3.3 {
family inet-vpn {
unicast;
}
}
neighbor 5.5.5.5 {
family inet-vpn {
unicast;
}
}
}
}
isis {
interface em2.23;
interface em2.25;
interface lo0.2;
}
ldp {
interface all;
}
}
policy-options {
policy-statement bgp-ospf {
term 1 {
from protocol bgp;
then accept;
}
}
policy-statement in-exp {
term 1 {
then reject;
}
}
policy-statement in-imp {
term 1 {
from {
protocol bgp;
community in;
}
then accept;
}
}
policy-statement out-exp {
term 1 {
from protocol ospf;
then {
community add out;
accept;
}
}
}
policy-statement out-imp {
term 1 {
then reject;
}
}
community in members target:100:100;
community out members target:100:101;
}
routing-instances {
in {
instance-type vrf;
interface em2.12;
route-distinguisher 2.2.2.2:1;
vrf-import in-imp;
vrf-export in-exp;
vrf-table-label;
protocols {
ospf {
export bgp-ospf;
area 0.0.0.0 {
interface em2.12;
}
}
}
}
out {
instance-type vrf;
interface em2.21;
route-distinguisher 2.2.2.2:2;
vrf-import out-imp;
vrf-export out-exp;
vrf-table-label;
protocols {
ospf {
area 0.0.0.0 {
interface em2.21;
}
}
}
}
}
routing-options {
autonomous-system 100 loops 1;
}
}
r3 {
interfaces {
em3 {
unit 23 {
vlan-id 23;
family inet {
address 23.23.23.2/24;
}
family iso;
family mpls;
}
unit 34 {
vlan-id 34;
family inet {
address 34.34.34.1/24;
}
family mpls;
}
}
lo0 {
unit 3 {
family inet {
address 3.3.3.3/32;
}
family iso {
address 49.0001.3333.3333.3333.00;
}
}
}
}
protocols {
mpls {
interface all;
}
bgp {
group 1 {
type internal;
local-address 3.3.3.3;
neighbor 2.2.2.2 {
family inet-vpn {
unicast;
}
}
}
}
isis {
interface em3.23;
interface lo0.3;
}
ldp {
interface all;
}
}
policy-options {
policy-statement bgp-ospf {
term 1 {
from protocol bgp;
then accept;
}
}
policy-statement c2-exp {
term 1 {
from protocol ospf;
then {
community add in;
accept;
}
}
}
policy-statement c2-imp {
term 1 {
from {
protocol bgp;
community out;
}
then accept;
}
}
community in members target:100:100;
community out members target:100:101;
}
routing-instances {
c2 {
instance-type vrf;
interface em3.34;
route-distinguisher 3.3.3.3:1;
vrf-import c2-imp;
vrf-export c2-exp;
vrf-table-label;
protocols {
ospf {
export bgp-ospf;
area 0.0.0.0 {
interface em3.34;
}
}
}
}
}
routing-options {
autonomous-system 100 loops 1;
}
}
r4 {
interfaces {
em4 {
unit 34 {
vlan-id 34;
family inet {
address 34.34.34.2/24;
}
}
}
lo0 {
unit 4 {
family inet {
address 200.200.0.1/32;
}
}
}
}
protocols {
ospf {
export static;
area 0.0.0.0 {
interface lo0.4;
interface em4.34;
}
}
}
policy-options {
policy-statement static {
term 1 {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 200.200.0.0/24 reject;
route 200.200.1.0/24 reject;
route 200.200.2.0/24 reject;
route 200.200.3.0/24 reject;
}
autonomous-system 1;
}
}
r5 {
interfaces {
em5 {
unit 25 {
vlan-id 25;
family inet {
address 25.25.25.2/24;
}
family iso;
family mpls;
}
unit 56 {
vlan-id 56;
family inet {
address 56.56.56.1/24;
}
family mpls;
}
}
lo0 {
unit 5 {
family inet {
address 5.5.5.5/32;
}
family iso {
address 49.0001.5555.5555.5555.00;
}
}
}
}
protocols {
mpls {
interface all;
}
bgp {
group 1 {
type internal;
local-address 5.5.5.5;
neighbor 2.2.2.2 {
family inet-vpn {
unicast;
}
}
}
}
isis {
interface em5.25;
interface lo0.5;
}
ldp {
interface all;
}
}
policy-options {
policy-statement bgp-ospf {
term 1 {
from protocol bgp;
then accept;
}
}
policy-statement c3-exp {
term 1 {
from protocol ospf;
then {
community add in;
accept;
}
}
}
policy-statement c3-imp {
term 1 {
from {
protocol bgp;
community out;
}
then accept;
}
}
community in members target:100:100;
community out members target:100:101;
}
routing-instances {
c3 {
instance-type vrf;
interface em5.56;
route-distinguisher 5.5.5.5:1;
vrf-import c3-imp;
vrf-export c3-exp;
vrf-table-label;
protocols {
ospf {
export bgp-ospf;
area 0.0.0.0 {
interface em5.56;
}
}
}
}
}
routing-options {
autonomous-system 100 loops 1;
}
}
r6 {
interfaces {
em6 {
unit 56 {
vlan-id 56;
family inet {
address 56.56.56.2/24;
}
}
}
lo0 {
unit 6 {
family inet {
address 203.203.0.1/32;
}
}
}
}
protocols {
ospf {
export static;
area 0.0.0.0 {
interface lo0.6;
interface em6.56;
}
}
}
policy-options {
policy-statement static {
term 1 {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 203.203.0.0/24 reject;
route 203.203.1.0/24 reject;
route 203.203.2.0/24 reject;
route 203.203.3.0/24 reject;
}
autonomous-system 1;
}
}
}
interfaces {
em0 {
unit 0 {
family inet {
address 192.168.2.9/24;
}
}
}
em1 {
vlan-tagging;
}
em2 {
vlan-tagging;
}
em3 {
vlan-tagging;
}
em4 {
vlan-tagging;
}
em5 {
vlan-tagging;
}
em6 {
vlan-tagging;
}
em7 {
vlan-tagging;
}
}

hoogen82

Too much info to read across.. Something I noticed.. Add "set protocols ospf domain-vpn-tag 0" on the hub router's Spoke instance.. that I believe is "out" in your case?

Hub sites requires this configuration on the spoke instance so that the hub instance will insall the routes to spoke CE.. You are running OSPF which carry a bit to prevent looping.. I don't remember much of the bit and how it affects OSPF.. but I know you need this command in the Hub Spoke scenario..

I also believe domain id's are very important when running OSPF hub-spoke scenario's

yren

hoogen82 wrote: »

Too much info to read across.. Something I noticed.. Add "set protocols ospf domain-vpn-tag 0" on the hub router's Spoke instance.. that I believe is "out" in your case?

Hub sites requires this configuration on the spoke instance so that the hub instance will insall the routes to spoke CE.. You are running OSPF which carry a bit to prevent looping.. I don't remember much of the bit and how it affects OSPF.. but I know you need this command in the Hub Spoke scenario..

I also believe domain id's are very important when running OSPF hub-spoke scenario's

Great, it works!!! As soon as i add "set proto ospf domain-vpn-tag 0", the problem was fixed. But it should be added to the routing-instance of "in", which is receiving routes from ce2&3

Just curious, how did you know this command? It is not mentioned at all in the JNCIE book, nor in the JUNOS 85 VPN config guide

Not sure how many such "hidden" commands will be tested in the real lab

Aldur

Good call hoogen!!

yren wrote: »

Not sure how many such "hidden" commands will be tested in the real lab

Is domain-vpn-tag hidden in 8.5? It's visible in 9.6.

hoogen82

@Aldur: I think he was more referring to the limitless options that can be tested on Junos...

Yuking my best advice.. do not get paranoid.. the lab is expert level.. and I believe you are almost there... This might be just a one off case that required some help..But I might say that this though was part of Hub-Spoke.. I had to some document research to get this working for me before... Good thing is that you are doing the hard work..And it will definitely pay off...

Aldur

hoogen82 wrote: »

@Aldur: I think he was more referring to the limitless options that can be tested on Junos... QUOTE]

Heh, yea, should have picked up on that. My only excuse is that it's Monday

yren

Aldur wrote: »

hoogen82 wrote: »

@Aldur: I think he was more referring to the limitless options that can be tested on Junos... QUOTE]

Heh, yea, should have picked up on that. My only excuse is that it's Monday

Aldur, sorry I said hidden just because it is not mentioned in the Junos85 Hub-spoke VPN config guide. It is definitely visible from the cli and it was introduced before junos7.4

Hoogen, thanks for advice. As some great guy said: "Only the Paranoid Survive", I am working hard to be one of them

Aldur

heh, no worries man, a command you don't know about is basically hidden

seriously, being a little paranoid and learning even the odd commands will save your butt at the end of the day. Good advice indeed

yren

Aldur wrote: »

heh, no worries man, a command you don't know about is basically hidden

Good point:)
I tried to change the ce-pe protocol to bgp on hub PE, and it seems not working again as I expected. Is there any equivalent of domain-vpn-tag for BGP? Or knob? I would like to call it "hidden" again as I definitely have no idea here:) Forgive me!

Another strange thing is I configured interprovide vpn (using RFC 4364 option 3) and CEs can learn all necessary routes. But I just can not ping or trace, even if the routes are there. My question is is it a problem of Olive? I am using VMware+Junos85. There are 2 problems I previously encountered when do VPN on olive: 1. must use vrf-table-label to enable ping in a VPN 2. must config protocol mpls icmp-tunneling to see the lsp when do CE-CE tracing (adviced by hoogen, thanks man!)

Not sure how import they are in terms of the JNCIE test, but I am just curious and hate to leave them unresolved!

hoogen82

Please post advertise/receive protocol output from hub.. show route hidden detail..

Also the last two problems you wouldn't require those commands on M-Series

yren

hoogen82 wrote: »

Please post advertise/receive protocol output from hub.. show route hidden detail..

Also the last two problems you wouldn't require those commands on M-Series

For the hub-spoke question using bgp, I figured it out.
If only bgp is used in hub-ce to hub-pe, then hub-ce needs be configured as-override on the bgp neighbor sending out the prefix, not on the neighbor receiving the prefix. (It has 2 bgp neighbors since there are 2 ce-pe interfaces)
If bgp is used in all ce-pe connections, then each PE should configure as-override on the vrf bgp neighbor facing the CE. For hub-PE, only vrf "in" needs config as-override since it is sending the prefix to hub-CE.
As a result, CEs' routes will be reflected back to themselves by PEs, since their original AS number is removed and PE believes this is a new ebgp peer with different AS number...I believe there are many ways to prevent this happening. I applied an export policy on the VRF BGP neighbor. In the policy, everything learned from protocol bgp, neighbor (ce's ip) is rejected.
I did not use "autonomos systems X loops 1" which is suggested in the SW config guide on PEs since hub-PE's AS number is overriden by hub-CE so it has no chance to see loop in AS-path.
Please let me know what you guys are doing to prevent loop, thanks!