Re: [j-nsp] user defined variables from radius

[Wojciech Janiszewski]

AFAIK you can use them with Radius attributes 26-65 / 26-66 to activate
service with dynamic parameters, which take the string like
"dynamic-profile-name(variable1, variable2, ...)".
The same can be done through CLI for testing purposes

Regards,
Wojciech

sob., 28 lis 2020, 03:16 użytkownik Baldur Norddahl 
napisał:

> Hello
>
> Under "dynamic-profile xxx variables" I can configure user defined
> variables. I get the impression that somehow these variables can be filled
> in by radius but how? Radius attributes are to my knowledge predefined.
>
> Say I create a variable called "foobar" - what would I do with my
> freeradius config to supply that variable?
>
> Thanks,
>
> Baldur
> ___
> 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] what do do with bug reports

[Wojciech Janiszewski]

Hi Baldur,

You should not give up and just report the bug.
JTAC may ask you to disable feature that is causing an impact, but in the
meantime they will work on resolving it.

Mind that it might take some time to replicate the problem, prepare the fix
and implement it in the next official software release.

Regards,


pon., 15 cze 2020, 08:23 użytkownik Baldur Norddahl 
napisał:

> Hello
>
> What am I supposed to do with glaring bugs? Are Juniper interested in
> knowing those or don't they care?
>
> In this case I found out that 19.1 behaves badly if you set [system
> services subscriber-management overrides interfaces family inet
> receive-gratuitous-arp]. The setting is supposed to enable updating the
> ARP table when receiving gratuitous ARP from clients. Instead it makes
> the router reply to those ARP packets, which causes the clients to
> reject the address.
>
> Packet monitor (somewhat shortened):
>
> 07:41:05.677882 bpf_flags 0x03,  In
>  Juniper PCAP Flags [no-L2, In]
>  -original packet-
>  PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>  -original packet-
>  PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
> 0x1b632c2a, Flags [Broadcast] (0x8000)
>  -original packet-
>  PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>  -original packet-
>  PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags
> [none], proto: UDP (17), length: 319) 185.24.168.248.bootps >
> 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid
> 0x1b632c2a, Flags [Broadcast] (0x8000)
>Your-IP 212.237.x.237
>  DHCP-Message Option 53, length 1: ACK
>  -original packet-
>  34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length
> 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype
> ARP, arp who-has 212.237.x.237 tell 212.237.x.237
> 07:41:05.686691 bpf_flags 0x00, Out
>  -original packet-
>  e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length
> 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17
> 07:41:05.689680 bpf_flags 0x03,  In
>  -original packet-
>  PFE proto 2 (ipv4): (tos 0x0, ttl  64, id 24111, offset 0, flags
> [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc >
> 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from
> 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000)
>  DHCP-Message Option 53, length 1: Decline
> ^C
> 8 packets received by filter
>
> The part that is plain wrong is "arp reply 212.237.x.237 is-at
> e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and
> by responding to this, the router causes the client to believe something
> else is using the address. Therefore the client sends Decline back to
> the DHCP server.
>
> Proxy-arp settings makes no difference at all. Doesn't matter if you
> have it entirely disabled or set to proxy-arp restricted. However
> disabling receive-gratuitous-arp makes the router stop doing this.
>
> If I made a case for this I am sure they will just tell me to disable
> receive-gratuitous-arp which is exactly what I did. I am just curious if
> there is any way to report bugs that I will live with as is. It is still
> clearly something that should get fixed.
>
> Regards,
>
> Baldur
>
>
>
> ___
> 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] Subscriber DHCPv6 lease time for IA_NA from Radius Server

[Wojciech Janiszewski]

Hi Sebastian,

If I remember correctly, DHCP Lease Time can be adjusted by using Radius
Session-Timeout attribute.

Regards,
Wojciech

śr., 11 mar 2020 o 11:32 Sebastian Wiesinger 
napisał(a):

> Hi,
>
> I'm currently testing IPv6 subscriber termination (PPP/L2TP) on an
> MX204 (18.4R2) and I have a bit of a problem with DHCPv6 IA_NA address
> allocation.
>
> By default the lease time for the address is one day (86400 seconds)
> when the address is received by Radius.
>
> The Cisco CPE configures this address on the Dialer interface which
> does not go down when the PPP session is cleared. So the address stays
> there for a day at least which is suboptimal.
>
> We want to reduce the lease time so that it is detected sooner that
> the address is invalid and can be released / reused.
>
> The only way to change this behaviour seems to be setting the
> 'asymmetric-lease-time' option in the dhcpv6 group overrides. I set it
> to 600 seconds which works as expected (address has a lifetime of 600
> seconds) BUT the MX does not respond to rebind queries from the
> client. So the address times out and the client has to solicit the
> address again.
>
> Traceoptions seem to indicate that the packet is handled in an special
> way because of the asymmetric lease time:
>
> Mar 11 10:58:56.881706 [MSTR][DEBUG] dhcpv6_packet_new: PACKET - Allocated
> new v6 packet 0xa176480
> Mar 11 10:58:56.881749 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] >> Decode
> message from == fe80::12f3:11ff:fe81:18fe/546 <<
> Mar 11 10:58:56.881760 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ msgtype ==
> DHCPV6-REBIND ]--
> Mar 11 10:58:56.881769 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ len == 76 ]--
> Mar 11 10:58:56.881778 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ xid == e72bcf ]--
> Mar 11 10:58:56.881787 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ Internally
> Unsupported Option
> Mar 11 10:58:56.881799 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603]   OPTION code   8,
> len   2, data 00 00 ]--
> Mar 11 10:58:56.881808 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ OPTION_CLIENTID
> Mar 11 10:58:56.881820 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603]   OPTION code   1,
> len  10, data 00 03 00 01 10 f3 11 81 18 fe ]--
> Mar 11 10:58:56.881829 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ OPTION_OPT_REQ
> Mar 11 10:58:56.881839 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603]   OPTION code   6,
> len   4, data 00 17 00 18 ]--
> Mar 11 10:58:56.881848 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ OPTION_IA_NA
> Mar 11 10:58:56.881856 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603]   OPTION code   3,
> len  40, iaid 1114113, T1 0, T2 0 ]--
> Mar 11 10:58:56.881866
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> dhcpv6_option_parse: Parsing suboptions of OPTION_IA_NA - Start
> Mar 11 10:58:56.881875 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] --[ OPTION_IAADDR
> Mar 11 10:58:56.881885 [MSTR][INFO]
> [default:default][SVR][INET6][si-0/0/0.3221225603] OPTION code   5,
> len  24, pre-ltime 600, valid-ltime 600, addr 2001:db8:8:1d::1, data NULL
> ]--
> Mar 11 10:58:56.881895
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> dhcpv6_option_parse: Parsing suboptions of OPTION_IA_NA - Done
> Mar 11 10:58:56.881905
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> dhcpv6_packet_decode: dhcpv6 pkt parsing - End
> Mar 11 10:58:56.881914 [MSTR][DEBUG] dhcpv6_packet_handle: ALQ: LQ update
> skipped - Not expected
> Mar 11 10:58:56.881926
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> jdhcpd_v6_short_lease_recv_check: Checking packet safd for short lease
> requirement
> Mar 11 10:58:56.881935
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> jdhcpd_v6_short_lease_recv_check: Packet safd has short lease configuration
> call short lease handler
> Mar 11 10:58:56.881952
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> jdhcpd_v6_short_lease_recv_check: Packet converted returning to sender
> Mar 11 10:58:56.881987
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> jdhcpd_v6_short_lease_recv_check: Short lease refreshed
> Mar 11 10:58:56.881997
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> dhcpv6_packet_handle: Short lease processing has consumed this packet
> Mar 11 10:58:56.882008
> [MSTR][DEBUG][default:default][SVR][INET6][si-0/0/0.3221225603]
> dhcpv6_packet_handle: leasequeryreply No, retries 0
> Mar 11 10:58:56.882016 [MSTR][DEBUG] dhcpv6_packet_free: PACKET - Freeing
> v6 packet 0xa176480
>
> The trace says "Short lease refreshed" but no reply 

Re: [j-nsp] GRE interfaces doesn't show up

