Re: [j-nsp] LSP's with IPV6 on Juniper

[Jared Mauch]

> On Aug 29, 2018, at 1:14 AM, Rob Foehl  wrote:
> 
> On Tue, 28 Aug 2018, adamv0...@netconsultings.com wrote:
> 
>> Just out of curiosity is there a business problem/requirement/limitation 
>> you're trying to solve by not changing the next hop to v6 mapped v4 address 
>> and using native v6 NHs instead please?
> 
> I'd asked a similar question as the OP two weeks ago in the thread about 
> mixing v4 and v6 in the same BGP peer groups, after several responses 
> extolling the virtues of avoiding any conflation between the two.  If that's 
> the case for routing, but forwarding v6 in an entirely v4-dependent manner on 
> a 100% dual stack network is tolerable, then this inconsistency is... 
> inconsistent.
> 
> By all outward appearances, v6 is still a second class citizen when it comes 
> to TE, and it doesn't seem unreasonable to ask why this is the way it is in 
> 2018.  There are plenty of valid reasons for wanting parity.
> 
>> On contrary 6PE/6VPE is such a well-trodden path.
> 
> The world is covered with well-trodden paths that have fallen into disuse 
> with the arrival of newer, better, more convenient infrastructure.
> 

Yes, I’m always reminding folks that router-id may be well known to be the same 
integer representation of your IP address in the protocol encoding, but often 
it’s not a requirement.

I would like to see some of the gaps closed that prevent me from having an IPv6 
loopback in my BGP OPEN message, but then again, I could just use the integer 
value of the serial number of my router instead.

- Jared

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

Re: [j-nsp] LSP's with IPV6 on Juniper

[Rob Foehl]

On Tue, 28 Aug 2018, adamv0...@netconsultings.com wrote:


Just out of curiosity is there a business problem/requirement/limitation you're 
trying to solve by not changing the next hop to v6 mapped v4 address and using 
native v6 NHs instead please?


I'd asked a similar question as the OP two weeks ago in the thread about 
mixing v4 and v6 in the same BGP peer groups, after several responses 
extolling the virtues of avoiding any conflation between the two.  If 
that's the case for routing, but forwarding v6 in an entirely v4-dependent 
manner on a 100% dual stack network is tolerable, then this inconsistency 
is... inconsistent.


By all outward appearances, v6 is still a second class citizen when it 
comes to TE, and it doesn't seem unreasonable to ask why this is the way 
it is in 2018.  There are plenty of valid reasons for wanting parity.



On contrary 6PE/6VPE is such a well-trodden path.


The world is covered with well-trodden paths that have fallen into disuse 
with the arrival of newer, better, more convenient infrastructure.


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

Re: [j-nsp] L3VPN/RR/PE on Same router

[Antti Ristimäki]

Hi,

There might be some corner cases where running a combined RR/PE can cause 
mysterious issues. For example, there was (or is - I'm not sure whether it's 
fixed or not) an issue that a RR didn't advertise iBGP learned VPLS routes when 
the RR itself had a local attachment circuit in the given VPLS instance.

Antti

- On 16 Aug, 2018, at 17:39, tim tiriche tim.tiri...@gmail.com wrote:

> Hello,
> 
> I have a MPLS PE (L3VPN) router that is acting as full mesh iBGP within the
> US.  The other routers in the US are not RR and regular iBGP.  This router
> also acts as RR for Europe and takes in full BGP table.  Is there some
> caveats to watch out for?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> --
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] LSP's with IPV6 on Juniper

[adamv0025]

> Of craig washington
> Sent: Monday, August 27, 2018 5:40 PM
> 
> Hello all.
> 
> Wondering if anyone is using MPLS with IPV6?
> 
> I have read on 6PE and the vpn counterpart but these all seem to take into
> account that the CORE isn't running IPV6?
> 
> My question is how can we get the ACTUAL IPV6 loopback addresses into
> inet6.3 table? Would I need to do a rib import for directly connected?
> 
> If you run "ipv6-tunneling" this seems to only work if the next-hop is an IPV4
> address. (next-hop self)
> 
> I also messed around with changing the next-hop on the v6 export policy to
> the IPV4 loopback and this works too but figured there should be a different
> way?
> 
> So overall, I am trying to find a way for v6 routes to use the same LSP's as 
> v4
> without changing the next hop to a v4 address.
> 
I'm not aware of any v6 extensions for RSVP.

