Re: [j-nsp] 40Gig Ether for MX480
John did you google this? https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/mic-mx-series-40-gigabit-ethernet-qsfp.html On Thu, Jul 18, 2019 at 5:59 PM John Brown wrote: > Hi, > I have a client that is wanting a 40Gig ether handoff. What would > folks recommend for > an interface on a MX480 system? > > The customer is also asking if we need to handle G.709 FEC > > Thoughts and tips appreciated. > > -- > Respectfully, > > John Brown, CISSP > Managing Member, CityLink Telecommunications NM, LLC > ___ > 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] 40Gig Ether for MX480
> On 19/07/2019, at 1:26 PM, Jared Mauch wrote: > > Is there a reason to not do 4x10G or 1x100G? It’s cheap enough these days. > > If they’re in-datacenter I can maybe understand 40G but outside the DC it’s > unclear to me why someone would do this. 40G doesn’t have potential hashing problems that 4x10G does, bundles means potential drama with protocols on some boxes. Less of an issue on MX which is… generally pretty good with these things, but who knows what the other end hardware is. 4x10G discrete services (i.e. not a bundle) means you’ve likely still got balancing problems. 40G is easier to send over a single pair between DCs, too - 4x10G means muxes or similar. 40G works the same way of course, but does it in the optic. -- Nathan Ward ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 40Gig Ether for MX480
Is there a reason to not do 4x10G or 1x100G? It’s cheap enough these days. If they’re in-datacenter I can maybe understand 40G but outside the DC it’s unclear to me why someone would do this. - Jared > On Jul 18, 2019, at 6:58 PM, John Brown wrote: > > Hi, > I have a client that is wanting a 40Gig ether handoff. What would > folks recommend for > an interface on a MX480 system? > > The customer is also asking if we need to handle G.709 FEC > > Thoughts and tips appreciated. > > -- > Respectfully, > > John Brown, CISSP > Managing Member, CityLink Telecommunications NM, LLC > ___ > 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] 40Gig Ether for MX480
Hi, I have a client that is wanting a 40Gig ether handoff. What would folks recommend for an interface on a MX480 system? The customer is also asking if we need to handle G.709 FEC Thoughts and tips appreciated. -- Respectfully, John Brown, CISSP Managing Member, CityLink Telecommunications NM, LLC ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hello
Some important information:
Top level encapsulation flex-eth and flex-vlan-tagging is not supported on
QFabric (QFX family) devices. That means you can't use a port that does ccc
with any other type of encap, i.e. vlan-bridge, ext-vlan-br, or set family inet
on a unit. Only MX with trio chipset can do that. If you did at *any other
point* configure some other units on there with different encaps, traffic will
remain one way. There is also a PR on the use of flex stuff on QFX that states
that at some points labels are not getting programmed properly and circuit will
stop working.
You don't need family ccc in the unit, only encap vlan-ccc
You should remove and RSVP-TE and static LSP config that you have to start
fresh and make it work only with LDP, then add complexity.
The pop/push operation on the unit is there to get a pure ethernet frame to
slap the LDP tag onto and possibly deliver untagged on the other side. It's not
necessary if you also deliver on a simple tagged unit on the other side. The
difference in the core network will be between ETHERNET-CCC and VLAN-CCC. You
don't need to force the encasulation type in config, this is automatic from
what you set on both sides.
Also, don't do ignore-mtu, but set the mtu to what you want as a value lower
than the physical interface mtu, the same on both sides.
I don't think QFX supports control-word.
Examples of what works:
Xe-X
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 538 {
encapsulation vlan-ccc;
no-traps;
vlan-id 538;
input-vlan-map pop;
output-vlan-map push;
}
interface xe-0/0/36.538 {
virtual-circuit-id 13911065;
no-control-word;
mtu 9000;
}
If you do use pop/push on the unit, make sure it's there on both sides. You can
also deliver untagged on the other side by doing something like this. It will
push the frame out untagged since you removed it accepting the packet
initially. Keep in mind this dedicates the port to that service.
mtu 9216;
encapsulation ethernet-ccc;
unit 0 {
no-traps;
family ccc;
}
interface xe-0/0/12.0 {
virtual-circuit-id 1385956;
no-control-word;
mtu 9000;
}
MX can have top flex-ethernet and flex-vlan tagging and mix and match stuff.
For the rest, config must stay the same.
Keep your stuff simple, leave as much as you can to the system to figure out
unless you absolutely need to force.
Cheers.
-Original Message-
From: juniper-nsp On Behalf Of Liam Farr
Sent: July 18, 2019 11:26 AM
To: Heng Chai, Tan
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
Tried as follows;
liam@NA-QFX5110-1# show interfaces xe-0/0/9 description "Temp Link to Arista";
vlan-tagging; mtu 9216; encapsulation flexible-ethernet-services; unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
family ccc;
}
liam@NA-QFX5110-1# show protocols l2circuit neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show interfaces xe-0/1/3 description "ISPCO-WN-PVE-1 C0/F3
enp6s0f1"; flexible-vlan-tagging; mtu 9216; encapsulation
flexible-ethernet-services; unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map push;
output-vlan-map pop;
family ccc;
}
liam@WN-MX204-1# show protocols l2circuit neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
When I removed the l2circuit encapsulation altogether from both ends I got an
EM -- encapsulation mismatch on the l2circuit
I also tried encapsulation internetworking / ethernet-vlan / ethernet
At some point I did get mac learning both ways in that at the QFX end I could
see mac from the MX end, but haven't successfully managed to pass icmp / ping.
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1233606.b737.b463DYNAMIC Et91 0:18:11 ago
1236c3b.6bf0.9b0fDYNAMIC Et41 8:55:37 ago
Total Mac Addresses for this criterion: 2
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
I've got an option to borrow a QFX-5110 tomorrow and set it up in a bit better
of a LAB config with a MX I have locally, where I can break things a bit more
without affecting prod traffic. That might be the go and rebuild some
l2circuits from scratch.
Re: [j-nsp] multi services
Yes there is no equivalent MX Services to SPC3 at this time, but this is being worked on. This is supposed to be coming in 19.3, via software only; new SW architecture. Many [large] customers are running large scale IPSEC termination, but 5G max, from what [little] I know. If someone needs more throughput, they will bond multiple IPSEC tunnels together. As for failover, any failure should cause a switch to redundant module, assuming one is present. HTH, Rich Richard McGovern Sr Sales Engineer, Juniper Networks 978-618-3342 I’d rather be lucky than good, as I know I am not good I don’t make the news, I just report it On 7/18/19, 8:00 AM, "harbor235" wrote: Is anyone using the ms-mpc for large scale IPSEC termination? above 10G? Data shows 16-24Gps per card 4-6 per NPU. I am interested in real world performance with IMIX. The new SPC3 cards look promising - 40Gbps per slot IMIX juniper marketing data, I dont think these cards are released yet for the MX series. Also, is anyone familiar with service sets for IPSEC on the MS-MPC cards, how is physical interface failures of the inside and outside interfaces handled? thanks in advance, Mike ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
Tried as follows;
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
family ccc;
}
liam@NA-QFX5110-1# show protocols l2circuit
neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show interfaces xe-0/1/3
description "ISPCO-WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map push;
output-vlan-map pop;
family ccc;
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
When I removed the l2circuit encapsulation altogether from both ends I got
an EM -- encapsulation mismatch on the l2circuit
I also tried encapsulation internetworking / ethernet-vlan / ethernet
At some point I did get mac learning both ways in that at the QFX end I
could see mac from the MX end, but haven't successfully managed to pass
icmp / ping.
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1233606.b737.b463DYNAMIC Et91 0:18:11 ago
1236c3b.6bf0.9b0fDYNAMIC Et41 8:55:37 ago
Total Mac Addresses for this criterion: 2
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
I've got an option to borrow a QFX-5110 tomorrow and set it up in a bit
better of a LAB config with a MX I have locally, where I can break things a
bit more without affecting prod traffic. That might be the go and rebuild
some l2circuits from scratch.
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html
*(QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600) When VLAN bridge
encapsulation is enabled on a CE connected interface, the switch drops
packets if both flexible Ethernet services and VLAN CCC encapsulations are
configured on the same logical interface. Only one can be configured, not
both. For example:set interfaces xe-0/0/18 encapsulation
flexible-ethernet-services, or set interfaces xe-0/0/18 encapsulation
vlan-ccc.*
As mentioned the above might be causing me issues, as I did have some sub
interfaces running vlan-bridge alongside the vlan-ccc interface on xe-0/0/9.
On Fri, 19 Jul 2019 at 02:20, Heng Chai, Tan wrote:
> Try Alain's recommendation. I completely forgot about the input/output
> vlan part. You should have it on the MX as well, so that VLAN 123 would be
> transmitted over the l2circuit.
>
> xe- {
> description
> flexible-vlan-tagging;
> mtu 9216;
> encapsulation flexible-ethernet-services;
> unit 123 {
> description
> encapsulation vlan-ccc;
> no-traps;
> vlan-id 123;
> input-vlan-map pop;
> output-vlan-map push;
> }
>
>
> Heng Chai, Tan
>
>
>
--
Kind Regards
Liam Farr
Maxum Data
+64-9-950-5302
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] multi services
Is anyone using the ms-mpc for large scale IPSEC termination? above 10G? Data shows 16-24Gps per card 4-6 per NPU. I am interested in real world performance with IMIX. The new SPC3 cards look promising - 40Gbps per slot IMIX juniper marketing data, I dont think these cards are released yet for the MX series. Also, is anyone familiar with service sets for IPSEC on the MS-MPC cards, how is physical interface failures of the inside and outside interfaces handled? thanks in advance, Mike ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Try Alain's recommendation. I completely forgot about the input/output
vlan part. You should have it on the MX as well, so that VLAN 123 would
be transmitted over the l2circuit.
xe- {
description
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
description
encapsulation vlan-ccc;
no-traps;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
}
Heng Chai, Tan
On 18-07-19 10:17 PM, Liam Farr wrote:
Hi,
That removed my ability to run bridge interfaces on xe-0/0/9, which
might cause me some design issues further down the track for
production deployments.
Applied this config, but same result.
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
On the MX end I can learn both MAC's, the NA/QFX test equip and the
WN/MX204 test equip (I have a HV connected to the QFX end for testing
running OVS and a test router VM).
root@WLG-PVE-1:~# ovs-appctl fdb/show vmbr0 | grep 123
4 123 36:06:b7:37:b4:63 0
5 123 6c:3b:6b:f0:9b:0f 0
root@WLG-PVE-1:~#
But on the QFX end I'm not learning any mac back out the interface
facing the l2tunnel (should be learning a mac on Et9 from the MX side,
but only learning a mac on Et4 which is the QFX test device).
NA-ARISTA#show vlan 123
VLAN Name Status Ports
- -
---
123 VLAN0123 active Et4, Et9
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
Vlan Mac Address Type Ports Moves Last Move
--- - - -
123 6c3b.6bf0.9b0f DYNAMIC Et4 1 8:18:08 ago
Total Mac Addresses for this criterion: 1
Multicast Mac Address Table
--
Vlan Mac Address Type Ports
--- -
Total Mac Addresses for this criterion: 0
On Fri, 19 Jul 2019 at 02:02, Heng Chai, Tan > wrote:
Try below on QFX5110 terminating l2circuit. Last I remember the
flexible-vlan-tagging + flexible-ethernet-services behaves oddly
on the
QFX5110.
delete interfaces xe-0/0/9 flexible-vlan-tagging
set interfaces xe-0/0/9 vlan-tagging
set interfaces xe-0/0/9 encapsulation vlan-ccc
Heng Chai, Tan
On 18-07-19 9:48 PM, Liam Farr wrote:
> Hi,
>
> Not sure if I'm "doing the dumb" or Junos bug or limitation of
the QFX /
> Trident 2+ chip-set.
>
> Trying to do a basic l2circuit as follows
>
> VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp >
QFX-5110
> l2circuit / ldp > VLAN Tagged Interface
>
> What I am seeing is traffic going Test Device > QFX-5110 >
QFX-5110 > MX204
>> Test Device arrives fine.
> Return path from Test Device > MX204 > QFX-5110 > QFX-5110 >
Test Device is
> broken.
>
>
> Config is as follows
>
> *MX204 Port facing test device on VLAN tag 123*
>
> liam@WN-MX204-1# show interfaces xe-0/1/3
> description "WN-PVE-1 C0/F3 enp6s0f1";
> flexible-vlan-tagging;
> mtu 9216;
> encapsulation flexible-ethernet-services;
> unit 123 {
> encapsulation vlan-ccc;
> vlan-id 123;
> family ccc;
> }
>
> MPLS port facing intermediate / transit QFX (MS)
>
> liam@WN-MX204-1# show interfaces xe-0/1/1
> description "OTN MS";
> mtu 9216;
> unit 0 {
> family inet {
> address 172.16.130.2/30 ;
> }
> family mpls;
> }
>
> liam@WN-MX204-1# show interfaces lo0
> unit 0 {
> family inet {
> address 127.0.0.1/32 ;
> address 192.168.68.3/32 ;
> }
> }
>
> liam@WN-MX204-1# show protocols l2circuit
> neighbor 192.168.68.5 {
> interface xe-0/1/3.123 {
> virtual-circuit-id 123;
> control-word;
> encapsulation-type ethernet-vlan;
> ignore-mtu-mismatch;
> pseudowire-status-tlv;
> }
> }
>
> liam@WN-MX204-1# show protocols ldp
> interface xe-0/1/1.0;
> interface lo0.0;
>
> liam@WN-MX204-1# show protocols mpls
> path-mtu {
> rsvp mtu-signaling;
> }
> ipv6-tunneling;
> icmp-tunneling;
> optimize-timer 60;
> label-switched-path wn-mx-to-na-qfx-test {
> from 192.168.68.3;
> to 192.168.68.5;
> adaptive;
> fast-reroute;
> primary
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
That removed my ability to run bridge interfaces on xe-0/0/9, which might
cause me some design issues further down the track for production
deployments.
Applied this config, but same result.
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
On the MX end I can learn both MAC's, the NA/QFX test equip and the
WN/MX204 test equip (I have a HV connected to the QFX end for testing
running OVS and a test router VM).
root@WLG-PVE-1:~# ovs-appctl fdb/show vmbr0 | grep 123
4 123 36:06:b7:37:b4:630
5 123 6c:3b:6b:f0:9b:0f0
root@WLG-PVE-1:~#
But on the QFX end I'm not learning any mac back out the interface facing
the l2tunnel (should be learning a mac on Et9 from the MX side, but only
learning a mac on Et4 which is the QFX test device).
NA-ARISTA#show vlan 123
VLAN Name StatusPorts
- -
---
123 VLAN0123 activeEt4, Et9
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1236c3b.6bf0.9b0fDYNAMIC Et41 8:18:08 ago
Total Mac Addresses for this criterion: 1
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
On Fri, 19 Jul 2019 at 02:02, Heng Chai, Tan wrote:
> Try below on QFX5110 terminating l2circuit. Last I remember the
> flexible-vlan-tagging + flexible-ethernet-services behaves oddly on the
> QFX5110.
>
> delete interfaces xe-0/0/9 flexible-vlan-tagging
> set interfaces xe-0/0/9 vlan-tagging
> set interfaces xe-0/0/9 encapsulation vlan-ccc
>
> Heng Chai, Tan
>
> On 18-07-19 9:48 PM, Liam Farr wrote:
> > Hi,
> >
> > Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
> > Trident 2+ chip-set.
> >
> > Trying to do a basic l2circuit as follows
> >
> > VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp > QFX-5110
> > l2circuit / ldp > VLAN Tagged Interface
> >
> > What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 >
> MX204
> >> Test Device arrives fine.
> > Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test Device
> is
> > broken.
> >
> >
> > Config is as follows
> >
> > *MX204 Port facing test device on VLAN tag 123*
> >
> > liam@WN-MX204-1# show interfaces xe-0/1/3
> > description "WN-PVE-1 C0/F3 enp6s0f1";
> > flexible-vlan-tagging;
> > mtu 9216;
> > encapsulation flexible-ethernet-services;
> > unit 123 {
> > encapsulation vlan-ccc;
> > vlan-id 123;
> > family ccc;
> > }
> >
> > MPLS port facing intermediate / transit QFX (MS)
> >
> > liam@WN-MX204-1# show interfaces xe-0/1/1
> > description "OTN MS";
> > mtu 9216;
> > unit 0 {
> > family inet {
> > address 172.16.130.2/30;
> > }
> > family mpls;
> > }
> >
> > liam@WN-MX204-1# show interfaces lo0
> > unit 0 {
> > family inet {
> > address 127.0.0.1/32;
> > address 192.168.68.3/32;
> > }
> > }
> >
> > liam@WN-MX204-1# show protocols l2circuit
> > neighbor 192.168.68.5 {
> > interface xe-0/1/3.123 {
> > virtual-circuit-id 123;
> > control-word;
> > encapsulation-type ethernet-vlan;
> > ignore-mtu-mismatch;
> > pseudowire-status-tlv;
> > }
> > }
> >
> > liam@WN-MX204-1# show protocols ldp
> > interface xe-0/1/1.0;
> > interface lo0.0;
> >
> > liam@WN-MX204-1# show protocols mpls
> > path-mtu {
> > rsvp mtu-signaling;
> > }
> > ipv6-tunneling;
> > icmp-tunneling;
> > optimize-timer 60;
> > label-switched-path wn-mx-to-na-qfx-test {
> > from 192.168.68.3;
> > to 192.168.68.5;
> > adaptive;
> > fast-reroute;
> > primary anypath;
> > }
> > path anypath;
> > interface xe-0/1/1.0;
> >
> > liam@WN-MX204-1# show protocols ospf
> > traffic-engineering;
> > area 0.0.0.0 {
> > interface lo0.0 {
> > passive;
> > }
> > interface fxp0.0 {
> > disable;
> > }
> > interface xe-0/1/0.549 {
> > interface-type p2p;
> > }
> > interface xe-0/1/1.0 {
> > interface-type p2p;
> > }
> > }
> >
> >
> > *Intermediate / transit QFX*, MPLS interface facing MX204
> >
> > liam@MS-QFX5110-1# show interfaces xe-0/0/1
> > description "OTN MS-WN";
> > mtu 9216;
> > unit 0 {
> > family inet {
> > address 172.16.130.1/30;
> > }
> > family mpls;
> > }
> >
> > Interface facing destination QFX
> >
> > liam@MS-QFX5110-1# show interfaces xe-0/0/0
> >
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Here is an production version (thx Phil) but on QFX-5100 and MX960
(and MX104 before).
This works for about 200ish circuits so far...
We had a bunch of issue with those which can lead to unresponsive
interface... So depending on your situation you may have to reboot the
switch :(
xe- {
description
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
description
encapsulation vlan-ccc;
no-traps;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
}
interface xe-.123 {
virtual-circuit-id 123456;
description
no-control-word;
mtu 9000;
}
-
Alain hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911http://www.pubnix.net Fax: 514-990-9443
On 2019-07-18 10:02, Heng Chai, Tan wrote:
Try below on QFX5110 terminating l2circuit. Last I remember the
flexible-vlan-tagging + flexible-ethernet-services behaves oddly on
the QFX5110.
delete interfaces xe-0/0/9 flexible-vlan-tagging
set interfaces xe-0/0/9 vlan-tagging
set interfaces xe-0/0/9 encapsulation vlan-ccc
Heng Chai, Tan
On 18-07-19 9:48 PM, Liam Farr wrote:
Hi,
Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
Trident 2+ chip-set.
Trying to do a basic l2circuit as follows
VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp >
QFX-5110
l2circuit / ldp > VLAN Tagged Interface
What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 >
MX204
Test Device arrives fine.
Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test
Device is
broken.
Config is as follows
*MX204 Port facing test device on VLAN tag 123*
liam@WN-MX204-1# show interfaces xe-0/1/3
description "WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
MPLS port facing intermediate / transit QFX (MS)
liam@WN-MX204-1# show interfaces xe-0/1/1
description "OTN MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.2/30;
}
family mpls;
}
liam@WN-MX204-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.3/32;
}
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show protocols ldp
interface xe-0/1/1.0;
interface lo0.0;
liam@WN-MX204-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path wn-mx-to-na-qfx-test {
from 192.168.68.3;
to 192.168.68.5;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/1/1.0;
liam@WN-MX204-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fxp0.0 {
disable;
}
interface xe-0/1/0.549 {
interface-type p2p;
}
interface xe-0/1/1.0 {
interface-type p2p;
}
}
*Intermediate / transit QFX*, MPLS interface facing MX204
liam@MS-QFX5110-1# show interfaces xe-0/0/1
description "OTN MS-WN";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.1/30;
}
family mpls;
}
Interface facing destination QFX
liam@MS-QFX5110-1# show interfaces xe-0/0/0
description "OTN MS-NA";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.5/30;
}
family mpls;
}
liam@MS-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.6/32;
}
}
liam@MS-QFX5110-1# show protocols ldp
interface xe-0/0/0.0;
interface xe-0/0/1.0;
interface lo0.0;
liam@MS-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
path anypath;
interface xe-0/0/0.0;
interface xe-0/0/1.0;
liam@MS-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vme.0 {
disable;
}
interface xe-0/0/0.0 {
interface-type p2p;
}
interface xe-0/0/1.0 {
interface-type p2p;
}
}
*Destination QFX / other end of l2circuit*, interfacing test
equipment on
vlan 123
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
Interface facing intermediate / transit QFX
liam@NA-QFX5110-1# show interfaces xe-0/0/1
description "OTN NA-MS";
mtu 9216;
unit 0 {
family inet {
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
I’m only aware of that being an issue when vlan bridge encapsulation is enabled
on the PHY:
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html
(There may, of course, be other cases too that are documented elsewhere)
In any event, this worked for me from a QFX to an ACX:
set interfaces xe-0/0/2 flexible-vlan-tagging
set interfaces xe-0/0/2 encapsulation flexible-ethernet-services
set interfaces xe-0/0/2 unit 11 encapsulation vlan-ccc
set interfaces xe-0/0/2 unit 11 vlan-id 11
set protocols l2circuit neighbor 10.15.48.100 interface xe-0/0/2.11
virtual-circuit-id 1
set protocols l2circuit neighbor 10.15.48.100 interface xe-0/0/2.11 description
foo
set protocols l2circuit neighbor 10.15.48.100 interface xe-0/0/2.11
encapsulation-type interworking
(I don’t recall if interworking is actually required here. That could be a
relic from a different test, likely port based to VLAN based)
> On Jul 18, 2019, at 10:02 AM, Heng Chai, Tan wrote:
>
> Try below on QFX5110 terminating l2circuit. Last I remember the
> flexible-vlan-tagging + flexible-ethernet-services behaves oddly on the
> QFX5110.
>
> delete interfaces xe-0/0/9 flexible-vlan-tagging
> set interfaces xe-0/0/9 vlan-tagging
> set interfaces xe-0/0/9 encapsulation vlan-ccc
>
> Heng Chai, Tan
>
> On 18-07-19 9:48 PM, Liam Farr wrote:
>> Hi,
>>
>> Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
>> Trident 2+ chip-set.
>>
>> Trying to do a basic l2circuit as follows
>>
>> VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp > QFX-5110
>> l2circuit / ldp > VLAN Tagged Interface
>>
>> What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 > MX204
>>> Test Device arrives fine.
>> Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test Device is
>> broken.
>>
>>
>> Config is as follows
>>
>> *MX204 Port facing test device on VLAN tag 123*
>>
>> liam@WN-MX204-1# show interfaces xe-0/1/3
>> description "WN-PVE-1 C0/F3 enp6s0f1";
>> flexible-vlan-tagging;
>> mtu 9216;
>> encapsulation flexible-ethernet-services;
>> unit 123 {
>> encapsulation vlan-ccc;
>> vlan-id 123;
>> family ccc;
>> }
>>
>> MPLS port facing intermediate / transit QFX (MS)
>>
>> liam@WN-MX204-1# show interfaces xe-0/1/1
>> description "OTN MS";
>> mtu 9216;
>> unit 0 {
>> family inet {
>> address 172.16.130.2/30;
>> }
>> family mpls;
>> }
>>
>> liam@WN-MX204-1# show interfaces lo0
>> unit 0 {
>> family inet {
>> address 127.0.0.1/32;
>> address 192.168.68.3/32;
>> }
>> }
>>
>> liam@WN-MX204-1# show protocols l2circuit
>> neighbor 192.168.68.5 {
>> interface xe-0/1/3.123 {
>> virtual-circuit-id 123;
>> control-word;
>> encapsulation-type ethernet-vlan;
>> ignore-mtu-mismatch;
>> pseudowire-status-tlv;
>> }
>> }
>>
>> liam@WN-MX204-1# show protocols ldp
>> interface xe-0/1/1.0;
>> interface lo0.0;
>>
>> liam@WN-MX204-1# show protocols mpls
>> path-mtu {
>> rsvp mtu-signaling;
>> }
>> ipv6-tunneling;
>> icmp-tunneling;
>> optimize-timer 60;
>> label-switched-path wn-mx-to-na-qfx-test {
>> from 192.168.68.3;
>> to 192.168.68.5;
>> adaptive;
>> fast-reroute;
>> primary anypath;
>> }
>> path anypath;
>> interface xe-0/1/1.0;
>>
>> liam@WN-MX204-1# show protocols ospf
>> traffic-engineering;
>> area 0.0.0.0 {
>> interface lo0.0 {
>> passive;
>> }
>> interface fxp0.0 {
>> disable;
>> }
>> interface xe-0/1/0.549 {
>> interface-type p2p;
>> }
>> interface xe-0/1/1.0 {
>> interface-type p2p;
>> }
>> }
>>
>>
>> *Intermediate / transit QFX*, MPLS interface facing MX204
>>
>> liam@MS-QFX5110-1# show interfaces xe-0/0/1
>> description "OTN MS-WN";
>> mtu 9216;
>> unit 0 {
>> family inet {
>> address 172.16.130.1/30;
>> }
>> family mpls;
>> }
>>
>> Interface facing destination QFX
>>
>> liam@MS-QFX5110-1# show interfaces xe-0/0/0
>> description "OTN MS-NA";
>> mtu 9216;
>> unit 0 {
>> family inet {
>> address 172.16.130.5/30;
>> }
>> family mpls;
>> }
>>
>> liam@MS-QFX5110-1# show interfaces lo0
>> unit 0 {
>> family inet {
>> address 127.0.0.1/32;
>> address 192.168.68.6/32;
>> }
>> }
>>
>> liam@MS-QFX5110-1# show protocols ldp
>> interface xe-0/0/0.0;
>> interface xe-0/0/1.0;
>> interface lo0.0;
>>
>> liam@MS-QFX5110-1# show protocols mpls
>> path-mtu {
>> rsvp mtu-signaling;
>> }
>> ipv6-tunneling;
>> icmp-tunneling;
>> optimize-timer 60;
>> path anypath;
>> interface xe-0/0/0.0;
>> interface xe-0/0/1.0;
>>
>> liam@MS-QFX5110-1# show protocols ospf
>> traffic-engineering;
>> area 0.0.0.0 {
>> interface lo0.0 {
>> passive;
>> }
>> interface vme.0 {
>> disable;
>> }
>> interface xe-0/0/0.0 {
>> interface-type p2p;
>> }
>> interface xe-0/0/1.0 {
>>
Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Try below on QFX5110 terminating l2circuit. Last I remember the
flexible-vlan-tagging + flexible-ethernet-services behaves oddly on the
QFX5110.
delete interfaces xe-0/0/9 flexible-vlan-tagging
set interfaces xe-0/0/9 vlan-tagging
set interfaces xe-0/0/9 encapsulation vlan-ccc
Heng Chai, Tan
On 18-07-19 9:48 PM, Liam Farr wrote:
Hi,
Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
Trident 2+ chip-set.
Trying to do a basic l2circuit as follows
VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp > QFX-5110
l2circuit / ldp > VLAN Tagged Interface
What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 > MX204
Test Device arrives fine.
Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test Device is
broken.
Config is as follows
*MX204 Port facing test device on VLAN tag 123*
liam@WN-MX204-1# show interfaces xe-0/1/3
description "WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
MPLS port facing intermediate / transit QFX (MS)
liam@WN-MX204-1# show interfaces xe-0/1/1
description "OTN MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.2/30;
}
family mpls;
}
liam@WN-MX204-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.3/32;
}
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show protocols ldp
interface xe-0/1/1.0;
interface lo0.0;
liam@WN-MX204-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path wn-mx-to-na-qfx-test {
from 192.168.68.3;
to 192.168.68.5;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/1/1.0;
liam@WN-MX204-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fxp0.0 {
disable;
}
interface xe-0/1/0.549 {
interface-type p2p;
}
interface xe-0/1/1.0 {
interface-type p2p;
}
}
*Intermediate / transit QFX*, MPLS interface facing MX204
liam@MS-QFX5110-1# show interfaces xe-0/0/1
description "OTN MS-WN";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.1/30;
}
family mpls;
}
Interface facing destination QFX
liam@MS-QFX5110-1# show interfaces xe-0/0/0
description "OTN MS-NA";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.5/30;
}
family mpls;
}
liam@MS-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.6/32;
}
}
liam@MS-QFX5110-1# show protocols ldp
interface xe-0/0/0.0;
interface xe-0/0/1.0;
interface lo0.0;
liam@MS-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
path anypath;
interface xe-0/0/0.0;
interface xe-0/0/1.0;
liam@MS-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vme.0 {
disable;
}
interface xe-0/0/0.0 {
interface-type p2p;
}
interface xe-0/0/1.0 {
interface-type p2p;
}
}
*Destination QFX / other end of l2circuit*, interfacing test equipment on
vlan 123
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
Interface facing intermediate / transit QFX
liam@NA-QFX5110-1# show interfaces xe-0/0/1
description "OTN NA-MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.6/30;
}
family mpls;
}
liam@NA-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.5/32;
}
}
liam@NA-QFX5110-1# show protocols l2circuit
neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@NA-QFX5110-1# show protocols ldp
interface xe-0/0/1.0;
interface lo0.0;
liam@NA-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path na-qfx-to-wn-mx-test {
from 192.168.68.5;
to 192.168.68.3;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/0/1.0;
liam@NA-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
[j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
Not sure if I'm "doing the dumb" or Junos bug or limitation of the QFX /
Trident 2+ chip-set.
Trying to do a basic l2circuit as follows
VLAN Tagged Interface > MX204 l2circuit / ldp > QFX-5110 / ldp > QFX-5110
l2circuit / ldp > VLAN Tagged Interface
What I am seeing is traffic going Test Device > QFX-5110 > QFX-5110 > MX204
> Test Device arrives fine.
Return path from Test Device > MX204 > QFX-5110 > QFX-5110 > Test Device is
broken.
Config is as follows
*MX204 Port facing test device on VLAN tag 123*
liam@WN-MX204-1# show interfaces xe-0/1/3
description "WN-PVE-1 C0/F3 enp6s0f1";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
MPLS port facing intermediate / transit QFX (MS)
liam@WN-MX204-1# show interfaces xe-0/1/1
description "OTN MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.2/30;
}
family mpls;
}
liam@WN-MX204-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.3/32;
}
}
liam@WN-MX204-1# show protocols l2circuit
neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show protocols ldp
interface xe-0/1/1.0;
interface lo0.0;
liam@WN-MX204-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path wn-mx-to-na-qfx-test {
from 192.168.68.3;
to 192.168.68.5;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/1/1.0;
liam@WN-MX204-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface fxp0.0 {
disable;
}
interface xe-0/1/0.549 {
interface-type p2p;
}
interface xe-0/1/1.0 {
interface-type p2p;
}
}
*Intermediate / transit QFX*, MPLS interface facing MX204
liam@MS-QFX5110-1# show interfaces xe-0/0/1
description "OTN MS-WN";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.1/30;
}
family mpls;
}
Interface facing destination QFX
liam@MS-QFX5110-1# show interfaces xe-0/0/0
description "OTN MS-NA";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.5/30;
}
family mpls;
}
liam@MS-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.6/32;
}
}
liam@MS-QFX5110-1# show protocols ldp
interface xe-0/0/0.0;
interface xe-0/0/1.0;
interface lo0.0;
liam@MS-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
path anypath;
interface xe-0/0/0.0;
interface xe-0/0/1.0;
liam@MS-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vme.0 {
disable;
}
interface xe-0/0/0.0 {
interface-type p2p;
}
interface xe-0/0/1.0 {
interface-type p2p;
}
}
*Destination QFX / other end of l2circuit*, interfacing test equipment on
vlan 123
liam@NA-QFX5110-1# show interfaces xe-0/0/9
description "Temp Link to Arista";
flexible-vlan-tagging;
mtu 9216;
encapsulation flexible-ethernet-services;
unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
family ccc;
}
Interface facing intermediate / transit QFX
liam@NA-QFX5110-1# show interfaces xe-0/0/1
description "OTN NA-MS";
mtu 9216;
unit 0 {
family inet {
address 172.16.130.6/30;
}
family mpls;
}
liam@NA-QFX5110-1# show interfaces lo0
unit 0 {
family inet {
address 127.0.0.1/32;
address 192.168.68.5/32;
}
}
liam@NA-QFX5110-1# show protocols l2circuit
neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
control-word;
encapsulation-type ethernet-vlan;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@NA-QFX5110-1# show protocols ldp
interface xe-0/0/1.0;
interface lo0.0;
liam@NA-QFX5110-1# show protocols mpls
path-mtu {
rsvp mtu-signaling;
}
ipv6-tunneling;
icmp-tunneling;
optimize-timer 60;
label-switched-path na-qfx-to-wn-mx-test {
from 192.168.68.5;
to 192.168.68.3;
adaptive;
fast-reroute;
primary anypath;
}
path anypath;
interface xe-0/0/1.0;
liam@NA-QFX5110-1# show protocols ospf
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface vme.0 {
disable;
}
interface xe-0/0/0.554 {
interface-type p2p;
}
interface xe-0/0/1.0 {
interface-type p2p;
}
}
L2 Circuit is up on the QFX
liam@NA-QFX5110-1> show l2circuit connections
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch
Re: [j-nsp] srx ipsec tunnel over mpls l3vpn
I wish there was a more elegant way, but when we approached JTAC and our Juniper SE about it. They confirmed it was the only method, which meant we were burning twice as many security zones per client L3VPN -> IPSEC tunnel service. My email search fu is failing in finding the kb article on it. On Fri, 12 Jul 2019 at 23:20, Aaron Gould wrote: > Craig, how did you do the LT config to "cycle" traffic back through ? you > have a link/kb on how-to ? Actually I'm wondering if there's a more > elegant > way then LT's (no offense since we all love accomplishing things and making > stuff work, but it seems that LT's and furthermore, physical cables lopped > from port to port on the front of the device, are usually ways to do things > that we can't figure out in software) :| > > Hugo, The other end is an MX104 with services card for ipsec capability > (MS-MIC-16G) > > I haven't yet put any customer edge interfaces behind the SRX or MX, but I > will do that this morning I simply wanted to put a subnet on the secure > tunnel interfaces and ping from st0.0 to ms-0/0/0.1 first, but I can do the > further edge config also. > > -Aaron > > -Original Message- > From: Hugo Slabbert [mailto:h...@slabnet.com] > Sent: Friday, July 12, 2019 1:26 AM > To: Aaron Gould > Cc: 'Emille Blanc'; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] srx ipsec tunnel over mpls l3vpn > > Is the other end of this also an SRX configured in a similar way, or > something else? This seems to contradict basically any Juniper docs on SRX > around MPLS traffic re: flow/packet mode. Specifically given that it's > showing "drop" for MPLS traffic, I would be confused about how it's passing > MPLS-encap'd traffic. > > Can you pass other non-IPSEC IPv4 traffic from the SRX (or behind it) > across > the l3vpn to validate bidirectional traffic passing? > > -- > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > pgp key: B178313E | also on Signal > > On Thu 2019-Jul-11 15:34:26 -0500, Aaron Gould wrote: > > > > >Thanks Emille, Ummm, I may be misunderstanding you , but I don't think > >I have change from SRX flow-mode default. But I do have ldp neighbor > >up and mpls forwarding is occurring via mpls l3vpn vrf . and I do > >believe the ike phase 1 and phase 2 is working over this mpls l3vpn within > the srx > >but I just don't seem to be able to ping from one side of the st0 > >tunnel interface to the other. > > > >See... > > > >root@demo-srx300> show security flow status > > Flow forwarding mode: > >Inet forwarding mode: flow based > >Inet6 forwarding mode: drop > >MPLS forwarding mode: drop > >ISO forwarding mode: drop > >Enhanced route scaling mode: Disabled > > Flow trace status > >Flow tracing status: off > > Flow session distribution > >Distribution mode: RR-based > >GTP-U distribution: Disabled > > Flow ipsec performance acceleration: off > > Flow packet ordering > >Ordering mode: Hardware > > > > > >root@demo-srx300> show route table mpls.0 > > > >mpls.0: 524 destinations, 524 routes (524 active, 0 holddown, 0 hidden) > >+ = Active Route, - = Last Active, * = Both > > > >0 *[MPLS/0] 04:51:07, metric 1 > > Receive > >1 *[MPLS/0] 04:51:07, metric 1 > > Receive > >2 *[MPLS/0] 04:51:07, metric 1 > > Receive > >13 *[MPLS/0] 04:51:07, metric 1 > > Receive > >16 *[VPN/0] 04:51:07 > > to table one.inet.0, Pop > >345552 *[LDP/9] 04:43:04, metric 3, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16507 > >345568 *[LDP/9] 04:43:04, metric 4, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16508 > >345584 *[LDP/9] 04:43:04, metric 2, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16512 > >345600 *[LDP/9] 04:43:04, metric 3, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16513 > >345616 *[LDP/9] 04:43:04, metric 3, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16516 > >345632 *[LDP/9] 04:43:04, metric 4, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16517 > >345648 *[LDP/9] 04:43:04, metric 3, tag 0 > >> to 10.101.14.197 via ge-0/0/0.0, Swap 16518 > > > >root@demo-srx300> show route table mpls.0 terse > > > >mpls.0: 524 destinations, 524 routes (524 active, 0 holddown, 0 hidden) > >+ = Active Route, - = Last Active, * = Both > > > >A V DestinationP Prf Metric 1 Metric 2 Next hopAS > path > >* ? 0 M 0 1 Receive > >* ? 1 M 0 1 Receive > >* ? 2 M 0 1 Receive > >* ? 13 M 0 1 Receive > >* ? 16