[Wojciech Janiszewski]

Hi Jeff,

What type of DPC card you're using?  As per your initial email I wouldn't
expect PIC 4 on DPC card related to gr-5/4/0 interface to be present as
PICs can take numbers between 0 and 3.
What is your network-services mode (show chassis network-services)?
Is DPC card up (show chassis fpc)?

As per documentation, if you specify a bandwidth that is not compatible,
tunnel services are not activated. For example, you cannot specify a
bandwidth of 1 Gbps for a Packet Forwarding Engine on a 10-Gigabit Ethernet
4-port DPC.
Have you verified with "show interfaces gr-* terse" if any GRE interface is
created?
If you're using DPC 40x1GE then tunnel interfaces shall be gr-x/[0-3]/10
(set chassis fpc X pic Y bandwidth 1g) and with DPC 4x10GE it shall be
gr-x/[0-3]/0 (set chassis fpc X pic Y bandwidth 10g).

Regards,
Wojciech


czw., 29 sie 2019 o 23:40 Jeff Meyers  napisał(a):

> Hi Jim,
>
> thanks for the quick reply! However, unfortunately that did not do the
> job and the interface still doesn't show up, neither with 1g nor 10g for
> the bandwidth:
>
> > # show chassis fpc 0
> > pic 0 {
> > tunnel-services {
> > bandwidth 10g;
> > }
> > }
>
> > # show interfaces gr-0/0/0
> > unit 0 {
> > description Tunnel;
> > tunnel {
> > source 1.2.3.4;
> > destination 4.3.2.1;
> > }
> > }
>
> > # run show interfaces gr-0/0/0
> > error: device gr-0/0/0 not found
>
> Any ideas? :-(
>
>
> Thanks,
> Jeff
>
>
>
> Am 29.08.2019 um 12:38 schrieb Jim Alias:
> > On DPCs you need to set the bandwidth setting.
> >
> > set chassis fpc  pic  tunnel-services bandwidth <10g - 100g>
> >
> > Be advised that this will burn a 10 gig port for each 10 gigs you assign
> to tunnel-services.
> >
> > Regard,
> > Clay Haynes
> >
> > Sent from my iPhone
> >
> >> On 29 Aug 2019, at 10:50, Jeff Meyers  wrote:
> >>
> >> Hi list,
> >>
> >> I'm trying to setup a GRE tunnel interface on a MX480 with DPCE
> >> linecards. I want to use xe-5/4/0 and have therefore configured this
> >> interface under 'edit chassis' for tunnel-services. The interface
> >> vanishes as expected. I have then configured the interface gr-5/4/0 with
> >> unit 0 but is not being created. It's the same behaviour on a secondary
> >> MX router so I might be missing something. I am running Junos 13.3
> >> respectively 15.1 on the routers I tested this with.
> >>
> >> I am unable to identify the reason right now, maybe someone from this
> >> list can help me with that? Thanks in advance!
> >>
> >> Best
> >> Jeff
> >> ___
> >> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EVPN all-active toward large layer 2?

[Wojciech Janiszewski]

Hi Rob,

You have effectively created L2 loop over EVPN, so to cut it you need a
link between bridged network and EVPN to be a single link. There is no STP
in EVPN.
If you need two physical connections to between those networks, then LAG is
a way to go. MC-LAG or virtual chassis can be configured on legacy switches
to maintain that connection. ESI will handle that on EVPN side.

HTH,
Wojciech


czw., 18 kwi 2019, 08:37 użytkownik Rob Foehl  napisał:

> On Thu, 18 Apr 2019, Krzysztof Szarkowicz wrote:
>
> > Hi Rob,
> > RFC 7432, Section 8.5:
> >
> >If a bridged network is multihomed to more than one PE in an EVPN
> >network via switches, then the support of All-Active redundancy mode
> >requires the bridged network to be connected to two or more PEs using
> >a LAG.
> >
> >
> > So, have you MC-LAG (facing EVPN PEs) configured on your switches?
>
> No, hence the question...  I'd have expected ESI-LAG to be relevant for
> EVPN, and in this case it's not a single "CE" device but rather an entire
> layer 2 domain.  For a few of those, Juniper-flavored MC-LAG isn't an
> option, anyway.  In any case, it's not clear what 8.5 means by "must be
> connected using a LAG" -- from only one device in said bridged network?
>
> -Rob
> ___
> 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] BGP default action constraints with advertise-inactive?

[Wojciech Janiszewski]

Hi Jason,

"advertise-inactive" makes router to advertise BGP route even if it is not
active. One example is when you have a static and BGP route for the same
prefix. By default, static route is preferred and BGP is marked as
inactive. As such BGP route would not be advertised. By configuring
"advertise-inactive" you can advertise such inactive BGP route.

HTH,
Wojciech


sob., 23 lut 2019, 16:58: Jason Lixfeld via juniper-nsp <
juniper-nsp@puck.nether.net> napisał(a):

> Hello!
>
> I’m confused about some observations while testing BGP announcements of
> inactive routes.  I’m hoping someone can offer some clue.
>
> I have this sample route:
>
> jlixfeld@mx# run show route table rifoo.inet.0 protocol static
> 44.44.44.0/21 detail
>
> rifoo.inet.0: 27 destinations, 29 routes (27 active, 0 holddown, 0 hidden)
> 44.44.44.0/21 (1 entry, 1 announced)
> *Static Preference: 5
> Next hop type: Discard, Next hop index: 0
> Address: 0x71101cc
> Next-hop reference count: 42
> State: 
> Age: 12:24:23
> Validation State: unverified
> Task: RT
> Announcement bits (1): 2-BGP_RT_Background
> AS path: I
> Communities: :1001
>
> [edit]
> jlixfeld@mx#
>
> My understanding is:
>
> 1. With advertise-inactive configured, this route should be advertised to
> an EBGP neighbor that has no export policy configured.
> [
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/advertise-inactive-edit-protocols-bgp.html
> ]
>
> 2. The BGP default action of 'accept' should not require an accept action
> in a policy statement.
> [
> https://www.juniper.net/documentation/en_US/junos/topics/concept/policy-routing-policies-actions-defaults.html
> ]
>
> However, neither of these two cases seem to be true, so my understanding
> is obviously wrong and I haven’t been able to find any documentation that
> points to the difference in behaviour.
>
> Based on the configuration below, here’s what works and what doesn’t:
>
> To 4.4.4.4: 44.44.44.0/21 is not announced.
> To 5.5.5.5: 44.44.44.0/21 is not announced unless tfoo includes 'then
> accept' and ANNOUNCE:ANCHOR then {} includes 'accept'
> To 6.6.6.6: 44.44.44.0/21 is not announced unless sfoo ANNOUNCE:ANCHOR
> then {} includes 'accept'
>
> routing-instances {
> rifoo {
> routing-options {
> rib rifoo.inet6.0 {
> static {
> route 2607:::/32 {
> discard;
> no-install;
> community :1001;
> }
> }
> }
> static {
> route 44.44.44.0/21 {
> discard;
> no-install;
> community :1001;
> }
> protocols {
> bgp {
> group gfoo {
> type external;
> advertise-inactive;
> neighbor 4.4.4.4 {
> peer-as ;
> }
> neighbor 5.5.5.5 {
> export pfoo
> peer-as ;
> }
> neighbor 6.6.6.6 {
> export sfoo
> peer-as ;
> }
> }
> }
> }
> }
> }
> policy-statement pfoo {
> term tfoo {
> from policy sfoo
> # then accept;
> }
> }
> policy-statement sfoo {
> term ANNOUNCE:ANCHOR {
> from {
> protocol static;
> community TYPE:ANCHOR;
> }
> then {
> community delete TYPE:ANCHOR;
> # accept;
> }
> }
> }
> community TYPE:ANCHOR members :1001;
>
> Can anyone see what I might be missing here?
>
> Thanks!
> ___
> 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] MX960 differing RE REVs is this ok

[Wojciech Janiszewski]

Hi Aaron,

I'd say it is not relevant for ISSU. Different hw revisions might have
different chips or capacitors here or there , but functionally they should
be the same.

Regards,
Wojciech

śr., 23 sty 2019, 16:55: Aaron Gould  napisał(a):

> Does ISSU require same *Rev* of RE ?
>
>
>
> ...and is there any reason why I would NOT want to run different Rev of RE
> in my MX960 ?
>
>
>
> Is it ok to run different rev of RE ?  I have REV 17 as RE0 and REV 15 as
> RE1.  Is this ok?
>
>
>
> root> show chassis hardware models | grep Routing
>
> Routing Engine 0 REV 17   750-054758   (removed)  RE-S-X6-64G-S
>
> Routing Engine 1 REV 15   750-054758   (removed)  RE-S-X6-64G-S
>
>
>
> -Aaron
>
> ___
> 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] mx960 junos upgrade fail

