Mailing List Archive

mkrzych@post.pl (Krzysztof Maj) writes:

> Hi,
> I have a question about a VPN Hub and Spoke topology, but a quite bit
> diffrent then a normal Juniper configuration. As everybody can read in
> docs I have for example 2 CE's connected to diffrent PE's (Spokes) and
> one PE with HUB CE router.
> To achieve this topology I must to configure two VRF: one for spokes
> and one for Hub routes.

You need 2 route targets. You may or may not need two VRFs in a given PE.

> I must to have two interfaces to hub CE router
> in diffrent VRFs too. Is it true?

Not is most cases. The recomendation for 2 interfaces comes from
scenarios where it is required to advertised routes received from
remote spokes back into other spokes. Given that there is no loop
prevention mechanism for that scenario, one must pass those through
and external peering session that tags an AS# to it...

Still, w/ 6.0+ i would probably recomend that you use a logical router
inside the box, or some other hackery, to loop routes around.

>
> Now imagine that I have 3 CE routers in one PE location and one CE
> router in other PE location where the hub is connected. All 4 CE
> routers are in the same VPN!

If you have spoke + hub in same PE these must be in separate VRFs. A
VRF is essentially a routing view and these guys need a different view
of the universe.

> I like to all traffic from particular CE's (Spokes) send via Hub CE,
> but not between CE's directly.
> Remember that all routers are in the same VPN (I have one VRF).

Not sure i can parse this statement. A typical hub & spoke scenario is
where spokes are not allowed to talk to each other directly.

The simplest configuration for this is:

routing-instances {
spoke {
instance-type vrf;
vrf-target import target:10458:1; /* hub RT */
vrf-target export target:10458:2; /* spoke RT */
interface ;
}
hub {
instance-type vrf;
vrf-target export target:10458:1; /* hub RT */
vrf-target import target:10458:2; /* spoke RT */
interface <if-hub>;
routing-options {
static {
x.y/z { /* aggregate of spoke prefixes */
next-hop <if-hub>;
}
}
}
}
}

This is if you have mpls switching downstream on the hub instance. If
you want to enable IP switching there it is a tad bit more complex in
terms of policy.

>
> The question is how I can do it?

In way too many ways :-)

Not sure i understand the full contrains of your problem.

Pedro.

In 6.0+ can you shed some light regarding to the use of logical router
or other hackeries to loop routes around?

-joe


-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Pedro Roque
Marques
Sent: Friday, November 07, 2003 2:32 PM
To: Krzysztof Maj
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Hub and Spoke VPN

mkrzych@post.pl (Krzysztof Maj) writes:

> Hi,
> I have a question about a VPN Hub and Spoke topology, but a quite bit
> diffrent then a normal Juniper configuration. As everybody can read in
> docs I have for example 2 CE's connected to diffrent PE's (Spokes) and
> one PE with HUB CE router.
> To achieve this topology I must to configure two VRF: one for spokes
> and one for Hub routes.

You need 2 route targets. You may or may not need two VRFs in a given
PE.

> I must to have two interfaces to hub CE router
> in diffrent VRFs too. Is it true?

Not is most cases. The recomendation for 2 interfaces comes from
scenarios where it is required to advertised routes received from
remote spokes back into other spokes. Given that there is no loop
prevention mechanism for that scenario, one must pass those through
and external peering session that tags an AS# to it...

Still, w/ 6.0+ i would probably recomend that you use a logical router
inside the box, or some other hackery, to loop routes around.

>
> Now imagine that I have 3 CE routers in one PE location and one CE
> router in other PE location where the hub is connected. All 4 CE
> routers are in the same VPN!

If you have spoke + hub in same PE these must be in separate VRFs. A
VRF is essentially a routing view and these guys need a different view
of the universe.

> I like to all traffic from particular CE's (Spokes) send via Hub CE,
> but not between CE's directly.
> Remember that all routers are in the same VPN (I have one VRF).

Not sure i can parse this statement. A typical hub & spoke scenario is
where spokes are not allowed to talk to each other directly.

The simplest configuration for this is:

routing-instances {
spoke {
instance-type vrf;
vrf-target import target:10458:1; /* hub RT */
vrf-target export target:10458:2; /* spoke RT */
interface ;
}
hub {
instance-type vrf;
vrf-target export target:10458:1; /* hub RT */
vrf-target import target:10458:2; /* spoke RT */
interface <if-hub>;
routing-options {
static {
x.y/z { /* aggregate of spoke
prefixes */
next-hop <if-hub>;
}
}
}
}
}

This is if you have mpls switching downstream on the hub instance. If
you want to enable IP switching there it is a tad bit more complex in
terms of policy.

>
> The question is how I can do it?

In way too many ways :-)

Not sure i understand the full contrains of your problem.

Pedro.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

Joe Lin writes:

> In 6.0+ can you shed some light regarding to the use of logical
> router or other hackeries to loop routes around?

You need a "router" to append something to the as-path in order to do
loop avoidance...

One could configure an LR for this purpose. Add a logical tunnel
interface pair between the main guy and the LR and loop routes that
way, via peering through the LR.

I haven't tried this myself so i don't have configs but it should be
doable.

Still, back to hub and spoke, do you really need to reflect spoke
routs back to other spokes ? shouldn't you be able to aggregate them
and/or inject a default at the hub ?

Pedro.

Well,

if you had multiple Hubs in your hub and spoke VPN. you wouldn't be able to
inject the default.

Altho, I haven't seen any deployment of such topology yet...

-Joe
----- Original Message -----
From: "Pedro Roque Marques" <roque@juniper.net>
To: "Joe Lin" <jlin@doradosoftware.com>
Cc: "'Krzysztof Maj'" <mkrzych@post.pl>; <juniper-nsp@puck.nether.net>
Sent: Friday, November 07, 2003 4:24 PM
Subject: RE: [j-nsp] Hub and Spoke VPN


> Joe Lin writes:
>
> > In 6.0+ can you shed some light regarding to the use of logical
> > router or other hackeries to loop routes around?
>
> You need a "router" to append something to the as-path in order to do
> loop avoidance...
>
> One could configure an LR for this purpose. Add a logical tunnel
> interface pair between the main guy and the LR and loop routes that
> way, via peering through the LR.
>
> I haven't tried this myself so i don't have configs but it should be
> doable.
>
> Still, back to hub and spoke, do you really need to reflect spoke
> routs back to other spokes ? shouldn't you be able to aggregate them
> and/or inject a default at the hub ?
>
> Pedro.
>
>

As I understood two ifaces in separate VRFs are required in scenario
when I want to send traffic via hub back to other spokes. Is it
possible to communicate groups of spokes in this way? (something like
full mesh topology)
My configs may be diffrent, hub and spokes in same PE or not, spokes
may talk to each other only via hub or in scenario when I have 3
spokes in same PE and one hub in diffrent PE I want to send traffic
only via hub back to other spokes.

> mkrzych@post.pl (Krzysztof Maj) writes:
>
> > Hi,
> > I have a question about a VPN Hub and Spoke topology, but a quite bit
> > diffrent then a normal Juniper configuration. As everybody can read in
> > docs I have for example 2 CE's connected to diffrent PE's (Spokes) and
> > one PE with HUB CE router.
> > To achieve this topology I must to configure two VRF: one for spokes
> > and one for Hub routes.
>
> You need 2 route targets. You may or may not need two VRFs in a given PE.
>
> > I must to have two interfaces to hub CE router
> > in diffrent VRFs too. Is it true?
>
> Not is most cases. The recomendation for 2 interfaces comes from
> scenarios where it is required to advertised routes received from
> remote spokes back into other spokes. Given that there is no loop
> prevention mechanism for that scenario, one must pass those through
> and external peering session that tags an AS# to it...
>
> Still, w/ 6.0+ i would probably recomend that you use a logical router
> inside the box, or some other hackery, to loop routes around.
>
> >
> > Now imagine that I have 3 CE routers in one PE location and one CE
> > router in other PE location where the hub is connected. All 4 CE
> > routers are in the same VPN!
>
> If you have spoke + hub in same PE these must be in separate VRFs. A
> VRF is essentially a routing view and these guys need a different view
> of the universe.
>
> > I like to all traffic from particular CE's (Spokes) send via Hub CE,
> > but not between CE's directly.
> > Remember that all routers are in the same VPN (I have one VRF).
>
> Not sure i can parse this statement. A typical hub & spoke scenario is
> where spokes are not allowed to talk to each other directly.
>
> The simplest configuration for this is:
>
> routing-instances {
> spoke {
> instance-type vrf;
> vrf-target import target:10458:1; /* hub RT */
> vrf-target export target:10458:2; /* spoke RT */
> interface ;
> }
> hub {
> instance-type vrf;
> vrf-target export target:10458:1; /* hub RT */
> vrf-target import target:10458:2; /* spoke RT */
> interface <if-hub>;
> routing-options {
> static {
> x.y/z { /* aggregate of spoke prefixes */
> next-hop <if-hub>;
> }
> }
> }
> }
> }
>
> This is if you have mpls switching downstream on the hub instance. If
> you want to enable IP switching there it is a tad bit more complex in
> terms of policy.
>
> >
> > The question is how I can do it?
>
> In way too many ways :-)
>
> Not sure i understand the full contrains of your problem.
>
> Pedro.
>

