Re: [j-nsp] LSP's with IPV6 on Juniper
On 28/Aug/18 02:05, Minto Mascarenhas wrote: > > shortcut is another option for rsvp lsps. > https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/shortcuts-edit-protocols-isis.html > I believe this would still rely on an IPv4 underlay. The OP is looking for a native control and data plane for MPLS in IPv6. Mark. ___ 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
shortcut is another option for rsvp lsps. https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/shortcuts-edit-protocols-isis.html -minto On Mon, Aug 27, 2018 at 2:20 PM Mark Tinka wrote: > > > On 27/Aug/18 18:39, craig washington wrote: > > > 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. > > LDPv6 is your friend. > > We have a dual-vendor network with varying levels of LDPv6 support, so > we haven't tested this in the real wild. > > Mark. > ___ > 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
On 27/Aug/18 18:39, craig washington wrote: > 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. LDPv6 is your friend. We have a dual-vendor network with varying levels of LDPv6 support, so we haven't tested this in the real wild. Mark. ___ 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
Hi, Am 27.08.2018 um 18:57 schrieb Olivier Benghozi: 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. There is LDPv6 on Juniper since a couple of releases (i believe 16.x) https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/configuring-ldp-native-ipv6-support.html So in theory you could run IPv6 only control Plane (IGP, LDP, BGP) with MPLS Data Plane. As there is no 4PE you either need to do v4 in MPLS VPN/VRF or run v4 and v6 Control plane in parallel to get v4 across. There is no v6 RSVP yet, but you might get your TE needs from SR/Spring. -- Kind Regards Tobias Heister ___ 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
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 mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] LSP's with IPV6 on Juniper
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
[j-nsp] VC ports not working until they are reset
Hello,
After reboot of our QFX5100 / EX4300 Mixed virtual chassis we lost connection
to several units. We can see the VC-Ports being up but they cannot see their
neighbor.
We deleted the Ports 1/2 of fpc4 and reset it as vc-port. After that the
connection worked again. The same has been done two times more with several
other connections to get a fully working virtual chassis again.
We see this quite often, nearly everytime we rebooted one of our VCs on
different VC.
Does anyone else notice such a problem with VC ports? This does not seem to be
a physical problem because the ports are working after they are being deleted
and set again as VC port.
After bootup:
Mstr Mixed Route
Neighbor List
Member ID Status Serial NoModel prio Role Mode Mode ID
Interface
0 (FPC 0) Prsnt qfx5100-48t-6q 129 Master* Y VC 9
vcp-255/0/48
1
vcp-255/0/50
1 (FPC 1) Prsnt ex4300-48t 0 Linecard Y VC 0
vcp-255/1/0
2
vcp-255/1/2
2 (FPC 2) Prsnt ex4300-48t 0 Linecard Y VC 1
vcp-255/1/0
3
vcp-255/1/2
3 (FPC 3) Prsnt ex4300-48t 0 Linecard Y VC 2
vcp-255/1/0
4
vcp-255/1/2
4 (FPC 4) Prsnt ex4300-48t 0 Linecard Y VC 3
vcp-255/1/0
5 (FPC 5) NotPrsnt qfx5100-48t-6q
6 (FPC 6) NotPrsnt ex4300-48t
7 (FPC 7) NotPrsnt ex4300-48t
8 (FPC 8) NotPrsnt ex4300-48t
9 (FPC 9) Prsnt ex4300-48t 0 Linecard Y VC 0
vcp-255/1/2
fpc4:
--
Interface Type Trunk Status SpeedNeighbor
or ID (mbps) ID Interface
PIC / Port
1/0 Configured -1Up 43 vcp-255/1/2
1/2 Configured -1Up 4
1/3 Configured Absent
1/1 Configured Absent
fpc9:
--
Interface Type Trunk Status SpeedNeighbor
or ID (mbps) ID Interface
PIC / Port
1/0 Configured -1Up 4
1/2 Configured -1Up 40 vcp-255/0/48
1/3 Configured Absent
1/1 Configured Absent
> request virtual-chassis vc-port delete pic-slot 1 port 2 member 4
fpc4:
--
Port deletion initiated, use cmd show virtual-chassis vc-port to verify
{master:0}
> show virtual-chassis vc-port member 4
fpc4:
--
Interface Type Trunk Status SpeedNeighbor
or ID (mbps) ID Interface
PIC / Port
1/0 Configured -1Up 43 vcp-255/1/2
1/3 Configured Absent
1/1 Configured Absent
{master:0}
> request virtual-chassis vc-port set pic-slot 1 port 2 member 4
fpc4:
--
Port conversion initiated, use show virtual-chassis vc-port to verify
{master:0}
> show virtual-chassis vc-port member 4
fpc4:
--
Interface Type Trunk Status SpeedNeighbor
or ID (mbps) ID Interface
PIC / Port
1/0 Configured -1Up 43 vcp-255/1/2
1/2 Configured -1Up 45 vcp-255/0/48
1/3 Configured Absent
1/1 Configured Absent
{master:0}
Member ID Status Serial NoModel prio Role Mode Mode ID
Interface
0 (FPC 0) Prsnt qfx5100-48t-6q 129 Master* Y VC 9
vcp-255/0/48
1
vcp-255/0/50
1 (FPC 1) Prsnt ex4300-48t 0 Linecard Y VC
Re: [j-nsp] Junos version to run on EX4550 with 40g module?
I have a (2) virtual chassis's of EX4550's. They've been solid performers for years. (1896 days) Running 12.2R4.5 as pure Ethernet switches with stp, virtual chassis, lots of ae interfaces. Recently I installed the EX4550-EM-2QSFP with QSFP+-40G-LR4 for dual 40 gig uplinks into my core MX960's, for aggregate ae interfaces link of 80 gbps In doing this I too saw that I had to upgrade to 13.2X50-D10 but I recall that I couldn't find that version on juniper.net so I went with something newer. https://www.juniper.net/documentation/en_US/release-independent/junos/topics /reference/specifications/expansion-module-ex4550.html My plan was to extend my mpls edge into this EX4550 VC I installed 15.1R6-S2.1 I tried to run MPLS L3VPN's in the EX4550 VC, but it's not acting right so I reverted back to pure Ethernet switching in the EX4550 VC and will probably be fine with MPLS edge on the MX960's 15.1R6-S2.1 has been working fine. - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Support contracts in Virtual Chassis
Hello everyone, with Virtual Chassis, do all VC members need to be in service contract with Juniper or just the routing engines in order to have TAC support software issues on the VC? I wonder if extra contract for EX4300 mixed with QFX5100 RE is neccessary as the EX have "Enhanced Limited Lifetime Warranty" anyway Best regards, Franz Georg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos version to run on EX4550 with 40g module?
Hi, we used some EX4550 switches with 40G QSFP and 15.1 software for some time and had no issues at all with them. Don't know which R Realese we used (something from end of 2017 or beginning 2018) before replacing them with 96 Port QFX some months ago. We used them for Layer2 only, so no clue if they have some issues in L3 mode. kind regards Rolf > I have a pair of standalone EX4550s running 12.3R6.6 that have > been stable for a few years. I have 2 EX4550-EM-2QSFPs to install > one in each switch, and I understand from > https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/expansion-module-ex4550.html > that I will need to upgrade Junos to newer than 13.2X50-D10. > > In an earlier thread this month though, it was said that 15.1R7 > isn't stable on the EX4550 even though its currently recommended, > so is anyone using these modules and can recommend a stable > version? > > Are the problems with 15.1R7 on a EX4500/EX4550 relevant to a > standalone configuration? OSPF and VRRP are the protocols being > used, with a loop free topology. I also have a pair of EX4500s in > a somewhat less production environment but same network design > I'm planning to run the newer version on for a month or so first. > > Thanks! > -Nick > ___ > 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
[j-nsp] Junos version to run on EX4550 with 40g module?
I have a pair of standalone EX4550s running 12.3R6.6 that have been stable for a few years. I have 2 EX4550-EM-2QSFPs to install one in each switch, and I understand from https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/specifications/expansion-module-ex4550.html that I will need to upgrade Junos to newer than 13.2X50-D10. In an earlier thread this month though, it was said that 15.1R7 isn't stable on the EX4550 even though its currently recommended, so is anyone using these modules and can recommend a stable version? Are the problems with 15.1R7 on a EX4500/EX4550 relevant to a standalone configuration? OSPF and VRRP are the protocols being used, with a loop free topology. I also have a pair of EX4500s in a somewhat less production environment but same network design I'm planning to run the newer version on for a month or so first. Thanks! -Nick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Apply-group brain fart
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 group 'EXAMPLE-VPN'
> ##
> description "DCN VPN to srx110:st0.0";
> ##
> ## 'inet' was inherited from group 'EXAMPLE-VPN'
> ##
> family inet {
> ##
> ## '100.64.255.1/30' was inherited from group 'EXAMPLE-VPN'
> ##
> address 100.64.255.1/30;
> }
> }
> }
>
> So Im a bit struck as to what is going wrong here. The only smoking gun I see
> is
> that my reth subinterfaces appear to be "hardware down" with the parents
> claiming "physical link down" when the