[Wojciech Janiszewski]

I'd first check if /var is mounted on the hard drive.

Regards,
Wojciech

czw., 5.04.2018, 17:32 użytkownik Aaron Gould  napisał:

> mx960 junos upgrade fail due to the following reasons. any idea how to
> overcome?
>
>
>
>
>
> I already did request system storage cleanup
>
>
>
>
>
> {master}
>
> agould@mx960> show version invoke-on all-routing-engines | grep
> "Model|Junos:"
>
> Model: mx960
>
> Junos: 15.1F7.3
>
> Model: mx960
>
> Junos: 15.1F7.3
>
>
>
>
>
> {master}
>
> agould@mx960> request system software validate in-service-upgrade
> junos-install-mx-x86-64-16.1R3-S7.1.tgz
>
> error: Not enough free_space: 17770832 reqd_pkgsize: 18181496
>
> error: not enough space in /var on re0.
>
> error: need at least 9308927696 bytes free.
>
>
>
>
>
>
>
>
>
> - Aaron
>
> ___
> 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] cdn.juniper.net slow?

[Wojciech Janiszewski]

 Hi Franz,

I believe it depends on what is currently being cached by the server.
If you're downloading a file which has not been downloaded before, the
download speed might be low.

My DNS resolves cdn.juniper.net as 184.50.174.254, but if I force wget to
use 23.37.55.189  I get couple of MB/s when downloading your file.

$ wget --no-check-certificate --header "Host: cdn.juniper.net" "
https://23.37.55.189/software/junos/18.1R1.9/junos-install-mx-x86-64-18.1R1.9.tgz?[..]
"
--2018-03-29 16:12:01--
https://23.37.55.189/software/junos/18.1R1.9/junos-install-mx-x86-64-18.1R1.9.tgz?[.
.]
Connecting to 23.37.55.189:443... connected.
WARNING: certificate common name ‘cdn.juniper.net’ doesn't match
requested host name ‘23.37.55.189’.
HTTP request sent, awaiting response... 200 OK
Length: 2726046587 (2.5G) [application/octet-stream]
Saving to: junos-install-mx-x86-64-18.1R1.9.tgz?[..]

 4% [===>   ]
132,318,152 11.0MB/s  eta 3m 15s
 8% [=> ]
221,542,816 11.8MB/s  eta 3m 16s
10% [=> ]
289,954,792 11.6MB/s  eta 3m 12s
11% [>  ]
326,848,336 11.6MB/s  eta 3m 10s


However, if I choose to download other file (which I presume is not
downloaded that often)  the speed is much lower.

$ wget --no-check-certificate --header "Host: cdn.juniper.net" "
https://cdn.juniper.net/software/junos/17.4R1.16/junos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[..]
"
--2018-03-29 16:17:09--
https://cdn.juniper.net/software/junos/17.4R1.16/junos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[.
.]
Resolving cdn.juniper.net (cdn.juniper.net)... 2.20.170.159
Connecting to cdn.juniper.net (cdn.juniper.net)|2.20.170.159|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2692264219 (2.5G) [application/x-gzip]
Saving to: unos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[..]

 0% [>  ]
26,432,656  1.60MB/s  eta 27m 1s
 7% [===>   ]
191,396,744 1.22MB/s  eta 28m 47s
 8% [=> ]
222,051,768  882KB/s  eta 29m 16s


Couple of minutes later, I get much better results for the same file:

$ wget --no-check-certificate --header "Host: cdn.juniper.net" "
https://cdn.juniper.net/software/junos/17.4R1.16/junos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[..]
"
--2018-03-29 16:25:28--
https://cdn.juniper.net/software/junos/17.4R1.16/junos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[.
.]
Resolving cdn.juniper.net (cdn.juniper.net)... 2.20.170.159
Connecting to cdn.juniper.net (cdn.juniper.net)|2.20.170.159|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 2692264219 (2.5G) [application/x-gzip]
Saving to: junos-install-media-usb-mx-x86-64-17.4R1.16-limited.img.gz?[..]

 2% [===>   ]
65,205,360  11.5MB/s  eta 2m 56s
 4% [===>   ]
129,117,560 11.7MB/s  eta 3m 12s
 6% [===>   ]
187,499,696 13.3MB/s  eta 3m 13s
 7% [===>   ]
192,402,672 11.6MB/s  eta 3m 13s

That's how cache server works...

HTH,

Regards,
Wojciech

2018-03-28 18:15 GMT+02:00 Franz Georg Köhler :

> Is cdn.juniper.net always slow? It only delivers between 500 and 1000
> kilobit per
> second to me while the traceroute looks fine and I am used to much faster
> downloads from Akamai:
>
> $ wget "https://cdn.juniper.net/software/junos/18.1R1.9/junos-
> install-mx-x86-64-18.1R1.9.tgz[...]"
> --2018-03-28 17:30:14--  https://cdn.juniper.net/
> software/junos/18.1R1.9/junos-install-mx-x86-64-18.1R1.9.tgz[...]
> Auflösen des Hostnamen »cdn.juniper.net (cdn.juniper.net)«... 23.37.55.189
> Verbindungsaufbau zu cdn.juniper.net (cdn.juniper.net)|23.37.55.189|:443...
> verbunden.
> HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
> Länge: 2726046587 (2,5G) [application/octet-stream]
> In »»junos-install-mx-x86-64-18.1R1.9.tgz[...]«« speichern.
>
> junos-install-mx-x86-64-18.1R1.9.tgz?SM_US 100%[=
> ===>]
>  2,54G   933KB/s   in 39m 37s
>
> 2018-03-28 18:09:51 (1,09 MB/s) - 
> »»junos-install-mx-x86-64-18.1R1.9.tgz[...]««
> gespeichert [2726046587/2726046587]
>
>
> $ mtr -r -w 23.37.55.189
> Start: Wed Mar 28 18:13:48 2018
> HOST: hermes Loss%   Snt
>  Last   Avg  Best  Wrst StDev
>   1.|-- gw-corpserv.dabuk47DB.frankfurt.de.velia.net0.0%10
>  59.7   7.9   1.3  59.7  18.2
>   2.|-- gauss.router.frankfurt.de.velia.net 0.0%10
> 0.3   0.3   0.3   0.3   

Re: [j-nsp] Stiching L2 to L3 on MX480

[Wojciech Janiszewski]

Hi Pshem,

Yes, you can. Just as I described in my previous post.

Regards,
Wojciech


22.12.2017 00:43 "Pshem Kowalczyk"  napisał(a):

Hi,

Can we use this for non-BNG functions as well? Despite a large number all
of those VLANs are 'static' customers.

kind regards
Pshem


On Thu, 21 Dec 2017 at 23:01  wrote:

> Hi Pshem,
>
> The feature designed specifically for what you are looking for is
> pseudowire
> headend (or pseudowire headed termination PWHT on junos). I'm just really
> surprised no one mentioned it already.
> The limit is 2048 in 15.1 and should be raised to around 15k on 17.1.
> But as always you should do a fair amount of scaling and performance
> testing
> to see if it's suitable for your product scale and BW requirements.
>
> I feel your pain when I was designing Carrier Ethernet  solution several
> years ago when there was no PWHE available had to use two routers at the
> head-end one to terminate PW into qinq and other with L3 to VRF.
> The only other option was bridge-domain per PW which obviously does not
> scale (well not at scales I needed anyways).
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> > Of Pshem Kowalczyk
> > Sent: Tuesday, December 19, 2017 10:07 PM
> > To: juniper-nsp@puck.nether.net
> > Subject: [j-nsp] Stiching L2 to L3 on MX480
> >
> > Hi,
> >
> > We have an existing setup consisting of a number of ACX5k and MX480
> > (single MPLS domain). We generally provide L2 services out of the ACXes
> and
> > L3 out of the MXes. Now, a new requirement emerged to provide L3 (with
> > features that ACX can't provide) in locations where we can't justify the
> MX.
> > I'd like to know if it's possible to do the following (and if anything
> special is
> > required on the MX) 1. Build a L2 PWE3 taking whole port on the ACX and
> > logically terminate it on the MX 2. The logical port on the MX (I
presume
> 'lt')
> > will be used to terminate individual dot1q and QinQ services into L3
> VPNs.
> >
> > Looking at the documentation it appears to be possible, but I'd like to
> know
> > what sort of limitations this solution might have, particularly when it
> comes to
> > QoS on the MX.
> >
> > kind regards
> > Pshem
> > ___
> > 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Stiching L2 to L3 on MX480

[Wojciech Janiszewski]

Hi Pshem,

I'd terminate l2circuits from ACX directly on pseudo-wire interfaces (psX).

By example:

PE1:
set chassis fpc 2 pic 1 tunnel-services bandwidth 10g
set interfaces ps1 anchor-point lt-2/1/0
set interfaces ps1 flexible-vlan-tagging
set interfaces ps1 unit 1234 vlan-id 1234
set interfaces ps1 unit 1234 family inet address 1.2.3.4/24
set protocols l2circuit neighbor 10.200.1.21 interface ps1.0
virtual-circuit-id 1
set protocols l2circuit neighbor 10.200.1.21 interface ps1.0
encapsulation-type ethernet
set protocols l2circuit neighbor 10.200.1.21 interface ps1.0
ignore-mtu-mismatch
set protocols l2circuit neighbor 10.200.1.21 interface ps1.0
pseudowire-status-tlv

PE2:
set interfaces ge-2/0/6 unit 1 encapsulation vlan-ccc
set interfaces ge-2/0/6 unit 1 vlan-id-range 1-2000
set protocols l2circuit neighbor 10.200.1.1 interface ge-2/0/6.1
virtual-circuit-id 1
set protocols l2circuit neighbor 10.200.1.1 interface ge-2/0/6.1
encapsulation-type ethernet
set protocols l2circuit neighbor 10.200.1.1 interface ge-2/0/6.1
ignore-mtu-mismatch

Regards,
Wojciech



2017-12-19 23:07 GMT+01:00 Pshem Kowalczyk :

> Hi,
>
> We have an existing setup consisting of a number of ACX5k and MX480 (single
> MPLS domain). We generally provide L2 services out of the ACXes and L3 out
> of the MXes. Now, a new requirement emerged to provide L3 (with features
> that ACX can't provide) in locations where we can't justify the MX.
> I'd like to know if it's possible to do the following (and if anything
> special is required on the MX)
> 1. Build a L2 PWE3 taking whole port on the ACX and logically terminate it
> on the MX
> 2. The logical port on the MX (I presume 'lt') will be used to terminate
> individual dot1q and QinQ services into L3 VPNs.
>
> Looking at the documentation it appears to be possible, but I'd like to
> know what sort of limitations this solution might have, particularly when
> it comes to QoS on the MX.
>
> kind regards
> Pshem
> ___
> 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] SNMPv3 Type $9 Passwords ?

[Wojciech Janiszewski]

Hi Kevin,

Please refer to RFC2574 for details of password to key algorithm.

Regards,
Wojciech

2017-06-20 16:46 GMT+02:00 kevin gannon :

> We are using Ansible to push configurations and also check the
> configuration in ansible versus what is on the box.
>
> The checking leads to an annoying problem. For auth keys using $9 style
> passwords we can generate them in advance in the Ansible scripts and deploy
> them as keys rather than passwords. What this means is when the check is
> run an Ansible diff there is no mismatch.
>
> However SNMPv3 somehow uses the SNMP engine-id as part of the hashing. But
> I cant figure out the logic to it. I know I could just ignore it but it is
> bothering me :-(.
>
> Take the sample below
>
> set snmp v3 usm remote-engine 00 user  authentication-md5
> authentication-password 
>
> Produces:
>
> $9$tvU80ORlKMXxdMWUjq.zF/CtpRhvWLxdbLXk.P5F3hSyeLxVwYgJGhSvLxNY25QzFnC
> 0BIyrv1IdbwYoaApu0EcevWN-wO1NdVwaJn/9ABIEhr8LNcSMX-dsYP5T3ApO1RyevB17-
> Vboa69Cp1RSyKL7-vMX-bwg4JGDkqf5QF9tu3n9pu0IRSreKLx
>
>
> If you decrypt the $9$ you get the below
>
> b6c75cc8798750649aee2d4e444944ee3d35af1f3172432a52c47c2bc047b0c0
>
> It does look like 2 x MD5 hashes but there is an extra character so am at a
> loss.
>
> Any help much appreciated.
>
> Thanks and regards
> Kevin
> ___
> 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] EX4200 show chassis environment discrepancy

[Wojciech Janiszewski]

Hi Lucio,

I believe there is no discrepancy between outputs because they show
different things.
As far as I remember, the "Status" field of "show chassis environment
output" can be one of the following: ok, failed, check, testing, absent

In your case EX-PFE2 is OK, but it's just too hot.
I'd recommend to check air flow on site. It might be also useful to check
in the logs since when fans are spinning at a high speed and if there is no
indication of the faulty fan. Alarms related to the faulty fan might be set
and cleared periodically, so you may not see them in "show system alarms"
but they should be visible in the log.

Regards,
Wojciech

2016-11-28 9:34 GMT+01:00 Valentini, Lucio :

> Hi folks,
> Has any of you ever come across this issue?
>
> If I look at the "show chassis environment output", everything seems to be
> OK, but when I look at the more common "show system alarms" , it tells me
> the temp is too high.
>
> Should I worry or can we keep going ? and if so, for how long ? is that
> perhaps a bug fixed in later versions? I am using ver. 12.3R3.4.
>
>
> user@switch> show chassis environment
> Class Item   Status Measurement
> Power FPC 0 Power Supply 0   OK
>   FPC 0 Power Supply 1   OK
> Temp  FPC 0 CPU  OK 51 degrees C / 123 degrees
> F
>   FPC 0 EX-PFE1  OK 69 degrees C / 156 degrees
> F
>   FPC 0 EX-PFE2  OK 91 degrees C / 195 degrees
> F
>   FPC 0 EX-PFE3  OK 68 degrees C / 154 degrees
> F
>   FPC 0 GEPHY Front Left OK 44 degrees C / 111 degrees
> F
>   FPC 0 GEPHY Front Middle   OK 48 degrees C / 118 degrees
> F
>   FPC 0 GEPHY Front RightOK 50 degrees C / 122 degrees
> F
>   FPC 0 Uplink Conn  OK 50 degrees C / 122 degrees
> F
> Fans  FPC 0 Fan 1OK Spinning at full speed
>   FPC 0 Fan 2OK Spinning at full speed
>   FPC 0 Fan 3OK Spinning at full speed
>
>
> user@switch > show system alarms
> 1 alarms currently active
> Alarm time   Class  Description
> 2016-11-22 18:36:43 CET  Minor  FPC 0 EX-PFE2 Temp Too Warm
>
> user@switch > show version
> fpc0:
> --
> Hostname: xxx
> Model: ex4200-48t
> JUNOS Base OS boot [12.3R3.4]
> JUNOS Base OS Software Suite [12.3R3.4]
> JUNOS Kernel Software Suite [12.3R3.4]
> JUNOS Crypto Software Suite [12.3R3.4]
> JUNOS Online Documentation [12.3R3.4]
> JUNOS Enterprise Software Suite [12.3R3.4]
> JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R3.4]
> JUNOS Routing Software Suite [12.3R3.4]
> JUNOS Web Management [12.3R3.4]
> JUNOS FIPS mode utilities [12.3R3.4]
>
> user@switch > show chassis temperature-thresholds
>Fan speed  Yellow alarm  Red alarm
> Fire Shutdown
>   (degrees C)  (degrees C) (degrees C)
>   (degrees C)
> Item Normal  High   Normal  Bad fan   Normal  Bad fan
>Normal
> FPC 0 CPU6070   80   70   95   85
> FPC 0 EX-PFE16070   80   70   95   85
> FPC 0 EX-PFE26070   80   70   95   85
> FPC 0 EX-PFE36070   80   70   95   85
> FPC 0 GEPHY Front Left   6070   80   70   95   85
> FPC 0 GEPHY Front Middle 6070   80   70   95   85
> FPC 0 GEPHY Front Right  6070   80   70   95   85
> FPC 0 Uplink Conn6070   80   70   95   85
>
> Is it going to shutdown when the temperature raises above 95 deg C ?
>
> Thanks
>
> Best regards
>
> Ing. Lucio Valentini
>
> ___
> 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] interpreting 10Gb interface "PCS statistics" values

[Wojciech Janiszewski]

Hi David,

I'd say it's a number of seconds with high error rate or errored blocks. In
other words it doesn't show the number of errors but the number of seconds
during which errors were detected.

Regards,
Wojciech

21.10.2016 20:08 "David B Funk"  napisał(a):

> Thanks guys but this isn't what I was asking.
>
> The optical power is similar (within a few tenths of a dBm) at my end,
> down by 3 dBm at the far end of the link that is having issues (-6.23 dBm
> as opposed to -3.73 dBm) but not enough to explain what I'm seeing.
>
> The big question I have is: What does "30 Seconds" mean for an attribute
> that by description of the docs is supposed to be number of PCS blocks with
> invalid Sync headers?
> Particularly when the guy on the Cisco at the other end says his error
> counters are going up like crazy (and packets are being dropped) while the
> stats my end stays constant at "30 Seconds".
> What does that mean?
>
> The particularly frustrating thing is that data streams are dropping
> packets (EG iperf3 showing retries and seriously degraded performance) but
> none of the interface stats are showing any values that indicate an issue
> other than that "30 Seconds".
>
> Can anybody tell me what "30 Seconds" means (in the context of an error
> counter)?
>
>
>
> On Fri, 21 Oct 2016, Christopher Costa wrote:
>
> Here's my notes from a jtac review about these a couple years ago:
>>
>>
>>
>> [pcs] encoding is continually transmitting to keep the line in sync. The
>> PCS layer is directly below the MAC layer so for MX,
>> it’s on the MIC. PCS errors can be caused by anything MIC or lower, i.e.
>> transceiver, fiber, line equipment, etc.
>>
>>
>>
>>  PCS functionality:
>>  ===
>>  IEEE 802.3ae 10GbE interfaces use a 64B/66B encoder/decoder in the
>> PHY-PCS (Physical Coding Sub layer) to allow reasonable
>> clock recovery and facilitate alignment of the data stream at the
>> receiver.
>>  As the scheme name suggests, 64 bits of data on the MAC layer are
>> transmitted as a 66-bit code block on the PHY layer, which
>> realizes easier clock/timing synchronization. A 66-bit code block
>> contains a 2-bit Sync. Header + 8 octets data/control field.
>>   If the Sync. header is '01', the 8 octets are entirely data.
>>  If the Sync. header is '10', an 8-bit Type field follows, plus 56 bits
>> of data/control field.
>>   The 8 octets data/control field is scrambled by using a
>> self-synchronous scrambler to achieve complete DC-balance on the
>> serial line.
>>  PCS statistics displays PCS fault conditions by checking valid Sync.
>> headers received with every 66 bits interval, so that we
>> can monitor 10Gbps high speed transmission line quality.
>>   If the 64B/66B receiver does not detect the 2-bit Sync.
>>  Header with regular 66-bit interval and it estimates the high BER (Bit
>> Error Rate of >10^-4), PCS statistics will report a
>> problem.
>>   PCS statistics :
>>  
>>  - "Bit errors" indicates the number of PCS blocks with invalid Sync
>> headers.
>>  - "Errored blocks" indicates the number of PCS blocks with a valid Sync.
>> header but invalid block format.
>>
>>
>> On Fri, Oct 21, 2016 at 9:37 AM, Michael Carey  wrote:
>>   David,
>>
>>   When I've seen PCS statistical errors before, it pointed to either a
>>   failing optic that needed replaced in our MX or a drastic change in
>> optical
>>   light levels caused by an OSP fiber issue.  How do your "show
>> interface
>>   diagnostic optic" levels look?
>>
>>   On Wed, Oct 19, 2016 at 7:40 PM, David B Funk <
>> dbf...@engineering.uiowa.edu>
>>   wrote:
>>
>>   > I've got a couple of 10Gig-eth interfaces (xe- on MX480) of which
>> I'm
>>   > trying to interpret the "PCS statistics" values.
>>   >
>>   > One of them is pretty steady at:
>>   >
>>   >   PCS statistics  Seconds
>>   > Bit errors 4
>>   > Errored blocks 4
>>   >
>>   > The other one seems to vary with the values ranging from 10 to 70.
>>   > EG:
>>   >
>>   >   PCS statistics  Seconds
>>   > Bit errors61
>>   > Errored blocks69
>>   >
>>   > The second interface will will trigger a number of error
>> conditions at the
>>   > other end which terminates in a Cisco router with out showing any
>> error
>>   > conditions at my end (EG BPDU Error: None, MAC-REWRITE Error:
>> None,
>>   > CRC/Align errors 0, FIFO errors 0, etc..) During some of these
>> times I'll
>>   > see significant packet loss and others see minimal problems.
>>   >
>>   > According to Juniper docs the PCS statistics should mean:
>>   >
>>   >  PCS statistics
>>   >   (10-Gigabit Ethernet interfaces) Displays Physical Coding
>> Sublayer (PCS)
>>   > fault
>>

Re: [j-nsp] MPC4E-32XGE firmware

[Wojciech Janiszewski]

Hi Jonas,

The easiest way is to install jfirmware package appropriate for your Junos
release (you can get it from JTAC) and then:
- show system firmware
to check that there is a new software available
- request system firmware upgrade pic fpc-slot X pic-slot Y
to upgrade firmware
- show system firmware
to check that the firmware is upgraded
- request chassis mic fpc-slot X mic-slot Y offline
- request chassis mic fpc-slot X mic-slot Y online
- request system software delete jfirmware

Regards,
Wojciech

2016-03-01 16:37 GMT+01:00 Jonas Frey (Probe Networks) :

> Hello,
>
> i am getting the following notice in the logs:
>
> Mar  1 13:58:07   fpc0 CMIC(0/3): VSC8248 cmic-vsc8248-0/0/7 is running
> out-of-date firmware version 2.52 (0x234).  Please upgrade firmware to
> version 2.53 (0x235) or later.
>
> Does anyone know howto update these?
>
> -Jonas
>
>
>
> ___
> 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] sequential commands in SLAX

[Wojciech Janiszewski]

Hi Martin,

I believe that jcs:invoke() is just a shortcut for jcs:open(),
jcs:execute() and jcs:close(), so you get a new connection each time you
execute jcs:invoke().

Regards,
Wojciech

2016-01-14 10:23 GMT+01:00 Martin T :

> Hi,
>
> while I am aware of jcs:open() function, which allows one to execute
> commands on other routing-engine, I was wondering if following logic
> is also possible in SLAX:
>
> $ cat login_to_other_re.slax
> version 1.0;
>
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
> import "../import/junos.xsl";
>
> match / {
>{
>
> /* rlogin to second RE */
> var $cmd_login_other_re =  "request routing-engine login
> other-routing-engine";
> var $cmd_login_other_re_results = jcs:invoke( $cmd_login_other_re );
>
> /* print out the name of the second RE */
>  $junos-context//routing-engine-name;
>
> /* exit rlogin session */
> var $cmd_quit_other_re =  "quit";
> var $cmd_quit_other_re_results = jcs:invoke( $cmd_quit_other_re );
>
>   }
> }
> $
>
>
> Why doesn't such approach work?
>
>
> thanks,
> Martin
> ___
> 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] RPD Crash on M320