Krzysztof Maj writes:

> As I understood two ifaces in separate VRFs are required in scenario
> when I want to send traffic via hub back to other spokes.

Not really... 2 ifaces are only required if you want to exchange spoke
routing information back to other spokes.

> Is it
> possible to communicate groups of spokes in this way? (something
> like full mesh topology)
My configs may be diffrent, hub and spokes
> in same PE or not, spokes may talk to each other only via hub or in
> scenario when I have 3 spokes in same PE and one hub in diffrent PE
> I want to send traffic only via hub back to other spokes.

You can do all this w/ a single ifl between CE and PE.

Pedro.

Let's say we have the following scenario:
_______ _______
S----| | | |
S----| | | |
S----| | | |-------Hub
S----| PE1 |---------| PE2 |
S----| | | |
S----|_____| |_____|

S - spoke sites connected via different [sub]interfaces to the
same vrf.

The main goal is to force the spokes to communicate only via hub.
Putting all spoke subinterfaces into single vrf is the simplest
solution to maintain and most preffered, however you have to set
static routes in this vrf to reach a particular spoke site. This
will cause that it is possible to reach spoke site 1 from spoke
site 2 omitting the hub site. (traffic will be routed within PE1
even if hub will export default route pointing it)
There can be more PE's with spokes connected to it. Is there any
way to achieve it without complicating things, like separate VRF
for each site?

Best regards,
Adam

-------------------------------------------------------------------
Rozejrzyj si? woko?o... ?wiat wilko?ak?w i wampir?w
jest bli?ej ni? si? wydaje! "Underworld" w kinach od 28 listopada!
http://film.wp.pl/p/film.html?id=7801

There are a number of options to achieve what you want. However, since "without complicating things" is subject to personal opinion it is probably hard to identify the "simplest" options:

- One VRF for every spoke (on the same PE), but I understand this is too complex in your opinion.
- An upstream and a downstream VRF, this also requires a upstream and downstream interface per spoke. Spokes send traffic through the upstream VRF (that only imports a default from the hub), and receive traffc through the downstream interface/VRF. This introduces some issues related unidirectional links.
- GRE tunnels from spokes to hub, only distribute loopbacks in the VRF/VPN, rest of routing through tunnels (e.g. OSPF).
- L2VPN solution, this requires as many sub-interfaces on the hub as there are spokes.

Possibly there are number more ...

cheers,
Eduard

ps in theory, you like to force the 'next-hop' of packets received on spoke interfaces (on the PE) to be set to the hub PE, but I'm not sure if this can be actually configured in a Juniper (or any other) box

> -----Original Message-----
> From: Adam Szymajda [mailto:aszymajd@wp.pl]
> Sent: vrijdag 14 november 2003 9:46
> To: juniper-nsp@puck.nether.net
> Subject: Re: Re: [j-nsp] Hub and Spoke VPN
>
>
> Let's say we have the following scenario:
> _______ _______
> S----| | | |
> S----| | | |
> S----| | | |-------Hub
> S----| PE1 |---------| PE2 |
> S----| | | |
> S----|_____| |_____|
>
> S - spoke sites connected via different [sub]interfaces to the
> same vrf.
>
> The main goal is to force the spokes to communicate only via hub.
> Putting all spoke subinterfaces into single vrf is the simplest
> solution to maintain and most preffered, however you have to set
> static routes in this vrf to reach a particular spoke site. This
> will cause that it is possible to reach spoke site 1 from spoke
> site 2 omitting the hub site. (traffic will be routed within PE1
> even if hub will export default route pointing it)
> There can be more PE's with spokes connected to it. Is there any
> way to achieve it without complicating things, like separate VRF
> for each site?
>
> Best regards,
> Adam
>
> -------------------------------------------------------------------
> Rozejrzyj si? woko?o... ?wiat wilko?ak?w i wampir?w
> jest bli?ej ni? si? wydaje! "Underworld" w kinach od 28 listopada!
> http://film.wp.pl/p/film.html?id=7801
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

You should have a separate vrf per spoke site. This way, you can avoid
possible operational config fubars, and each spoke site's view of the world
would be contain in their own vrf.

if you want all the spokes in one vrf because of design issues. You could
achieve the same if you used static routes or do policy trickery/egress
filtering..

but that seems like a lot of work when the easy way is to have a vrf per
spoke.

If this is for L2VPN or CCC, you can nail up p2p connections from spoke to
hub..

-joe

----- Original Message -----
From: "Adam Szymajda" <aszymajd@wp.pl>
To: <juniper-nsp@puck.nether.net>
Sent: Friday, November 14, 2003 12:46 AM
Subject: Re: Re: [j-nsp] Hub and Spoke VPN


> Let's say we have the following scenario:
> _______ _______
> S----| | | |
> S----| | | |
> S----| | | |-------Hub
> S----| PE1 |---------| PE2 |
> S----| | | |
> S----|_____| |_____|
>
> S - spoke sites connected via different [sub]interfaces to the
> same vrf.
>
> The main goal is to force the spokes to communicate only via hub.
> Putting all spoke subinterfaces into single vrf is the simplest
> solution to maintain and most preffered, however you have to set
> static routes in this vrf to reach a particular spoke site. This
> will cause that it is possible to reach spoke site 1 from spoke
> site 2 omitting the hub site. (traffic will be routed within PE1
> even if hub will export default route pointing it)
> There can be more PE's with spokes connected to it. Is there any
> way to achieve it without complicating things, like separate VRF
> for each site?
>
> Best regards,
> Adam
>
> -------------------------------------------------------------------
> Rozejrzyj si? woko?o... ?wiat wilko?ak?w i wampir?w
> jest bli?ej ni? si? wydaje! "Underworld" w kinach od 28 listopada!
> http://film.wp.pl/p/film.html?id=7801
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

aszymajd@wp.pl (Adam Szymajda) writes:

> Let's say we have the following scenario:
> _______ _______
> S----| | | |
> S----| | | |
> S----| | | |-------Hub
> S----| PE1 |---------| PE2 |
> S----| | | |
> S----|_____| |_____|
>
> S - spoke sites connected via different [sub]interfaces to the
> same vrf.
>
> The main goal is to force the spokes to communicate only via hub.

Yes, i believe that is what everybody understands by "hub & spoke".

> Putting all spoke subinterfaces into single vrf is the simplest
> solution to maintain and most preffered, however you have to set
> static routes in this vrf to reach a particular spoke site. This
> will cause that it is possible to reach spoke site 1 from spoke
> site 2 omitting the hub site. (traffic will be routed within PE1
> even if hub will export default route pointing it)

You can do this w/ 2 VRFs on PE1. One VRF that is used for routing
information and for the forwarding information that is used downstream
(traffic received from other PEs) and one VRF that is used to switch
traffic from the PEs.

This would work like this:

All 'spoke' interfaces belong to 'spoke_main' VRF but have FBF nexthop
into 'spoke_upstream' VRF.

routing-intances {
spoke_main { /* this is the routing-instance
advertised via 2547 */
interface <s1>;
interface <s2>;
...
interface <sn>;
vrf-import <reject-all>;
vrf-export <RT-spoke>;
/* whatever routing protocol you use to the spokes */
}

spoke_upstream { /* used for local forwarding */
vrf-import <RT-hub>;
vrf-export <reject-all>;
}
}



> There can be more PE's with spokes connected to it. Is there any
> way to achieve it without complicating things, like separate VRF
> for each site?
>

I think 2 VRFs per PE is better than one VRF per spoke.

An alternative approach w/ a single VRF would be to configure
'forwarding-table export' policy to reject all routes from the spokes
from being installed in the VRF forwarding table. Thus the forwarding
lookup would only find the hub route.

Somehow my impression is that filtering of routing-updates to the
forwarding table is less intuitive and more tricky
operationally. i.e. you always have to remember that the contents of
the forwarding table itself may be filtered...

Pedro.