Re: [j-nsp] SRX5800 HA over 40 KM
Hi, On Thu, Sep 30, 2010 at 3:36 PM, Fahad Khan fahad.k...@gmail.com wrote: I am unable to access this link. Can you please attach the file or provide exact URL? Start here: http://kb.juniper.net/index?page=contentid=TN21actp=LIST cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MPLSoMPLS - horrible?
Hi all, I'm pondering my first production use of MPLS and I'm looking for some free advice. I'm looking at building a new 'enterprise' network - an extranet of sorts - *on top of* a NSP's L3VPN service. It's all Ethernet. I'd like to be able to build my own pseudowires and create my own L3VPNs on top of the NSP's platform and without their involvement. In effect, my CE routers (from the NSP's perspective) become PE routers to *my* customers (3rd parties, e.g. business partners and suppliers). I suppose this means doing MPLSoMPLS, and actually depending on the upper layers in the protocol stack, it could end up looking pretty scary if you looked at what was being shifted around in the NSP's core :-) (over and above MPLS, I'm thinking about how the stack looks when further encapsulation, such as IPSec, is used.) So, noting the protocol stack size and potential MTU issues, is anyone doing this? How are you distributing labels? Is it too horrible to even contemplate? I'd be looking at using J and/or SRX as the CE-pseudo-PE devices. Any pointers would be appreciated. I've only just embarked on this little adventure and I'm still relative new to Juniper platforms. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] flow based v packet based routing
Hi Guys,
Quick question. We have 2 x 6350's on 100mb connections to the internet and a
secure tunnel between them. Both run 9.6R3.8.
We were only seeing 40mb/s throughput on this and as a last gasp before
faulting to the carriers we moved it onto packet based forwarding with the
below:-
forwarding-options {
family {
inet6 {
mode packet-based;
}
iso {
mode packet-based;
}
}
This was only done on one of the routers but has now resolved the slow
throughput issues. Anyone seen the same issues?
Nick
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender. Any
offers or quotation of service are subject to formal specification.
Errors and omissions excepted. Please note that any views or opinions
presented in this email are solely those of the author and do not
necessarily represent those of Lumison.
Finally, the recipient should check this email and any attachments for the
presence of viruses. Lumison accept no liability for any
damage caused by any virus transmitted by this email.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Where is RE-850 temperature sensor physically located?
I have a M10i router with RE-850(740-011202) routing engine. If I execute show chassis environment routing-engine, following information is printed: r...@m10i show chassis environment routing-engine Routing Engine 0 status: State Online Master Temperature42 degrees C / 107 degrees F r...@m10i Where is this temperature sensor located? Is this 42C temperature of the CPU of the RE0? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLSoMPLS - horrible?
On Thu, Sep 30, 2010 at 05:52:56PM +1000, Dale Shaw wrote: Hi all, I'm pondering my first production use of MPLS and I'm looking for some free advice. I'm looking at building a new 'enterprise' network - an extranet of sorts - *on top of* a NSP's L3VPN service. It's all Ethernet. I'd like to be able to build my own pseudowires and create my own L3VPNs on top of the NSP's platform and without their involvement. In effect, my CE routers (from the NSP's perspective) become PE routers to *my* customers (3rd parties, e.g. business partners and suppliers). It's called CsC - Carrier Supporting Carrier, and this technique is known for years. I suppose this means doing MPLSoMPLS, and actually depending on the upper layers in the protocol stack, it could end up looking pretty scary if you looked at what was being shifted around in the NSP's core :-) (over and above MPLS, I'm thinking about how the stack looks when further encapsulation, such as IPSec, is used.) So, noting the protocol stack size and potential MTU issues, is anyone doing this? How are you distributing labels? Right question would be 'How do you exchange labels with your NSP?'. Because if there are no such exchange your NSP will not know what to do with MPLS packet entering his network and will just drop it at ingress. Is it too horrible to even contemplate? It's hardly possible without setting CsC with your NSP. With L3VPN all you have is IP[v6] connectivity between your CE routers, so the only way to run MPLS without NSP support is to run GRE tunnels between your CE's and then run MPLS over these GRE tunnels. And, yes, it is horrible: ethernet frame passing your pseudowire will become ethernet over MPLS over GRE over IP over MPLS over ethernet with terrific overhead and lots of MTU issues :) I'd be looking at using J and/or SRX as the CE-pseudo-PE devices. Any pointers would be appreciated. I've only just embarked on this little adventure and I'm still relative new to Juniper platforms. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Policy based routing on SRX 210
Dear all,
My PBR configuration is below. I have configured everything as suggested in
juniper's documentation. But it's not working as desired. Please help me out
to sort out the issue.
ge-0/0/0 {
unit 0 {
description HO-LAN;
family inet {
address 10.139.1.1/24;
fe-0/0/5 {
unit 0 {
description SUBISU-INTERNET;
family inet {
address 10.10.10.2/29;
fe-0/0/6 {
unit 0 {
description ADSL;
family inet {
address 192.168.254.2/24;
routing-options {
interface-routes {
rib-group inet IMPORT-PHY;
}
static {
route 0.0.0.0/0 {
next-hop [ 10.10.10.1 1 192.168.254.1 ];
metric 5;
}
rib-groups {
IMPORT-PHY {
import-rib [ pbr_fe-0/0/5_static.inet.0 pbr_fe-0/0/6_adsl.inet.0
inet.0 ];
nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
rule-set TRUST-TO-WIFI-NAT {
from zone trust;
to zone WIFI-ZONE;
rule wifi-nat {
match {
source-address 10.139.1.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
zones {
security-zone trust {
address-book {
address HO-LAN 10.139.1.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
telnet;
}
protocols {
all;
}
}
interfaces {
fe-0/0/5.0 {
host-inbound-traffic {
system-services {
ping;
https;
ssh;
telnet;
ike;
security-zone WIFI-ZONE {
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
from-zone trust to-zone WIFI-ZONE {
policy TRUST-TO-WIFI {
match {
source-address HO-LAN;
destination-address any;
application any;
}
then {
permit;
}
firewall {
filter trust-adsl {
term TERM1 {
from {
source-address {
10.139.1.167/32;
}
}
then {
routing-instance pbr_fe-0/0/6_adsl;
}
}
term TERM2 {
then {
routing-instance
Re: [j-nsp] MPLSoMPLS - horrible?
Hi Alexandre, On Thu, Sep 30, 2010 at 7:17 PM, Alexandre Snarskii s...@snar.spb.ru wrote: Right question would be 'How do you exchange labels with your NSP?'. Because if there are no such exchange your NSP will not know what to do with MPLS packet entering his network and will just drop it at ingress. Is it too horrible to even contemplate? It's hardly possible without setting CsC with your NSP. Right. Yes, I hadn't appreciated that the carrier's PE would need to handle labelled packets. It seems obvious now :-) With L3VPN all you have is IP[v6] connectivity between your CE routers, so the only way to run MPLS without NSP support is to run GRE tunnels between your CE's and then run MPLS over these GRE tunnels. And, yes, it is horrible: ethernet frame passing your pseudowire will become ethernet over MPLS over GRE over IP over MPLS over ethernet with terrific overhead and lots of MTU issues :) OK, yeah. It sounds .. sub-optimal .. but now that I have some more key words / concepts to search for, I'm getting the impression it's not an uncommon configuration, especially as it seems J does not support L2TPv3. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLSoMPLS - horrible?
Hi Dale, This is a pretty key point because it will change the way you would implement it.. I'm looking at building a new 'enterprise' network - an extranet of sorts - *on top of* a NSP's L3VPN service. So they are routing IP? It's all Ethernet. Or are they are switching ethernet? If they are providing you with a switched ethernet environment, you should be able to implement MPLS over the top of it, without them needing to change anything. The confusion is that you mentioned ethernet, but also quoted L3VPN. Cheers Heath ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLSoMPLS - horrible?
Hi Heath, On Thu, Sep 30, 2010 at 9:14 PM, Heath Jones hj1...@gmail.com wrote: So they are routing IP? Or are they are switching ethernet? Sorry, I can see how it wasn't clear. All of the CE-PE access links are Ethernet, or at least have an Ethernet hand-off. It's probably not relevant. cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLSoMPLS - horrible?
Hi Dale, I've been working on a similar project for one of my customers. It can be a little ugly in my opinion as you end up with a lot of extra protocols running (potentially). Juniper does have this really neat feature called Dynamic GRE tunnels which really make enabling MPLS over GRE (over MPLS) easy to configure. It only allows for L3VPN as LDP is not running as it uses BGP for label exchange. I got this up and running really fast compared to my testing of a traditional MPLS over GRE (over MPLS) solution which in my customer's case involved: GRE, LDP, ISIS, iBGP in addition to their existing OSPF, eBGP configuration Feel free to let me know your thoughts. BTW - CsC/InterAS is not involved at all, so no coordination short of understanding your provider's max MTU and perhaps QoS mappings (you'll need to map ToS/DSCP to GRE potentially) - I have not tested this so far but Juniper has ways to copy these bits into the GRE header. Good luck On Thu, Sep 30, 2010 at 3:52 AM, Dale Shaw dale.shaw+j-...@gmail.comdale.shaw%2bj-...@gmail.com wrote: Hi all, I'm pondering my first production use of MPLS and I'm looking for some free advice. I'm looking at building a new 'enterprise' network - an extranet of sorts - *on top of* a NSP's L3VPN service. It's all Ethernet. I'd like to be able to build my own pseudowires and create my own L3VPNs on top of the NSP's platform and without their involvement. In effect, my CE routers (from the NSP's perspective) become PE routers to *my* customers (3rd parties, e.g. business partners and suppliers). I suppose this means doing MPLSoMPLS, and actually depending on the upper layers in the protocol stack, it could end up looking pretty scary if you looked at what was being shifted around in the NSP's core :-) (over and above MPLS, I'm thinking about how the stack looks when further encapsulation, such as IPSec, is used.) So, noting the protocol stack size and potential MTU issues, is anyone doing this? How are you distributing labels? Is it too horrible to even contemplate? I'd be looking at using J and/or SRX as the CE-pseudo-PE devices. Any pointers would be appreciated. I've only just embarked on this little adventure and I'm still relative new to Juniper platforms. Cheers, Dale ___ 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] MPLSoMPLS - horrible?
Ahh I'm with you. A lot of people do refer to a l2 ethernet service (vpls, pseudowires, LES etc) as L3VPN. when you said that it's all Ethernet, I thought I'd raise it :) On 30 September 2010 12:30, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi Heath, On Thu, Sep 30, 2010 at 9:14 PM, Heath Jones hj1...@gmail.com wrote: So they are routing IP? Or are they are switching ethernet? Sorry, I can see how it wasn't clear. All of the CE-PE access links are Ethernet, or at least have an Ethernet hand-off. It's probably not relevant. cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Policy based routing on SRX 210
This config is doing exactly what you configured it to do. That's how
computers work. Did you want it to do something else? If so, you might
want to tell us what you think it should be doing that it isn't.
On Thu, 30 Sep 2010, Bikash Bhattarai wrote:
Dear all,
My PBR configuration is below. I have configured everything as suggested in
juniper's documentation. But it's not working as desired. Please help me out
to sort out the issue.
ge-0/0/0 {
unit 0 {
description HO-LAN;
family inet {
address 10.139.1.1/24;
fe-0/0/5 {
unit 0 {
description SUBISU-INTERNET;
family inet {
address 10.10.10.2/29;
fe-0/0/6 {
unit 0 {
description ADSL;
family inet {
address 192.168.254.2/24;
routing-options {
interface-routes {
rib-group inet IMPORT-PHY;
}
static {
route 0.0.0.0/0 {
next-hop [ 10.10.10.1 1 192.168.254.1 ];
metric 5;
}
rib-groups {
IMPORT-PHY {
import-rib [ pbr_fe-0/0/5_static.inet.0 pbr_fe-0/0/6_adsl.inet.0
inet.0 ];
nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
rule-set TRUST-TO-WIFI-NAT {
from zone trust;
to zone WIFI-ZONE;
rule wifi-nat {
match {
source-address 10.139.1.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
zones {
security-zone trust {
address-book {
address HO-LAN 10.139.1.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
telnet;
}
protocols {
all;
}
}
interfaces {
fe-0/0/5.0 {
host-inbound-traffic {
system-services {
ping;
https;
ssh;
telnet;
ike;
security-zone WIFI-ZONE {
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
from-zone trust to-zone WIFI-ZONE {
policy TRUST-TO-WIFI {
match {
source-address HO-LAN;
destination-address any;
application any;
}
then {
permit;
}
firewall {
filter trust-adsl {
term TERM1 {
from {
source-address {
10.139.1.167/32;
}
}
then {
routing-instance pbr_fe-0/0/6_adsl;
}
}
term TERM2 {
then {
routing-instance pbr_fe-0/0/5_static;
}
}
}
}
routing-instances {
pbr_fe-0/0/5_static {
instance-type forwarding;
routing-options {
Re: [j-nsp] Policy based routing on SRX 210
I'm not exactly sure what you are trying to get this config to do, but at
the very least you need to apply the firewall rule for the PBR to the
relevant interface,
set interface x unit 0 family inet filter input trust-adsl
Joe
On Thu, Sep 30, 2010 at 5:32 AM, Bikash Bhattarai bik...@dristi.com.npwrote:
Dear all,
My PBR configuration is below. I have configured everything as suggested in
juniper's documentation. But it's not working as desired. Please help me
out
to sort out the issue.
ge-0/0/0 {
unit 0 {
description HO-LAN;
family inet {
address 10.139.1.1/24;
fe-0/0/5 {
unit 0 {
description SUBISU-INTERNET;
family inet {
address 10.10.10.2/29;
fe-0/0/6 {
unit 0 {
description ADSL;
family inet {
address 192.168.254.2/24;
routing-options {
interface-routes {
rib-group inet IMPORT-PHY;
}
static {
route 0.0.0.0/0 {
next-hop [ 10.10.10.1 1 192.168.254.1 ];
metric 5;
}
rib-groups {
IMPORT-PHY {
import-rib [ pbr_fe-0/0/5_static.inet.0 pbr_fe-0/0/6_adsl.inet.0
inet.0 ];
nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
rule-set TRUST-TO-WIFI-NAT {
from zone trust;
to zone WIFI-ZONE;
rule wifi-nat {
match {
source-address 10.139.1.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
zones {
security-zone trust {
address-book {
address HO-LAN 10.139.1.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
telnet;
}
protocols {
all;
}
}
interfaces {
fe-0/0/5.0 {
host-inbound-traffic {
system-services {
ping;
https;
ssh;
telnet;
ike;
security-zone WIFI-ZONE {
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
from-zone trust to-zone WIFI-ZONE {
policy TRUST-TO-WIFI {
match {
source-address HO-LAN;
destination-address any;
application any;
}
then {
permit;
}
firewall {
filter trust-adsl {
term TERM1 {
from {
source-address {
10.139.1.167/32;
}
}
then {
routing-instance pbr_fe-0/0/6_adsl;
}
}
term TERM2 {
Re: [j-nsp] Policy based routing on SRX 210
I want to have all the traffic default routed to 10.10.10.1 and when it comes
from source address 10.139.1.167/32 it should be routed to 192.168.254.1. I
have also applied filter to the LAN interface in inbound direction. But still
all the traffic is going through 10.10.10.1 even if it is originated from
10.139.1.167/32.
Regards,
Bikash
From: Joe Goldberg [mailto:joe.goldb...@falconstor.com]
Sent: बिहीवार, सेप्टेम्बर 30, 2010 7:55 PM
To: Bikash Bhattarai
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Policy based routing on SRX 210
I'm not exactly sure what you are trying to get this config to do, but at the
very least you need to apply the firewall rule for the PBR to the relevant
interface,
set interface x unit 0 family inet filter input trust-adsl
Joe
On Thu, Sep 30, 2010 at 5:32 AM, Bikash Bhattarai bik...@dristi.com.np wrote:
Dear all,
My PBR configuration is below. I have configured everything as suggested in
juniper's documentation. But it's not working as desired. Please help me out
to sort out the issue.
ge-0/0/0 {
unit 0 {
description HO-LAN;
family inet {
address 10.139.1.1/24;
fe-0/0/5 {
unit 0 {
description SUBISU-INTERNET;
family inet {
address 10.10.10.2/29;
fe-0/0/6 {
unit 0 {
description ADSL;
family inet {
address 192.168.254.2/24;
routing-options {
interface-routes {
rib-group inet IMPORT-PHY;
}
static {
route 0.0.0.0/0 {
next-hop [ 10.10.10.1 1 192.168.254.1 ];
metric 5;
}
rib-groups {
IMPORT-PHY {
import-rib [ pbr_fe-0/0/5_static.inet.0 pbr_fe-0/0/6_adsl.inet.0
inet.0 ];
nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
rule-set TRUST-TO-WIFI-NAT {
from zone trust;
to zone WIFI-ZONE;
rule wifi-nat {
match {
source-address 10.139.1.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
zones {
security-zone trust {
address-book {
address HO-LAN 10.139.1.0/24;
}
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
vlan.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
ge-0/0/0.0 {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
all;
}
}
}
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
https;
ping;
ssh;
telnet;
}
protocols {
all;
}
}
interfaces {
fe-0/0/5.0 {
host-inbound-traffic {
system-services {
ping;
https;
ssh;
telnet;
ike;
security-zone WIFI-ZONE {
interfaces {
fe-0/0/6.0 {
host-inbound-traffic {
system-services {
ping;
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
from-zone trust to-zone WIFI-ZONE {
policy TRUST-TO-WIFI {
match {
source-address HO-LAN;
destination-address
Re: [j-nsp] Policy based routing on SRX 210
I'm not sure that this is the only issue, but something I just spotted under pbr_fe-0/0/6_adsl: route 0.0.0.0/24 I would have thought that if it didnt match a route that instance, it would have been dropped. If that is the case, then something else is going wrong beforehand and the traffic isn't hitting that instance. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX 3k A/P and IDP
Aloha, does anyone out there have any experience deploying an SRX3k series (3400 cluster strictly A/P), with IDP services? Anyone know of any A/P IDP-specific gotchas? or recommendations on running IDP in an A/P configuration? we are looking to deploy this setup for a customer in the next month or two, and just curious to hear some real-life deployment stories (horror or otherwise!). Currently i'm looking at deploying the current JTAC recommended code of 10.1R3. We have our fair share of battle scars from last year with some of the branch boxes (9.5-9.6 timeframe) even without the hassle of UTM or IDP features. Needless to say we've learned our lesson on selling a 'branch box' even though the stated speeds/feeds seem more than sufficient (ready for the SRX1400 to come out...). i've read and heard that the 3k/5k are much more stable . . . here's to hoping! Thanks, Will ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] weird MTU size on show interface
Hi, I was checking my EX4200 trying to resolve a strange connection problem with my vendor through a Metro Ethernet. During that time I found another weird situation (it is not related to the metroEthernet connection). I setup two topology to test EX4200.ae0 ===(LACP,trunk)=== ae0.M10 On above setup, the interface link-level MTU on EX4200 side (interface ae0) shows MTU 1514. But on M10 the interface link-level MTU shows 1518. The 1518 is what I expect to have as a VLAN trunk interface should be. However, I do able to ping each other with size at 1472 (i.e. Ethernet Tagged Frame Size at 1518). Is there anyone have similar experience on your EX4200 switches? Is that simply a bug or it is designed to be that way? Thanks, -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] J6350 Jumbo frame MTU and OSPF setting
Dear all,
We had subscribed a private line circuit between 2 different data center
for Data Backup and replication. The bandwidth of the private line is
100Mbps.
According to the provider, The Circuit is Built across their
Network as 2 STS1's or High Speed DS3's which equals 100meg.
Their GE port setting as follows.
MTU Size - 9600
Auto Negotiation - OFF
Remote Client Fail - Disabled.
The private circuit is connected directly to the fiber module of our J6350
Services router at each Data Center. The Circuit is up and running but when
we perform some TCP throughput test, we only get ~3Mbps for a Single TCP
session with iPerf and the latency between two data center across the
private circuit is ~80ms.
I am trying to configure our J6350 fiber interface to MTU 9192 to get a
better TCP throughput. However, I can only able to configure the MTU size
below 1500, when I configure the MTU to 9192 and commit the changes, it
still shows MTU 1500 on the physical interface.
Do you have any experience on using Jumbo frame MTU size on the J6350? We
are also running OSPF across the private circuit, is JUNOS support OSPF
ignore-mtu like cisco?
Please advise.
Fiber module
FPC 3REV 18 750-013599 AAAH7361 FPC
PIC 0 1x GE SFP
Xcvr 0 REV 02 740-011614 PG336CS SFP-LX10
show interfaces ge-3/0/0
speed 1g;
mtu 1400;
link-mode full-duplex;
gigether-options {
no-auto-negotiation;
}
unit 0 {
family inet {
address xxx.xxx.xxx.253/30;
}
}
har...@j6350# run show interfaces ge-3/0/0
Physical interface: ge-3/0/0, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 184
Link-level type: Ethernet, MTU: 1400, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Disabled, Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Current address: b0:c6:9a:87:35:36, Hardware address: b0:c6:9a:87:35:36
Last flapped : 2010-09-27 02:32:24 UTC (4d 02:29 ago)
Input rate : 0 bps (0 pps)
Output rate: 0 bps (0 pps)
Active alarms : None
Active defects : None
show interfaces ge-3/0/0
speed 1g;
mtu 9192;
link-mode full-duplex;
gigether-options {
no-auto-negotiation;
}
unit 0 {
family inet {
address xxx.xxx.xxx.253/30;
}
}
run show interfaces ge-3/0/0
Physical interface: ge-3/0/0, Enabled, Physical link is Up
Interface index: 152, SNMP ifIndex: 184
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled,
Source filtering: Disabled, Flow control: Enabled, Auto-negotiation:
Disabled, Remote fault: Online
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
Link flags : None
CoS queues : 8 supported, 8 maximum usable queues
Current address: b0:c6:9a:87:35:36, Hardware address: b0:c6:9a:87:35:36
Last flapped : 2010-09-27 02:32:24 UTC (4d 02:35 ago)
Input rate : 0 bps (0 pps)
Output rate: 1192 bps (2 pps)
Active alarms : None
Active defects : None
Thanks
Harris
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