[Wojciech Janiszewski]

Hi,

11.2 is end of support so my guess is that's there no point in raising a
case. As first step  I'd  try the upgrade to some supported release and
then check if that helps.

Regards,
Wojciech
4 sty 2016 17:02 "Niall Donaghy"  napisał(a):

>
>
> From your comments I understand there was no CPU spike, and traceoptions
> aren’t the cause either.
>
> By this point* I would have raised a JTAC case for analysis of the core
> dump, and taken their lead.
>
>
>
> * assuming you’ve checked all sources of information and found no clues as
> to the cause, ie: logfile analysis, resource exhaustion checks, analysis of
> config, eg: are you using suspected buggy features, or anything
> non-standard/complex/advanced?
>
>
>
> We are running 14.1R5.5 on MX series and have lots of features turned on,
> and several workarounds in place. We have found a few bugs for JNPR...
>
>
>
> Kind regards,
>
> Niall
>
>
>
> From: Alireza Soltanian [mailto:soltan...@gmail.com]
> Sent: 04 January 2016 15:18
> To: Niall Donaghy
> Cc: juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] RPD Crash on M320
>
>
>
> Just asking. Anyway any idea about my comments? Also is there any
> mechanism or approach for dealing with these kind of situations?
>
> On Jan 4, 2016 6:45 PM, "Niall Donaghy"  > wrote:
>
> Reading the core dump is beyond my expertise I’m afraid.
>
>
>
> Br,
>
> Niall
>
>
>
> From: Alireza Soltanian [mailto:soltan...@gmail.com  soltan...@gmail.com> ]
> Sent: 04 January 2016 15:14
> To: Niall Donaghy
> Cc: juniper-nsp@puck.nether.net 
> Subject: RE: [j-nsp] RPD Crash on M320
>
>
>
> Hi
> Yes I checked the CPU graph and there was a spike on CPU load.
> The link was flappy 20 minutes before crash. Also it remained flappy two
> hours after this crash. During this time we can see LDP sessions go UP DOWN
> over and over. But the only time there was a crash was this time and there
> is no spike on CPU.
> I must mention we had another issue with another M320. Whenever a link
> flapped, CPU of RPD went high and all OSPF sessions reset. I found out the
> root cause for that. It was traceoption for LDP. For this box we dont use
> traceoption.
> Is there any way to read the dump?
>
> Thank you
>
> On Jan 4, 2016 6:34 PM, "Niall Donaghy"  > wrote:
>
> Hi Alireza,
>
> It seemed to me this event could be related to the core dump: Jan  3
> 00:31:28  apa-rtr-028 /kernel: jsr_prl_recv_ack_msg(): received PRL ACK
> message on non-active socket w/handle 0x10046fa004e
> However upon further investigation
> (http://kb.juniper.net/InfoCenter/index?page=content <
> http://kb.juniper.net/InfoCenter/index?page=content=KB18195>
> =KB18195) I see these
> messages are normal/harmless.
>
> Do you have Cacti graphs of CPU utilisation for both REs, before the rpd
> crash? Link flapping may be giving rise to CPU hogging, leading to
> instability and subsequent rpd crash.
> Was the link particularly flappy just before the crash?
>
> Kind regards,
> Niall
>
>
>
>
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net  juniper-nsp-boun...@puck.nether.net> ] On Behalf
> Of
> > Alireza Soltanian
> > Sent: 04 January 2016 11:04
> > To: juniper-nsp@puck.nether.net 
> > Subject: [j-nsp] RPD Crash on M320
> >
> > Hi everybody
> >
> > Recently, we had continuous link flap between our M320 and remote sites.
> We
> > have a lot of L2Circuits between these sites on our M320. At one point we
> had
> > crash on RPD process which lead to following log. I must mention the link
> flap
> > started at 12:10AM and it was continued until 2:30AM. But Crash was
> occurred
> > at 12:30AM.
> >
> >
> >
> > Jan  3 00:31:04  apa-rtr-028 rpd[42128]: RPD_LDP_SESSIONDOWN: LDP session
> > 10.237.253.168 is down, reason: received notification from peer
> >
> > Jan  3 00:31:05  apa-rtr-028 rpd[42128]: RPD_LDP_SESSIONDOWN: LDP session
> > 10.237.254.1 is down, reason: received notification from peer
> >
> > Jan  3 00:31:05  apa-rtr-028 rpd[42128]: RPD_LDP_SESSIONDOWN: LDP session
> > 10.237.253.120 is down, reason: received notification from peer
> >
> > Jan  3 00:31:05  apa-rtr-028 /kernel: jsr_prl_recv_ack_msg(): received
> PRL
> ACK
> > message on non-active socket w/handle 0x1008af801c6
> >
> > Jan  3 00:31:06  apa-rtr-028 rpd[42128]: RPD_LDP_SESSIONDOWN: LDP session
> > 10.237.253.192 is down, reason: received notification from peer
> >
> > Jan  3 00:31:28  apa-rtr-028 /kernel: jsr_prl_recv_ack_msg(): received
> PRL
> ACK
> > message on non-active socket w/handle 0x10046fa004e
> >
> >
> >
> > Jan  3 00:32:18  apa-rtr-028 init: routing (PID 42128) terminated by
> signal
> > number 6. Core dumped!
> >
> > Jan  3 00:32:18  apa-rtr-028 init: routing (PID 18307) started
> >
> > Jan  3 00:32:18  apa-rtr-028 rpd[18307]: L2CKT acquiring mastership for
> 

Re: [j-nsp] Radius Accounting in Juniper Steel Belted Radius with Cisco IOS devices

[Wojciech Janiszewski]

Hi Arun,

It's been a while since I last touched SBR but for sure you may configure
SBR to store accounting records in an external database like SQL.
After that making a nice GUI that would allow you to filter or aggregate
the data shouldn't be a problem.

Regards,
Wojciech

2015-08-25 11:51 GMT+02:00 Arun Kumar narain.a...@gmail.com:

 Hi All,

 I am evaluating Juniper SBR as AAA server. Most of the devices in our
 network are Cisco. Completed Authentication and Authorization part of SBR
 but stuck in Accounting part.

 The requirement is to have GUI in SBR to view 'accounting' logs per device,
 but in SBR all the accounting logs are stored in a notepad but date-wise
 and not on device-wise.

 a. Would there be an option of providing the accounting logs per device
 view in .GUI
 b. Use of 3rd party tools to achieve this.


 thanks in advance
 Arun
 ___
 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] Fwd: Quick way to Shift MPLS traffic away from an interface

[Wojciech Janiszewski]

Hi Adam,

RFC 5817 could be a solution for that problem but apparently it's not
supported yet. Pitty.

Regards,
Wojciech
22 maj 2015 15:13 Adam Vitkovsky adam.vitkov...@gamma.co.uk napisał(a):

 Hello Tim,

  tim tiriche
  Sent: 21 May 2015 04:02
 
  Hello,
 
  What is the quick way to shift LSP traffic from an interface after
  increasing the igp metric?
 
 If you have configured loose EROs (hops) in your LSPs and you have also
 used optimize-timer (as unfortunately Juniper does not have a reoptimize
 timer enabled by default) the LSPs should reoptimize automatically after a
 period of time configured.


  question:
 
  - What command can I use to find all lsp traversing the iface and a good
  way to clear them? I am assuming I would need to run clear mpls
  optimize-aggressive on the lsp's on that particular router only? Is my
  understanding correct?
 
 I think you can use show mpls lsp to list the active RSVP LSPs
 traversing the box.

 But how to trigger LSP reoptimization from a mid-point router that is a
 good question indeed.
 Since the LSPs are signalled from the head-end router they can be rerouted
 only by the head-end router.
 Saying that you have to force the mid-point router to send a RSVP PathErr
 msg towards the head-end router,
 the head-end router should then perform the LSP reoptimization
 As Ivan proposed breaking the RSVP session is the obvious choice
 -but preferably you'd want to do the reoptimization in a make before break
 fashion (though if you don't have the LSPs configured as adaptive it
 doesn't matter)
 -anyways I really don't know if it's possible to trigger reoptimization
 from a mid-point router when you are not using BW reservations.



  - Is it a good idea to turn on optimize-aggressive?
 If you are using RSVP LSPs just for pure MPLS forwarding and not for BW
 reservations or you're not using SRLGs then you can reduce the CSPF to just
 comparing IGP metric.

 
  Any best practices or pointers would be appreciated!
 I think that good practice would be optimize-timer so that paths are
 optimized automatically (e.g. once a day) and to use adaptive LSPs to
 enable make before break.


 addam

 ---
  This email has been scanned for email related threats and delivered
 safely by Mimecast.
  For more information please visit http://www.mimecast.com

 ---
 ___
 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] Is there juniper output interpreter ?