Just out of curiosity is there a business problem/requirement/limitation you're 
trying to solve by not changing the next hop to v6 mapped v4 address and using 
native v6 NHs instead please?
Please be aware that whatever solution you'll find will likely put you on the 
long tail of the usual deployment graph with all its drawbacks.   
On contrary 6PE/6VPE is such a well-trodden path.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


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

Re: [j-nsp] LSP's with IPV6 on Juniper

[craig washington]

Thanks everyone for the feedback.

We are running RSVP so LDPv6 won't currently be an option.

I'll keep digging around, again, thank you everyone for the feedback.




From: juniper-nsp  on behalf of Olivier 
Benghozi 
Sent: Monday, August 27, 2018 4:57 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] LSP's with IPV6 on Juniper

In global we have 6PE.
In VRF we have 6VPE.
Just works so far.

An yes, the MPLS control-plane uses only IPv4: (the intercos between routers 
are in IPv4, LDP uses IPv4, IGP uses IPv4, and IPv6 is really announced over 
specific AFI/SAFI (labeled unicast IPv6 for 6PE, VPNv6 for 6VPE) in IPv4 
MP-iBGP sessions ; but it doesn't matter.

Of course the actual IPv6 loopbacks won't go to inet6.3 since they are not used 
to resolve the routes (you will see your IPv4 mapped over IPv6 addressing). The 
next-hops are IPv4, but again, it doesn't matter, only the results matter: it 
works :)

You don't explicitly "change" the next-hop of IPv6 using policies, you just use 
nexthopself and that's it.

> Le 27 août 2018 à 18:39, craig washington  a 
> écrit :
>
> Hello all.
>
> Wondering if anyone is using MPLS with IPV6?
>
> I have read on 6PE and the vpn counterpart but these all seem to take into 
> account that the CORE isn't running IPV6?
>
> My question is how can we get the ACTUAL IPV6 loopback addresses into inet6.3 
> table? Would I need to do a rib import for directly connected?
>
> If you run "ipv6-tunneling" this seems to only work if the next-hop is an 
> IPV4 address. (next-hop self)
>
> I also messed around with changing the next-hop on the v6 export policy to 
> the IPV4 loopback and this works too but figured there should be a different 
> way?
>
> So overall, I am trying to find a way for v6 routes to use the same LSP's as 
> v4 without changing the next hop to a v4 address.
>
> Hope this makes sense 
>
>
> Any feedback is much appreciated.
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
juniper-nsp Info Page - 
puck.nether.net
puck.nether.net
To see the collection of prior postings to the list, visit the juniper-nsp 
Archives.. Using juniper-nsp: To post a message to all the list members, send 
email to juniper-nsp@puck.nether.net.



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

Re: [j-nsp] Apply-group brain fart

[Tom Storey]

Hi Balasankar,

I dont have the same issue when I configure in the foreground.

I am running software version 15.1X49-D120.3 if that helps.

Ive been informed that we have support on this gear, so I will raise a case
via JTAC too.

Thanks!
Tom

On Mon, 27 Aug 2018 at 08:28, Balasankar Rajaguru 
wrote:

> Hi Tom,
>
> > Ive tried defining the st0 interface and unit 1 within the interfaces
> stanza, but
> > that didnt help. What am I missing? What can I look at? Am I trying to do
> > something that simply cant be done?
>
> Does the issue happens when the same config is configured in foreground
> under
> Interface stanza without the apply-groups config.
>
> Regards,
> Balasankar
>
> > -Original Message-
> > From: juniper-nsp  On Behalf Of Tom
> > Storey
> > Sent: Friday, August 24, 2018 3:35 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Apply-group brain fart
> >
> > Hi everyone. I am trying to build some configuration groups with the
> intention of
> > keeping related configuration for some IPSEC VPNs etc nicely contained
> in one
> > spot - define all relevant configuration in a group and apply it in one
> go, and also
> > remove it *all* when you delete and remove the configuration group. This
> way,
> > hopefully, little bits and pieces dont get left behind as VPNs are set
> up and torn
> > down, ideally maintaining a cleaner configuration.
> >
> > But I have an odd situation. I am working with a cluster of SRX345, and
> it seems
> > that when ever I apply a config group with an st interface defined, my
> default
> > route disappears and some connected routes seem to disappear or change
> from
> > local to reject, and I lose the ability to manage the cluster via SSH
> and have to
> > use the console. The same does not happen on a standalone SRX110.
> >
> > For example, prior to applying the configuration, my routing table looks
> > like:
> >
> > 0.0.0.0/0  *[Static/5] 16:51:49
> > > to 10.32.31.1 via reth2.0
> > 10.32.31.0/24  *[Direct/0] 16:51:49
> > > via reth2.0
> > 10.32.31.230/32*[Local/0] 16w6d 23:56:30
> >   Local via reth2.0
> > 10.32.31.231/32*[Static/1] 6d 22:02:40
> >   Receive
> > 100.64.0.0/24  *[Direct/0] 16:51:49
> > > via reth3.0
> > 100.64.0.1/32  *[Local/0] 1w0d 19:43:19
> >   Local via reth3.0
> >
> > And after applying the apply group:
> >
> > 10.32.31.230/32*[Local/0] 16w6d 23:58:13
> >   Reject
> > 10.32.31.231/32*[Static/1] 6d 22:04:23
> >   Receive
> > 100.64.0.1/32  *[Local/0] 1w0d 19:45:02
> >   Reject
> > 100.64.255.0/30*[Direct/0] 00:00:04
> > > via st0.1
> > 100.64.255.1/32*[Local/0] 00:00:04
> >   Local via st0.1
> >
> > The very simple configuration group that I have defined is (I removed a
> lot of it
> > during debugging, and this is all that is left):
> >
> > groups {
> > EXAMPLE-VPN {
> > interfaces {
> > st0 {
> > unit 1 {
> > description "DCN VPN to srx110:st0.0";
> > family inet {
> > address 100.64.255.1/30;
> > }
> > }
> > }
> > }
> > }
> > }
> >
> > I set this with:
> >
> > {primary:node0}[edit]
> > root@node0-srx345# set apply-groups EXAMPLE-VPN
> >
> > Pretty straight forward I thought...
> >
> > In the configuration, after the commit has completed (no complaints) I
> do see
> > my st0 configuration inherited, and all of the configuration for my reth
> > interfaces is also inherited, and show int terse shows them all there
> with their IP
> > addresses.
> >
> > # show interfaces | display inheritance
> > ...
> > reth2 {
> > description UNTRUST;
> > ##
> > ## 'redundant-ether-options' was inherited from group
> 'SRX34X-CLUSTER'
> > ##
> > redundant-ether-options {
> > ##
> > ## '1' was inherited from group 'SRX34X-CLUSTER'
> > ##
> > redundancy-group 1;
> > }
> > unit 0 {
> > family inet {
> > address 10.32.31.230/24;
> > }
> > }
> > }
> > reth3 {
> > description "AVAILABLE - Parent for ge-[05]/0/3";
> > ##
> > ## 'redundant-ether-options' was inherited from group
> 'SRX34X-CLUSTER'
> > ##
> > redundant-ether-options {
> > ##
> > ## '1' was inherited from group 'SRX34X-CLUSTER'
> > ##
> > redundancy-group 1;
> > }
> > unit 0 {
> > family inet {
> > address 100.64.0.1/24;
> > }
> > }
> > }
> > ...
> > ##
> > ## 'st0' was inherited from group 'EXAMPLE-VPN'
> > ##
> > st0 {
> > ##
> > ## '1' was inherited from group 'EXAMPLE-VPN'
> > ##
> > unit 1 {
> > ##
> > ## 'DCN VPN to srx110:st0.0' was inherited from