Re: [j-nsp] lable unicast
On Tuesday, June 11, 2013, Oren Peled wrote: Hi all Can I get information about mpls label unicast here And how to separate networks in level 1 Regards Oren. I'm assuming the question is about BGP LU. The following guide may help. http://www.juniper.net/us/en/local/pdf/design-guides/8020013-en.pdf Regards, Addy. Oren Peled IP Network Dep. Technologies div. Partner Communications Company LTD. Office: +972-547815661 Mobile: +972-544815661 Mail: oren.pe...@orange.co.il javascript:;blocked::mailto: yaniv.michalov...@orange.co.il javascript:; This message contains information that may be confidential or privileged. If you are not the intended recipient, you may not use, copy or disclose to anyone any of the information in this message. If you have received this message and are not the intended recipient, kindly notify the sender and delete this message from your computer. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:; 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] instance-specific filters for VPLS BUM/flood filtering
Folks:
When Trio MPCs were released, original behavior pertaining to policer
behavior on VPLS instances was different from that observed on I-CHIP DPCs
(as has been uncovered in this thread). This was changed via PR/674408,
which should now be externally viewable. It changes the default Trio MPC
behavior to be more in line with I-CHIP DPC default.
https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR674408
Regards,
Addy.
On Fri, Nov 9, 2012 at 2:57 PM, Christopher E. Brown
chris.br...@acsalaska.net wrote:
Please share case #, I have same complaints in discussion with our SE
and up that chain.
Personally I think they need to add instance-specific as a keyword to
the policer to make them shared or not-shared by choice. 95% of the
time I need unshared, but can think of a few cases where shared sould be
useful.
On 11/8/12 7:06 AM, Saku Ytti wrote:
In my mind, the default is fine. It is consistent with normal behavior
and there are times when a shared policer would be desired. The lack
of
a instance specific option though, that is stupid beyond belief,
shocking surprise.
To me the biggest problem is, you cannot know if instance policers are
shared or not, as it is version dependent.
I opened JTAC case (I can unicast case# if you want to pass it to your
account team).
Query:
Case A)
# show firewall filter PROTECT-FROM_IP_OPTION
term police-ip-options {
from {
ip-options any;
}
then {
policer POLICE-IP_OPTIONS;
count police-ip-options;
}
}
term accept-all {
then {
count accept-all;
accept;
}
}
# show firewall policer POLICE-IP_OPTIONS
if-exceeding {
bandwidth-limit 3m;
burst-size-limit 320;
}
then discard;
set routing-instances RED forwarding-options family inet filter
PROTECT-FROM_IP_OPTION
set routing-instances BLUE forwarding-options family inet filter
PROTECT-FROM_IP_OPTION
Will RED and BLUE share 3Mbps, or will each get own 3Mbps?
Case B)
...amily vpls filter PROTECT-UNKNOWN_UNICAST
term unknown_unicast {
from {
traffic-type unknown-unicast;
}
then {
policer POLICE-UNKNOWN_UNICAST;
accept;
}
}
term accep {
then accept;
}
show configuration firewall policer POLICE-UNKNOWN_UNICAST
if-exceeding {
bandwidth-limit 42m;
burst-size-limit 100k;
}
then discard;
set routing-instances GREEN forwarding-options family vpls filter input
PROTECT-UNKNOWN_UNICAST
set routing-instances YELLOW forwarding-options family vpls filter input
PROTECT-UNKNOWN_UNICAST
Will GREEN, YELLOW share 42Mbps or get own 42Mbps policers?
JTAC response
Query: If you configure same FW with policer to multiple instances, what
is expected result? Should policer be shared or should it be dedicated per
instances?
JTAC: It will be dedicated per instance. In your example RED and BLUE
will consume 3MB independently.
---
But as per my own testing, I know IP-OPTIONS policer was shared in 10.4
(which
is what I want for IP options). And VPLS policer I want not-shared, as
in 11.4.
--
Christopher E. Brown chris.br...@acsalaska.net desk (907) 550-8393
cell (907) 632-8492
IP Engineer - ACS
___
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 mx lag minimum bandwidth
On Saturday, July 28, 2012, Schahzad Zafar wrote: Hi list, I am not aware of if we can configure LAG to forward traffic only if certin bandwidth (not full links as in minimum links instead line 2.5 G ) is available. I was looking at JNCIE work book and some where there was a task to configure LAG interface to forward traffic only if there 2.5 G bandwidth is available i am only aware of option to have minimum Links to keep the LAG up. Intrestingly show interface ae0 shows Minimum Links required as well as Minimum Bandwidth Capacity too which is more confusing me. Any one know about it ? Have you looked into bandwidth-based-metrics? http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-routing/routing-dynamically-adjusting-ospf-interface-metrics-based-on-bandwidth.html -- Best Regards Schahzad 0092 - 321 -9001131 Never argue with an idiot, they will just *drag you* down to *their level and beat* you with experience. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:; 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] DSCP classifier on CCC interface
Serge:
What platform/line-card are you trying this on? This is possible in JUNOS
11.4 when using Trio/MPC line-cards on the MX. See 11.4 release notes:
http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/release-notes/11.4/index.html?topic-62949.html#jd0e3519
--Addy.
On Mon, Mar 19, 2012 at 2:27 PM, Serge Vautour sergevaut...@yahoo.cawrote:
Hello,
Would anyone know if it's possible to apply a DSCP classifier on a CCC
interface? Here's what I have:
Interface:
ge-1/2/1 {
encapsulation ethernet-ccc;
unit 0;
}
Routing-Instance:
instance-type l2vpn;
interface ge-1/2/1.0;
vrf-target target:123:41;
protocols {
l2vpn {
encapsulation-type ethernet;
no-control-word;
site Site1 {
site-identifier 1;
interface ge-1/2/1.0;
}
}
}
Class-of-Service interface:
ge-1/2/1 {
unit 0 {
classifiers {
dscp dscp-classifier;
}
}
}
Class-of-service classifier:
dscp dscp-classifier {
import default;
forwarding-class expedited-forwarding {
loss-priority low code-points [ 101000 101001 101010 101011 101100
101101 101110 10 ];
}
}
Note that the L2VPN is port based. Any valid ethernet frame will go
through.
To test this I generate a ping and set the ToS field to 101. The
classifier above should drive this to the EF class but it isn't.
I'm wondering if maybe you can't use a DSCP classifier on a non-IP
interface? Anybody tried this before? I thought I'd try this mailing list
before opening a case.
Thanks,
Serge
___
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] Random BGP peer drops
Serge: Do you have ldp synchronization enabled? http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/routing-configuring-synchronization-between-ldp-and-igps.html --Addy. On Tuesday, February 14, 2012, Serge Vautour sergevaut...@yahoo.ca wrote: Hello, We have an MPLS network made up of many MX960s and MX80s. We run OSPF as our IGP - all links in area 0. BGP is used for signaling of all L2VPN VPLS. At this time we only have 1 L3VPN for mgmt. LDP is used for for transport LSPs. We have M10i as dedicated Route Reflectors. Most MX are on 10.4S5. M10i still on 10.0R3. Each PE peers with 2 RRs and has 2 diverse uplinks for redundancy. If 1 link fails, there's always another path. It's been rare but we've seen random iBGP peer drops. The first was several months ago. We've now seen 2 in the last week. 2 of the 3 were related to link failures. The primary path from the PE to the RR failed. BGP timed out after a bit. Here's an example: Feb 8 14:05:32 OURBOX-re0 mib2d[2279]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 129, ifAdminStatus up(1), ifOperStatus down(2), ifName xe-7/0/0 Feb 8 14:05:32 OURBOX-re0 mib2d[2279]: %DAEMON-4-SNMP_TRAP_LINK_DOWN: ifIndex 120, ifAdminStatus up(1), ifOperStatus down(2), ifName xe-0/0/0 Feb 8 14:06:33 OURBOX-re0 rpd[1413]: %DAEMON-4: bgp_hold_timeout:3660: NOTIFICATION sent to 10.1.1.2 (Internal AS 123): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 10.1.1.2 (Internal AS 123), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 1056225956 snd_nxt: 1056225956 snd_wnd: 16384 rcv_nxt: 3883304584 rcv_adv: 3883320968, hold timer 0 BGP holdtime is 90sec. This is more than enough time for OSPF to find the other path and converge. The BGP peer came back up before the link so things did eventually converge. The last BGP peer drop happened without any links failure. Out of the blue, BGP just went down. The logs on the PE: Feb 13 20:40:48 OUR-PE1 rpd[1159]: %DAEMON-4: bgp_hold_timeout:3660: NOTIFICATION sent to 10.1.1.2 (Internal AS 123): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 10.1.1.2 (Internal AS 123), socket buffer sndcc: 0 rcvcc: 0 TCP state: 4, snd_una: 2149021074 snd_nxt: 2149021074 snd_wnd: 16384 rcv_nxt: 2049196833 rcv_adv: 2049213217, hold timer 0 Feb 13 20:40:48 OUR-PE1 rpd[1159]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.2 (Internal AS 123) changed state from Established to Idle (event HoldTime) Feb 13 20:41:21 OUR-PE1 rpd[1159]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.2 (Internal AS 123) changed state from OpenConfirm to Established (event RecvKeepAlive) The RR side shows the same: Feb 13 20:40:49 OUR-RR1-re0 rpd[1187]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.61 (Internal AS 123) changed state from Established to Idle (event RecvNotify) Feb 13 20:40:49 OUR-RR1-re0 rpd[1187]: %DAEMON-4: bgp_read_v4_message:8927: NOTIFICATION received from 10.1.1.61 (Internal AS 123): code 4 (Hold Timer Expired Error), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4, snd_una: 2049196833 snd_nxt: 2049196871 snd_wnd: 16384 rcv_nxt: 2149021095 rcv_adv: 2149037458, hold timer 1:03.112744 Feb 13 20:41:21 OUR-RR1-re0 rpd[1187]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 10.1.1.61 (Internal AS 123) changed state from EstabSync to Established (event RsyncAck) Feb 13 20:41:30 OUR-RR1-re0 rpd[1187]: %DAEMON-3: bgp_send: sending 30 bytes to 10.1.1.61 (Internal AS 123) blocked (no spooling requested): Resource temporarily unavailable You can see the peer wasn't down long and re-established on it's own. The logs on the RR make it look like it received a msg from the PE that it was dropping the BGP session. The last error on the RR seems odd as well. Has anyone seen something like this before? We do have a case open regarding a large number of LSA retransmits. TAC is saying this is a bug related to NSR but shouldn't cause any negative impacts. I'm not sure if this is related. I'm considering opening a case for this as well but I'm not very confident I'll get far. Any help would be appreciated. Thanks, Serge ___ 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] tag-protocol-id matching in vlan-tags
On Wednesday, July 27, 2011, David Ball davidtb...@gmail.com wrote:
MX running 10.0 (DPCE-R-20GE-2XGE for int in question)
Should I expect that a logical unit configured with 'vlan-tags outer
0x88A8.100' would also permit frames using TPID 8100 and VLAN ID 100 ?
I kinda expected not (since it doesn't 'match'), yet if I change my
test set to send normal 0x8100.100 frames, they're still accepted by
the interface (config below) and stuffed into the associated VPN.
[edit interfaces ge-1/1/0]
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
gig-ether-options {
no-auto-negotiation;
ethernet-switch-profile {
tag-protocol-id 0x88A8;
}
}
unit 100 {
encapsulation vlan-ccc;
vlan-tags outer 0x88A8.100;
input-vlan-map pop;
output-vlan-map push;
}
Are my expectations that specifying the TPID in the vlan-tags
statement would ONLY match frames with that TPID wrong? Practice
would indicate that I'm wrong, but I guess I'm wondering if this is
expected behaviour.
David: I don't believe your expectation is incorrect. Could you please post
the exact JUNOS release (including minor version) and the output of show
interface ge-1/1/0?
TIA,
David
___
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] Juniper MX80 IRB
On Wednesday, July 28, 2010, Mark Tinka mti...@globaltransit.net wrote: On Tuesday, July 27, 2010 10:31:18 pm Chuck Anderson wrote: Finally, JTAC/ATAC can't even figure out the above!!! I have a case open and they *still* haven't come to the solution because they haven't realized that Today Trio only supports the old style config and what that really means. The disconnect between JTAC and the core of the development team has always been there, in my opinion. It took a whole year of back-and-forth with JTAC on a case that, when it was finally escalated to a senior engineer within Juniper, was resolved in 30 minutes. No, seriously... It's easy to assume that just because JTAC work for Juniper, they're familiar with JUNOS and the Juniper hardware. But this, as I've seen time time again, really isn't the case. Mark. Although it doesn't answer the specific question raised via this thread, the following link dose offer some general guidance on Trio chipset features. Should mostly be applicable to the MX80 as well. http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-features.html Regards, Addy. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX80 IRB
On Tuesday, July 27, 2010, Tim Vollebregt t...@interworx.nl wrote:
On Jul 26, 2010, at 11:25 PM, Chuck Anderson wrote:
On Mon, Jul 26, 2010 at 06:52:14PM +0200, Tim Vollebregt wrote:
We have just received a Juniper MX80 and are building the configuration.
The machine is running Junos 10.2 R1.8
The issue we are experiencing is that the IRB interface seems to be
not working, although it seems to be configured correctly.
Configuration:
Try configuring it the old 9.2 way and let us know if it works:
ge-1/0/0 {
unit 200 {
encapsulation vlan-bridge;
vlan-id 200;
irb {
unit 200 {
family inet {
address x.x.x.x/27;
address x.x.x.x/29;
bridge-domains {
VLAN200 {
domain-type bridge;
vlan-id 200;
interface ge-1/0/0.200;
routing-interface irb.200;
Thanks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Hi Chuck,
I'm getting errors when changing to this configuration. It is only possible
to use encapsulation vlan-bridge on unit 0. And when I change it to unit 0:
messageVLAN Encapsulation: Not allowed on untagged interfaces/message
/xnm:error
source-daemondcd/source-daemon
edit-path[edit interfaces ge-1/0/0]/edit-path
statementunit 0/statement
message invalid encapsulation/message
/xnm:error
error: configuration check-out failed
This issue seems to be really strange as we have it working the 10.x way on
another router. When I configure Ge-1/0/0 as a routed interface it works fine.
Regards,
Tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tim:
Could you please paste in your entire ge-1/0/0 interface and
bridge-domain VLAN200 configuration at the time you do get the commit
error?
Thanks,
Addy.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
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
--
Sent from my mobile device
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospfv3 - JUNOS sends zero mtu in dbd - stuck in ExStart
I ran into this a few years ago. Even without going into the JUNOS implementation (they will probably tell you that this is works-as-designed, and that this was a conscious decision), this should not cause an issue in the OSPF session establishment. Per RFC 2328 section 10.6, If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected. Otherwise, if the neighbor state is: ... ExStart If the received packet matches one of the following cases, then the neighbor state machine should be executed with the event NegotiationDone (causing the state to transition to Exchange)... Theoretically, MTU=0 would imply that the DBD packets should always be received/processed, and thereby *not* cause any interop concerns. --Addy. On Thu, Jun 17, 2010 at 6:29 PM, Volker D. Pallas juniper-...@sqmail.de wrote: Hi again, yeah, this makes total sense! At first I thought this is a JUNOS-problem, as Cisco does send the right mtu along. I closed the bug report on the quagga bugzilla for now (with closed/invalid) and will talk to JTAC. I'll get back to you and the list as soon as I have some confirmation and/or fix. I'm not so sure anymore. A fellow reader has challenged my interpretation of the RFC wording, that it might mean OSPF virtual links, not tunnel (and similar virtual, non-physical) interfaces. Upon re-reading with that interpretation in mind, I tend to agree. Thinking further about it, mtu=0 for OSPF virtual links makes sense, as only OSPF PDUs are being tunnelled, no actual traffic. So there is no sensible MTU to report in the DBD packets. On real tunneling interfaces though, everything (OSPF PDUs and actual traffic) gets tunnelled, and the tunnel has a real MTU associated. So in fact, I think my interpretation was wrong and JUNOS is actually misbehaving by advertising MTU=0. It should report the tunnel interface L3 MTU. Sorry for the noise. I suggest raising a case with JTAC and closing off the Quagga bug filing. No, not at all! Thanks a lot for your input! I did not even read the appropriate RFC before you posted, which I should do next time. BTW, I noticed your Linux tunnel interface being named gre-nc - I guess the gre part is a leftover misnomer from trying GRE encaps? exactly ;-) It's actually sit now on the linux side Best regards from Porz to Porz, Daniel and best wishes back to you! Volker ___ 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] Load Balance in VRF by Junos
Gabriel:
What kind of flows and variations exist in your traffic? Regardless
of the loadbalance configuration, without enough variance, traffic
distribution will be polarized.
Regards,
Addy.
On 4/5/10, Gabriel Farias gabrielfaria...@gmail.com wrote:
Hi,
I configured the router the suggested parameters in URL:
{master}[edit]
RT110# show policy-options policy-statement load-balance
term 1 {
then {
load-balance per-packet;
}
}
RT110# show routing-options
forwarding-table {
export load-balance;
}
RT110# show forwarding-options
load-balance {
indexed-next-hop;
}
hash-key {
family inet {
layer-3;
layer-4;
}
}
The continuing imbalance in the physical interfaces:
{master}[edit]
RT110# run show interfaces ge-3/0/3 | match rate
Input rate: 520010728 bps (98183 pps)
Output rate: 585910320 bps (176371 pps)
{master}[edit]
RT110# run show interfaces ge-3/0/0 | match rate
Input rate: 621317752 bps (107767 pps)
Output rate: 107517264 bps (17319 pps)
The configuration is correct? Or we would have to configure within the
routing-instances dados.
Thanks
Gabriel Farias
2010/4/5 Serge Vautour sergevaut...@yahoo.ca
Hello,
eBGP shouldn't come into play here. Your physical interfaces are bundled
as
1 logical interface (ae0). Load balancing over L3 LAG interfaces works the
same as ECMP links. You have to configure this:
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-policy/policy-configuring-per-packet-load-balancing.html
Stefan has suggested this below. Have you tried it?. Can you post your
relevant config?
What I find weird is you do have some egress traffic on both physical
links. It's just not even close to being balanced. Without any load
balancing configs, I would expect to see 0 bps on one link. Do you have
enough flows? If most of your traffic is generated from just a few flows,
you may not be able to get much better.
Serge
- Original Message
From: Gabriel Farias gabrielfaria...@gmail.com
To: mail-list mohan.nand...@gmail.com
Cc: juniper-nsp@puck.nether.net; uniper-nsp-boun...@puck.nether.net
Sent: Mon, April 5, 2010 1:20:33 PM
Subject: Re: [j-nsp] Load Balance in VRF by Junos
Stefan,
This configuration has no effect, because the connection (PE x CE) uses
EBGP
routing within the VRF dados.
What I need is to balance the outbound traffic of physical interfaces of
RT110, you have any other suggestions?
Thanks
Gabriel Farias
2010/4/5 mail-list mohan.nand...@gmail.com
try this and see if it makes any difference...
set forwarding-options hash-key family mpls label-1
set forwarding-options hash-key family mpls payload ip
or
set forwarding-options hash-key family mpls label-1
set forwarding-options hash-key family mpls label-2
set forwarding-options hash-key family mpls payload ip
On Mon, Apr 5, 2010 at 8:35 AM, Gabriel Farias
gabrielfaria...@gmail.comwrote:
Stefan,
Any suggestions to correct this imbalance?
Thanks,
Gabriel Farias
2010/4/1 Gabriel Farias gabrielfaria...@gmail.com
Sorry for my bad translation, follows the configuration:
*Interfaces*:
show configuration interfaces ge-3/0/0
description *BA* G2/47 - SW001;
gigether-options {
802.3ad ae0;
}
show configuration interfaces ge-3/0/3
description *BA* G1/47 - SW001;
gigether-options {
802.3ad ae0;
}
show configuration interfaces ae0
description *BA* Po150 - SW001;
mtu 9192;
unit 0 {
family inet {
address 10.251.40.53/30;
}
}
*VRF instances*:
show configuration routing-instances dados
instance-type vrf;
interface ae0.0;
...
protocols {
bgp {
group PEER-SW001 {
type external;
hold-time 30;
peer-as 65100;
as-override;
neighbor 10.251.40.54;
}
}
What I need is to balance the outbound traffic of physical
interfaces,
see
that is constant unbalance
{master}
RT110 show interfaces ge-3/0/0 | match rate
Input rate : 271677184 bps (69055 pps)
Output rate: 37802544 bps (10429 pps)
{master}
RT110 show interfaces ge-3/0/3 | match rate
Input rate : 293302512 bps (61095 pps)
Output rate: 628471504 bps (134276 pps)
{master}
RT110 show interfaces ge-3/0/0 | match rate
Input rate : 298597864 bps (70456 pps)
Output rate: 34856992 bps (8756 pps)
{master}
RT110 show interfaces ge-3/0/3 | match rate
Input rate : 288075200 bps (57232 pps)
Output rate: 657782056 bps (129224 pps)
2010/3/31 Stefan Fouant sfou...@shortestpathfirst.net
I'm sorry, your request is getting lost in translation. Why don't
you
just
show us your configs and do a 'show
Re: [j-nsp] Verify loss priority for a forwarding class
Just realized that you're using an M7i - this is not supported. The other thing I can think of would be to configure a tos/dscp rewrite rule on egress for that specific forwarding-class and loss-priority high, and confirm the tos/dscp values on the tester. --Addy. On 3/13/10, meryem Z merye...@hotmail.com wrote: Hello , There is no loss-priority criteria to match on it. Possible completions are below: Thanks. # set firewall filter test_plp term 1 from ? Possible completions: address Match IP source or destination address + ah-spi Match IPSec AH SPI value + ah-spi-exceptDo not match IPSec AH SPI value + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups destination-address Match IP destination address + destination-classMatch destination class + destination-class-except Do not match destination class + destination-port Match TCP/UDP destination port + destination-port-except Do not match TCP/UDP destination port destination-prefix-list Match IP destination prefixes in named list + dscp Match Differentiated Services (DiffServ) code point + dscp-except Do not match Differentiated Services (DiffServ) code point + esp-spi Match IPSec ESP SPI value + esp-spi-except Do not match IPSec ESP SPI value first-fragment Match if packet is the first fragment + forwarding-class Match forwarding class + forwarding-class-except Do not match forwarding class fragment-flags Match fragment flags (in symbolic or hex formats) + fragment-offset Match fragment offset + fragment-offset-except Do not match fragment offset + icmp-codeMatch ICMP message code + icmp-code-except Do not match ICMP message code + icmp-typeMatch ICMP message type + icmp-type-except Do not match ICMP message type interfaceMatch interface name + interface-group Match interface group + interface-group-except Do not match interface group interface-setMatch interface in set + ip-options Match IP options + ip-options-exceptDo not match IP options is-fragment Match if packet is a fragment + packet-lengthMatch packet length + packet-length-except Do not match packet length + port Match TCP/UDP source or destination port + port-except Do not match TCP/UDP source or destination port + precedence Match IP precedence value + precedence-exceptDo not match IP precedence value prefix-list Match IP source or destination prefixes in named list + protocol Match IP protocol type + protocol-except Do not match IP protocol type service-filter-hit Match if service-filter-hit is set source-address Match IP source address + source-class Match source class + source-class-except Do not match source class + source-port Match TCP/UDP source port + source-port-except Do not match TCP/UDP source port source-prefix-list Match IP source prefixes in named list tcp-established Match packet of an established TCP connection tcp-flagsMatch TCP flags (in symbolic or hex formats) tcp-initial Match initial packet of a TCP connection [edit] mer...@liscr2# set firewall filter test_plp term 1 from Date: Thu, 11 Mar 2010 07:14:31 -0500 Subject: Re: [j-nsp] Verify loss priority for a forwarding class From: addy.mat...@gmail.com To: merye...@hotmail.com; david@orange-ftgroup.com; juniper-nsp@puck.nether.net Meryem: Maybe try a firewall filter with a counter on the egress interface? Something like: from forwarding-class forwarding-class_name from loss-priority high then count fc-blah_lp-high then accept --Addy. On 3/11/10, meryem Z merye...@hotmail.com wrote: Hello David , Thanks for your response, but this command is supported M320 routers and T-series routing platforms only.. Is there any equivalent for M7i routers ? Thank you. From: david@orange-ftgroup.com To: merye...@hotmail.com CC: juniper-nsp@puck.nether.net Date: Wed, 10 Mar 2010 14:12:10 +0100 Subject: RE: [j-nsp] Verify loss priority for a forwarding class Hi, You can view drops at the fabric level via the command : show class-of-service fabric statistics David David Roy Orange France - RBCI IP Technical Assistance Center Tel. +33(0)299876472 Mob. +33(0)685522213 Email. david@orange-ftgroup.com -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de meryem Z Envoyé : mercredi 10 mars 2010 13:17 Cc : juniper-nsp@puck.nether.net Objet : [j-nsp] Verify loss priority for a forwarding class hello Community, I configured a forwarding class with high priority
Re: [j-nsp] Verify loss priority for a forwarding class
Meryem: Maybe try a firewall filter with a counter on the egress interface? Something like: from forwarding-class forwarding-class_name from loss-priority high then count fc-blah_lp-high then accept --Addy. On 3/11/10, meryem Z merye...@hotmail.com wrote: Hello David , Thanks for your response, but this command is supported M320 routers and T-series routing platforms only.. Is there any equivalent for M7i routers ? Thank you. From: david@orange-ftgroup.com To: merye...@hotmail.com CC: juniper-nsp@puck.nether.net Date: Wed, 10 Mar 2010 14:12:10 +0100 Subject: RE: [j-nsp] Verify loss priority for a forwarding class Hi, You can view drops at the fabric level via the command : show class-of-service fabric statistics David David Roy Orange France - RBCI IP Technical Assistance Center Tel. +33(0)299876472 Mob. +33(0)685522213 Email. david@orange-ftgroup.com -Message d'origine- De : juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] De la part de meryem Z Envoyé : mercredi 10 mars 2010 13:17 Cc : juniper-nsp@puck.nether.net Objet : [j-nsp] Verify loss priority for a forwarding class hello Community, I configured a forwarding class with high priority loss. Now I need to verify that the traffic sent under this forwarding class ( using a traffic generator) has a high priority loss. The show interface queue doesn't show this information. is there any other way to do it ? Thank you. _ Votre messagerie et bien plus où que vous soyez. Passez à Windows Live Hotmail, c'est gratuit ! https://signup.live.com/signup.aspx?id=60969 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. _ Hotmail : une messagerie performante et gratuite avec une sécurité signée Microsoft https://signup.live.com/signup.aspx?id=60969 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Sent from my mobile device ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
