[j-nsp] ERX ERX-EM-LTU license
Hi I have an ERX1400 series, the license ERX-EM-LTU appears on the system price list as an event mirroring licence, but there is no information in the documentation about how I activate it and if it is really needed for packet mirroring or any other feature, please let me know if anyone have more information that is not public on the web. Thanks in advance JAS ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
On Thu, Feb 18, 2010 at 10:10:12PM -0700, Tommy Perniciaro wrote: > Yes - that's correct. > > Junos will complain about not having the license but BGP will still > work, same deal on the J series not having the route reflector > license, still works just complains :) EX's BGP license is (last I checked) stil nagware which can be filtered or ignored, though I'm sure that will change over time. J-series' BGP route-reflector license on the other hand is now hard enforced (any neighbors with clusters configured will not come up) as of at least a year+ ago (somewhere in the 8.x's I think). The ironic part is J-series is absolutely worthless as a route-reflector, it suffers *heavily* from the slow route installation bug, and if you ask Juniper about it they say J-series CPU is mostly locked towards forwarding packets rather than processing BGP, and is not intended to be a BGP route reflector (and yet they're still taking your money for the BGP RR licenses, go figure :P). -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EOMPLS between 10G subinterface and GE subinterface between two 7600 with Juniper MX480 as CE1
On Saturday 20 February 2010 12:45:17 am Ioan Branet wrote: > There is no problem with IOS because on another 7609 with > same IOS the EOMPLS circuit works the only difference > is that on the 7609 on which the EOMPLS won't works is > that i have redundant processors and the following > module: I can't co-relate having redundant supervisor modules with the inability of the EoMPLS pw to come up. Have you tried disabling the second supervisor module, just in case you suspect it's an issue? Otherwise, your line card compliment appears to be the same on both platforms, except that they are installed in separate slots (not that that should be important). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
OMG! Jk :). Yeah, that's not a concern of ours at this particular point, with basic carrier failover and some basic route selection we're fine with what it handles. Dan -Original Message- From: Mark Tinka [mailto:mti...@globaltransit.net] Sent: Friday, February 19, 2010 12:13 PM To: juniper-nsp@puck.nether.net Cc: Dan Farrell; TCIS List Acct Subject: Re: [j-nsp] EX series needs a special license for BGP? On Friday 19 February 2010 10:52:22 pm Dan Farrell wrote: > TBH, I have no clue about the licensing ramifications, only that for > the price I paid, I was given the ability to do OSPF, IBGP/EBGP. And > it works, with a few kinks (full tables incoming seems to be an > issue). As you've probably realized, the platform won't support a full v4 table. Cheers, Mark. __ Information from ESET NOD32 Antivirus, version of virus signature database 4881 (20100219) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
On Friday 19 February 2010 10:52:22 pm Dan Farrell wrote: > TBH, I have no clue about the licensing ramifications, > only that for the price I paid, I was given the ability > to do OSPF, IBGP/EBGP. And it works, with a few kinks > (full tables incoming seems to be an issue). As you've probably realized, the platform won't support a full v4 table. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EOMPLS between 10G subinterface and GE subinterface between two 7600 with Juniper MX480 as CE1
Hello, I use 7609 with the following IOS: #sh ver | i IOS Cisco IOS Software, c7600s72033_rp Software (c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB4, RELEASE SOFTWARE (fc3) There is no problem with IOS because on another 7609 with same IOS the EOMPLS circuit works the only difference is that on the 7609 on which the EOMPLS won't works is that i have redundant processors and the following module: show module 7 Mod Ports Card Type Model Serial No. --- - -- -- --- 74 CEF720 4 port 10-Gigabit Ethernet WS-X6704-10GE SAL1337YN4W Mod MAC addresses HwFw Sw Status --- -- -- --- 7 0025.45a5.fea0 to 0025.45a5.fea3 3.0 12.2(14r)S5 12.2(33)SRB4 Ok Mod Sub-Module Model Serial Hw Status --- -- --- --- --- 7 Distributed Forwarding Card WS-F6700-DFC3CXL SAL1326T0S6 1.4Ok Mod Online Diag Status --- 7 Pass On the router on which EOMPLS works I have: # sh module 1 Mod Ports Card Type Model Serial No. --- - -- -- --- 14 CEF720 4 port 10-Gigabit Ethernet WS-X6704-10GE SAL113929UN Mod MAC addresses HwFw Sw Status --- -- -- --- 1 0019.3037.14fc to 0019.3037.14ff 2.6 12.2(14r)S5 12.2(33)SRB4 Ok Mod Sub-Module Model Serial Hw Status --- -- --- --- --- 1 Distributed Forwarding Card WS-F6700-DFC3CXL SAL1326SUSG 1.4Ok Mod Online Diag Status --- 1 Pass Thank you, John On Fri, Feb 19, 2010 at 6:13 PM, Mark Tinka wrote: > On Friday 19 February 2010 04:52:30 pm Ioan Branet wrote: > > > I used a 6500 instead of 7600 as PE1 and connect this > > 6500 to Juniper MX (PE1-CE1 link) and it works,it seems > > that the problem is with this Cisco 7600,maybe a bug or > > something like this. > > You probably mentioned this in an earlier post, but just in > case, what code are you running on the 7600? > > Cheers, > > Mark. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EOMPLS between 10G subinterface and GE subinterface between two 7600 with Juniper MX480 as CE1
On Friday 19 February 2010 04:52:30 pm Ioan Branet wrote: > I used a 6500 instead of 7600 as PE1 and connect this > 6500 to Juniper MX (PE1-CE1 link) and it works,it seems > that the problem is with this Cisco 7600,maybe a bug or > something like this. You probably mentioned this in an earlier post, but just in case, what code are you running on the 7600? Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX series needs a special license for BGP?
TBH, I have no clue about the licensing ramifications, only that for the price I paid, I was given the ability to do OSPF, IBGP/EBGP. And it works, with a few kinks (full tables incoming seems to be an issue). Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TCIS List Acct Sent: Friday, February 19, 2010 12:02 AM To: juniper-nsp Subject: [j-nsp] EX series needs a special license for BGP? Hrmm -- from what I've read, it seems the EX series DOES need a license for BGP, but the J-series does not, unless you need the route-reflector functionality. Am I correct or ? Dan Farrell wrote: > If I'm not mistaken I got an EX3200-24T for around $3k (give or take) and I > have BGP peering on it. > > Dan Farrell > da...@appliedi.net > > > -Original Message- > From: TCIS List Acct [mailto:lista...@tulsaconnect.com] > Sent: Thursday, February 18, 2010 10:04 AM > To: Patrik Olsson > Cc: Dan Farrell; juniper-nsp > Subject: Re: [j-nsp] J2320 as BGP router > > But don't you need the "advanced feature license" to do BGP on the EX3200 > series? That license adds thousands to the cost.. > > --Mike --Mike ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ Information from ESET NOD32 Antivirus, version of virus signature database 4878 (20100218) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4880 (20100219) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Verify traffic loss-priority
Loss priority is a internal setting for COS so its not carried in the IP packet so AFAIK its not possible On Fri, Feb 19, 2010 at 6:10 AM, meryem Z wrote: > > Hello Community, > > Is it possible on juniper router to verify/monior the loss-priority of > ingress or egress realtime traffic ? > > Thank you. > > > > > _ > Hotmail : une messagerie fiable avec une protection anti-spam performante > https://signup.live.com/signup.aspx?id=60969 > ___ > 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] Verify traffic loss-priority
Hello Community, Is it possible on juniper router to verify/monior the loss-priority of ingress or egress realtime traffic ? Thank you. _ Hotmail : une messagerie fiable avec une protection anti-spam performante https://signup.live.com/signup.aspx?id=60969 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] dscp classifier doesn't work - junos 9.6
Hi,
Only the IQ2 PIC supports ingress queue stats.
Truman
On 19/02/2010, at 9:48 PM, meryem Z wrote:
> Hello Truman,
>
> Thank you for your suggestion.
> Finally i found that classification is correctly done but the interface is
> unable to show ingress statistics (IQ PIC) unlike the IQ2 PICs.
>
> show interfaces queue ingress ge-0/2/0
> Ingress queue statistics are not applicable to this interface.
>
> is this a normal behaviour for IQ PICs or I should activate something ?
>
> Thanks.
>
> BR.
>
>
> > Subject: Re: [j-nsp] dscp classifier doesn't work - junos 9.6
> > From: tru...@suspicious.org
> > Date: Wed, 17 Feb 2010 16:26:53 +1100
> > CC: juniper-nsp@puck.nether.net
> > To: merye...@hotmail.com
> >
> >
> > On 16/02/2010, at 10:14 PM, meryem Z wrote:
> >
> > >
> > > Hello ,
> > >
> > > I have an M7i router with junos 9.6 R3 .
> > >
> > > Below it's hardware config :
> > >
> > > Hardware inventory:
> > > Item Version Part number Serial number Description
> > > Chassis A6156 M7i
> > > Midplane REV 05 710-008761 CY8948 M7i Midplane
> > > Power Supply 0 Rev 06 740-008537 6122911 AC Power Supply
> > > Routing Engine REV 12 740-009459 9005089909 RE-5.0
> > > CFEB REV 07 750-010463 CY8890 Internet Processor II
> > > FPC 0 E-FPC
> > > PIC 0 REV 11 750-002970 CZ3397 4x OC-3 SONET, SMIR
> > > PIC 1 REV 08 750-010238 CY7657 1x G/E SFP, 1000 BASE
> > > Xcvr 0 REV 01 740-011782 PAR1XC7 SFP-SX
> > > PIC 2 REV 09 750-007641 CW5063 1x G/E IQ, 1000 BASE
> > > Xcvr 0 REV 01 740-011782 PAR1XFB SFP-SX
> > > PIC 3 REV 10 750-005723 CZ9407 2x OC-3 ATM-II IQ, SMIR
> > > FPC 1 E-FPC
> > > PIC 2 BUILTIN BUILTIN 1x Tunnel
> > > PIC 3 REV 08 750-009099 CY5909 1x G/E, 1000 BASE
> > > Xcvr 0 REV 01 740-011782 PAR1XC3 SFP-SX
> > > Fan Tray Rear Fan Tray
> > >
> > >
> > > I configuerd a group on a sub-interface on the IQ PIC 2 , including
> > > classifier , re-write rules and scheduler map.
> > >
> > > I'm sending traffic on this sub-interface , correctly marked (0xB8 for
> > > ef) , using iperf traffic generator. Iperf server is connected to an
> > > extreme alpine switch.
> > >
> > > when I issue show interface queue i see that all the traffic is on the BE
> > > queue , no matter the marking is.
> > >
> > > my Cos configuration is :
> > >
> > > mer...@liscr2> show configuration class-of-service interfaces ge-0/2/0
> > > unit 1004
> > > apply-groups cos_customer_ivo;
> > >
> > > mer...@liscr2> show configuration groups cos_customer_ivo
> > > class-of-service {
> > > interfaces {
> > > {
> > > unit <*> {
> > > scheduler-map sch_map_ivo;
> > > classifiers {
> > > dscp classify_dscp;
> > > }
> > > rewrite-rules {
> > > dscp rewrite_dscp;
> > > ieee-802.1 default;
> > > }
> > > }
> > > }
> > > }
> > > }
> > >
> > >
> > > mer...@liscr2> show configuration class-of-service classifiers dscp
> > > classify_dscp
> > > import default;
> > > forwarding-class best-effort {
> > > loss-priority high code-points 01;
> > > }
> > >
> > > mer...@liscr2>
> > >
> > > Is there anything wrong with the config ?
> > >
> > >
> > > Thank you.
> >
> >
> > Hi Meryem,
> >
> > Perhaps you can try with a MF classifier (ie. firewall) that matches on the
> > DSCP field to verify that the traffic is being marked correctly upon
> > ingressing into ge-0/2/0.1004? You can have an action of a forwarding class
> > as well:
> >
> > [edit firewall family inet]
> > r...@r1# show
> > filter foo {
> > term 1 {
> > from {
> > dscp ef;
> > }
> > then forwarding-class expedited-forwarding;
> > }
> > }
> >
> > Then you can verify everything before you switch back to BA classification.
> >
> > Truman
> >
>
> Hotmail : une messagerie fiable avec la protection anti-spam performante de
> Microsoft Inscrivez-vous
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] dscp classifier doesn't work - junos 9.6
Hello Truman,
Thank you for your suggestion.
Finally i found that classification is correctly done but the interface is
unable to show ingress statistics (IQ PIC) unlike the IQ2 PICs.
show interfaces queue ingress ge-0/2/0
Ingress queue statistics are not applicable to this interface.
is this a normal behaviour for IQ PICs or I should activate something ?
Thanks.
BR.
> Subject: Re: [j-nsp] dscp classifier doesn't work - junos 9.6
> From: tru...@suspicious.org
> Date: Wed, 17 Feb 2010 16:26:53 +1100
> CC: juniper-nsp@puck.nether.net
> To: merye...@hotmail.com
>
>
> On 16/02/2010, at 10:14 PM, meryem Z wrote:
>
> >
> > Hello ,
> >
> > I have an M7i router with junos 9.6 R3 .
> >
> > Below it's hardware config :
> >
> > Hardware inventory:
> > Item Version Part number Serial number Description
> > ChassisA6156 M7i
> > Midplane REV 05 710-008761 CY8948M7i Midplane
> > Power Supply 0 Rev 06 740-008537 6122911 AC Power Supply
> > Routing Engine REV 12 740-009459 9005089909RE-5.0
> > CFEB REV 07 750-010463 CY8890Internet Processor
> > II
> > FPC 0E-FPC
> > PIC 0 REV 11 750-002970 CZ33974x OC-3 SONET, SMIR
> > PIC 1 REV 08 750-010238 CY76571x G/E SFP, 1000
> > BASE
> >Xcvr 0 REV 01 740-011782 PAR1XC7 SFP-SX
> > PIC 2 REV 09 750-007641 CW50631x G/E IQ, 1000 BASE
> >Xcvr 0 REV 01 740-011782 PAR1XFB SFP-SX
> > PIC 3 REV 10 750-005723 CZ94072x OC-3 ATM-II IQ,
> > SMIR
> > FPC 1E-FPC
> > PIC 2 BUILTIN BUILTIN 1x Tunnel
> > PIC 3 REV 08 750-009099 CY59091x G/E, 1000 BASE
> >Xcvr 0 REV 01 740-011782 PAR1XC3 SFP-SX
> > Fan Tray Rear Fan Tray
> >
> >
> > I configuerd a group on a sub-interface on the IQ PIC 2 , including
> > classifier , re-write rules and scheduler map.
> >
> > I'm sending traffic on this sub-interface , correctly marked (0xB8 for ef)
> > , using iperf traffic generator. Iperf server is connected to an extreme
> > alpine switch.
> >
> > when I issue show interface queue i see that all the traffic is on the BE
> > queue , no matter the marking is.
> >
> > my Cos configuration is :
> >
> > mer...@liscr2> show configuration class-of-service interfaces ge-0/2/0 unit
> > 1004
> > apply-groups cos_customer_ivo;
> >
> > mer...@liscr2> show configuration groups cos_customer_ivo
> > class-of-service {
> >interfaces {
> > {
> >unit <*> {
> >scheduler-map sch_map_ivo;
> >classifiers {
> >dscp classify_dscp;
> >}
> >rewrite-rules {
> >dscp rewrite_dscp;
> >ieee-802.1 default;
> >}
> >}
> >}
> >}
> > }
> >
> >
> > mer...@liscr2> show configuration class-of-service classifiers dscp
> > classify_dscp
> > import default;
> > forwarding-class best-effort {
> >loss-priority high code-points 01;
> > }
> >
> > mer...@liscr2>
> >
> > Is there anything wrong with the config ?
> >
> >
> > Thank you.
>
>
> Hi Meryem,
>
> Perhaps you can try with a MF classifier (ie. firewall) that matches on the
> DSCP field to verify that the traffic is being marked correctly upon
> ingressing into ge-0/2/0.1004? You can have an action of a forwarding class
> as well:
>
> [edit firewall family inet]
> r...@r1# show
> filter foo {
> term 1 {
> from {
> dscp ef;
> }
> then forwarding-class expedited-forwarding;
> }
> }
>
> Then you can verify everything before you switch back to BA classification.
>
> Truman
>
_
Hotmail : une messagerie fiable avec la protection anti-spam performante de
Microsoft
https://signup.live.com/signup.aspx?id=60969
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX tunnel termination
It's printed in the limitations section of the release notes actually. On Wed, Feb 17, 2010 at 06:37, OBrien, Will wrote: > We ran into an interesting case where we can't terminate tunnel interfaces > on virtual routers on a SRX - only the primary. Has anyone else run into > this? It's pretty critical to how we deploy our networks to meet PCI. > ___ > 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] EOMPLS between 10G subinterface and GE subinterface between two 7600 with Juniper MX480 as CE1
Hello, I used a 6500 instead of 7600 as PE1 and connect this 6500 to Juniper MX (PE1-CE1 link) and it works,it seems that the problem is with this Cisco 7600,maybe a bug or something like this. Thank you for your help, John On Fri, Feb 19, 2010 at 9:53 AM, Ioan Branet wrote: > Hello, > > Here is a ping result with monitor traffic activated on xe-3/1/0. > I Ping the other CE and it seems that the ping leaves the Juniper > interface: > > I also create an extended access list on CE2 and debub ip packet detail > 199 > > #sh ip access-lists 199 > Extended IP access list 199 > 10 permit icmp host 150.1.1.2 host 150.1.1.1 > 20 permit icmp host 150.1.1.1 host 150.1.1.2 (6 matches) > > The ICMP echo requests from Juniper does not arrive at Cisco and also I > ping from Cisco CE2 to Juniper CE1 and i have encapsulation failed because > it dows not learn arp from Juniper: > > > > monitor traffic interface xe-3/1/0 extensive > Address resolution is ON. Use to avoid any reverse lookup > delay. > Address resolution timeout is 4s. > Listening on xe-3/1/0, capture size 1514 bytes > > 09:49:41.426537 Out > Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22 > Device Media Type Extension TLV #3, length 1, value: Ethernet (1) > Logical Interface Encapsulation Extension TLV #6, length 1, > value: Ethernet (14) > Device Interface Index Extension TLV #1, length 2, value: 193 > Logical Interface Index Extension TLV #4, length 4, value: 79 > > Logical Unit Number Extension TLV #5, length 4, value: 32767 > -original packet- > Reverse lookup for 150.1.1.1 failed (check DNS reachability). > Other reverse lookup failures will not be reported. > Use to avoid reverse lookups on IP addresses. > > 0:21:59:a7:c4:30 > 0:16:9c:6d:42:80, ethertype 802.1Q (0x8100), > length 102: vlan 999, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 21993, > offset 0, flags [none], proto: ICMP (1), length: 84) 150.1.1.2 > 150.1.1.1: > ICMP echo request, id 58212, seq 69, length 64 > 09:49:42.427316 Out > Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22 > Device Media Type Extension TLV #3, length 1, value: Ethernet (1) > Logical Interface Encapsulation Extension TLV #6, length 1, > value: Ethernet (14) > Device Interface Index Extension TLV #1, length 2, value: 193 > Logical Interface Index Extension TLV #4, length 4, value: 79 > > Logical Unit Number Extension TLV #5, length 4, value: 32767 > -original packet- > 0:21:59:a7:c4:30 > 0:16:9c:6d:42:80, ethertype 802.1Q (0x8100), > length 102: vlan 999, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 22035, > offset 0, flags [none], proto: ICMP (1), length: 84) 150.1.1.2 > 150.1.1.1: > ICMP echo request, id 58212, seq 70, length 64 > 09:49:43.428108 Out > Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22 > Device Media Type Extension TLV #3, length 1, value: Ethernet (1) > Logical Interface Encapsulation Extension TLV #6, length 1, > value: Ethernet (14) > Device Interface Index Extension TLV #1, length 2, value: 193 > Logical Interface Index Extension TLV #4, length 4, value: 79 > > Logical Unit Number Extension TLV #5, length 4, value: 32767 > -original packet- > 0:21:59:a7:c4:30 > 0:16:9c:6d:42:80, ethertype 802.1Q (0x8100), > length 102: vlan 999, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 22038, > offset 0, flags [none], proto: ICMP (1), length: 84) 150.1.1.2 > 150.1.1.1: > ICMP echo request, id 58212, seq 71, length 64 > 09:49:44.428895 Out > Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22 > Device Media Type Extension TLV #3, length 1, value: Ethernet (1) > Logical Interface Encapsulation Extension TLV #6, length 1, > value: Ethernet (14) > Device Interface Index Extension TLV #1, length 2, value: 193 > Logical Interface Index Extension TLV #4, length 4, value: 79 > > Logical Unit Number Extension TLV #5, length 4, value: 32767 > -original packet- > 0:21:59:a7:c4:30 > 0:16:9c:6d:42:80, ethertype 802.1Q (0x8100), > length 102: vlan 999, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 22042, > offset 0, flags [none], proto: ICMP (1), length: 84) 150.1.1.2 > 150.1.1.1: > ICMP echo request, id 58212, seq 72, length 64 > 09:49:45.429691 Out > Juniper PCAP Flags [Ext], PCAP Extension(s) total length 22 > Device Media Type Extension TLV #3, length 1, value: Ethernet (1) > Logical Interface Encapsulation Extension TLV #6, length 1, > value: Ethernet (14) > Device Interface Index Extension TLV #1, length 2, value: 193 > Logical Interface Index Extension TLV #4, length 4, value: 79 > > Logical Unit Number Extension TLV #5, length 4, value: 32767 > -original packet- > 0:2