[Wojciech Janiszewski]

Hi Brijesh,

You might take a look at JCATS - Juniper Case Attachment Tool Suite
  http://kb.juniper.net/TN299
You need to be registered to use it.

To get a simple backtrace from the core file you might use:
  show system core-dumps core-file-info core-filename

Regards,
Wojciech

2015-05-15 13:39 GMT+02:00 Brijesh Patel brju.pa...@gmail.com:

 Hi All,

 Most of in this community I guess everyone face core dump (show system
 core-dump)in juniper. and most of time as requested by juniper we ftp to
 juniper. Rest we all know,

 *Any one has idea where we can find like cisco output interpreter for
 juniper ?*

 Many Thanks,

 Brijesh Patel
 ___
 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] DDOS_PROTOCOL_VIOLATION_SET: Protocol Reject:aggregate

[Wojciech Janiszewski]

Hi,

Make sure that you have a discard next-hop instead of default reject in
your aggregate routes.
That should help.

Regards,
Wojciech

2014-12-10 23:16 GMT+01:00 Brendan Mannella bmanne...@teraswitch.com:

 Just wondering if anyone has ever seen these DDOS messages before and
 what i should be looking at to resolve.

 Dec 10 11:10:24  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 931 times, from 2014-12-10 11:05:23
 EST to 2014-12-10 11:05:23 EST

 Dec 10 11:23:44  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 932 times, started
 at 2014-12-10 11:23:43 EST

 Dec 10 11:28:49  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 932 times, from 2014-12-10 11:23:43
 EST to 2014-12-10 11:23:43 EST

 Dec 10 12:50:55  re0.edge2 xntpd[2681]: kernel time sync enabled 6001

 Dec 10 13:08:00  re0.edge2 xntpd[2681]: kernel time sync enabled 2001

 Dec 10 15:01:34  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
 Protocol Reject:aggregate is violated at fpc 1 for 933 times, started
 at 2014-12-10 15:01:33 EST

 Dec 10 15:06:34  re0.edge2 jddosd[2710]:
 DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
 to normal. Violated at fpc 1 for 933 times, from 2014-12-10 15:01:33
 EST to 2014-12-10 15:01:33 EST
 ___
 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] DDOS_PROTOCOL_VIOLATION_SET: Protocol Reject:aggregate

[Wojciech Janiszewski]

Hi Rodrigo,

It is as simple as set routing-options aggregate route destination
discard

Regards,
Wojciech

2014-12-11 4:22 GMT+01:00 Rodrigo 1telecom rodr...@1telecom.com.br:

 Can you put an exame of this configuration Janiszewski?!


 Enviado via iPhone 
 Grupo Connectoway

  Em 10/12/2014, às 23:54, Wojciech Janiszewski 
 wojciech.janiszew...@gmail.com escreveu:
 
  Hi,
 
  Make sure that you have a discard next-hop instead of default reject
 in
  your aggregate routes.
  That should help.
 
  Regards,
  Wojciech
 
  2014-12-10 23:16 GMT+01:00 Brendan Mannella bmanne...@teraswitch.com:
 
  Just wondering if anyone has ever seen these DDOS messages before and
  what i should be looking at to resolve.
 
  Dec 10 11:10:24  re0.edge2 jddosd[2710]:
  DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
  to normal. Violated at fpc 1 for 931 times, from 2014-12-10 11:05:23
  EST to 2014-12-10 11:05:23 EST
 
  Dec 10 11:23:44  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
  Protocol Reject:aggregate is violated at fpc 1 for 932 times, started
  at 2014-12-10 11:23:43 EST
 
  Dec 10 11:28:49  re0.edge2 jddosd[2710]:
  DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
  to normal. Violated at fpc 1 for 932 times, from 2014-12-10 11:23:43
  EST to 2014-12-10 11:23:43 EST
 
  Dec 10 12:50:55  re0.edge2 xntpd[2681]: kernel time sync enabled 6001
 
  Dec 10 13:08:00  re0.edge2 xntpd[2681]: kernel time sync enabled 2001
 
  Dec 10 15:01:34  re0.edge2 jddosd[2710]: DDOS_PROTOCOL_VIOLATION_SET:
  Protocol Reject:aggregate is violated at fpc 1 for 933 times, started
  at 2014-12-10 15:01:33 EST
 
  Dec 10 15:06:34  re0.edge2 jddosd[2710]:
  DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol Reject:aggregate has returned
  to normal. Violated at fpc 1 for 933 times, from 2014-12-10 15:01:33
  EST to 2014-12-10 15:01:33 EST
  ___
  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

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

Re: [j-nsp] MX5 BNG licensing

[Wojciech Janiszewski]

Correct, unless you use other features that requires S-MX80-SSM-FP.

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

Re: [j-nsp] MX5 BNG licensing

[Wojciech Janiszewski]

Hi Андрей,

In addition to ordinary per-subscriber AAA you may also configure
per-service accounting for which the S-MX80-SSM-FP license is required.

Regards,
Wojciech

2014-09-22 5:20 GMT+02:00 Шепелев Андрей xamalon...@gmail.com:

 HI!
 Wojciech Janiszewski - can you explain in more details about S-MX80-SSM-FP
 license.
 What do you mean license is not necessary if you only need
 per-subscriber AAA.

 thx

 2014-09-22 3:46 GMT+06:00 Wojciech Janiszewski 
 wojciech.janiszew...@gmail.com:

 Hi Octavio,

 IIRC the S-MX80-SSM-FP license is not necessary if you only need
 per-subscriber AAA. The S-MX80-SSM-FP is required if you need per-service
 accounting or need to change variables within profile via Radius, or
 require COA, RID or SRC.  In addition you might require SA-nnnK license
 according to the number of subscribers connected.

 Regards,
 Wojciech

 2014-09-21 8:14 GMT+02:00 Octavio Alfageme octavio.alfag...@gmail.com:

  Hello everyone,
 
  MX5 has two licenses related to subscriber management:
 
  * S-MX80-SA-FP - Subscriber Management Feature Pack License on MX80
 Series
  * S-MX80-SSM-FP - Subscriber Service Management Feature Packet License
  (RADIUS/SRC Based Service Activation and Deactivation) Per-Service
  Accounting Features for Subscribers, MX80 Series
 
  I would like to manage my subscribers' service from a RADIUS server. Do
 you
  know if I need both licenses or only the second one? I believe they are
  incremental, but I would like somebody to confirm it.
 
  Thanks in advance
 
  Kind regards
 
  Octavio
 
 ___
 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] MX5 BNG licensing

[Wojciech Janiszewski]

Hi Octavio,

IIRC the S-MX80-SSM-FP license is not necessary if you only need
per-subscriber AAA. The S-MX80-SSM-FP is required if you need per-service
accounting or need to change variables within profile via Radius, or
require COA, RID or SRC.  In addition you might require SA-nnnK license
according to the number of subscribers connected.

Regards,
Wojciech

2014-09-21 8:14 GMT+02:00 Octavio Alfageme octavio.alfag...@gmail.com:

 Hello everyone,

 MX5 has two licenses related to subscriber management:

 * S-MX80-SA-FP - Subscriber Management Feature Pack License on MX80 Series
 * S-MX80-SSM-FP - Subscriber Service Management Feature Packet License
 (RADIUS/SRC Based Service Activation and Deactivation) Per-Service
 Accounting Features for Subscribers, MX80 Series

 I would like to manage my subscribers' service from a RADIUS server. Do you
 know if I need both licenses or only the second one? I believe they are
 incremental, but I would like somebody to confirm it.

 Thanks in advance

 Kind regards

 Octavio

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

