[j-nsp] Mixing v4/v6 neighbors in BGP groups

[Rob Foehl]

Wondering aloud a bit... I've seen plenty of cases where wedging parallel
v4/v6 sessions into the same BGP group and letting the router sort out
which AFI it's supposed to be using on each session works fine, and nearly
as many where configuring anything family-specific starts to get ugly
without splitting them into separate v4/v6 groups. Are there any
particularly compelling reasons to prefer one over the other?

I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts. Curious
what others are doing here.

Thanks!

-Rob
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

Wondering aloud a bit...  I've seen plenty of cases where wedging
parallel v4/v6 sessions into the same BGP group and letting the router
sort out which AFI it's supposed to be using on each session works
fine, and nearly as many where configuring anything family-specific
starts to get ugly without splitting them into separate v4/v6 groups. 
Are there any particularly compelling reasons to prefer one over the
other?
I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts. 
Curious what others are doing here.

I prefer not to find out whether walking on hot coal will kill all
feeling in my feet, or just numb them for 2hrs :-).

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman

[Job Snijders]

For the purpose of inter-domain routing I'd advise against mixing warm
mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6.

Keeping things separate maybe makes debugging easier.

Kind regards,

Job
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Rob Foehl]

Post by Mark Tinka
I prefer not to find out whether walking on hot coal will kill all
feeling in my feet, or just numb them for 2hrs :-).

So... Is that a vote for or against, and which one? ;)

Post by Mark Tinka
For the purpose of inter-domain routing I'd advise against mixing warm
mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6.
Keeping things separate maybe makes debugging easier.

I may have been insufficiently specific... I'm referring to:

group example {
neighbor 192.0.2.0;
neighbor 2001:db8::;
}

vs.

group example-ipv4 {
neighbor 192.0.2.0;
}

group example-ipv6 {
neighbor 2001:db8::;
}


The former is (operationally) simpler to deal with, until it isn't --
think "deactivate group example", etc. I'm tempted to just be explicit
about the split everywhere, but I already spend enough time explaining
that there are two of everything and it's been that way for a while now...

-Rob
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Job Snijders]

Post by Rob Foehl

Post by Job Snijders
For the purpose of inter-domain routing I'd advise against mixing warm
mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6.
Keeping things separate maybe makes debugging easier.

group example {
neighbor 192.0.2.0;
neighbor 2001:db8::;
}
vs.
group example-ipv4 {
neighbor 192.0.2.0;
}
group example-ipv6 {
neighbor 2001:db8::;
}
The former is (operationally) simpler to deal with, until it isn't -- think
"deactivate group example", etc. I'm tempted to just be explicit about the
split everywhere, but I already spend enough time explaining that there are
two of everything and it's been that way for a while now...

I'd be explicit about this split. You'll maybe have routing policies
applied on the group level, perhaps also on the neighbor level - maybe
not always. What happens when you put a policy designed for only IPv4
on IPv6 neighbors? What will happen on the other vendors you'll later
pull into your network?

If the network is automated the split doesn't matter that much anyway.

Kind regards,

Job
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

 
So...  Is that a vote for or against, and which one? ;)

I wouldn't do it.

One would argue that it's to reduce time and effort. However, if you are
researching the method and asking on this list, then one could say you
have the time and effort to run both protocols in parallel.

Which would leave the question of the "cool factor". In this case, the
cool factor is one most folk wouldn't understand/appreciate, or care for
since they have their own networks to run.

So then why do it?

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo

[Rob Foehl]

Post by Rob Foehl
group example {
neighbor 192.0.2.0;
neighbor 2001:db8::;
}
vs.
group example-ipv4 {
neighbor 192.0.2.0;
}
group example-ipv6 {
neighbor 2001:db8::;
}

Hey folks,

Appreciate all the responses here, even those which apparently assumed I'd
been bored and daydreaming about trying to wedge both address families
into a single session -- hopefully the six week late reply is sufficient
proof otherwise... :)

I have a few follow up questions on related topics, especially for those
in favor of separate peer groups:

Are you doing anything differently in your IGP? (Okay, a bit of a loaded
question, I know...) What about LDP and/or RSVP transport?

How are you handling v6 TE -- nothing yet, 6PE, inet6 shortcuts, native v6
LSPs, waiting for SR to take over the world, something else? Which Junos
release(s) were necessary to get there?

I'm still carrying v6 traffic around natively, though not sure how much
longer that'll be workable. 6PE seems like a step backward when the
network is already 100% v6 enabled, but then I haven't quite wrapped my
head around all of the options here... Thanks in advance for any clue.

-Rob
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Mark Tinka]

 
Are you doing anything differently in your IGP?  (Okay, a bit of a
loaded question, I know...)  What about LDP and/or RSVP transport?

IS-IS, single Level-2 domain, MT support enabled.

We run LDP only.

How are you handling v6 TE -- nothing yet, 6PE, inet6 shortcuts,
native v6 LSPs, waiting for SR to take over the world, something
else?  Which Junos release(s) were necessary to get there?

We don't do TE.

I'm still carrying v6 traffic around natively, though not sure how
much longer that'll be workable.  6PE seems like a step backward when
the network is already 100% v6 enabled, but then I haven't quite
wrapped my head around all of the options here...  Thanks in advance
for any clue.

