[j-nsp] Junos EEOL releases confusion
Hello there! Let's say i have 9.3R3.8 and 9.3R4.4 in production I hit some bugs here and there. JTAC provided me with fix for one bug and gave me 9.3S5 version. Also they told me i can use it in producion. Now i have questions. Is it service release or not? If yes, i don't want to use in producion If no, where is the place where i can download it and future relases which has all bugfixes? For some reasons Juniper staff can't (or don't want) provide clear answers. They said that there will be no *R* relases in 9.3 anymore only *S* ones. but things are still unclear for me. If its a release where are release notes so on ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos EEOL releases confusion
Hi Tima If JTAC recommends a specific Junos Service release for your network, you can few it as being equivalent to a maintenance release. A service release is also requestion tested against the required platforms but does not have release notes as you mentioned. On 2009/12/22 10:01, Tima Maryin wrote: Hello there! Let's say i have 9.3R3.8 and 9.3R4.4 in production I hit some bugs here and there. JTAC provided me with fix for one bug and gave me 9.3S5 version. Also they told me i can use it in producion. Now i have questions. Is it service release or not? If yes, i don't want to use in producion If no, where is the place where i can download it and future relases which has all bugfixes? For some reasons Juniper staff can't (or don't want) provide clear answers. They said that there will be no *R* relases in 9.3 anymore only *S* ones. but things are still unclear for me. If its a release where are release notes so on ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Anton ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE-forwarded IPv6
Can you post the relevant configuration from the box? I expect that the host is directly connect to the MX-960; and the interface that is facing the host is running RA; furthermore if you look at the routing table on the host, you will see a default route to the MX's link-local address? Now is the 6in4 tunnel configured on the MX or is this further upstream? Does the other end of the 6in4 tunnel know how to reach your prefixes? Kind regards, Truman On 21/12/2009, at 9:57 AM, Jonathan Lassoff wrote: I'm having an odd problem routing IPv6 traffic through an MX-960 I'm testing. I'm sending traffic from a directly connected host through the Juniper box to be routed out to the Internet. I can ping the address on the MX from the downstream router, but can't seem to route *through* the Juniper. One thing that may be pertinent is that the next-hop I expect the traffic should take is on the other end of a 6in4 tunnel. Any ideas? Cheers, jonathan ___ 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] Does ERX 14xx support mac authentication for static IP address ?
Hi, the ERX does not support 802.1x. In a static environment you can restrict MAC address on an interface though ... The ERX can provide RADIUS proxy support to an 802.1x network that is downstream from the ERX. Cheers, Truman On 14/12/2009, at 6:38 PM, guan wang wrote: Hi All As i know the ERX support mac authentication for DHCP and PPPoE . But i cannot find any authentication solution on the ERX to deal with static IP address . Does ERX 14xx support mac authentication for static IP address ? like 802.1x ? Thanks WangGuan ___ 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] Junos EEOL releases confusion
9.3S5 _is_ a Service Release and it is fully supported. It _is_ intended for production use. E-EOL releases are maintained using the Service Release mechanism, and, as you were told, there will be no more R releases for 9.3. Throughout the remainder of the 9.3 E-EOL support period, there will only be S releases. Service Releases are made available to customers on an as-needed basis. You will be provided with a download URL whenever a service release is recommended as the resolution of a support case. Release Notes are not provided for service releases; you can obtain a list of PRs fixed from your support team. Paul Goyette Juniper Networks Customer Service JTAC Senior Escalation Engineer Juniper Security Incident Response Team PGP Key ID 0x53BA7731 Fingerprint: FA29 0E3B 35AF E8AE 6651 0786 F758 55DE 53BA 7731 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tima Maryin Sent: Tuesday, December 22, 2009 1:02 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Junos EEOL releases confusion Importance: High Hello there! Let's say i have 9.3R3.8 and 9.3R4.4 in production I hit some bugs here and there. JTAC provided me with fix for one bug and gave me 9.3S5 version. Also they told me i can use it in producion. Now i have questions. Is it service release or not? If yes, i don't want to use in producion If no, where is the place where i can download it and future relases which has all bugfixes? For some reasons Juniper staff can't (or don't want) provide clear answers. They said that there will be no *R* relases in 9.3 anymore only *S* ones. but things are still unclear for me. If its a release where are release notes so on ? ___ 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] Urgent reply required
Hi, I have following topology ospf Agilentrouter I am pumping type 5 ext LSA from agilent to the router. I observe in the ospf database, i am seeing Extern LSA, but i dont see it in the routing table. What could be the reason. Urgent reply is appreciated. Thanks with Regds, Shekar.B -- Thanks with regards Shekar.B -- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RED Drops with Qos
Scott,
I think the packet dropping is unavoidable, no matter how you configure RED.
Most of the time, your TCP is in congestion avoidance state, it increases
its transmission window size by one every RTT (round trip time). In other
words, it will increase its transmission rate till congestion happens (that
is when RED or tail drop kicks in). After TCP detects packet drops, it will
decrease its window size by half ,and start increasing its transmission
window size by one every RTT till congestion happens again.
If you are using MS Windows TCP, Windows has a default limit on the maximum
TCP window size (I do not remember the exact number). So if you have enough
number of T1 to support the maximum TCP transmission rate limited by the
maximum window size, you will not see drops. You can also change the
maximum TCP window size to much larger number by editing the registry.
Li
On Mon, Dec 21, 2009 at 4:58 PM, Scott Berkman sc...@sberkman.net wrote:
Derick,
FYI after making your suggested changes I am still seeing drops:
show configuration chassis fpc 2 pic 2
red-buffer-occupancy {
weighted-averaged {
instant-usage-weight-exponent 9;
}
}
show interfaces queue ds-2/2/0:1:5:1
Physical interface: ds-2/2/0:1:5:1, Enabled, Physical link is Up
Interface index: 165, SNMP ifIndex: 79
Description: Test-1
Forwarding classes: 4 supported, 4 in use
Egress queues: 4 supported, 4 in use
Queue: 0, Forwarding classes: be
Queued:
Packets : 290 0 pps
Bytes:375596 0 bps
Transmitted:
Packets : 268 0 pps
Bytes:346908 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets :22 0 pps
Low, non-TCP: 0 0 pps
Low, TCP:22 0 pps
High, non-TCP : 0 0 pps
High, TCP : 0 0 pps
RED-dropped bytes: 28688 0 bps
Low, non-TCP: 0 0 bps
Low, TCP: 28688 0 bps
High, non-TCP : 0 0 bps
High, TCP : 0 0 bps
Thanks,
-Scott
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: Monday, December 21, 2009 4:41 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there
is
no allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and
you
should put a weight of 9 as a start.
From: Scott Berkman sc...@sberkman.net
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing
RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously
wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
Re: [j-nsp] Urgent reply required
The router does need to know who is the ASBR otherwise it won't install this route in the RIB. So the router need to have a LSA type 4 present in the ospf database. JNCIS Study Guide page 85. HTH ./diogo -montagner On Tue, Dec 22, 2009 at 12:17 PM, chandrasekaran iyer shekar1...@gmail.com wrote: Hi, I have following topology ospf Agilentrouter I am pumping type 5 ext LSA from agilent to the router. I observe in the ospf database, i am seeing Extern LSA, but i dont see it in the routing table. What could be the reason. Urgent reply is appreciated. Thanks with Regds, Shekar.B -- Thanks with regards Shekar.B -- ___ 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] Urgent reply required
I don't know about anyone else, but I'd really appreciate it, if every post you posted wasn't 'urgent'. We're not here to serve you. -Shane On 22/12/2009, at 10:17 PM, chandrasekaran iyer wrote: Hi, I have following topology ospf Agilentrouter I am pumping type 5 ext LSA from agilent to the router. I observe in the ospf database, i am seeing Extern LSA, but i dont see it in the routing table. What could be the reason. Urgent reply is appreciated. Thanks with Regds, Shekar.B -- Thanks with regards Shekar.B -- ___ 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] Urgent reply required
What? this isn't JTAC? =) Regards, - Chris. On 2009-12-22, at 7:22 AM, Shane Short wrote: I don't know about anyone else, but I'd really appreciate it, if every post you posted wasn't 'urgent'. We're not here to serve you. -Shane On 22/12/2009, at 10:17 PM, chandrasekaran iyer wrote: Hi, I have following topology ospf Agilentrouter I am pumping type 5 ext LSA from agilent to the router. I observe in the ospf database, i am seeing Extern LSA, but i dont see it in the routing table. What could be the reason. Urgent reply is appreciated. Thanks with Regds, Shekar.B -- Thanks with regards Shekar.B -- ___ 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] PFE-forwarded IPv6
Excerpts from Truman Boyes's message of Tue Dec 22 04:17:22 -0800 2009:
Can you post the relevant configuration from the box? I expect that the host
is
directly connect to the MX-960; and the interface that is facing the host is
running RA; furthermore if you look at the routing table on the host, you will
see a default route to the MX's link-local address?
Actually, I was testing with a Cisco Cat6k/Sup720 box downstream to test
the interoperability of the two routers, and also IPv6 on the Cat6k.
As a test to better understand what's going on, I attached a host
downstream from the MX960. I can ping and reach the MX's inet6 interface
just fine. I'm also setting my default route to go through the inet6
interface on the MX. Pinging out to 2001:500:2f::f (f.root-servers.net)
through this interface causes the MX to return an ICMPv6 Unreachable
(Address unreachable) message.
However, there's a route on the MX to that destination:
--
j...@mx1.sfo2-re0 show route 2001:500:2f::f
inet6.0: 2299 destinations, 2302 routes (2299 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:500:2f::/48 *[BGP/170] 1w3d 20:24:53, localpref 100
AS path: x 3557 I
to :xxx::xx::1 via ipip.0
--
Here's the relevant configuration of interface ipip:
--
j...@mx1.sfo2-re0 show configuration interfaces ipip
unit 0 {
tunnel {
source xxx.xxx.xxx.xxx;
destination xxx.xxx.xxx.xxx;
}
family inet6 {
address 2001:xxx::xx::2/64;
}
}
--
Thanks for any help or insight you can provide.
Cheers,
jonathan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Does ERX 14xx support mac authentication for static IP address ?
WangGuan, The ERX supports static subscriber interfaces, but configuration is a very manual process unless you also have an SDX/SRC: interface ip rs192.168.112.26 ip share-interface GigabitEthernet 4/0.21 ip unnumbered loopback 1 no ip proxy-arp ip source-prefix 192.168.112.26 255.255.255.255 ! Cheers, Ben On 14/12/2009, at 5:38 PM, guan wang wrote: Hi All As i know the ERX support mac authentication for DHCP and PPPoE . But i cannot find any authentication solution on the ERX to deal with static IP address . Does ERX 14xx support mac authentication for static IP address ? like 802.1x ? Thanks WangGuan ___ 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] no router alert
This is expected behaviour. All other IP packets will also have an ip-options
field and they are matching so they are then discarded. Maybe you need some
more terms to accomplish what you want. I suspect you might want to explicitly
discard specific ip-options.
Truman
On 21/12/2009, at 7:16 PM, Bit Gossip wrote:
Dear experts,
I am struggling to formulate a term to drop all packets with any
ip-option set apart from router-alert.
The following term does NOT work because drops not only packets with
ip-options other than router-alert, but also packet with NO
ip-option Which of course is devastating !
Any idea how to implement it?
Thanks,
bit.
inactive: term NO-RT-ALERT {
from {
ip-options-except router-alert;
}
then {
count NO-RT-ALERT;
log;
discard;
}
}
___
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] PFE-forwarded IPv6
Hi,
Have you enabled the tunnel-services statement at the [ edit chassis fpc
slot-number pic pic-number] stanza?
Otherwise the ipip.0 tunnel is only from the RE, which can't forward transit
traffic.
Truman
On 23/12/2009, at 8:47 AM, Jonathan Lassoff wrote:
Excerpts from Truman Boyes's message of Tue Dec 22 04:17:22 -0800 2009:
Can you post the relevant configuration from the box? I expect that the host
is
directly connect to the MX-960; and the interface that is facing the host is
running RA; furthermore if you look at the routing table on the host, you
will
see a default route to the MX's link-local address?
Actually, I was testing with a Cisco Cat6k/Sup720 box downstream to test
the interoperability of the two routers, and also IPv6 on the Cat6k.
As a test to better understand what's going on, I attached a host
downstream from the MX960. I can ping and reach the MX's inet6 interface
just fine. I'm also setting my default route to go through the inet6
interface on the MX. Pinging out to 2001:500:2f::f (f.root-servers.net)
through this interface causes the MX to return an ICMPv6 Unreachable
(Address unreachable) message.
However, there's a route on the MX to that destination:
--
j...@mx1.sfo2-re0 show route 2001:500:2f::f
inet6.0: 2299 destinations, 2302 routes (2299 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
2001:500:2f::/48 *[BGP/170] 1w3d 20:24:53, localpref 100
AS path: x 3557 I
to :xxx::xx::1 via ipip.0
--
Here's the relevant configuration of interface ipip:
--
j...@mx1.sfo2-re0 show configuration interfaces ipip
unit 0 {
tunnel {
source xxx.xxx.xxx.xxx;
destination xxx.xxx.xxx.xxx;
}
family inet6 {
address 2001:xxx::xx::2/64;
}
}
--
Thanks for any help or insight you can provide.
Cheers,
jonathan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE-forwarded IPv6
Excerpts from Truman Boyes's message of Tue Dec 22 18:25:23 -0800 2009:
Have you enabled the tunnel-services statement at the [ edit chassis fpc
slot-number pic pic-number] stanza?
Thanks Truman!
Nope. I've yet to find reference to this in the documentation relating
to setting up tunnels. Do you have any recommendations for where I find
out more about what this is doing architectually?
On which slot and pic number do you think I should choose? I read that
the MX's DPCs have built-in tunnel-services PICs along with a number of
fixed interface PICs.
I assumed I should choose the DPC and PIC number for the upstream
interface that goes towards the tunnel's outer IP destination:
j...@mx1.sfo2-re0 show configuration chassis fpc 3
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
However, I'm still seeing the same ICMPv6 responses, and traffic is not
passing.
Thanks,
Jonathan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE-forwarded IPv6
Hi Jonathan,
You can use any of your DPCs. On non-MX JUNOS routers you need to have tunnel
pics (ie. packet that needs to be encapsulated/tunneled/etc will switch from
PFE to PIC to PFE). MX does not require this because you can make the DPC
perform tunnel-services.
Once you create the tunnel-services function on the DPC, you can associate the
IPIP tunnel interface with the tunnel service. Ie. Change the IPIP.0 to:
ip-3/0/0.0, which corresponds to your FPC 3 PIC 0, port 0 unit 0.
Take a look at:
http://www.juniper.net/techpubs/software/junos/junos83/swconfig83-services/download/tunnel-config.pdf
Search for MX960.
Hope this helps. Your tunnel should work once you create this association.
Kind regards,
Truman
On 23/12/2009, at 2:49 PM, Jonathan Lassoff wrote:
Excerpts from Truman Boyes's message of Tue Dec 22 18:25:23 -0800 2009:
Have you enabled the tunnel-services statement at the [ edit chassis fpc
slot-number pic pic-number] stanza?
Thanks Truman!
Nope. I've yet to find reference to this in the documentation relating
to setting up tunnels. Do you have any recommendations for where I find
out more about what this is doing architectually?
On which slot and pic number do you think I should choose? I read that
the MX's DPCs have built-in tunnel-services PICs along with a number of
fixed interface PICs.
I assumed I should choose the DPC and PIC number for the upstream
interface that goes towards the tunnel's outer IP destination:
j...@mx1.sfo2-re0 show configuration chassis fpc 3
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
However, I'm still seeing the same ICMPv6 responses, and traffic is not
passing.
Thanks,
Jonathan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE-forwarded IPv6
Excerpts from Truman Boyes's message of Tue Dec 22 20:12:34 -0800 2009:
Hi Jonathan,
You can use any of your DPCs. On non-MX JUNOS routers you need to have tunnel
pics (ie. packet that needs to be encapsulated/tunneled/etc will switch from
PFE to PIC to PFE). MX does not require this because you can make the DPC
perform tunnel-services.
Once you create the tunnel-services function on the DPC, you can associate the
IPIP tunnel interface with the tunnel service. Ie. Change the IPIP.0 to:
ip-3/0/0.0, which corresponds to your FPC 3 PIC 0, port 0 unit 0.
That seems to have done the trick.
One thing I found when trying this on my platform is that configuring:
fpc 3 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
Which is:
FPC 3REV 15 750-021157 xxDPCE 40x 1GE R TX
CPUREV 03 710-022351 xxDPC PMB
PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) RJ45
Yields an ip-3/0/10, instead of the ip-3/0/0 that's shown as an example in the
documentation.
I configured this, and traffic passes just fine.
Thanks for the tip Truman.
Cheers,
jonathan
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Flow Based Router
Hi Guys while searching on the net for Flow Based router building limitation came across www.anagran.com who have built the first flow based router(or may be second after caspian). 1) Just want to know anybody has worked on this device and how effective it is. 2) Also are Juniper/Cisco plan to build such device in coming future. Regards Abhijeet.C ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