Re: [j-nsp] OSPF Confusion

[Wojciech Janiszewski]

Hi Crist,

From this Router LSA you can see that 10.56.1.1 (R3) has two links:
1) id 10.56.1.1, data 10.56.1.1, Type Transit (2)
where:
id 10.56.1.1 - Designated Router address for that link
data 10.56.1.1 - IP address of interface of router R3 for that link
2) id 10.56.1.17, data 10.56.1.17, Type Transit (2)
where:
id 10.56.1.17- Designated Router address for that link
data 10.56.1.17 - IP address of interface of router R3 for that link

I assume that R3 is a DR for that links, and then the aforementioned
outputs is correct.

If you would look at the router LSA of the other routers, for the same
links you would probably see something like this:
for R1 - id 10.56.1.1, data 10.56.1.14, Type Transit (2)
for R2 - id 10.56.1.17, data 10.56.1.22, Type Transit (2)

Regarding your question, please check the Forwarding Addresses in NSSA LSAs
and how they resolve.

Regards,
Wojciech Janiszewski


2014-02-26 0:11 GMT+01:00 Crist Clark cjc+j-...@pumpky.net:

 This may be something simple, but I've been staring at it a while and am
 confused now. I have a rather simple network,

 11

 R1 - R2

  \   /20

   \10   /

\   /

 \ /

  \   /

 10\ /20

   R3


 The numbers are the OSPF metrics for each interface. The R1-R2 link is 10
 Gbps. The interface metric is manually set to 1 on R1 and R2. The other two
 links are both 1 Gbps media, but the R1-R3 is limited to 500 Mbps and the
 R2-R3 to 100 Mbps by their respective carriers. (Well, not really. This is
 a lab set up meant to simulate the real network.) I've used the 10 and 20
 metrics on the interfaces as shown to tell OSPF something about that.


 What I want to happen is all traffic from R3 to go to both R1 and R2 via
 the R1-R3 link unless that link is down. With the costs configured as they
 are, I would think it would do that, but it's not working for R3.


 This is all a NSSA. R3 is distributing a default route into the area. Both
 R1 and R2 are importing static routes into the area. The routing on R1 and
 R2 works how I want. R2 sees R1 as the best next hop for the default and
 all of R1's statics. R1 sees R3 as the default next hop and sees R2 as best
 for all of R2's statics.


 The problem is that R3 sees R2 as the best next hop for all of the statics
 on R2. I don't understand why. The cost of the path from R3 to R2 is lowest
 via R1, 11 vs. 20, right?


 R3 is a EX4500/4200 chassis running 11.1R3.5. In trying to troubleshoot
 this, I'm also a bit baffled by the router LSA that R3 is sending out to
 the area. Here's the IP info for the links,


 R1-R2:  160.33.151.85-160.33.151.86/30

 R1-R3:  10.56.1.14-10.56.1.1/28

 R2-R3:  10.56.1.22-10.56.1.17/29


 But when I look at the LSA for itself in R3's database,


 OSPF database, Area 0.0.0.1

  Type   ID   Adv Rtr   Seq  Age  Opt  Cksum
  Len

 Router  *10.56.1.110.56.1.10x8030  2005  0x20 0x9786
  48

   bits 0x2, link count 2

   id 10.56.1.1, data 10.56.1.1, Type Transit (2)

 Topology count: 0, Default metric: 10

   id 10.56.1.17, data 10.56.1.17, Type Transit (2)

 Topology count: 0, Default metric: 20

   Topology default (ID 0)

 Type: Transit, Node ID: 10.56.1.17

   Metric: 20, Bidirectional

 Type: Transit, Node ID: 10.56.1.1

   Metric: 10, Bidirectional

   Gen timer 00:09:48

   Aging timer 00:26:35

   Installed 00:33:25 ago, expires in 00:26:35, sent 00:33:23 ago

   Last changed 00:36:20 ago, Change count: 22, Ours

 It looks like its listing itself in as its neighbors? Wha'?

 The other devices' router LSAs look like I expect. BTW, the other two
 routers are Palo Alto Networks firewalls.

 Like I said, I'm probably missing something easy. Haven't done much OSPF in
 JUNOS or tried much traffic shaping before.
 ___
 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] MX960 - Release 12.3R4

[Wojciech Janiszewski]

Hi,

If you consider rsvp and link-protection, it's better to use 12.3R5

Regards,
Wojciech
22 sty 2014 04:02, Giuliano Medalha giuli...@wztech.com.br napisał(a):

 People,

 Does anyone used JUNOS 12.3R4 on MX960 gear ?

 Is this a stable release ?

 Could you please send some feedback about it ?

 We have a recommendation of using it but we need to know if is stable or
 not in production environment ... considering BGP and MPLS.

 Thanks a lot,

 Giuliano
 ___
 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] smartctl for junos

[Wojciech Janiszewski]

Hi,

You can read smart data from the shell using smartd with appropriate
parameters, i.e. smartd -oa /dev/ad2
Please follow http://kb.juniper.net/KB13103 for more details.

It is also possible to read smart data and execute smart tests from
cli, by using hidden hard-disk-test command, i.e.
request chassis routing-engine hard-disk-test disk /dev/ad2 show-status

Regards,
Wojciech Janiszewski



2014/1/8 snort bsd snort...@yahoo.com.au

 hi all:

 there is smartd running on junos, but i am not able to find smartctl 
 utility for smartd.

 thanks
 ___
 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] 'lib_ifbd-ifbd_curr_num_macs = adjust_count' failed

[Wojciech Janiszewski]

Hi Lukasz,

IMHO it's a software bug in Layer 2 address learning daemon. You should
send collected core dump file to JTAC, for further analysis.

Regards,
Wojciech Janiszewski


2013/10/21 Lukasz Trabinski luk...@trabinski.net

 Hi

 Strange situation on MX960 (Junos 10.4S12) with following scenario:

 About 250 customers with static mac addresses and no-mac-learning options
 putted into

 routing-instances XXX bridge-domains XXX

 with following configuration:

 interface xe-xx/x/x.xxx {
 interface-mac-limit {
 1;
 packet-action drop;
 }
 static-mac xx:xx:xx:xx:xx:x;
 no-mac-learning;


 After flap (up/down) of the 10Gbit/s port

 we got:

 Oct 17 09:43:55  xx-xx_re0 fpc0 ICHIP(0)_REG_ERR:5 Wi seg ucode discards
 in fabric stream 40 pfe_id 20

 and some traffic to some random ports was dropped.

 After that, we decided to deactivate and activate some static mac address
 and no-mac-learning

 deactivate routing-instances XXX bridge-domains XXX bridge-options
 interface  aex.xx static-mac xx:xx:xx:xx:xx:x

 commit

 activate routing-instances XXX bridge-domains XXX bridge-options
 interface  aex.xx static-mac xx:xx:xx:xx:xx:x

 commit

 After last commit, we got message from syslog:

 xx-xx_re0 l2ald[86898]: ../../../../src/junos/usr.**
 sbin/l2ald/l2ald_mlrn_ifbd.h:**175: insist 'lib_ifbd-ifbd_curr_num_macs
 = adjust_count' failed


 and core files was dumped into /var/tmp/


 Solution of this problems was:

 deactivate routing-instances XXX bridge-domains XX bridge-options
 commit
 activate routing-instances XXX bridge-domains XX bridge-options
 commit

 Question is, is that software or hardware bug? Why flap of one TenGig port
 caused problem with traffic beetween other ports?



 Lukasz
 __**_
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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] vrf-table-lable with logical systems

[Wojciech Janiszewski]

Yes. A least on M-series.

Regards,
Wojciech Janiszewski

W dniu 2011-07-14 16:22 użytkownik Vladislav A. VASILEV 
vladislavavasi...@gmail.com napisał:

Does anyone know if vrf-table-lable is supported with logical-systems and
VLAN core-facing interfaces between P/PE routers? I seem to be not able to
find that information on Juniper's website.

Thank you!

Regards,
Vladislav A. VASILEV
___
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