6PE, IMHO, would be a step backward. We sleep well at night knowing that
IPv4 and IPv6 are both running native, ships-in-the-night. I'd rather
not have one protocol depending on the other to survive.

Same reason why we separate the BGP routing policies between both protocols.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/list

[Rolf Hanßen]

Hi,

started with a "everything configured separately" network (on
Cisco/Quagga) but now I prefer both together in one group (started with it
during a vendor replacement (Cisco to Juniper) and new config from scratch
2 years ago).

Because it is easier to handle (shut only one group, do not forget that
there may be somebody really using IPv6 you forget to shutdown).
Because it makes sure both have the same routing policies (I don't want
them to behave different).
Because it reduces the config size (we do not have hundreds of routers
deployed by some scripts).

I set families and source address (if using loopback) with an apply-group:
set groups blablabla protocols bgp group <*> neighbor <*:*> local-address ...
set groups blablabla protocols bgp group <*> neighbor <*:*> family inet6
unicast

In case I need some v4/v6 sepcific stuff in a policy I create 2 terms in
one policy.

but that's more like "do you prefer vanilla or chocolate ?" than an
essential question.

kind regards
Rolf

PS: Would be great if Juniper would allow both families together in a
single route-filter.

Post by Rob Foehl
Wondering aloud a bit... I've seen plenty of cases where wedging parallel
v4/v6 sessions into the same BGP group and letting the router sort out
which AFI it's supposed to be using on each session works fine, and nearly
as many where configuring anything family-specific starts to get ugly
without splitting them into separate v4/v6 groups. Are there any
particularly compelling reasons to prefer one over the other?
I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts. Curious
what others are doing here.
Thanks!
-Rob
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Youssef Bengelloun-Zahr]

Hi,

As far as the saying goes : divide to conquer !

Best regards.

Post by Rolf Hanßen
Hi,
started with a "everything configured separately" network (on
Cisco/Quagga) but now I prefer both together in one group (started with it
during a vendor replacement (Cisco to Juniper) and new config from scratch
2 years ago).
Because it is easier to handle (shut only one group, do not forget that
there may be somebody really using IPv6 you forget to shutdown).
Because it makes sure both have the same routing policies (I don't want
them to behave different).
Because it reduces the config size (we do not have hundreds of routers
deployed by some scripts).
set groups blablabla protocols bgp group <*> neighbor <*:*> local-address ...
set groups blablabla protocols bgp group <*> neighbor <*:*> family inet6
unicast
In case I need some v4/v6 sepcific stuff in a policy I create 2 terms in
one policy.
but that's more like "do you prefer vanilla or chocolate ?" than an
essential question.
kind regards
Rolf
PS: Would be great if Juniper would allow both families together in a
single route-filter.

Post by Rob Foehl
Wondering aloud a bit... I've seen plenty of cases where wedging parallel
v4/v6 sessions into the same BGP group and letting the router sort out
which AFI it's supposed to be using on each session works fine, and nearly
as many where configuring anything family-specific starts to get ugly
without splitting them into separate v4/v6 groups. Are there any
particularly compelling reasons to prefer one over the other?
I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts. Curious
what others are doing here.
Thanks!
-Rob
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether

[Antti Ristimäki]

We try to keep IPv4 and IPv6 configuration always distinct from each
other, where possible. Thus, not mixing v4 and v6 peerings in the same
groups. This kind of ships in the night approach makes it much more
comfortable to operate the network as it minimizes the risk that changes
related to one family impacts the other one too.

Antti

Wondering aloud a bit...  I've seen plenty of cases where wedging
parallel v4/v6 sessions into the same BGP group and letting the router
sort out which AFI it's supposed to be using on each session works fine,
and nearly as many where configuring anything family-specific starts to
get ugly without splitting them into separate v4/v6 groups.  Are there
any particularly compelling reasons to prefer one over the other?
I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts.  Curious
what others are doing here.
Thanks!
-Rob
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

--
CSC - Tieteen tietotekniikan keskus Oy:n asiakas- seka sidosryhmarekisterien henkilotietojen kasittely kuvataan tietosuojaselosteissa:
https://www.csc.fi/tietosuoja

CSC - IT Center for Science Ltd processes customer and other stakeholder personal information in the following way:
https://www.csc.fi/privacy


_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net

[Sebastian Becker]

Hi Rob,

We keep the configs separate per address-family.

—
Sebastian Becker

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juni

[Tom Beecher]

In my view, the benefits of keeping them separate far outweigh the
additional effort of creating and managing the additional groups.

Post by Rob Foehl
Wondering aloud a bit... I've seen plenty of cases where wedging parallel
v4/v6 sessions into the same BGP group and letting the router sort out
which AFI it's supposed to be using on each session works fine, and nearly
as many where configuring anything family-specific starts to get ugly
without splitting them into separate v4/v6 groups. Are there any
particularly compelling reasons to prefer one over the other?
I can think of a bunch of reasons for and against on both sides, and
several ways to handle it with apply-groups or commit scripts. Curious
what others are doing here.
Thanks!
-Rob
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp