[j-nsp] PYEZ module hangs

[serge vautour]

Hello,

I'm having problems with the import of PYEZ module hanging. My python
script:

from jnpr.junos import Device
def main():
 blah = ""

if __name__ == "__main__":
main()

That's as simple as possible. When I remove the "from jnpr.junos" line, the
problem described below goes away.

When I run this using a unix for loop I get:

[root@]# for i in {1..100}; do echo $i;time python test.py ; done
1

real0m0.725s
user0m0.635s
sys 0m0.092s
2

real0m0.647s
user0m0.567s
sys 0m0.082s
3

real0m0.654s
user0m0.573s
sys 0m0.084s

etc...

Eventually, and this appears completely random, it will hang:

35

real0m0.650s
user0m0.572s
sys 0m0.079s
36
^\Quit

real0m27.527s
user0m0.360s
sys 0m0.059s
37
^\Quit

real0m11.761s
user0m0.350s
sys 0m0.067s
38
^\Quit

real0m51.663s
user0m0.357s
sys 0m0.062s

The ^\Quit is me killing that instance of the python script with ctrl-\. If
I wait long enough it unblocked by itself:

39

real2m55.709s   <--- It eventually unblocked on it's own
user0m0.588s
sys 0m0.079s
40

real0m0.647s
user0m0.573s
sys 0m0.076s
41

real0m0.647s
user0m0.575s
sys 0m0.074s
42

How long it takes once hung is random. How often it hangs is random.
Sometimes I can run it over a 1000 times without an issue.

I am on the latest version of python and of the module (I think):
[root@xx# python
Python 2.7.5 (default, Feb 20 2018, 09:19:12)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-28)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from jnpr.junos import version
>>> print version.VERSION
2.2.0

Just today I ran the PIP command to update PYEZ and all dependencies. The
problem is still present.

This is running on a VM with lots of resources (32G RAM, 8CPU). top shows
less than 1G RAM in use and nearly no CPU usage even with it hangs. I have
tried running the same code on a different VM (on a different physical
chassis) with the same version of python and PYEZ and cannot reproduce.

Any suggestions on how to troubleshoot this? Is it possible it's the
underlying VM Hardware or virtualization software?

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

Re: [j-nsp] [c-nsp] show ospf lsdb - topology drawing

[serge vautour]

Went down this road before and ended up developing something in house. One
key thing we wanted was a way to display the nodes on a map based on GPS
coordinates. Has anyone ever seen a tool that does this? Obviously some
input file with "node to GPS coordinate" is required.

-Serge

On Thu, Oct 25, 2018 at 11:07 AM  wrote:

> > Robert Raszuk
> > Sent: Thursday, October 25, 2018 2:42 PM
> >
> > Hi,
> >
> > Would anyone be able to recommend some open or closed src tool which
> > can draw nice topology of the OSPFv2 single area0 based on the show ospf
> > lsdb output capture ?
> >
> > I saw https://blog.webernetz.net/ospf-visualizer/ but looking for more
> tools
> > like this proven in battle field especially those compatible as is with
> junos
> > output.
> >
> Hi Robert,
>
> Literally plug and play:
> https://github.com/CiscoDevNet/Opendaylight-BGP-Pathman-apps
> -just point your bgp-ls at the thing and you're done
>
> adam
>
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
>
>
> ___
> 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] 6PE static route

[serge vautour]

Hello,

Does anyone know if it's possible to create a 6PE static default route? It
tried creating one like this:

set routing-options rib inet6.0 static route ::/0 next-hop :::1.2.3.4
set routing-options rib inet6.0 static route ::/0 resolve

I have an ISIS-SR label for 1.2.3.4 in inet3.0. When I look at ::/0 it
shows a single label push with the same label as 1.2.3.4. However, there is
no BGP 6PE label 2 service label. Is there a way to tell the box to add
this?

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

Re: [j-nsp] PyEZ - variable into rpc.get request

[serge vautour]

Hello,

I've been coding a lot lately in python using PEYZ. I love it! I've found
using tables/views to be by far the easiest way to retrieve config data and
show commands. There's lots of info in the developer guide:

https://www.juniper.net/documentation/en_US/junos-pyez/information-products/pathway-pages/junos-pyez-developer-guide.html

Here's how to accomplish your command:

---

import yaml
from jnpr.junos import Device
from jnpr.junos.factory.factory_loader import FactoryLoader

DeviceIP = "1.2.3.4"
Username = "user"
Password = "pass"

dev = Device(host=DeviceIP, user=Username, password=Password,
normalize=True).open()

## YAML for the interface list
RouteYAML = """
---
RouteTable:
  rpc: get-route-information
  item: route-table/rt/rt-entry
  args:
table: 'inet.0'
destination: '10.1.2.4'
  args_key:
table
destination
  view: RouteView
RouteView :
  fields:
protocolName: protocol-name
activeTag: active-tag
preference: preference
"""
globals().update(FactoryLoader().load(yaml.load(RouteYAML)))
RouteTableList = RouteTable(dev)
RouteTableList.get()

for item in RouteTableList:
   print "protocolName: " + item.protocolName
   print "activeTag: " + item.activeTag
   print "preference:" + item.preference
---

This route at the CLI:

show route 10.1.2.4 table inet.0

inet.0: 836 destinations, 855 routes (831 active, 0 holddown, 5 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.2.4/31*[OSPF/10] 5d 09:57:18, metric 3400
> to 10.12.100.209 via ae64.100
  to 10.12.100.254 via ae62.0

The XML:

show route 10.1.2.4 table inet.0 | display xml
http://xml.juniper.net/junos/17.4R2/junos;>
http://xml.juniper.net/junos/17.4R2/junos-routing;>

inet.0
836
855
831
0
5

10.1.2.4/31

*


OSPF
10
5d 09:57:37
3400


10.12.100.209
ae64.100


10.12.100.254
ae62.0






{master}



In the PEYZ YAML definition I pulled back a few fields for fun:

[root@blah]# python test2.py
protocolName: OSPF
activeTag: *
preference:10

I hope this helps.
Serge

On Mon, Sep 3, 2018 at 9:40 PM Stacy W. Smith  wrote:

> Remove the quotes around r2check.
>
> i.e. the line should be:
> r2response = dev.rpc.get_route_information(table='inet.0',
> destination=r2check)
>
> --Stacy
>
> > On Sep 3, 2018, at 6:33 PM, Jason Taranto 
> wrote:
> >
> > Hi All,
> >
> > After a while of my head colliding with the wall beside me, would anyone
> know how to get a variable into an rpc command via pyez.
> >
> > My latest attempt is below.
> >
> >  r2check = raw_input("Route to check e.g XXX.XXX.XXX.XXX : ")
> >  print ("Checking if route is in the table..")
> >  time.sleep(2)
> >  r2response = dev.rpc.get_route_information(table='inet.0',
> destination='r2check')
> >  time.sleep(2)
> >
> print("")
> >  print("
> ")
> >  print("  Response from router below...
>")
> >  print (etree.tostring(r2response))
> >
> >
> > The error message I get is:
> > jnpr.junos.exception.RpcError: RpcError(severity: error, bad_element:
> r2check, message: could not resolve name: r2check)
> >
> >
> >
> > Thanks in advance,
> > Jason
> >
> >
> >
> > ___
> > 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] Anyone uses Adaptive Load Balancing?

[serge vautour]

Hello,

We have been using it for a while. Works great. We have a few small links
in a LAG bundle with a small number of fat flows over them. Without
adaptive LAG the flows would sometimes hash on the same link. With adaptive
LAG they are always split.

I agree that there probably aren't many use cases for this. We ran into one
and this solution worked.

Serge


On Fri, Nov 17, 2017 at 6:36 PM, Alex K.  wrote:

> Hello everyone,
>
> A customer of mine, is looking forward for a technology able to load
> balance a traffic across a LAG.
>
> The LAG in question comprised of Ethernet link and can grow from a few
> links (4) to say, 20 - as required bandwidth grows. The gear is MX boxes.
>
> Since I'm familiar with adaptive load balancing but never used it myself,
> I'll glad if someone here can share his/her experience using it? Can it
> deliver pretty good load balancing across a LAG between routers? Is it
> stable? Is there any caveats one should avoid? Anything else we should
> consider, before deploying this thing into production? Feel free to share
> (off list/on list) your experience and everything else you think relevant.
>
> Thank you.
> ___
> 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] Match multiple bgp communities in a policy with AND condition

[serge vautour]

IMHO whether you add a community to a policy term match statement or add a
community to a community members list, you still have to add the community
somewhere. I don't see how you get from 2x10 to 100 Maybe I don't
understand the ask.

The only way I know how to get the AND logic to work in a single policy
term is to call another policy. This isn't tested but something like this:

[edit policy-options]
+   policy-statement communityb {
+   term term1 {
+   from community b;
+   then accept;
+   }
+   }
+   policy-statement xy {
+   term term1 {
+   from {
+   community a;
+   policy communityb;
+   }
+   then accept;
+   }
+   }
[edit policy-options]
+   community a members 123:1;
+   community b members 123:2;


I hope this helps.
Serge


On Thu, Apr 6, 2017 at 12:10 PM, "Rolf Hanßen"  wrote:

> Hello Serge,
>
> this works, but that is exactly the config I would like to avoid.
> In case of 2 communities this adds a third one, but in case of 2x 10
> communities that can be combined this adds 100 additional communities.
>
> kind regards
> Rolf
>
> > Hello,
> >
> > Have you tried this?
> >
> > set policy-options community MATCH2 members [ 123:1 123:2 ]
> >
> > I believe this will result in a logical AND.
> >
> > Serge
> >
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Match multiple bgp communities in a policy with AND condition

[serge vautour]

Hello,

Have you tried this?

set policy-options community MATCH2 members [ 123:1 123:2 ]

I believe this will result in a logical AND.

Serge

On Thu, Apr 6, 2017 at 8:47 AM, "Rolf Hanßen"  wrote:

> Hello,
>
> please show me an example, maybe I understood wrong.
> If I just create multiple policies and add them to the import/export
> statement, they are processed indiviually one after another.
> This would result in the same OR-behaviour.
>
> If this match was the whole policy I could combine 2 terms that do an
> invert-match and reject them (and accept in a 3rd term) but this sounds
> even worse than a new community to me. ;)
>
> kind regards
> Rolf
>
> > Hello. You need to Creat 2 policy and make AND in export import
> protokół
> > statement.
> > W dniu czw., 6.04.2017 o 13:04 "Rolf Hanßen" 
> > napisał(a):
> >
> >> Hello,
> >>
> >> I wanted to match 2 named communities in a policy and I am interested
> >> how
> >> you solve such things.
> >>
> >> policy-options {
> >> policy-statement xy {
> >> from {
> >> community [a b];
> >> }
> >> }
> >> community a members 123:1;
> >> community b members 123:2;
> >> }
> >>
> >> This matches in case one of the communities is set (typical Juniper OR
> >> condition).
> >>
> >> Is there a way to match "one" AND "two"?
> >> I would like to avoid creating a third community with both members set
> >> because in case of many combinations this does not scale well.
> >>
> >> Is there maybe even a way to combine both like "a and (b or c)"?
> >>
> >> Kind regards
> >> Rolf
> >>
> >>
> >> ___
> >> 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] Juniper vmx not able to find op and event script files

[serge vautour]

What are the file permissions? ls -laF in the /var/db/scripts/op/ folder.

Serge

On Thu, May 19, 2016 at 6:37 PM, Martin T  wrote:

> Hi,
>
> thanks for reply! Actually I tried that already, but SLAX script file
> was still not found:
>
> root@vMX-A> op ?
> Possible completions:
>   

Re: [j-nsp] Suppressing SNMP Trap to just one packet

[serge vautour]

Neat option. I have 15.1F5 running in the lab and don't see it as a regular
or hidden knob. The Juniper PR database doesn't list a "Resolved In"
version. Looking forward to seeing this one available.

Serge

On Fri, Apr 8, 2016 at 3:44 PM, Jeff Haas  wrote:

> I was clearing through old inbox stuff and noted this one.  Conveniently
> there's at least progress here to report:
>
>
> > On Sep 9, 2015, at 9:40 AM, Alireza Soltanian 
> wrote:
> > We are implementing SNMP Trap on Juniper routers. The case is when an
> event
> > occurred, device sends trap for it several times(every one/two minute).
> Our
> > trap receiver is connected to a mailing system which generate email upon
> > receiving the trap. This action causes sending a lot of email for just
> one
> > event.
> > [...]
>
> > Is there one here who can suggest any soultion for sending just one trap
> > after an event. Specially when a BGP neighbor is down.
> > We are using variations of M Series router and JunOS versions from
> version
> > 9 to 12
>
> PR: 1056230
> Description: Adds a configurable snmp-option to BGP that suppresses the
> sending of backward state trap notifications except for transitions
> from the Established state.  This cuts down on the noise from
> too many uninteresting trap notifications.
>
> set protocols bgp snmp-options backward-traps-only-from-established
>
> --
>
> This is in at least 15.1+.  No help for older version at the moment, sorry.
>
> -- Jeff
>
>
> >
> > Thank you
> > Alireza
> > ___
> > 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] VMX to VMX traffic on ESXi

[serge vautour]

No I didn't clone the VMs. I did 2 fresh installs from the same juniper
image. You can see in my outputs that the MACs are different. Everything is
working now that I've applied the license. -Serge

On Mon, Mar 21, 2016 at 5:41 PM, Eduardo Schoedler <lis...@esds.com.br>
wrote:

> Did you cloned VM? Did you change the mac-address?
>
> --
> Eduardo Schoedler
>
> 2016-03-21 16:32 GMT-03:00 serge vautour <sergervaut...@gmail.com>:
> > Hello,
> >
> > Thanks to everyone who replied with suggestions.
> >
> > I did not have any licenses installed. Oddly enough VMX2 was showing:
> >
> > user@LabVMX2> show pfe statistics traffic bandwidth
> > Configured Bandwidth : 100 bps
> > Bandwidth: 0 bps
> > Average Bandwidth: 339 bps
> >
> > This explains why VMX1 could receive traffic from VMX2. VMX1 had:
> >
> > user@LabVMX1> show pfe statistics traffic bandwidth
> > Configured Bandwidth : 0 bps
> > Bandwidth: 0 bps
> > Average Bandwidth: 0 bps
> >
> > This is very strangle considering I created both VMX from the same
> install
> > file and they have near identical configs!?!
> >
> > Anyway I downloaded a 60 trial license from the Juniper web site and
> > installed on both. Everything is now working as expected.
> >
> > Thanks,
> > Serge
> >
> >
> > On Sun, Mar 20, 2016 at 8:13 AM, Raphael Mazelier <r...@futomaki.net>
> wrote:
> >
> >> I have got some strange problem with vmx on vmware.
> >> First double check if all our vswitch are in promiscuous mode.
> >> Check also if you use vxnet or e1000 type of interface, I've got erratic
> >> problems with vxnet, and gave up with it.
> >> Check the mac address mapping, and finaly check if you have proper
> license
> >> installed ;) (I've spend one hour to find why one of my test vmx does
> not
> >> anymore, before I found that the license have expired...)
> >>
> >> --
> >> Raphael Mazelier
> >>
> >> Le 18/03/2016 21:49, serge vautour a écrit :
> >>
> >>> Hello,
> >>>
> >>> I haven't had any replies in the Juniper VMX forum so I thought I'd try
> >>> here:
> >>>
> >>> I have setup 2 VMX (each with a VCP & VPFE) on one ESXi host using
> Junos
> >>> VMX 15.1F4. Each VMX seems to be working fine on it's own. I can
> remotely
> >>> access the fxp0 interface.
> >>>
> >>> I created a dedicated vswitch with promiscuous mode on for the GE
> >>> interface. I used this vswitch for the 3rd NIC on each VPFE. I did not
> >>> attach any physical NICs to the vswitch as I only want to use it for
> >>> VMX-VMX traffic. Each VMX sees all 8 GE with ge-0/0/0 being up. I
> >>> configure:
> >>>
> >>> user@LabVMX1> show configuration interfaces ge-0/0/0
> >>> description "Link to VMX2 ge-0/0/0";
> >>> unit 0 {
> >>> family inet {
> >>> address 10.5.5.0/31;
> >>> }
> >>> }
> >>>
> >>> user@LabVMX2> show configuration interfaces ge-0/0/0
> >>> description "Link to VMX1 ge-0/0/0";
> >>> unit 0 {
> >>> family inet {
> >>> address 10.5.5.1/31;
> >>> }
> >>> }
> >>>
> >>> I also added OSPF to each interface. VMX1 seems to work fine. It shows
> >>> in/out traffic. VMX2 only shows outbound traffic.
> >>>
> >>> Using "monitor traffic interface ge-0/0/0" command I see:
> >>>
> >>> VMX1:
> >>>
> >>> 14:56:57.489954 In IP 10.5.5.1 > 224.0.0.5: OSPFv2, Hello, length 56
> >>> 14:57:02.079691 Out IP truncated-ip - 20 bytes missing! 10.5.5.0 >
> >>> 224.0.0.5:
> >>> OSPFv2, Hello, length 60
> >>>
> >>> VMX2:
> >>> 14:57:48.925035 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 >
> >>> 224.0.0.5:
> >>> OSPFv2, Hello, length 56
> >>>
> >>> 14:57:58.487367 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 >
> >>> 224.0.0.5:
> >>> OSPFv2, Hello, length 56
> >>>
> >>> VMX1 arp cache:
> >>>
> >>> 00:0c:29:a7:e9:09 10.5.5.1 ge-0/0/0.0 none
> >>>
> >>> VMX2 arp cache is empty.
> >>>
> >>> I never see any inbound packets on VMX2. I've tied ping same result. I
> >>> through this might be a broadcast/multicast problem so I tried
> configuring
> >>> static arp entries and then did a ping but this didn't help.
> >>>
> >>> 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
> >>
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> Eduardo Schoedler
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VMX to VMX traffic on ESXi

[serge vautour]

Hello,

Thanks to everyone who replied with suggestions.

I did not have any licenses installed. Oddly enough VMX2 was showing:

user@LabVMX2> show pfe statistics traffic bandwidth
Configured Bandwidth : 100 bps
Bandwidth: 0 bps
Average Bandwidth: 339 bps

This explains why VMX1 could receive traffic from VMX2. VMX1 had:

user@LabVMX1> show pfe statistics traffic bandwidth
Configured Bandwidth : 0 bps
Bandwidth: 0 bps
Average Bandwidth: 0 bps

This is very strangle considering I created both VMX from the same install
file and they have near identical configs!?!

Anyway I downloaded a 60 trial license from the Juniper web site and
installed on both. Everything is now working as expected.

Thanks,
Serge


On Sun, Mar 20, 2016 at 8:13 AM, Raphael Mazelier <r...@futomaki.net> wrote:

> I have got some strange problem with vmx on vmware.
> First double check if all our vswitch are in promiscuous mode.
> Check also if you use vxnet or e1000 type of interface, I've got erratic
> problems with vxnet, and gave up with it.
> Check the mac address mapping, and finaly check if you have proper license
> installed ;) (I've spend one hour to find why one of my test vmx does not
> anymore, before I found that the license have expired...)
>
> --
> Raphael Mazelier
>
> Le 18/03/2016 21:49, serge vautour a écrit :
>
>> Hello,
>>
>> I haven't had any replies in the Juniper VMX forum so I thought I'd try
>> here:
>>
>> I have setup 2 VMX (each with a VCP & VPFE) on one ESXi host using Junos
>> VMX 15.1F4. Each VMX seems to be working fine on it's own. I can remotely
>> access the fxp0 interface.
>>
>> I created a dedicated vswitch with promiscuous mode on for the GE
>> interface. I used this vswitch for the 3rd NIC on each VPFE. I did not
>> attach any physical NICs to the vswitch as I only want to use it for
>> VMX-VMX traffic. Each VMX sees all 8 GE with ge-0/0/0 being up. I
>> configure:
>>
>> user@LabVMX1> show configuration interfaces ge-0/0/0
>> description "Link to VMX2 ge-0/0/0";
>> unit 0 {
>> family inet {
>> address 10.5.5.0/31;
>> }
>> }
>>
>> user@LabVMX2> show configuration interfaces ge-0/0/0
>> description "Link to VMX1 ge-0/0/0";
>> unit 0 {
>> family inet {
>> address 10.5.5.1/31;
>> }
>> }
>>
>> I also added OSPF to each interface. VMX1 seems to work fine. It shows
>> in/out traffic. VMX2 only shows outbound traffic.
>>
>> Using "monitor traffic interface ge-0/0/0" command I see:
>>
>> VMX1:
>>
>> 14:56:57.489954 In IP 10.5.5.1 > 224.0.0.5: OSPFv2, Hello, length 56
>> 14:57:02.079691 Out IP truncated-ip - 20 bytes missing! 10.5.5.0 >
>> 224.0.0.5:
>> OSPFv2, Hello, length 60
>>
>> VMX2:
>> 14:57:48.925035 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 >
>> 224.0.0.5:
>> OSPFv2, Hello, length 56
>>
>> 14:57:58.487367 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 >
>> 224.0.0.5:
>> OSPFv2, Hello, length 56
>>
>> VMX1 arp cache:
>>
>> 00:0c:29:a7:e9:09 10.5.5.1 ge-0/0/0.0 none
>>
>> VMX2 arp cache is empty.
>>
>> I never see any inbound packets on VMX2. I've tied ping same result. I
>> through this might be a broadcast/multicast problem so I tried configuring
>> static arp entries and then did a ping but this didn't help.
>>
>> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] VMX to VMX traffic on ESXi

[serge vautour]

Hello,

I haven't had any replies in the Juniper VMX forum so I thought I'd try
here:

I have setup 2 VMX (each with a VCP & VPFE) on one ESXi host using Junos
VMX 15.1F4. Each VMX seems to be working fine on it's own. I can remotely
access the fxp0 interface.

I created a dedicated vswitch with promiscuous mode on for the GE
interface. I used this vswitch for the 3rd NIC on each VPFE. I did not
attach any physical NICs to the vswitch as I only want to use it for
VMX-VMX traffic. Each VMX sees all 8 GE with ge-0/0/0 being up. I configure:

user@LabVMX1> show configuration interfaces ge-0/0/0
description "Link to VMX2 ge-0/0/0";
unit 0 {
family inet {
address 10.5.5.0/31;
}
}

user@LabVMX2> show configuration interfaces ge-0/0/0
description "Link to VMX1 ge-0/0/0";
unit 0 {
family inet {
address 10.5.5.1/31;
}
}

I also added OSPF to each interface. VMX1 seems to work fine. It shows
in/out traffic. VMX2 only shows outbound traffic.

Using "monitor traffic interface ge-0/0/0" command I see:

VMX1:

14:56:57.489954 In IP 10.5.5.1 > 224.0.0.5: OSPFv2, Hello, length 56
14:57:02.079691 Out IP truncated-ip - 20 bytes missing! 10.5.5.0 > 224.0.0.5:
OSPFv2, Hello, length 60

VMX2:
14:57:48.925035 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 > 224.0.0.5:
OSPFv2, Hello, length 56

14:57:58.487367 Out IP truncated-ip - 16 bytes missing! 10.5.5.1 > 224.0.0.5:
OSPFv2, Hello, length 56

VMX1 arp cache:

00:0c:29:a7:e9:09 10.5.5.1 ge-0/0/0.0 none

VMX2 arp cache is empty.

I never see any inbound packets on VMX2. I've tied ping same result. I
through this might be a broadcast/multicast problem so I tried configuring
static arp entries and then did a ping but this didn't help.

Any help would be appreciated.

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

Re: [j-nsp] Link with errors, how to fast detect ?

[serge vautour]

Hello,

If you're worried about the link flapping, just set a Down-->Up hold-timer
directly on the interface.

http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/hold-time-edit-interfaces.html

Serge

On Mon, Oct 19, 2015 at 11:33 AM, james list  wrote:

> Dear experts,
>
> I currently have a wan link between two MXs that sometimes is experiencing
> errors.
>
> I’ve on top of the link OSPF (timer 1/3)  as routing protocol and I’d like
> to find out any possible way to exclude the link when errors are in place
> and below to the 3 seconds of the OSPF timers.
>
>
> I’ve analyzed the following:
>
> 1)  BFD  with OSPF  but it doesn’t support hold-time (as BGP does), in
> order to avoid OSPF flapping and generate higher instability I cannot use
> it
>
> 2)  RPM event based script: probe interval is currently not below of 1
> second, hence to detect results with no false positive I need some sampling
> and we’re still at 3 seconds or more
>
> Any other possible options ?
>
> OAM ? does it support hold-time ?
>
>
> Cheers
>
> James
> ___
> 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] Distributed PPM and LACP always goes into Queue 3. host-outbound-traffic knob has no effect -- bug?

[Serge Vautour]

Hello,
Yes I've seen and confirmed this behavior a while back as well. If you ask I'm 
sure you'll be told this is not a bug and would require a feature request to 
change. See:
http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/general/hw-cos-default-re-queues-reference-cos-config-guide.html
For all protocol packets sent to queue 3 over a VLAN-taggedinterface, the 
software sets the 802.1p bits to 110. However, whenprotocol packets such as BFD 
are handled by the Packet ForwardingEngine, the software sets the 802.1p bits 
to 000.
As you can see on top of putting all packets in queue 3, the pbits aren't even 
marked correctly :(
Serge  
  From: Huan Pham drie.huanp...@gmail.com
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
 Sent: Thursday, May 14, 2015 9:22 PM
 Subject: [j-nsp] Distributed PPM and LACP always goes into Queue 3. 
host-outbound-traffic knob has no effect -- bug?
   
Hi list,

I've tested in the lab and confirm that distributed PPM (e.g. one hop BFD)
and LACP on MX does not honour host-outbound-traffic class of service nor
outbound RE-reclassificaiton filter. This traffic always gets into queue 3.
Depending on your design, this behaviour could be a problem, especially if
your queue 3 is not designed for critical traffic.
Is is a bug? Is there any way to move this control traffic to a different
queue?

Thanks very much in advance.

Huan
___
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] Shaper burst size

[Serge Vautour]

Hello,
We use egress shapers on our Juniper MX. They uses a default burst size that 
are set automatically based on the size of the shaper. So far, these defaults 
have served us well.
We have notice that some downstream devices that perform rate conversion can't 
seem to buffer the bursts properly. Ex:
- Traffic flow
Start - 1G - DeviceA -1G - MX with 80M shaper - 1G - DeviceB - 100M - End

The setup above works fine when DeviceB is connected at 1G on both interfaces. 
Likewise, it works fine when Start-DeviceA is also 100M. With the exact setup 
above, when DeviceB does 1G to 100M conversion, it can't seem to handle the 
bursts of data handed out by the MX and drops traffic. Configuring the MX burst 
size to 0 (actual lowest value possible is 1 Byte) seems to solve the problem: 
no more drops by DeviceB.
Is setting the shaper burst size to 0 a good idea? Are there any consequences 
to doing this?
Thanks,Serge

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

Re: [j-nsp] MX80 vs. MX80-T

[Serge Vautour]

Hello,
My understanding is the T model is physically different than the regular 
older model. They look the same but have a chip to provide the timing support. 
You can't just upgrade with a license. You need the T model hardware version 
to support timing.
Serge

  From: Dave Peters - Terabit Systems d...@terabitsystems.com
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
 Sent: Thursday, December 18, 2014 2:43 PM
 Subject: [j-nsp] MX80 vs. MX80-T
   
Hi all--

Just wondering if you can use the timing support features on a regular MX80 as 
you can on an MX80-T. Is the timing support a feature that needs to be licensed 
on a standard MX80 to make it a T model, or is it currently a Juniper 
honor-system feature?
The physical properties of the two units look exactly the same, from what I can 
tell.

All information, as always, very much appreciated.

--Dave Peters

___
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] Class of service groups with wildcards

[Serge Vautour]

Where this gets applied depends on where you have your groups applied. For 
example if you do:

    set class-of-service interfaces apply-groups LAYER2-COS

your QOS-MAP will get applied to every interface configured under 
class-of-service interfaces.
If you do:

    set class-of-service interfaces ge-1/2/3 apply-groups LAYER2-COS

your QOS-MAP will only get applied to ge-1/2/3.

Same for your VLAN-QOS. This:

    set class-of-service interfaces ge-1/2/3 apply-groups VLAN-QOS

will apply the classifier and re-write rules to all IFL under ge-1/2/3. You can 
view the final config (post inheritance) with:

    show conf class-of-service | display inheritance

If that doesn't work for you, please post your entire config including:

show conf
show conf | display inheritance terse

I hope that helps. 

Serge



 From: John Neiberger jneiber...@gmail.com
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Thursday, February 6, 2014 3:49:06 PM
Subject: [j-nsp] Class of service groups with wildcards
 

I'm a little confused about how wildcards work in groups that use for our
class of service configs. I was thinking that the wildcard would allow us
to apply a configuration to an interface and all its logical units with one
command, but now I don't think that's the case. Here is an basic example:

LAYER2-COS {

    class-of-service {

        interfaces {

            * {

                scheduler-map QOS-MAP;

            }

        }

    }

}



VLAN-COS {

    class-of-service {

        interfaces {

            * {

                unit * {

                    classifiers {

                        dscp DSCPV4-CLASSIFIER;

                        dscp-ipv6 DSCPV6-CLASSIFIER;

                    }

                    rewrite-rules {

                        dscp DSCPV4-REWRITE;

                        dscp-ipv6 DSCPV6-REWRITE;

                    }

                }

            }

        }

    }

}


The first group applies the scheduler-map to the main interface. I thought
the second group would then apply the classifiers and rewrite rules to the
logical units. However, when I apply those groups to an interface with
multiple LUs, the classifiers and rewrite rules only get applied to the
first logical unit.


My thought is that the wildcard doesn't do what I thought it did and that
I'll actually have to separately apply VLAN-COS to each LU that requires it.


Or am I wrong? Is there a way to do this all in one or two commands for all
LUs?


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] MX ping - ToS overrided

[Serge Vautour]

If you're capturing your outbound ping packet, why does the capture show echo 
reply? Shouldn't you be capturing the echo request?

Serge





 From: Arash Alizadeh aras...@hotmail.se
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Wednesday, January 22, 2014 10:21:44 AM
Subject: [j-nsp] MX ping - ToS overrided
 

Hi,

I'm experiencing issues when initating ToS ping from MX devices. The specified 
ToS argument just seems to be overrided to dec 192 when leaving the interface.

I verified this with the traffic monitor on the egress interface:

user@node ping 8.8.8.8 tos 96 
64 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=15.675 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms

user@node monitor traffic interface xe-0/0/0.0 extensive matching icmp 
PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], 
proto: ICMP (1), length: 84) x.x.x.x  8.8.8.8: ICMP echo reply, id 47826, seq 
0, length 64
14:06:58.721197 Out 

I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same 
result.

Did anyone else ran into this issue? 
Any input is appriciated. 

Regards,
Arash
                          
___
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 Junos 12.3R3.4 Processor Utilization

[Serge Vautour]

We hit an SNMP memory leak bug on 12.3R3 which drove up the CPU  Mem. Might be 
something similar. 12.3R4 is out. Maybe give it a try?

Serge





 From: David Miller dmil...@tiggee.com
To: juniper-nsp@puck.nether.net 
Sent: Friday, September 20, 2013 5:59:35 PM
Subject: [j-nsp] EX4200 Junos 12.3R3.4 Processor Utilization
 


Anyone running the JTAC recommended version of Junos (12.3R3.4) on any
EX4200s and collecting configs with RANCID?  If so, then I would be
curious to see what your proc utilization looks like.

What I see on my 12.3R3.4 switch is a large CPU spike whenever RANCID
collects data.

The command that seems to be the issue is:
show version detail | no-more

On my switch the following 3 log messages appear in /var/log/messages
every time 'show version detail' is run:

Jun 14 03:19:39   mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer
'remote-operations'
Jun 14 03:19:39   mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer
'dhcp'
Jun 14 03:19:40   mgd[2139]: UI_OPEN_TIMEOUT: Timeout connecting to peer
'autoinstallation'

Top shows:
CPU states: 39.2% user,  0.0% nice, 55.3% system,  0.1% interrupt,  5.5%
idle
during a run of this show command.

My SNMP monitoring over time shows spikes of:
jnxOperatingCPU.FPC0  max: 81.80
jnxOperatingCPU.RE0   max: 35.92

Anyone else seeing this as well?

I can reproduce this behavior exactly on a brand new switch, upgraded to
12.3R3.4, with vanilla default Juniper config on it (so I don't think
that it is my config).

Am I missing some simple config option?
set chassis routing-engine dont-blow-out-cpus-on-simple-show-cmds

- DMM


___
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] Site Range (out of range) for L2VPNs - Juniper MX

[Serge Vautour]

Try site ID 2 for site LAB-C. -Serge





 From: Austin Leyland austin.leyl...@gmail.com
To: juniper-nsp@puck.nether.net 
Sent: Tuesday, August 13, 2013 2:07:50 PM
Subject: [j-nsp] Site Range (out of range) for L2VPNs - Juniper MX
 

Hi,

I have three MX80s in a learning lab, in is-is and ibgp full mesh.  I am
trying to configure two L2VPN circuits as follows

LAB-A port 1/1/2 vlan 510 to LAB-B port 1/1/2 vlan 510
LAB-A port 1/1/2 vlan 512 to LAB-C port 1/1/2 vlan 512

When i try to bring the circuits up, I get an 'out of range' error, even
though I have not varied the site-range from the default which I understand
to be 65535.

Instance: TEST205-2006
  Local site: LAB-C (3)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   OR

The config I am using is :


LAB-A (loopback ip 192.168.11.10):

interfaces {
    ge-1/1/2 {
        description TEST;
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 510 {
            description service 1;
            encapsulation vlan-ccc;
            vlan-id 510;
        }
        unit 512 {
            description service 2;
            encapsulation vlan-ccc;
            vlan-id 512;
        }
}

routing-instances {
    TEST205-2005 {
        instance-type l2vpn;
        interface ge-1/1/2.510;
        route-distinguisher 192.168.11.10:510;
        vrf-target target:12345:510;
        protocols {
            l2vpn {
                encapsulation-type ethernet-vlan;
                interface ge-1/1/2.510;
                site LAB-A {
                    site-identifier 1;
                    interface ge-1/1/2.510;
                }
            }
        }
    }
    TEST205-2006 {
        instance-type l2vpn;
        interface ge-1/1/2.512;
        route-distinguisher 192.168.11.10:512;
        vrf-target target:12345:512;
        protocols {
            l2vpn {
                encapsulation-type ethernet-vlan;
                interface ge-1/1/2.512;
                site LAB-A {
                    site-identifier 1;
                    interface ge-1/1/2.512;
                }
            }
        }
    }
}


LAB-C (loopback IP 192.168.11.12):

interfaces {
    ge-1/1/2 {
        apply-groups INTERFACE-PARAMETERS-EDGE;
        description SERVICE2;
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 512 {
            encapsulation vlan-ccc;
            vlan-id 512;
        }
    }
}

routing-instances {
    TEST205-2006 {
        instance-type l2vpn;
        interface ge-1/1/2.512;
        route-distinguisher 192.168.11.12:512;
        vrf-target target:12345:512;
        protocols {
            l2vpn {
                encapsulation-type ethernet-vlan;
                interface ge-1/1/2.512;
                site LAB-C {
                    site-identifier 3;
                    interface ge-1/1/2.512;
                }
            }
        }
    }
}

Any idea why this is occurring?

AL
___
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] Displaying config during commit

[Serge Vautour]

Hello,

Can anyone tell me how to display the output of the following using a commit 
script (or other means) every time there's a commit?

show | display set |match deactivate  

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

Re: [j-nsp] What is this ethernet switching trace telling us?

[Serge Vautour]

Our VoIP guys have these ACME SBCs. I do know they run in Active/Passive
 mode with a VRRP like protocol. This means a common MAC that floats 
between both boxes depending on which is primary. Maybe both boxes think
 they're primary and keep advertising the same MAC? This would cause a constant 
move of the same MAC.

Serge




 From: John Neiberger jneiber...@gmail.com
To: Georgios Vlachos g.vlac...@kestrel-is.gr 
Cc: juniper-nsp@puck.nether.net 
Sent: Saturday, June 8, 2013 9:32:19 PM
Subject: Re: [j-nsp] What is this ethernet switching trace telling us?
 

We added a firewall filter to count incoming frames with the wrong MAC
addresses and we are seeing incrementing counters. Between that and the
trace logs it sends clear that the addresses are jumping around. I'm not
sure what OS the Acme SBC is running, but hopefully there is a tunable knob
somewhere.
On Jun 8, 2013 7:50 AM, Georgios Vlachos g.vlac...@kestrel-is.gr wrote:

 You can use the MAC Move Limiting feature with action log to see what is
 happening,

 Or just use a interface-specific FF with from the source MAC and action
 count (with implicit accept)...



 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of
 John Neiberger
 Sent: Saturday, June 08, 2013 4:16 PM
 To: Gavin Henry
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] What is this ethernet switching trace telling us?

 This is an Acme Packet chassis. I really have no idea what it has running
 on it, but I'll find out from our voice team.

 Thanks!
 On Jun 8, 2013 1:35 AM, Gavin Henry ghe...@suretec.co.uk wrote:

  Hi John,
 
  We (SureVoIP) have seen this on some of our hosted SIP servers which
  run on Linux with multiple interfaces. This was connected to a Cisco
  switch though. If the SBC is on linux then install arpwatch and add
  your email to /etc/aliases. We found that the Linux kernel doesn't
  send the same arp response out of the same interface. For example, one
  interface was a public IP and one was a private IP. The kernel would
  send a I'm on MAC blah for the private IP out of the public IP port!
 
  arptables is the solution, but in 10 years it's the first time I'd
  seen this. Google shows otherwise (me):
 
  http://www.gossamer-threads.com/lists/drbd/users/24805
 
 

 http://serverfault.com/questions/58146/what-can-cause-two-network-interfaces
 -on-the-same-machine-to-flip-flop-their-ip
 
  arpwatch will report flip flop in the logs.
 
  If you're not on Linux then I'm not sure :-(
 
  Thanks.
 
 
  On 8 June 2013 01:49, John Neiberger jneiber...@gmail.com wrote:
   Here is another example of the same type of thing. In this case, a MAC
   address appears to be jumping from one four-port card to another on the
  same
   switch. Port 5 is connected to one NIC, while port 8 is on another
  four-port
   NIC and should never, ever use the MAC address we're learning on port
 5.
  Do
   these logs really indicate that the MAC is being learned on those
   interfaces, or is it cryptically trying to tell us something else? I
  don't
   want to assume.
  
   Jun  7 23:21:15.686871 Attempt to add vlan sbc-core mac
  00:08:25:fa:3c:91,
   ifname ge-0/0/8.0, pnac_status 0, 0
  
   Jun  7 23:21:15.686981 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40),
 iif
  =
   ge-0/0/8.0: present in FDB
  
   Jun  7 23:21:15.687048 (3, 00:08:25:fa:3c:91) next-hop index change
  [1330 -
   1329]
  
   Jun  7 23:21:15.687172 Attempt to add vlan sbc-core mac
  00:08:25:fa:3c:91,
   ifname ge-0/0/5.0, pnac_status 0, 0
  
   Jun  7 23:21:15.687267 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40),
 iif
  =
   ge-0/0/5.0: present in FDB
  
   Jun  7 23:21:15.687501 (3, 00:08:25:fa:3c:91) next-hop index change
  [1329 -
   1330]
  
   Jun  7 23:21:15.687672 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index
  1330
  
   Jun  7 23:21:15.687732 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac
   00:08:25:fa:3c:91
  
   Jun  7 23:21:49.269317 Attempt to add vlan sbc-core mac
  00:08:25:fa:3c:91,
   ifname ge-0/0/5.0, pnac_status 0, 0
  
   Jun  7 23:21:49.269427 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40),
 iif
  =
   ge-0/0/5.0: present in FDB
  
   Jun  7 23:21:49.269583 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index
  1330
  
   Jun  7 23:21:49.269646 krt_dequeue: type FDB op change 3,
  00:08:25:fa:3c:91
   Direct nh 1330
  
   Jun  7 23:21:49.270539 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac
   00:08:25:fa:3c:91
  
   Jun  7 23:37:09.776588 Attempt to add vlan sbc-core mac
  00:08:25:fa:3c:91,
   ifname ge-0/0/8.0, pnac_status 0, 0
  
   Jun  7 23:37:09.776953 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40),
 iif
  =
   ge-0/0/8.0: present in FDB
  
   Jun  7 23:37:09.777140 (3, 00:08:25:fa:3c:91) next-hop index change
  [1330 -
   1329]
  
  
  
   On Fri, Jun 7, 2013 at 6:30 PM, John Neiberger jneiber...@gmail.com
  wrote:
  
   I just checked and we do not have spanning tree enabled on this switch
  or
   its 

Re: [j-nsp] 1000BaseT SFP

[Serge Vautour]

Very likely no. What's the SFP model number and the line card type you're using 
on the MX?

Serge




 From: Keith kwo...@citywest.ca
To: juniper-nsp@puck.nether.net 
Sent: Tuesday, May 10, 2011 8:59:06 PM
Subject: [j-nsp] 1000BaseT SFP
 


Trying to connect GE copper SFP on MX to a 100meg port on a cisco switch, 3560 
actually.


ge-0/0/2 { description  Test Link ; enable; speed 100m; link-mode 
full-duplex; unit 0 { family inet { address 192.168.1.2/26; show interface 
ge-0/0/2: Physical interface: ge-0/0/2, Enabled, Physical link is Up Interface 
index: 136, SNMP ifIndex: 511 Description:  Test Link  Link-level type: 
Ethernet, MTU: 1514, Speed: 100mbps, BPDU Error: None, MAC-REWRITE Error: None, 
Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled, 
Auto-negotiation: Enabled, 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: 
80:71:1f:91:10:02, Hardware address: 80:71:1f:91:10:02 Last flapped   : 
2011-04-28 13:44:09 PDT (1w5d 03:08 ago) Input rate : 0 bps (0 pps) Output 
rate: 0 bps (0 pps) Active alarms  : None Active defects : None Logical 
interface ge-0/0/2.0 (Index 74) (SNMP ifIndex 522) Flags: SNMP-Traps
 0x400 Encapsulation: ENET2 Input packets : 0 Output packets: 19 Protocol 
inet, MTU: 1500 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred 
Is-Primary Destination: 192.168.1.0/26, Local: 192.168.1.2, Broadcast: 
192.168.1.63 Protocol multiservice, MTU: Unlimited Swapped cables etc, my 
question is can these 1000BaseT SFP's work at 100M? I can configure them as such
but do they actually work at 100M? Thanks,
Keith 



___
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] SNMP on logical-system fxp0

[Serge Vautour]

I've encountered many other troubles in the past trying to do this in the 
lab.Lat time I tried it NSR broke?!? I agree this should be pretty standard 
stuff but it seems to break lots of features. 

We tend to put everything in inet.0 and point static routes out fxp0 for any 
traffic initiated by the RE. For requests inbound to the RE, we NAT the source 
on the routers used as the gateway off fxp0. That way all inbound requests look 
like they're from gateway. No return routes required.

Serge





 From: Klaus Groeger kla...@gmail.com
To: Juniper NSP juniper-nsp@puck.nether.net 
Sent: Saturday, April 20, 2013 11:23:20 AM
Subject: Re: [j-nsp] SNMP on logical-system fxp0
 

Hi


the fxp0 interface is bound to the RE, witch always resides in the first 
logical system and ist bound to the default routing table or master table, 
which is inet.0. All route lookups regarding the RE start in inet.0.


Just put all your productive interfaces in a separate virtual router and you 
are done. 


Klaus




---
___
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] MX80 vs MX10 software testing

[Serge Vautour]

Hello,

Before we deploy a new Junos version to production we run it through a series 
of test cases to prove all the functionality we use. We will also re-test on 
each piece of hardware (ie MX80 vs MX960). 


Any comments on the Hardware differences between an MX80 and MX10? Juniper 
initial had MX80-10 which were the exact same Hardware as MX80. There was a 
gentleman's agreement license as to which ports you could use. Technically, the 
box was an MX80.

Now Juniper has MX5, MX10 and MX40. These are slightly different than MX80 as 
they won't work before 11.x while MX80 started on 10.2 code. We're being told 
the difference is minor (new eprom chip and timing kit). 


We're struggling with the level of testing we should do between MX80 and MX10. 
Should we repeat all test cases on both? Some test cases? Which ones? Should we 
not bother at all (ie anything that works on MX10 will also work in MX80)?

Juniper is tell us the differences are minor and we shouldn't have to repeat 
testing on both platforms.


Comments? Thanks,

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

Re: [j-nsp] MX5-T VPLS fowarding problem

[Serge Vautour]

I'm pretty sure tunnel-services is only required on M/T platforms. In those 
boxes you needed a tunnel PIC to allow VPLS to work. On MX series the 
functionality is built into the line cards. You do need to explicitly disable 
tunnel-services under 
routing-instances routing-instance-name protocols vpls:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/configuration-statement/no-tunnel-services-edit-protocols-vpls.html

The command set chassis fpc XX pic XX tunnel-services bandwidth 1g|10G 
lets you create LT interfaces that can be used to logically connect 2 Logical 
Systems or Virtual Routers together. Essentially, the MPC line cards in MX have 
built-in tunnel PICs. This lets you use them. 

https://www.juniper.net/techpubs/en_US/junos12.2/topics/example/logical-systems-connecting-lt.html

You shouldn't need this for VPLS.Hope this helps.

Serge







 From: Mathias Sundman math...@nilings.se
To: Caillin Bathern caill...@commtelns.com 
Cc: juniper-nsp@puck.nether.net 
Sent: Friday, March 29, 2013 6:27:25 PM
Subject: Re: [j-nsp] MX5-T VPLS fowarding problem
 
On 03/29/2013 12:40 PM, Caillin Bathern wrote:
 First try adding set chassis fpc XX pic XX tunnel-services
 bandwidth 1g|10G.  You then have tunnel services on the MX80.  Can't
 remember if this has any caveats on being done to a live system though..

Can someone explain the benefits of using tunnel-services vs no-tunnel-services 
on the MX80 platform for VPLS services?

With a 10G backbone using 3-4 of the built-in 10G interfaces, and an expected 
VPLS use of 1-4G of bandwidth, what would be the recommended config?
___
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-T VPLS fowarding problem

[Serge Vautour]

Simplest way is to swap on egress. Under your unit add output-vlan-map swap. 
As long as all your VPLS end points have the same number of tags (sounds like 
this do), the S-tag can be different on each end. Output swap will take care of 
everything. You could achieve the same thing with pop on ingress and push on 
egress but I just find that more complicated than it has to be.

Serge





 From: Mathias Sundman math...@nilings.se
To: sth...@nethelp.no 
Cc: juniper-nsp@puck.nether.net 
Sent: Friday, March 29, 2013 10:51:05 AM
Subject: Re: [j-nsp] MX5-T VPLS fowarding problem
 
On 03/29/2013 02:36 PM, sth...@nethelp.no wrote:
 I got an off-list message from Diogo saying that the logical interface
 (VLAN ID) on each side must be the same, unless you do some
 pop/push/swap magic. Changing that did solve the problem! I still don't
 see why though. I only use the VLAN locally on each site to separate the
 traffic between multiple customers in the access switches, so the VLAN
 tag should never be included in the actual frames forwarded between the
 routers.
 The BGP-based VPLS RFC (RFC 4761) specifies in section 4.1:
 
     Ethernet frames received from CE devices are encapsulated for
     transmission over the packet switched network connecting the PEs.
     The encapsulation is as in [7].
OK, then I understand. I consider the customer switch/router that they attach 
outside my access-switch the CE Device, while the RFC consider the first 
device connected to the PE router the CE device regardless of how it's used, 
and I guess that's where the confusion is created.

 where reference 7 is RFC 4448, which in its turn says:
 
     In Ethernet PW operates in one of two modes: raw mode or tagged
     mode.  In tagged mode, each frame MUST contain at least one 802.1Q
     [802.1Q] VLAN tag, and the tag value is meaningful to the NSPs at the
     two PW termination points.
 
 Tagged mode is what you get if you have a VLAN subinterface and you
 don't do anything specific to remove the tag. Thus you should *expect*
 the VLAN tag to be included.
 
 It would have been possible for Juniper to automatically translate
 VLAN IDs on output - this is what for instance Cisco does on single-
 tagged pseudowires. Such automatic translation means that the VLAN
 IDs don't have to match. However, Juniper has chosen not to do such
 automatic translation.
 

My goal is to use Q-in-Q on the trunk between my PE router and my 
access-switch, and then q-tunnel mode on the customer port to allow him to 
transport any VLANs he want inside the VPLS tunnel.

So, if I want to achieve that without having to use the same outer VLAN ID 
between my PE and access-switch on each side, what do I have todo?

Can I just pop the ingress outer tag (my S-VLAN) and consider it a RAW mode PW, 
or will it not allow the customer VLANs to be transported then?

or would I have to swap in incoming S-VLAN to a common VLAN between my PEs and 
then swap it back to the locally unique S-VLAN used at each site?

Thx
___
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] interface-transmit-statistics

[Serge Vautour]

Hello,

We hit a bug back on 10.4R5/S5 where DPC ILF  IFD stats were incorrectly 
reported when a Traffic Control Profile was used. If I remember correctly, when 
we sent a constant bit rate stream through a TCP shaper, the queue stats would 
should traffic sent + drops (different counters) while the ILF  IFD stats 
would should the sum of traffic sent + drop. This is obviously incorrect. The 
IFL/IFD should only show traffic sent.

This command fixed this in 10.4R6+. We have it applied on all DPC interfaces. 
My notes say PR574355 and/or PR586347. I hope this help.

Serge





 From: Richard A Steenbergen r...@e-gerbil.net
To: juniper-nsp@puck.nether.net 
Sent: Saturday, February 23, 2013 5:52:14 PM
Subject: [j-nsp] interface-transmit-statistics
 
I was skimming through some release notes and noticed the following new 
feature, which was supposedly added in 12.3 and 11.4R3 (new features in 
an R3 release? *cough*):

http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/interface-transmit-statistics-reporting-improvements-overview.html
http://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/interface-transmit-statistics-edit-interfaces.html

The description on this is pretty vague, but it SOUNDS like this might 
compensate for the long-standing issue where the L2 overhead on packets 
don't get reported in the SNMP counters on Juniper hardware, in 
violation of the spec and opposition to how every other vendor does it. 
Actually it doesn't sound like this at all (did I mention this 
description is ridiculously vague and poorly written), but that's a 
pretty serious long-standing issue that I'd LOVE to see get addressed, 
and the only one I can think of related to transmit statistics, so I'm 
hopeful that this is what it fixes. If anybody has any further details, 
it'd be much appreciated. :)

That said, what hardware is it actually supported on? The release notes 
just say MX, but when I try it on MPC-16XGE or MPC2 interfaces on a 
box running 11.4R6 it says:

dcd[1550]: %DAEMON-3: Interface-Transmit-Statistics Knob not supported 
on this hardware. Will have no effect.

And a more interesting question, would this also affect the packet 
counters reported to MPLS LSPs when doing auto-bandwidth calculations? 
This issue causes one of the biggest problems with auto-bandwidth on 
Juniper, the lack of L2 overhead in the counters makes it possible for 
high-pps traffic like a DoS attack to be completely invisible to RSVP, 
causing uncompensated for congestion.

-- 
Richard A Steenbergen r...@e-gerbil.net      http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] delay-buffer in Juniper

[Serge Vautour]

All of my testing was on Q cards (DPCE-R-Q-40GE-SFP). I never tried on on a 
pure R card. And yes on this type of card rate-limit acts exactly like a 
policer. -Serge




 From: Johannes Resch j...@xor.at
To: Serge Vautour se...@nbnet.nb.ca 
Cc: Serge Vautour sergevaut...@yahoo.ca; Huan Pham drie.huanp...@gmail.com; 
Stefan Fouant sfou...@shortestpathfirst.net; juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net 
Sent: Wednesday, October 17, 2012 10:13:58 AM
Subject: Re: [j-nsp] delay-buffer in Juniper
 
Hi,c

 My testing has shown the following with regards to queue commands:

 DPC:
 -Rate-limit: works as expected, queue is policed.

note that support of rate-limit on regular DPC (non EQ types)
is relatively new (added in 10.x?).

 -Exact: Not supported

did you test this on regular DPC (non EQ type)?

we did successfully test this in our setup on non-EQ DPC (specifically 
DPCE-R-40GE-SFP, DPCE-R-4XGE-XFP, DPCE-R-20GE-2XGE),
we found it behaves like a shaper (so it is mandatory to combine it with 
buffer size temporal x to keep buffer size/resulting jitter in 
acceptable range for low latency queues).

on EQ type cards (DPCE-R-Q-), exact is not supported, but 
rate-limit works (from our tests, looks like strict policer).

cheers,
-jr

PS: and yes, maybe JNPR could have designed this with fewer config 
option/HW compatibility permutations :-)

 -Shaping-Rate: Command takes but it does nothing. The queue isn't
 capped and traffic can reach sub-interface or interface shaped rate.

 MPC:
 -Rate-limit: Command takes but it does nothing. The queue isn't
 capped and traffic can reach sub-interface or interface shaped rate.
 -Exact: The result looks like a shaper.
 -Shaping-Rate: Results look exactly like the exact command. Traffic
 looks shaped.

 The summary is that DPC cards can only police queues and MPC cards can only 
 shape queues. I agree that the docs aren't very clear on what's supported. 
 I had to run my own tests to figure it out.

 Serge




 
   From: Huan Pham drie.huanp...@gmail.com
 To: Stefan Fouant sfou...@shortestpathfirst.net
 Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Sent: Saturday, October 13, 2012 8:45:58 PM
 Subject: Re: [j-nsp] delay-buffer in Juniper



 Honestly, that's 9.5 documentation. Perhaps something changed at some
 point, but in current versions of code this is not how it works.




 Hi Stefan,

 You are right, I should to pay attention to the version, as the behaviour
 may have changed. I am new to Juniper (moving from the Cisco background),
 so I am still not familiar with navigating Juniper documentation. I relied
 on Google first hit :) . Will try to navigate the Juniper documentation.

 However, for this feature in the newest OS, I do not think that the
 behaviour is as you described. Although worded differently, it basically
 means the same as the one I quoted:

 Here's the link to the 12.1 OS:

 http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/transmit-rate-edit-cos.html

 rate-limit—(Optional) Limit the transmission rate to the rate-controlled
 amount. In contrast to the exact option, the scheduler with the rate-limit
 option shares unused bandwidth above the rate-controlled amount.


 I do not always trust the documentation, especially there may be limitation
 with hardware platform, OS version etc that is not well documented, so I
 set up a quick lab (running version 11.4R5.5) to test this feature. The
 behaviour in this case is the same as documented.


 When I use transmit-rate rate-limit I can send more traffic than the
 transmit rate-controlled amount. The transmit-rate rate-limit is 1m, but I
 can send traffic at 8Mbps.

 When I use transmit-rate exact I can not send more traffic than the
 transmit rate-controlled amount.

 One side note though, when I set the rate to a very low number (e.g. 10k,
 or even 500k), and use the exact option, the actual transmuted rate (on
 1Gbps port) is not rate limited to the configured value. This is probably
 understandable, due to factors as sampling intervals etc.

 Here's my lab config and results:


           ge-1/0/0                ge-1/1/0
 (MX5) R1  R2 (Virtual)
           10.1.1.1                10.1.1.2


 I generated traffic by pinging from R2 to R1
 lab@MX5 ping 10.1.1.1 routing-instance R2 rapid count 10 size 1000

 (Ping from R2 to R1, and monitor traffic on outbound of R1)




 lab@MX5 show configuration class-of-service schedulers admin-sched
 transmit-rate {
      1m;
      rate-limit;
 }
 buffer-size percent 10;
 priority medium-low;



 lab@MX5 show interfaces queue ge-1/1/0 | find admin
 Queue: 1, Forwarding classes: admin
    Queued:
      Packets              :                 75751                   931 pps
      Bytes                :              80750566               7942744 bps
    Transmitted:
      Packets

Re: [j-nsp] delay-buffer in Juniper

[Serge Vautour]

Hello,

What kind of hardware are you using? The behavior is different on MPC vs DPC. 
The MX80 family use built-in MPC cards. 

My testing has shown the following with regards to queue commands:

DPC:
-Rate-limit: works as expected, queue is policed.
-Exact: Not supported
-Shaping-Rate: Command takes but it does nothing. The queue isn't 
capped and traffic can reach sub-interface or interface shaped rate.

MPC:
-Rate-limit: Command takes but it does nothing. The queue isn't 
capped and traffic can reach sub-interface or interface shaped rate.
-Exact: The result looks like a shaper.
-Shaping-Rate: Results look exactly like the exact command. Traffic 
looks shaped.

The summary is that DPC cards can only police queues and MPC cards can only 
shape queues. I agree that the docs aren't very clear on what's supported. I 
had to run my own tests to figure it out.

Serge





 From: Huan Pham drie.huanp...@gmail.com
To: Stefan Fouant sfou...@shortestpathfirst.net 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Saturday, October 13, 2012 8:45:58 PM
Subject: Re: [j-nsp] delay-buffer in Juniper
 


 Honestly, that's 9.5 documentation. Perhaps something changed at some
 point, but in current versions of code this is not how it works.




Hi Stefan,

You are right, I should to pay attention to the version, as the behaviour
may have changed. I am new to Juniper (moving from the Cisco background),
so I am still not familiar with navigating Juniper documentation. I relied
on Google first hit :) . Will try to navigate the Juniper documentation.

However, for this feature in the newest OS, I do not think that the
behaviour is as you described. Although worded differently, it basically
means the same as the one I quoted:

Here's the link to the 12.1 OS:

http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/transmit-rate-edit-cos.html

rate-limit—(Optional) Limit the transmission rate to the rate-controlled
amount. In contrast to the exact option, the scheduler with the rate-limit
option shares unused bandwidth above the rate-controlled amount.


I do not always trust the documentation, especially there may be limitation
with hardware platform, OS version etc that is not well documented, so I
set up a quick lab (running version 11.4R5.5) to test this feature. The
behaviour in this case is the same as documented.


When I use transmit-rate rate-limit I can send more traffic than the
transmit rate-controlled amount. The transmit-rate rate-limit is 1m, but I
can send traffic at 8Mbps.

When I use transmit-rate exact I can not send more traffic than the
transmit rate-controlled amount.

One side note though, when I set the rate to a very low number (e.g. 10k,
or even 500k), and use the exact option, the actual transmuted rate (on
1Gbps port) is not rate limited to the configured value. This is probably
understandable, due to factors as sampling intervals etc.

Here's my lab config and results:


         ge-1/0/0                ge-1/1/0
(MX5) R1  R2 (Virtual)
         10.1.1.1                10.1.1.2


I generated traffic by pinging from R2 to R1
lab@MX5 ping 10.1.1.1 routing-instance R2 rapid count 10 size 1000

(Ping from R2 to R1, and monitor traffic on outbound of R1)




lab@MX5 show configuration class-of-service schedulers admin-sched
transmit-rate {
    1m;
    rate-limit;
}
buffer-size percent 10;
priority medium-low;



lab@MX5 show interfaces queue ge-1/1/0 | find admin
Queue: 1, Forwarding classes: admin
  Queued:
    Packets              :                 75751                   931 pps
    Bytes                :              80750566               7942744 bps
  Transmitted:
    Packets              :                 75751                    931 pps
    Bytes                :              80750566               7942744 bps
    Tail-dropped packets :                     0                     0 pps
    RED-dropped packets  :                     0                     0 pps
     Low                 :                     0                     0 pps
     Medium-low          :                     0                     0 pps
     Medium-high         :                     0                     0 pps
     High                :                     0                     0 pps
    RED-dropped bytes    :                     0                     0 bps
     Low                 :                     0                     0 bps
     Medium-low          :                     0                     0 bps
     Medium-high         :                     0                     0 bps
     High                :                     0                     0 bps



Change to using exact, I can not send more than 1M as expected.

lab@MX5 show configuration class-of-service schedulers admin-sched
transmit-rate {
    1m;
    exact;
}
buffer-size percent 10;
priority medium-low;



lab@MX5 show interfaces queue ge-1/1/0 | find 

Re: [j-nsp] WAN input prioritization on MX

[Serge Vautour]

Humm. My understand, at least with the command sets I'm use to using, is that 
you do classification on ingress and then queuing and marking on egress. When 
you do classification, the packets are assigned to a  Forwarding Class (FC) 
inside the box. This makes sure the box gives those packets proper treatment 
inside the box and that the packets get assigned to the proper egress interface 
queue. While the packets exit the queue (based on egress schedulers), the 
packet QoS headers are remarked.

Basically, this diagram:

http://www.juniper.net/techpubs/images/g017213.gif

Packets travel through the box based on the outer boxes following the solid 
lines. The dotted lines all point to or from the FC to identify how the 
decision is made. 

Serge





 From: Doug Hanks dha...@juniper.net
To: Chris Evans chrisccnpsp...@gmail.com; Gustavo Santos 
gustkil...@gmail.com 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Sunday, October 14, 2012 12:09:53 AM
Subject: Re: [j-nsp] WAN input prioritization on MX
 
How is this weird? You can mark on ingress, but the queuing happens on the
egress interface when it's to be transmitted.


On 10/13/12 6:07 AM, Chris Evans chrisccnpsp...@gmail.com wrote:

JUNOS does a weird way of marking packets.. It is done on the egress of
the
box, not on ingress (there is an exception in a few newer modules that can
do this). So it is probably working as the other poster mentioned.  Make
sure you take this methodology into consideration as it can hinder your
granularity of CoS with marking vs passing through and
you inadvertently remark traffic you didn't mean to.

On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos
gustkil...@gmail.comwrote:

 Doug and Hanks @juniper. I had to left the office and leave
configuration
 as is. On monday I will update you after verify what you have pointed,

 What I can tell is that I didn't have made any modification on the
systems
 default class of service  / mapping configuration.

 Thank you!

 Gustavo Santos
 Analista de Redes
 CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER



 2012/10/13 Harry Reynolds ha...@juniper.net

  Doug raises some good points.
 
  Also, for testing, perhaps add some counters to the terms to aid in
  confirming matches. You may also want to show config | display
  detail/inheritance to see if the prefix list is expanding as you
expect.
 
  Regards
 
 
 
  -Original Message-
  From: juniper-nsp-boun...@puck.nether.net [mailto:
  juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks
  Sent: Friday, October 12, 2012 9:36 PM
  To: Gustavo Santos; juniper-nsp@puck.nether.net
  Subject: Re: [j-nsp] WAN input prioritization on MX
 
  I'm sure it's working just fine. Are you checking the egress
interface to
  see if the traffic is being marked and queued properly? A common
mistake
 is
  to check the ingress interface queues.
 
 
  If this doesn't work, we would need to see your entire
class-of-service
  configuration.
 
  On 10/12/12 6:04 PM, Gustavo Santos gustkil...@gmail.com wrote:
 
  Hi,
  
  I'm new on Juniper class of service / shaping. I'm reading some tech
  docs from Juniper and a Juniper's  MX book, but it's kind tricky.
  Today I get asked to do a pretty simple configuration, but I tried
some
  settings but none of then worked. Any of you guys can help me with
that?
  
  What I want to achieve is pretty (conceptualy speaking) simple.  I
have
  a Gig interface and want to rate limit the interface at 500Mbits ,
mark
  a destination subnet with expedited forwarding class, mark anything
  else with best effort. I tried the config below but it's not working.
  The rate-limit works but the prioritization isn't.
  
  
  
  
  gustavo@MX5-1 show configuration firewall family inet filter
  wan-control physical-interface-filter; term high-priority {
      from {
          destination-prefix-list {
              high-priority-dst;
          }
      }
      then {
          policer limit500;
          loss-priority low;
          forwarding-class expedited-forwarding;
          }
  }
  term else {
      then {
          policer limit500;
          loss-priority high;
          forwarding-class best-effort
         }
  
  
  ( policer limit500)
  physical-interface-policer;
  if-exceeding {
      bandwidth-limit 480m;   (set the value lower to check policer
  working..
  but it wasn't as desired)
      burst-size-limit 625k;
  }
  then discard;
  
  then the filter was applied on the interface family inet filter input
  wan-control
  
  Gustavo Santos
  Analista de Redes
  CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER
  ___
  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] /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500

[Serge Vautour]

Getting errors to stop from showing up in the logs is easy. I want to know why 
they're being generated in the first place. -Serge




 From: Tima Maryin timamar...@mail.ru
To: Serge Vautour se...@nbnet.nb.ca 
Cc: Serge Vautour sergevaut...@yahoo.ca; Juniper-Nsp 
juniper-nsp@puck.nether.net 
Sent: Friday, May 11, 2012 1:07:17 PM
Subject: Re: [j-nsp] /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500
 
Hi,

On 08.05.2012 22:52, Serge Vautour wrote:
 We have an MX960 running 10.4R7 with the same problem. What's worse is the 
 error has been logging every 5-10min ever since we made the change ~3 months 
 ago. JTAC case hasn't resulted in anything useful yet. It's still open.


Did you try to change syslog level to warning ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Update on 10.4R9 stability for MX?

[Serge Vautour]

We've started to implement 10.4R9 in Prod. A few MX960s with MPC  DPC mix and 
MX80s have been upgraded without a problem (knock on wood!). We use L2VPN  
VPLS with OSPF/LDP/BGP.


Serge




 From: Clarke Morledge chm...@wm.edu
To: juniper-nsp@puck.nether.net 
Sent: Wednesday, May 9, 2012 4:13:26 PM
Subject: [j-nsp] Update on 10.4R9 stability for MX?
 
It has been a couple of months since the JTAC recommended Junos software 
versions has been updated for the MX.   As of February, the recommendation was 
to use 10.4R8.5 for the MX, except that there is an issue related to BFD 
configurations on the DPC line cards.   Supposedly, the fix is in 10.4R9.

In looking at the release notes, there are some issues that have been resolved 
in the 11.x series but nothing noted yet for any future 10.4.x releases.   
Perhaps there are future 10.4.x versions planned to carry forward these fixes?

I am curious to know about anyone's experience with 10.4R9 over the past few 
months.  I have DPC only currently; i.e. no MPC hardware -- and no 
MultiServices.

Thanks.



Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
___
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] Default route in OSPF NSSA

[Serge Vautour]

Hello,

I've used the following config on an MX960 to generate a default route into an 
OSPF NSSA area:

area 0.0.1.2 {
    nssa {
    default-lsa {
    default-metric 1;
    type-7;
    }
    no-summaries;
    }
}

It works but the default route shows up as an N1 type route (OSPF NSSA external 
type):

O*N1    0.0.0.0/0 [110/11] via 4.5.6.7, VLAN7, 00:01:01


When I configure what I think is the equivalent on a Cisco router running IOS 
XR it sends an O IA route (OSPF Inter Area):

O*IA    0.0.0.0/0 [110/11] via 1.2.3.4, VLAN9, 20:36:59

The AR box always prefers the O IA route over the N1 route as expected. I 
can't seem to find knobs on either box to change between N1 and O IA. 


Would anyone know how to change this in Junos?

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

Re: [j-nsp] Default route in OSPF NSSA

[Serge Vautour]

Well I'm almost certain I had tried that and it had just stopped advertising a 
default all together. It's working now:

nssa {
    default-lsa default-metric 1;
    no-summaries;
}

Thanks,Serge



 From: Harry Reynolds ha...@juniper.net
To: Serge Vautour se...@nbnet.nb.ca; juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net 
Sent: Thursday, May 10, 2012 1:14:52 PM
Subject: Re: [j-nsp] Default route in OSPF NSSA
 
IIRC, the juni will send a type 3 network summary if you remove the type-7 
statement, which is forcing it to generate a NSSA type 7 external for the 
default.

HTHs




-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serge Vautour
Sent: Thursday, May 10, 2012 8:57 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Default route in OSPF NSSA

Hello,

I've used the following config on an MX960 to generate a default route into an 
OSPF NSSA area:

area 0.0.1.2 {
    nssa {
    default-lsa {
    default-metric 1;
    type-7;
    }
    no-summaries;
    }
}

It works but the default route shows up as an N1 type route (OSPF NSSA external 
type):

O*N1    0.0.0.0/0 [110/11] via 4.5.6.7, VLAN7, 00:01:01


When I configure what I think is the equivalent on a Cisco router running IOS 
XR it sends an O IA route (OSPF Inter Area):

O*IA    0.0.0.0/0 [110/11] via 1.2.3.4, VLAN9, 20:36:59

The AR box always prefers the O IA route over the N1 route as expected. I 
can't seem to find knobs on either box to change between N1 and O IA. 


Would anyone know how to change this in Junos?

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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500

[Serge Vautour]

We have an MX960 running 10.4R7 with the same problem. What's worse is the 
error has been logging every 5-10min ever since we made the change ~3 months 
ago. JTAC case hasn't resulted in anything useful yet. It's still open.


Serge




 From: Jonathan Lassoff j...@thejof.com
To: Alex D. listensamm...@gmx.de 
Cc: Juniper-Nsp juniper-nsp@puck.nether.net 
Sent: Tuesday, May 8, 2012 3:14:35 PM
Subject: Re: [j-nsp] /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500
 
On Tue, May 8, 2012 at 10:58 AM, Alex D. listensamm...@gmx.de wrote:
 Hi list,

 i manually set IPv6 mtu to 1500 on M- an MX-Series routers running JunOS
 10.4R8.5
 After configuration, following message appears in syslog:
 /kernel: %KERN-6: MTU for ff02::0005 reduced to 1500

 Is it a problem or why does the router inform about the change ?
 Whith manually set IPv4 MTU, there are no such messages in the logfile.

I would presume this is just a new codepath, and some logging was
added into the kernel.

To me, logging MTU changes on interfaces seems prudent and useful.
___
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] mx240 vs asr 9006

[Serge Vautour]

Note that the MX requires an MS-DPC card in order to to NetFlow v9.

Serge



 From: Doug Hanks dha...@juniper.net
To: Peter piotr.1...@interia.pl; juniper-nsp@puck.nether.net 
juniper-nsp@puck.nether.net 
Sent: Tuesday, April 24, 2012 1:41:24 PM
Subject: Re: [j-nsp] mx240 vs asr 9006
 
The last time I looked the ASR9K still had a small FIB and tapped out at
around 500K.

Thank you,

-- 
Doug Hanks - JNCIE-ENT #213,  JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 4/24/12 8:55 AM, Peter piotr.1...@interia.pl wrote:

Hi

I have to upgrade my bgp routers, i have budget for two options:

1.
- bundle: MX240BASE-AC-HIGH, MPC1-3D-R-B, MIC-3D-20XGE-SFP,
MIC-3D-2XGE-XFP; configurable RE, SCB, and PEM
- better routing engine RE-S-1800X2-8G-UPG-BB + jflow license ( netflow
v9 or ipfix) S-ACCT-JFLOW-IN

or

2. asr 9006
- A9K-RSP-4G
- A9K-MOD80-TR, 80G Modular Linecard, Packet Transport Optimized
- license for l3 vpn

the price is almost the same. I need:

- ports: from  4x10G line to  max 8x10G, line rate
- 3 virtual routers with full ip routing table v4
- 10 virtual routers with ca 10k prefix in routing table v4
- v6
- up to 12 full bgp feed
- netflow v9 or ipfix, sampling max 100/s
- define counters on logical and physical interfaces, count many times
to the same counter, one packet could be count to different counters in
next term
- access to counters via snmp
- independent control plane and data plane
- and few others things on bgp edge

which model will be better ?
thanks for some advice

regards
Peter

___
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] DSCP classifier on CCC interface

[Serge Vautour]

Hello,

I was testing this on a DPC card in an MX960. That link helps. It's not the 
news I wanted to hear but it helps.

Thanks,
Serge




 From: Addy Mathur addy.mat...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Tuesday, March 20, 2012 11:49:40 AM
Subject: 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
___
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 Vautour]

pbit based classifiers work fine, I've used them before. The problem is the 
traffic will be untagged and therefore I wanted to use DSCP/ToS. I found a 
similar reference in the 11.2 release notes for DPC cards. It's not ideal but 
at least I know why it doesn't work.

Thanks -Serge



 From: Leigh Porter leigh.por...@ukbroadband.com
To: Addy Mathur addy.mat...@gmail.com; Serge Vautour se...@nbnet.nb.ca 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Tuesday, March 20, 2012 1:59:41 PM
Subject: RE: [j-nsp] DSCP classifier on CCC interface
 
Therefore, you do not have to depend on the underlying Layer 2 QoS support.

So it sounds as though is the layer 2 QoS field is there you can use that.

--
Leigh



 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Addy Mathur
 Sent: 20 March 2012 14:58
 To: Serge Vautour
 Cc: juniper-nsp@puck.nether.net
 Subject: 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
 
 __
 This email has been scanned by the Symantec Email Security.cloud
 service.
 For more information please visit http://www.symanteccloud.com
 __

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] DSCP classifier on CCC interface

[Serge Vautour]

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

Re: [j-nsp] QOS (Network Control traffic Queue)

[Serge Vautour]

Hello,

Folks can correct me if I'm wrong but I'll take a shot at this.

By default Junos assigns traffic generated by the RE to different queues based 
on the traffic type:

http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-cos/id-10346810.html#id-10346810

It's not very clear on that page but traffic generated in Queue 3 will get 
proper ToS markings applied. Here's an OSPF packet capture:

me@blah monitor traffic interface xe-0/0/0 no-resolve size 1500 detail 
Address resolution is OFF.
Listening on xe-0/0/0, capture size 1500 bytes

16:04:41.745098 Out IP (tos 0xc0, ttl   1, id 21968, offset 0, flags [none], 
proto: OSPF (89), length: 84) 10.1.1.1  224.0.0.5: OSPFv2, Hello, length 48

Note the ToS value is 0xC0 = 1100  - The ToS field = 110 = 6.


There are default IP classifiers applied to all L3 interfaces. For example, 
here are the defaults for an MPLS interface:

me@blah show class-of-service interface xe-0/0/0 
Physical interface: xe-0/0/0, Index: 154
Queues supported: 8, Queues in use: 8
  Scheduler map: default, Index: 2
  Congestion-notification: Disabled

  Logical interface: xe-0/0/0.0, Index: 2684275768
    Object  Name   Type    Index
    Rewrite exp-default    exp (mpls-any) 33
    Classifier  exp-default    exp    10
    Classifier  ipprec-compatibility   ip 13

The default IP classifier:

me@blah show class-of-service classifier type inet-precedence name 
ipprec-compatibility 
Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 13
  Code point Forwarding class    Loss priority
  000    best-effort low 
  001    best-effort high    
  010    best-effort low 
  011    best-effort high    
  100    best-effort low 
  101    best-effort high    
  110    network-control low 
  111    network-control high 


As you can see pbit 6 traffic goes to the NC queue. The default schedulers 
applies to the interface:

me@blah show class-of-service scheduler-map    
Scheduler map: default, Index: 2

  Scheduler: default-be, Forwarding class: best-effort, Index: 21
    Transmit rate: 95 percent, Rate Limit: none, Buffer size: 95 percent, 
Buffer Limit: none, Priority: low
    Excess Priority: low
    Drop profiles:
  Loss priority   Protocol    Index    Name
  Low any 1    default-drop-profile  
  Medium low  any 1    default-drop-profile    
  Medium high any 1    default-drop-profile  
  High    any 1    default-drop-profile    

  Scheduler: default-nc, Forwarding class: network-control, Index: 23
    Transmit rate: 5 percent, Rate Limit: none, Buffer size: 5 percent, Buffer 
Limit: none, Priority: low
    Excess Priority: low
    Drop profiles:
  Loss priority   Protocol    Index    Name
  Low any 1    default-drop-profile  
  Medium low  any 1    default-drop-profile    
  Medium high any 1    default-drop-profile  
  High    any 1    default-drop-profile    



Note that 5% is assigned to NC making sure that RE traffic always has a minimum 
BW %.

I'm note sure why you'd want to change this. You obviously want to add other 
Queues and assign BW % as required. Just make sure you always leave pbit 6 
mapped to NC FC (queue 3) and leave some BW assigned to it. I wouldn't re-map 
RE traffic from Queue 3 to some other queue. In Junos (the MX anyway) the queue 
number as no meaning so there's no reason to move NC from queue 3 to some other 
queue.

I hope this helps.
Serge




 From: MOHAMED EDREES - JNT m.edrees@mobily.com.sa
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Monday, March 12, 2012 10:28:50 AM
Subject: [j-nsp] QOS (Network Control traffic Queue)
 
Dear Experts



    As known in juniper routers the network control traffic by default will be 
queued in the default queue # 3 which by default called network-control, my 
questions are



How this forwarding will be forwarded to the queue without applying and 
classifier on the control plane or even in interface fxp1?



Another question which will depend on the answer of the first one



If we modified the queues to carry different code points as shown below, will 
the control traffic such as BGP messages will follow these changes or it will 
go to the default queue # 3 without 

[j-nsp] MPLS Core QoS

[Serge Vautour]

Hello,

Would folks be willing to share their MPLS Core QoS model? We use R cards for 
Core links leaving us with 8 Forwarding Classes (FC)  8 Queues (1-1 
relationship). We decouple the services from the FC. There's only 8 FC so each 
service can't get dedicated FCs. We dedicate the NC FC for the routing 
protocols leaving 7 Q.


What I'm really interested in is how people handle scheduling. There seems to 
be 2 things you can tune:

-BW % allocation (transmit-rate)

-Priority (low, medium-low, medium-high, high, strict-high)

If you keep the same priority on each FC, each Q gets the minimum allocated BW 
assigned by the %. Excess is shared differently depending on card type or 
tuning. If you set different priority for each Q, the % doesn't seem to do 
much. Which model do you use? Do you use Priority? If not, how do you allocate 
BW to each Q?


And finally, do you use WRED? In every Q or just some?

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

Re: [j-nsp] VPLS Between 2 Routers

[Serge Vautour]

If you just want 2 end points, an L2VPN would be much simpler to setup. This 
works for me:

interfaces {
    ge-1/0/2 {
    mtu 9192;
    encapsulation ethernet-ccc;
    unit 0;
    }
}
routing-instances {
    TEST {
    instance-type l2vpn;
    interface ge-1/0/2.0;
    vrf-target target:123:987700;
    protocols {
    l2vpn {
    encapsulation-type ethernet;
    no-control-word;
    site site1 {
    site-identifier 1;
    interface ge-1/0/2.0;
    }
    }
    }
    }
}

This is completely transparent. Any valid ethernet frame with/without a dot1q 
tag will go through.

Once you add the interface to your site, your config looks similar. Try adding 
the vlan-id all knob under the RI.

Serge







 From: David Ball davidtb...@gmail.com
To: Craig Whitmore len...@orcon.net.nz 
Cc: juniper-nsp@puck.nether.net 
Sent: Thursday, March 1, 2012 8:55:30 PM
Subject: Re: [j-nsp] VPLS Between 2 Routers
 
  Try adding the interface (ge-0/0/7.0) under the 'site' definition in the
routing instance config.it's required, as far as I know.  The rest
looks pretty familiar.

David


On 1 March 2012 17:06, Craig Whitmore len...@orcon.net.nz wrote:

 Hi there

 I am pretty new to MPLS but what I'm trying to do is set up a L2 Tunnel
 between 2 Routers  via VPLS. The idea is the customer can plug a TRUNK port
 at both ends and run whatever VLANS they want between them . Maybe there is
 a easier way to do it. There are LOTS of examples in LOTS of different
 places on how VPLS should be set up and all are slightly different. I
 cannot
 get any data thru the VPLS connection..

 The set up is 2 Juniper Routers running OSPF between them and then BGP
 between the Loopbacks also running MPLS/LDP etc

 The Config is (the same on both ends basically)

 ge-0/0/7 {
    description VPLS;
    per-unit-scheduler;
    encapsulation ethernet-vpls;
    unit 0 {
        family vpls;
    }
 }

 VPLS-Customer {
    instance-type vpls;
    interface ge-0/0/7.0;
    route-distinguisher X:2000;  (XX:1000 on other side).. ( =
 the AS number)
    vrf-target target:X:100;
    protocols {
        vpls {
            site-range 10;
            no-tunnel-services;
            site router-2000 {
                site-identifier 5; (different on both sides)
            }
        }
    }
 }


 Debug..

 # show vpls connections  extensive

 Instance: VPLS-Customer
  Local site: router-2000 (5)
    Number of local interfaces: 1
    Number of local interfaces up: 1
    IRB interface present: no
    ge-0/0/7.0
    lsi.1049090         6         Intf - vpls VPLS-Customer local site 5
 remote site 6
    Label-base        Offset     Size  Range     Preference
    262153            1          8      8         100
    connection-site           Type  St     Time last up          # Up trans
    6                         rmt   Up     Mar  2 11:32:17 2012           1
      Remote PE: Y.Y.Y.Y, Negotiated control-word: No (Y.Y.Y.Y = Loopback of
 other router)
      Incoming label: 262158, Outgoing label: 262165
      Local interface: lsi.1049090, Status: Up, Encapsulation: VPLS
        Description: Intf - vpls VPLS-Customer local site 5 remote site 6
    Connection History:
        Mar  2 11:32:17 2012  status update timer
        Mar  2 11:32:17 2012  loc intf up                  lsi.1049090
        Mar  2 11:32:17 2012  PE route changed
        Mar  2 11:32:17 2012  Out lbl Update                    262165
        Mar  2 11:32:17 2012  In lbl Update                     262158
        Mar  2 11:32:17 2012  loc intf down


 #show bgp summary instance VPLS-Customer

 Groups: 0 Peers: 0 Down peers: 0
 Table          Tot Paths  Act Paths Suppressed    History Damp State
 Pending
 VPLS.l2vpn.0           1          1          0          0          0
 0

 # show bgp summary.

 Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last
 Up/Dwn State|#Active/Received/Accepted/Damped...
 Y.Y.Y.Y           56030       6057       4657       0       0 1d 11:40:03
 Establ (Y.Y.Y.Y = IP Address of other routers loopback)
  inet.0: 2/5156/2/0
  inet.2: 0/0/0/0
  bgp.l2vpn.0: 1/1/1/0
  bgp.l3vpn.0: 0/0/0/0
  VPLS-Customer.l2vpn.0: 1/1/1/0






 ___
 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] 10.4R9 on MX stable?

[Serge Vautour]

We've had it loaded in the lab for a week now. Nothing seems broken yet. We're 
still testing.

Serge



 From: Paul Stewart p...@paulstewart.org
To: juniper-nsp@puck.nether.net 
Sent: Friday, February 17, 2012 12:18:02 PM
Subject: [j-nsp] 10.4R9 on MX stable?
 
Hey there.



We need to upgrade from our 10.0R3.10 releases on MX platform.  Up until a
month ago we were ready to roll to recommended release 10.4R8 and well, we
know that wasn't exactly a perfect solution ;)



Has anyone got 10.4R9 running on MX platform in production yet?  I'm looking
for any feedback as JTAC is recommending we go to this release.



Thanks,



Paul



___
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] Mounting MX80 at an angle

[Serge Vautour]

Hello,

Has anyone ever rack mounted an MX80 or a similar sized router at an angle 
before? Any reason why this isn't a good idea? Could it have an impact on the 
electrical components? 

We've run into alot of COs where we could save money by installing them at an 
angle. Existing racks aren't big enough and we've had to buy complete new racks 
which drives up the costs. Our guys have found angled brackets that would work.

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

Re: [j-nsp] Mounting MX80 at an angle

[Serge Vautour]

I don't mean angled side-side, I mean angles front-back. So the back end would 
be lower than the front end. After mounting, if you stood in front of the MX, 
the front plate would be pointing towards the ceiling a bit instead of 
horizontally.

Serge




 From: Justin M. Streiner strei...@cluebyfour.org
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Thursday, February 16, 2012 1:22:34 PM
Subject: Re: [j-nsp] Mounting MX80 at an angle
 
On Thu, 16 Feb 2012, Serge Vautour wrote:

 Has anyone ever rack mounted an MX80 or a similar sized router at an angle 
 before? Any reason why this isn't a good idea? Could it have an impact on the 
 electrical components?

I'm not entirely sure what you mean by mounting at an angle.  Do you have any 
pictures/examples?

jms
___
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 Vautour]

We do. It's standard on all our interfaces:

myuser@MYPE1-re0 show configuration protocols ospf area 0 interface xe-0/0/0 
interface-type p2p;
metric 100;
ldp-synchronization;


Serge




 From: Addy Mathur addy.mat...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Wednesday, February 15, 2012 10:54:29 AM
Subject: 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] Random BGP peer drops

[Serge Vautour]

Our NMS gets CPU  Mem usage on both REs on the RR every 5min. The graphs don't 
show anything abnormal. CPU usage is 5% on both RE and Mem is 25%.

Serge




 From: David Ball davidtb...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca 
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net 
Sent: Tuesday, February 14, 2012 4:47:41 PM
Subject: Re: [j-nsp] Random BGP peer drops
 
  I saw something similar on a T-series w/2 REs running 10.0, and it
was related to an NSR bug that was causing the backup RE to thrash and
push CPU through the roof on the primary.  Also recall a mib2d bug
resulting in high CPU, though I'm sure you would have noticed in
either case.

David


On 14 February 2012 15:31, Serge Vautour sergevaut...@yahoo.ca wrote:
 Yes. That was the first thing we checked. I should've mentioned that.


 Serge



 
  From: sth...@nethelp.no sth...@nethelp.no
 To: se...@nbnet.nb.ca; sergevaut...@yahoo.ca
 Cc: juniper-nsp@puck.nether.net
 Sent: Tuesday, February 14, 2012 3:41:02 PM
 Subject: Re: [j-nsp] Random BGP peer drops

 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.

 Have you verified that you have a consistent MTU throughout your net?

 Steinar Haug, Nethelp consulting, sth...@nethelp.no
 ___
 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] MX960 Redundant RE problem

[Serge Vautour]

You can also run the following command on the backup RE to check it's state:

me@BLAH-re1 show system switchover 
Graceful switchover: On
Configuration database: Ready
Kernel database: Ready
Peer state: Steady State


If this command and show task replication on the master RE don't show the 
correct outputs, I agree with the recommendation to turn GRES/NSR on/off. If 
that doesn't work, reboot REs.


Serge




 From: Mohammad masal...@gmail.com
To: juniper-nsp@puck.nether.net 
Sent: Wednesday, February 15, 2012 6:44:42 AM
Subject: Re: [j-nsp] MX960 Redundant RE problem
 
Kindly find the following output, I hope it is helpful
x show task replication 
        Stateful Replication: Enabled
        RE mode: Master

    Protocol                Synchronization Status
    OSPF                    Complete              
    BGP                     Complete              
    IS-IS                   Complete              
    MPLS                    Complete              
    RSVP                    Complete              

{master}



___
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] Random BGP peer drops

[Serge Vautour]

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

Re: [j-nsp] Random BGP peer drops

[Serge Vautour]

Yes. That was the first thing we checked. I should've mentioned that.


Serge




 From: sth...@nethelp.no sth...@nethelp.no
To: se...@nbnet.nb.ca; sergevaut...@yahoo.ca 
Cc: juniper-nsp@puck.nether.net 
Sent: Tuesday, February 14, 2012 3:41:02 PM
Subject: Re: [j-nsp] Random BGP peer drops
 
 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.

Have you verified that you have a consistent MTU throughout your net?

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RAD Data Mirici-155 SFP OC3 in MX?

[Serge Vautour]

Hello,

Are you using the FE or GE version? We are using the GE version as we couldn't 
get the FE version to work. The GE ones are a little more expensive but we were 
left with no choice. You do have to disable autoneg on the MX.

We have these working on MX960 and MX80 10.4S5.

  4 GIGE 1000LX10 SM    LambdaGain L04A-1EXT155G 1310 nm 


This particular one is in a DPC 40x1G card. The other end is in an MX80 20x1G 
MIC. Since it works in an MX80, it should work in a MPC card as well.


Our supplier per-configures all the SFP parameters we want so we don't have to 
change them ourselves. For this reason we haven't enabled inband mgmt. I can 
send you a list of parameters we use if you want. Try it back-back before going 
over your transport system. As long as you have the same parameters on both 
sides, you should be OK.

Serge




 From: Dave hartzell hartz...@gmail.com
To: juniper-nsp@puck.nether.net 
Sent: Wednesday, February 8, 2012 5:14:36 PM
Subject: [j-nsp] RAD Data Mirici-155 SFP OC3 in MX?
 
Hello,

I have been trying to get a RAD Data Communications Mirici-155 SFP to
work in an MX-series box.

The Mirici-155 is an SFP-compatible OC-3 plug-able optic that looks
and feels like an Ethernet SFP to the switch or router, except it
takes Ethernet frames and encapsulates them in GFP for SONET delivery
over a WAN.  A small, onboard server allows for configuration of
various SONET and Ethernet parameters via HTTP.  The device is much,
much cheaper than POS and works well (when it works).

This SFP works fine in EX, M-series and Cisco switches, but not the MX
(at least not the MX240 I have).  The MX sees the SFP, and everything
looks normal, but we cannot ping the server-agent on the SFP, or pass
frames through the device to a known working far-side.  STP is
disabled.  LLDP/CDP frames won't pass either.

I'm curious if anyone else has experience with these devices, and if
there are some trace or monitor options I can look at to try to figure
this out...

Thanks!

Dave
___
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] aggregated-ethernet and metric adjustment, if one link fails

[Serge Vautour]

Hello,

There is a minimum member option in LAG links which will allow you to shutdown 
the whole bundle if 1 member fails.

If you just want to increase metrics when 1 interface fails, you can do that 
with an event-script. Here's an example for OSPF. Adjust as required.

Serge

version 1.0;

ns junos = http://xml.juniper.net/junos/*/junos;;
ns xnm = http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = http://xml.juniper.net/junos/commit-scripts/1.0;;

import ../import/junos.xsl;

/*
 * Increase OSPF cost when interface goes Down.

 * Note: This script only works when OSPF interfaces use unit 0 and with area 0.

 * Version 2: Updated to allow 2 instances to be called simultaneously

*/

var $arguments = {
   argument {
  name interface;
  description Interface to lower cost;
   }
   argument {
  name metric;
  description New OSPF metric;
   }
}

var $area = 0.0.0.0;

/* Decides where the output will go, 0 - stdout, 1 - syslog, 2 - none */
var $silent = 1;

var $maxattempts = 5; /* Number of times to try before giving up */

match / {

   /*
    * xml config to set interface metric
   */

   var $xml = {
    configuration {
  protocols {
  ospf {
  area {
  name$area;
  interface {
  name$interface;
  metric$metric;
  }
  }   
  }
  }
    }
   }
   var $attempt = 1;
   call doConfigChange($xml, $attempt);


}

template doConfigChange($xml, $attempt) {
   /*
    * Open connection with mgd
    */
    var $con = jcs:open();

    if (not($con)) {
   call emit-error($message = Not able to connect to local mgd);
    }
    var $config-private = open-configuration {
   private;
    }
    var $private-results = jcs:execute($con, $config-private);
    var $load-configuration = load-configuration {
   copy-of $xml;
    }

   var $load-results = jcs:execute($con, $load-configuration);
  /*
   * Use load-configuration template defined in junos.xsl to load and
   * commit the configuration
   */

   var $commit-configuration = commit-configuration;
   var $commit-results = jcs:execute($con, $commit-configuration);

   /* Keep trying if we get an error while committing. This could be because 
another
    * instance of the script is committing.
   */

   if( $attempt  $maxattempts ) {
 /* Give up */

 for-each ($commit-results//xnm:error) {
    call emit-error($message = message);
 }

 var $giveupmessage = ChangeOSPFMetric.slax configuration changes could 
not be made after  _ $attempt _  attempts. - Script is exiting.;
 expr jcs:syslog(user.error, ChangeOSPFMetric.slax[Error]: , 
$giveupmessage);
   } 
   else {
 /* if we have an error, wait 10sec, increment attempts and perform 
recursive call to try again */
 if ($commit-results//xnm:error) {
   var $error-msg = configuration change failed, a user may be editing the 
config or the script attempted to load a bad config.  Configuration change 
error info follows -  _ $commit-results _  - trying again in 10 seconds . . . 
;
   expr jcs:syslog(5, $error-msg);
   expr jcs:sleep(10);
   call doConfigChange($xml, $attempt = $attempt + 1 );  
 } 
 else {
  call emit-success($message = Changed Metric);

  for-each ($commit-results//xnm:warning) {
   call emit-warn($message = message);
  }

 } /* end if commit-results */
   }  /* end if attempt statement */

   var $close-private = close-configuration;
   var $close-configuration-results = jcs:execute($con, $close-private);
   var $close-results = jcs:close($con);
}


template emit-success($message) {

   if ($silent == 0) {
  expr jcs:output($message);
   } else if ($silent == 1) {
  expr jcs:syslog(user.info,ChangeOSPFMetric.slax[Success]: , $message);
   }
}
 
template emit-error($message) {

   if ($silent == 0) {
  expr jcs:output($message);
   } else if ($silent == 1) {
  expr jcs:syslog(user.error, ChangeOSPFMetric.slax[Error]: , $message);
  }
}

template emit-warn($message) {

   if ($silent == 0) {
  expr jcs:output($message);
   } else if ($silent == 1) {
  expr jcs:syslog(user.warning, ChangeOSPFMetric.slax[Warning]: , 
$message);
   }
}


Config to activate the script:

event-options {
    policy TrackCoreInt {
    events snmp_trap_link_down;
    attributes-match {
    snmp_trap_link_down.interface-name matches (xe-0/0/0)|(xe-0/1/0);
    }
    then {
    execute-commands {
    commands {
    show interfaces {$$.interface-name};
    show conf interfaces {$$.interface-name};
    show conf protocols ospf;
    }
    output-filename TrackCore_show_commands.txt;
    destination local;
    

Re: [j-nsp] MX VPLS Trunk with VLAN rewriting

[Serge Vautour]

Hello,

Have you tried building this up from a very simple setup that works and adding 
complexity as you go? I've done something like this with the vlan-id all 
before but not with the VLAN tag manipulations at the same time.

The first thing that looks odd to me is the input-vlan map. Why do you need it? 
Swap on egress should be enough. Another thing I'm not sure about is both 
sub-interfaces in the same site. I'd put them in separate sites. 


Try making this work by using the same VLAN on both ends, then add the VLAN 
manipulation. I've got something that looks almost exactly the same as this in 
my lab and it works:


interfaces {
  ae2 {
    unit 100 {
  encapsulation vlan-vpls;
  vlan-id 100;
  }
    unit 301 {
  encapsulation vlan-vpls;
  vlan-id 301;
  }
}

routing-instances {
  test-service {
  instance-type vpls;
  vlan-id all;
  interface ae2.100;
  interface ae2.301;
  vrf-target target:65000:10003;
  protocols {
  vpls {
  no-tunnel-services;
  site vlan100 {
  site-identifier 1;
  interface ae2.100;
  }
  site vlan301 {
  site-identifier 2;
  interface ae2.301;
  }
  }
  }
  }
}


Use the same config on both ends, update the site-IDs to make all 4 unique.


If you get this working, start adding the egress swap. I am having trouble 
reasoning how it will work. The box needs a way to know what traffic to 
associate to which sub-interface. I don't think it can do that in this case. 


I hope that helps.

Serge





 From: Sebastian Wiesinger juniper-...@ml.karotte.org
To: Juniper NSP juniper-nsp@puck.nether.net 
Sent: Thursday, December 22, 2011 10:34:43 AM
Subject: [j-nsp] MX VPLS Trunk with VLAN rewriting
 
Hi,

I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.

Example:

      Site 1   VPLS   Site 2
LAN1: vl100       vl10        vl200
LAN2: vl301       vl11        vl201


I did the following config:

Site1:
interfaces {
  ae2 {
    unit 100 {
      encapsulation vlan-vpls;
      vlan-id 100;
      input-vlan-map {
          swap;
          vlan-id 10;
      }
      output-vlan-map swap;
  }
    unit 301 {
      encapsulation vlan-vpls;
      vlan-id 301;
      input-vlan-map {
          swap;
          vlan-id 11;
      }
      output-vlan-map swap;
  }
}

routing-instances {
  test-service {
      instance-type vpls;
      vlan-id all;
      interface ae2.100;
      interface ae2.301;
      vrf-target target:65000:10003;
      protocols {
          vpls {
              no-tunnel-services;
              site local-ce {
                  site-identifier 1;
                  interface ae2.100;
                  interface ae2.301;
              }
              mac-flush {
                  any-interface;
              }
          }
      }
  }
}


Site2:

interfaces {
  ae2 {
    unit 200 {
      encapsulation vlan-vpls;
      vlan-id 200;
      input-vlan-map {
          swap;
          vlan-id 10;
      }
      output-vlan-map swap;
  }
    unit 201 {
      encapsulation vlan-vpls;
      vlan-id 201;
      input-vlan-map {
          swap;
          vlan-id 11;
      }
      output-vlan-map swap;
  }
}

routing-instances {
  test-service {
      instance-type vpls;
      vlan-id all;
      interface ae2.200;
      interface ae2.201;
      vrf-target target:65000:10003;
      protocols {
          vpls {
              no-tunnel-services;
              site local-ce {
                  site-identifier 2;
                  interface ae2.200;
                  interface ae2.201;
              }
              mac-flush {
                  any-interface;
              }
          }
      }
  }
}


When I try to commit this config I get an error:

[edit routing-instances test-service interface]
  'ae2.100'
    interface with input/output vlan-maps cannot be added to a routing-instance 
with a vlan-id/vlan-tags configured

JunOS version is 11.2R4

When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.

Any idea what to do? Our Juniper consultant said it would be possible
to do this.

Regards

Sebastian

-- 
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
            -- Terry Pratchett, The Fifth Elephant
___
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] IP/MPLS fast convergence

[Serge Vautour]

Hello,

We did started a greenfield deployment 2 years ago. We had no requirement for 
FRR and stayed clear of RSVP. We did implement LDP + OSPF LFA since it was just 
an extra knob and gave us something for free. We used Link Protection.


The caveat with LFA is that it will not protect 100% of your paths. A given 
link failure may re-route some of your traffic via LFA while the rest has to 
wait for standard OSPF convergence. WANDL did some LFA coverage analysis for us 
and if I remember correctly based on our topology we have ~70% of paths covered.


I ran some tests on our Prod network before it went live. LFA did in fact allow 
sub-50ms convergence. For paths that weren't covered by LFA in a worst case 
scenario, I got about 300ms. Not too bad. Junos seems really fast at converging 
even without LFA. We use MX960s and MX80s.

I hope this helps.

Serge




 From: Amos Rosenboim a...@oasis-tech.net
To: juniper-nsp@puck.nether.net 
Sent: Wednesday, December 21, 2011 2:34:22 PM
Subject: [j-nsp] IP/MPLS fast convergence
 
Hello All,

I'm planning a greenfield IP/MPLS network for a mobile operator.
The requirements are to support MPLS services (mainly L3 VPNs but also some 
VPLS), enforce  strict but fairly simple CoS model, and support fast 
convergence.
No requirement for CSPF based TE.

Traditionally I'de set single hop RSVP LSPs (from access/edge) to core just for 
the sake of FRR, and tunnel LDP inside these LSPs.
This way I would get FRR without the burden of full mesh RSVP LSPs.

However in the last two years I read more and more about LFA, IP/LDP FRR and 
similar technologies.

I'm considering to drop RSVP in favor of LFA and LDP, but was wondering if 
anyone is actually using this in the field, if so what is the impression.

Regards

Amos


___
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] RE : MX80 MIC won't come online

[Serge Vautour]

Hello,

I suppose I didn't include what was obvious to me. The Junos version is 10.2S6. 
The MIC is a 20x1G (MIC-3D-20GE-SFP). We have a few other MX80s in Prod all 
running the same Junos version and using the same MIC. The MIC does not show up 
under show chassis hardware. The lab box we tried happened to be on 10.4R4. 
We 
tried is to prove that the MIC itself was good, not to prove the software.

Thanks,
Serge



- Original Message 
From: Stéphane Grosjean stephane.grosj...@telindus.fr
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Tue, June 21, 2011 5:27:08 AM
Subject: [j-nsp] RE : MX80 MIC won't come online

Hello,


I assume you have checked your JunOS version? Please give us what MIC it is and 
JunOS you're running.


Kind Regards,


Stephane

Hello,

We're trying to turn up a new MIC in an MX80. The MIC has been inserted in slot
1 and the box sees it:

user@box show chassis fpc pic-status
Slot 0   Online
  PIC 0  Online   4x 10GE XFP
Slot 1   Online
  PIC 0  Online   10x 1GE(LAN) SFP
  PIC 1  Online   10x 1GE(LAN) SFP
  PIC 2  Offline
  PIC 3  Offline

There are also log entries for FRU insertion. When we try to online to card we
get:

user@box request chassis mic fpc-slot 1 mic-slot 1 online
FPC 1, MIC 1 is empty

We tried the new MIC in another MX80 and it comes up fine. Any suggestions 
other
than a bad slot?
___
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] RE : MX80 MIC won't come online

[Serge Vautour]

LOL - Yes :)

Serge



- Original Message 
From: Chris Evans chrisccnpsp...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Tue, June 21, 2011 8:51:55 AM
Subject: Re: [j-nsp] RE : MX80 MIC won't come online

Jtac case opened?
On Jun 21, 2011 7:44 AM, Serge Vautour sergevaut...@yahoo.ca wrote:
 Hello,

 I suppose I didn't include what was obvious to me. The Junos version is
10.2S6.
 The MIC is a 20x1G (MIC-3D-20GE-SFP). We have a few other MX80s in Prod
all
 running the same Junos version and using the same MIC. The MIC does not
show up
 under show chassis hardware. The lab box we tried happened to be on
10.4R4. We
 tried is to prove that the MIC itself was good, not to prove the software.

 Thanks,
 Serge



 - Original Message 
 From: Stéphane Grosjean stephane.grosj...@telindus.fr
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Sent: Tue, June 21, 2011 5:27:08 AM
 Subject: [j-nsp] RE : MX80 MIC won't come online

 Hello,


 I assume you have checked your JunOS version? Please give us what MIC it
is and
 JunOS you're running.


 Kind Regards,


 Stephane

Hello,

We're trying to turn up a new MIC in an MX80. The MIC has been inserted in
slot
1 and the box sees it:

user@box show chassis fpc pic-status
Slot 0 Online
 PIC 0 Online 4x 10GE XFP
Slot 1 Online
 PIC 0 Online 10x 1GE(LAN) SFP
 PIC 1 Online 10x 1GE(LAN) SFP
 PIC 2 Offline
 PIC 3 Offline

There are also log entries for FRU insertion. When we try to online to
card we
get:

user@box request chassis mic fpc-slot 1 mic-slot 1 online
FPC 1, MIC 1 is empty

We tried the new MIC in another MX80 and it comes up fine. Any suggestions

 other
than a bad slot?
 ___
 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


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

Re: [j-nsp] RE : MX80 MIC won't come online

[Serge Vautour]

We have support. I just find a often get a better and quicker response from 
this 
list. 


FYI: We have gotten this to work. We had to push the button on the MIC using a 
paper clip to reset it. We were then able online the PIC with the software 
command. Must be a bug!

Serge



- Original Message 
From: Chris Evans chrisccnpsp...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Tue, June 21, 2011 10:37:53 AM
Subject: Re: [j-nsp] RE : MX80 MIC won't come online

Just making sure. A lot of folks rely on others in forums vs the vendor. We
pay them for support and how will they know of problems when they aren't
reported.
On Jun 21, 2011 8:06 AM, Serge Vautour sergevaut...@yahoo.ca wrote:
 LOL - Yes :)

 Serge



 - Original Message 
 From: Chris Evans chrisccnpsp...@gmail.com
 To: Serge Vautour se...@nbnet.nb.ca
 Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Sent: Tue, June 21, 2011 8:51:55 AM
 Subject: Re: [j-nsp] RE : MX80 MIC won't come online

 Jtac case opened?
 On Jun 21, 2011 7:44 AM, Serge Vautour sergevaut...@yahoo.ca wrote:
 Hello,

 I suppose I didn't include what was obvious to me. The Junos version is
 10.2S6.
 The MIC is a 20x1G (MIC-3D-20GE-SFP). We have a few other MX80s in Prod
 all
 running the same Junos version and using the same MIC. The MIC does not
 show up
 under show chassis hardware. The lab box we tried happened to be on
 10.4R4. We
 tried is to prove that the MIC itself was good, not to prove the
software.

 Thanks,
 Serge



 - Original Message 
 From: Stéphane Grosjean stephane.grosj...@telindus.fr
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Sent: Tue, June 21, 2011 5:27:08 AM
 Subject: [j-nsp] RE : MX80 MIC won't come online

 Hello,


 I assume you have checked your JunOS version? Please give us what MIC it
 is and
 JunOS you're running.


 Kind Regards,


 Stephane

Hello,

We're trying to turn up a new MIC in an MX80. The MIC has been inserted
in
 slot
1 and the box sees it:

user@box show chassis fpc pic-status
Slot 0 Online
 PIC 0 Online 4x 10GE XFP
Slot 1 Online
 PIC 0 Online 10x 1GE(LAN) SFP
 PIC 1 Online 10x 1GE(LAN) SFP
 PIC 2 Offline
 PIC 3 Offline

There are also log entries for FRU insertion. When we try to online to
 card we
get:

user@box request chassis mic fpc-slot 1 mic-slot 1 online
FPC 1, MIC 1 is empty

We tried the new MIC in another MX80 and it comes up fine. Any
suggestions

 other
than a bad slot?
 ___
 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


 ___
 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

[j-nsp] MX80 MIC won't come online

[Serge Vautour]

Hello,

We're trying to turn up a new MIC in an MX80. The MIC has been inserted in slot 
1 and the box sees it:

user@box show chassis fpc pic-status
Slot 0   Online  
  PIC 0  Online   4x 10GE XFP
Slot 1   Online  
  PIC 0  Online   10x 1GE(LAN) SFP
  PIC 1  Online   10x 1GE(LAN) SFP
  PIC 2  Offline 
  PIC 3  Offline

There are also log entries for FRU insertion. When we try to online to card we 
get:

user@box request chassis mic fpc-slot 1 mic-slot 1 online 
FPC 1, MIC 1 is empty

We tried the new MIC in another MX80 and it comes up fine. Any suggestions 
other 
than a bad slot?

Thanks,
Serge

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

Re: [j-nsp] Commit script: xsltMaxDepth

[Serge Vautour]

Phil and I have been exchanging emails. For the benefit of the list, this 
turned 
out to be a bug in Junos. Phil says it'll be fixed in a future release. I was 
on 
10.4R4. The bug has to do with trying to issue an emit-change while the context 
is in get-chassis-inventory instead the config. As a work around, Phil 
suggested 
to bring the context back to the config by adding a for-each ($dot) before 
the 
emit-change. This worked!

Serge



- Original Message 
From: Phil Shafer p...@juniper.net
To: Serge Vautour se...@nbnet.nb.ca; Serge Vautour sergevaut...@yahoo.ca
Cc: juniper-nsp@puck.nether.net
Sent: Wed, June 1, 2011 5:21:17 PM
Subject: Re: [j-nsp] Commit script: xsltMaxDepth 

Serge Vautour writes:
I'm not a programmer but can usually find a way to code what I want. I've 
written a few basic commit  event scripts and they work. This one is getting 
very long - lots of for-each loops inside loops.

The issue isn't looping, but infinite recursion.  If a template
calls itself (or another template that calls the first), it will
hit a limit (3000 calls) that will prevent it from eating all memory
on the box.

So look at the call paths of your script to see which call is at
fault.

This is mostly because I can't 
find a way to store data in a hash in reference that data later (that's what I 
would do in perl). 

The XSLT language (and SLAX-1.0) don't allow mutable variables,
but you can build the XML equivalent of hashes by building
XML content.  For example:

var $typedefs := {
typedef name=dnsname {
match {
regex ^[a-zA-Z0-9._-]{1,255}$;
message must contain 1-255 letters, numbers and characters;
}
}
typedef name=ip-address {
match {
regex ^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}$;
message must be a valid IP address;
}
}
typedef name=ip-prefix {
match {
regex 
^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/[0-9]{1,2}$;
message must be a valid IP prefix;
}
}
}

This hash can be consulted using normal XPath expressions:

var $td = $typedefs/*[@name == $type];
if ($td  $td/match/regex) {
var $re = jcs:regex($td/match/regex, $response);
...
}

The content doesn't have to be static, like this example, but could
be build from other data.  For example, you could take the results
of the get-chassis-inventory RPC and turn them into a hash that
maps the slot number to the fpc type.

Thanks,
Phil

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

Re: [j-nsp] MX80 Opinions

[Serge Vautour]

Hello,

Would it be possible for you to share what code version you recommend for Trio? 
We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC 
cards to our MX960s and are struggling what version to go with. Continue with 
10.2 or move to 10.4? We're also planning on adding alot more MX80s.

Thanks,
Serge



- Original Message 
From: Richard A Steenbergen r...@e-gerbil.net
To: Doug Hanks dha...@juniper.net
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Thu, June 2, 2011 9:10:19 PM
Subject: Re: [j-nsp] MX80 Opinions

On Thu, Jun 02, 2011 at 04:26:54PM -0700, Doug Hanks wrote:
 Daniel,
 
 I have nothing but good things to say about the MX80.

I have almost nothing but good things to say, now that 90-95% of the 
cripling Trio-specific bugs have been worked out of the current code.

The integrated RE is probably the biggest design limitation. For 
example, we just got bit by a bad flash drive on one, which caused the 
kernel to lock up when writing to the disk. This required a physical 
power cycle to bring the box back every time it happened, left no 
evidence in the logs (so we had to catch it actually happening on 
console to know what was going on), and required a complete RMA of the 
chassis to fix. The lack of redundant REs severely limits the potential 
of this otherwise excellent little box. Oh and don't forget, a single RE 
will make your upgrade process take a lot longer too.

Juniper would really do well to introduce a 1U small/simple external RE 
which can be connected over Ethernet, to redundantize a box like the 
MX80, and to be a reasonably sized BGP route reflector.

-- 
Richard A Steenbergen r...@e-gerbil.net  http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

Re: [j-nsp] MX80 Opinions

[Serge Vautour]

Hello,

Interesting comments. We've just finished a full suite of tests on an MX960 Lab 
box running combo DPC (4x10G  40x1G) and MPC (20x1G and 2x10G MIC) on 10.4R4. 
We uncovered a few bugs during the testing. Most notable:

-DPC R-Q ports report passed + dropped traffic under show int when using a 
TCP 
with a shaper. show int queue has the correct data. Known bug.
-We use a common templates VPLS BUM policer. Normally when it's applied to 
sub-interfaces on a port, each sub-interface (VLAN) gets it's own instance and 
polices traffic independently. Under MPC cards, all VLANs share the same 
instance. JTAC case pending.

Other than that, things seem to be working OK. Thanks for the heads up.

Serge




- Original Message 
From: Mark Tinka mti...@globaltransit.net
To: juniper-nsp@puck.nether.net; Serge Vautour se...@nbnet.nb.ca
Cc: Richard A Steenbergen r...@e-gerbil.net
Sent: Fri, June 3, 2011 1:04:09 PM
Subject: Re: [j-nsp] MX80 Opinions

On Friday, June 03, 2011 11:31:51 PM Serge Vautour wrote:

 Would it be possible for you to share what code version
 you recommend for Trio? We've had a few MX80s in Prod
 with 10.2S6 for a while now. We need to add MPC cards to
 our MX960s and are struggling what version to go with.
 Continue with 10.2 or move to 10.4? We're also planning
 on adding alot more MX80s.

For the chassis-based MX's, we've generally found happiness 
in staying current for Junos 10.4 (now at 10.4R4.5). This 
has fixed random PFE crashes, FPC reboots, e.t.c., since the 
boxes shipped with 10.4R1.

We're actively staying away from Junos 11 for now.

One thing to think seriously about is whether you're going 
to run your MX's with a mixture of DPC's and MPC's. 
Depending on which features you need to turn on, you may not 
be able to boot DPC cards if you have MPC's installed as 
well.

I'd seriously suggest checking with your SE before turning 
up any features if you're going to mix DPC's and MPC's, or 
if certain features for the MPC's seem kinky. We've had 
too much pain for some items.

Cheers,

Mark.

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

[j-nsp] Commit script: xsltMaxDepth

[Serge Vautour]

Hello,

I'm getting this error when I run a commit script I've written:

re0: 
error: runtime error: file /var/db/scripts/import/junos.xsl line 100 element 
param
error: xsltApplyXSLTTemplate: A potential infinite template recursion was 
detected.
You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number 
of 
nested template calls and variables/params (currently set to 3000).

I'm not a programmer but can usually find a way to code what I want. I've 
written a few basic commit  event scripts and they work. This one is getting 
very long - lots of for-each loops inside loops. This is mostly because I can't 
find a way to store data in a hash in reference that data later (that's what I 
would do in perl). 


I had this script working by parsing an apply macro:

apply-macro slot-type {
0 dpc;
1 dpc;
7 mpc;
}

I would like to replace the macro with a get-chassis-inventory call in the 
script so that I don't have to manually update the macro when cards change. I 
have get-chassis-inventory working on it's own but when I merge it with my 
other 
script, it clearly adds to many loops when it parses every single card over and 
over. 


Can anyone suggest a way to solve the problem above? Is there a way to have a 
separate commit script to maintain the apply-macro? Is there a way to creates 
hashes in slax? I don't expect to be able to change the xsltMaxDepth.

I can post the script if someone wants to see it. Since I'm not the best 
programmer, I tend not to make my code public.

Thanks,
Serge

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

Re: [j-nsp] MX80-48T Fan Speed Variation

[Serge Vautour]

JTAC told me there wasn't. -Serge



- Original Message 
From: Bill Blackford bblackf...@gmail.com
To: juniper-nsp@puck.nether.net
Cc: Serge Vautour sergevaut...@yahoo.ca
Sent: Tue, April 5, 2011 1:42:40 PM
Subject: Re: [j-nsp] MX80-48T Fan Speed Variation

 For now, I just added a config to stop all these entries from filling up the
 logs:

file messages {
any info;
authorization info;
match !(.*CHASSISD_BLOWERS_SPEED.*);
explicit-priority;
}

As a work around, is there a way to change the water marks to trigger
the fan speed shifting at slightly higher or lower temperatures in an
attempt to have it shift less and thusly reduce the potential for
mechanical stress on the fan assembly itself?

-b

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

[j-nsp] ifAlias on sub-interfaces

[Serge Vautour]

Hello,

I'm not seeing sub-interface descriptions show up in ifAlias. Has anyone seen 
this before?


MYBOX-re0 show  interfaces ge-5/0/1  
extensive   

Physical interface: ge-5/0/1, Enabled, Physical link is Up
  Interface  index: 210, SNMP ifIndex: 507, Generation: 257
  Description:  [BLAH1][BLAH2][BLAH3]
 
If I walk ifAlias  for this SNMP ID:
 
[me@vmrancid-ngn-nb00s0 ~]$ snmpwalk -v 2c -c string 10.10.10.10 
.1.3.6.1.2.1.31.1.1.1.18.507
IF-MIB::ifAlias.507 = STRING: [BLAH1][BLAH2][BLAH3]
 
Now a  sub-interface:
 
MYBOX-re0 show  interfaces ge-5/0/1.2 extensive  
  Logical interface ge-5/0/1.2 (Index 123)  (SNMP ifIndex 646) (Generation 412)
Description:  [Sub1][Sub2][Sub3]
 
If I walk it's  ifIndex:
 
[me@vmrancid-ngn-nb00s0 ~]$ snmpwalk -v 2c -c string 10.10.10.10 
.1.3.6.1.2.1.31.1.1.1.18.646
IF-MIB::ifAlias.646 = STRING: 

Is this a bug in Junos? Is there some other MIB Juniper stores this in?

Thanks,
Serge



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

Re: [j-nsp] ifAlias on sub-interfaces

[Serge Vautour]

Sorry about missing the details! I'm seeing this on 10.2S6. I've continued to 
test after sending the first post and found that it is only happening on some 
interfaces. I can't find anything yet that sets the broken interfaces apart. 
I'll continue to test and open a case with JTAC if necessary. My guess is this 
will in fact be some bug.

Serge



- Original Message 
From: Keegan Holley keegan.hol...@sungard.com
To: Chris Adams cmad...@hiwaay.net; juniper-nsp@puck.nether.net
Sent: Tue, March 15, 2011 1:16:24 PM
Subject: Re: [j-nsp] ifAlias on sub-interfaces

On Tue, Mar 15, 2011 at 11:53 AM, Chris Adams cmad...@hiwaay.net wrote:

 Once upon a time, Serge Vautour sergevaut...@yahoo.ca said:
  I'm not seeing sub-interface descriptions show up in ifAlias. Has anyone
 seen
  this before?

 No, I haven't had that problem.  You didn't say what platform, JUNOS
 version, etc. though.


I've had to look through release notes lately and I remember seeing a bunch
of bugs related to the interface polling, ifIndex and the like.  I agree
though they are all JunOS and platform specific.  Have you consulted Juniper
and/or looked at the release notes for your Junos version?


 --
 Chris Adams cmad...@hiwaay.net
 Systems and Network Administrator - HiWAAY Internet Services
 I don't speak for anybody but myself - that's enough trouble.
 ___
 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] ifAlias on sub-interfaces

[Serge Vautour]

Hello,

That work around worked! Not ideal but it'll do for now. I have a case open 
with 
JTAC. I'm seeing it in 10.2R3 and 10.2S6. 


Serge



- Original Message 
From: Andy Vance andy.va...@360.net
To: Serge Vautour se...@nbnet.nb.ca; juniper-nsp@puck.nether.net
Sent: Tue, March 15, 2011 1:52:53 PM
Subject: Re: [j-nsp] ifAlias on sub-interfaces

Serge,

I saw this same behavior in 10.2R3.10 but didn't open a JTAC case on it.
I haven't seen it since I moved to 10.2S6 but that doesn't mean it isn't
still present ;-)

My workaround for this was to edit the interface a time or two and
commit the changes, eventually the ifAlias would be populated.

Cheers,
Andy

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serge Vautour
Sent: Tuesday, March 15, 2011 9:43 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] ifAlias on sub-interfaces

Sorry about missing the details! I'm seeing this on 10.2S6. I've
continued to 
test after sending the first post and found that it is only happening on
some 
interfaces. I can't find anything yet that sets the broken interfaces
apart. 
I'll continue to test and open a case with JTAC if necessary. My guess
is this 
will in fact be some bug.

Serge



- Original Message 
From: Keegan Holley keegan.hol...@sungard.com
To: Chris Adams cmad...@hiwaay.net; juniper-nsp@puck.nether.net
Sent: Tue, March 15, 2011 1:16:24 PM
Subject: Re: [j-nsp] ifAlias on sub-interfaces

On Tue, Mar 15, 2011 at 11:53 AM, Chris Adams cmad...@hiwaay.net
wrote:

 Once upon a time, Serge Vautour sergevaut...@yahoo.ca said:
  I'm not seeing sub-interface descriptions show up in ifAlias. Has
anyone
 seen
  this before?

 No, I haven't had that problem.  You didn't say what platform, JUNOS
 version, etc. though.


I've had to look through release notes lately and I remember seeing a
bunch
of bugs related to the interface polling, ifIndex and the like.  I agree
though they are all JunOS and platform specific.  Have you consulted
Juniper
and/or looked at the release notes for your Junos version?


 --
 Chris Adams cmad...@hiwaay.net
 Systems and Network Administrator - HiWAAY Internet Services
 I don't speak for anybody but myself - that's enough trouble.
 ___
 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

___
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] Simple Script Running

[Serge Vautour]

Hello,

For example, here's a script that checks OSPF, LDP and BGP neighbors on a box 
with 1 commands.

blah@PE1-STJHLab-re0 op status-neighbors

- OSPF: There are 4 active OSPF neighbors. Those neighbors are:
   Interface: ge-1/3/9.0 , IP Address: 10.10.81.5 , ID: 10.10.80.3
   Interface: xe-0/0/0.0 , IP Address: 10.10.81.1 , ID: 10.10.80.80
   Interface: xe-0/2/0.0 , IP Address: 10.10.81.11 , ID: 10.10.80.10
   Interface: xe-7/1/0.0 , IP Address: 10.10.81.9 , ID: 10.10.80.80

- BGP: There are 2 active BGP neighbors. Those neighbors are:
   Session with: 10.10.80.50 , in AS: 855 , IP Address:10.10.80.50+53564
   Session with: 10.10.80.52 , in AS: 855 , IP Address:10.10.80.52+179

- LDP: There are 3 active LDP neighbors. Those neighbors are:
   Session with: 10.10.80.3 (neighbor ID)
   Session with: 10.10.80.10 (neighbor ID)
   Session with: 10.10.80.80 (neighbor ID)


The script is below. Lots of examples at: 
http://code.google.com/p/junoscriptorium/

Serge

version 1.0;
ns junos = http://xml.juniper.net/junos/*/junos;;
ns xnm = http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = http://xml.juniper.net/junos/commit-scripts/1.0;;
import ../import/junos.xsl;
 
match / {
op-script-output {
var $command1 = {
command 'show ospf neighbor';
}
var $out1 = jcs:invoke($command1);
var $contador1 = count($out1/ospf-neighbor[ospf-neighbor-state = 
'Full']);
output {
if ($contador1) {
expr '\n\n- OSPF: There are ' _ $contador1 _ ' active OSPF 
neighbors. Those neighbors are:\n';
for-each ($out1/ospf-neighbor) {
var $ifname = ./interface-name;
var $ip = ./neighbor-address;
var $id = ./neighbor-id;
expr '   Interface: ' _ $ifname _ ' , IP 
Address: ' _ $ip _ ' , ID: ' _ $id _ '\n';
}
} else {
expr \n\n- OSPF: There are not active OSPF neighbors.\n;
}
}
 
var $command3 = {
command 'show bgp neighbor';
}
var $out3 = jcs:invoke($command3);
var $contador3 = count($out3/bgp-peer[peer-state = 'Established']);
output {
if ($contador3) {
expr '\n\n- BGP: There are ' _ $contador3 _ ' active BGP 
neighbors. Those neighbors are:\n';
for-each ($out3/bgp-peer) {
var $ip = ./peer-address;
var $id = ./peer-id;
var $as = ./peer-as;
expr '   Session with: ' _ $id _ ' , in AS: ' _ 
$as _ ' , IP Address:' _ $ip _ '\n';
}
} else {
expr \n\n- BGP: There are not active BGP neighbors.\n;
}
}
 
 
var $command4 = {
command 'show ldp session';
}   
var $out4 = jcs:invoke($command4);
var $contador4 = count($out4/ldp-session[ldp-connection-state = 
'Open']);
output {
if ($contador4) {
expr '\n\n- LDP: There are ' _ $contador4 _ ' active LDP 
neighbors. Those neighbors are:\n';
for-each ($out4/ldp-session) {
var $ip = ./ldp-neighbor-address;
expr '   Session with: ' _ $ip _ ' (neighbor 
ID)\n';
}
} else {
expr \n\n- LDP: There are not active LDP neighbors.\n;
}
}
 
 
 }
}


- Original Message 
From: ben b benboyd.li...@gmail.com
To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Thu, February 3, 2011 10:59:02 AM
Subject: [j-nsp] Simple Script Running

All,

I'm trying to get a feel for op scripts in JUNOS and I can invoke commands,
but I'm not seeing the output I thought I'd see (it looks like raw data).

What I'd like to do is run a list of show commands with a script alias.

Could someone point me in the right direction to be able to run like 5
'show' commands (with normal output) in a row with one simple command like
'op status'


Thanks in advance,
Ben
___
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] compound rewrite-rule

[Serge Vautour]

Hello,

Are you trying to rewrite the MPLS header and IP header inside the MPLS packet? 
I think you can do this. See:

http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-cos/topic-27835.html#id-11667692


Serge



- Original Message 
From: Luca Tosolini bit.gos...@chello.nl
To: Lista-Juniper juniper-nsp@puck.nether.net
Sent: Mon, September 6, 2010 1:37:54 PM
Subject: [j-nsp] compound rewrite-rule

Experts,
on Mx and Junos 10.2R2.11
the following rewrite-rules configuration:
show configuration class-of-service interfaces xe-4/1/0  
unit 0 {
classifiers {
exp MPLS;
ieee-802.1 DOT1P;
inet-precedence TOS;
}
rewrite-rules {
exp MPLS-RW;
ieee-802.1 DOT1P-RW;
inet-precedence TOS-RW;
}
}

It looks like only one of the rewrite is executed but not all of them;
see the following capture of an egress frame:

sudo tcpdump -i eth1 -n -v -c1 mpls
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
65535 bytes
16:12:14.043480 MPLS (label 0 (IPv4 explicit NULL), exp 6, [S], ttl 62)
IP (tos 0x0, ttl 63, id 0, offset 0, flags [none], proto UDP (17),
length 114)


Here exp=6 and tos=0 so for an MPLS packet only MPLS-RW is executed.
Instead on a IP frame I see that TOS-RW is executed.

So it looks that the rewrite-rules are NOT executed together on same
frame !!
Is this the wanted behavior?

Thanks,
Bit.

___
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] Managing MX480 fxp0

[Serge Vautour]

Putting fxp0 in a LS works from a routing perspective but it breaks NSR  GRES 
- 
at least it does in 10.0R2. I have a JTAC case pending.

Serge



- Original Message 
From: Chen Jiang iloveb...@gmail.com
To: Jim Devane jdev...@switchnap.com
Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Thu, July 8, 2010 4:54:15 AM
Subject: Re: [j-nsp] Managing MX480 fxp0

You cannot put fxp0 into VRF but could put it into a logical system. And
logical system also have a seperate routing table other than inet.0.



On Thu, Jul 8, 2010 at 3:16 AM, Jim Devane jdev...@switchnap.com wrote:

 Hello,

 I need some ideas/help on a scenario I am sure comes up a lot but having
 problems with.

 I have an MX480. I want to be able to manage this MX from an internal
 (1918) network through the fxp0 port. The internal network is not flat but
 routed and there are several subnets which may contact the MX for
 management/polling. I was thinking/hoping to set up a VRF for this port and
 set routes/default route for the VRF to connect. It turns out I am not able
 to put fxp0 into a routing-instance. (errors on config checkout)
 So I put everything production in to a logical system leaving the fxp in
 the master instance and installing a default route for the master instance.
 This works, but now the MS-DPC will not export flows if it is in a logical
 system. So the logical system is out b/c the MS-DPC has to be in the master
 instance. But I can't but the fxp0 into a logical/routing instance.

 What is the BCP/recommended method for managing this box if fxp0 is not a
 public routed interface?

 Unfortunately, I don't have another port to place into a VRF besides the
 fxp0 (all other ports are 10G)

 Thanks for any help/ideas!
 Jim

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




-- 
BR!



  James Chen
___
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] OSPF LFA and LDP LSPs

[Serge Vautour]

Hello,

An update on this thread for anyone who might find it in the future. It appears 
the problem (or design) is with the traceroute mpls ldp command. It will test 
both the primary and backup LSP paths setup by OSPF LFA. Per JTAC, I simulated 
customer traffic over my lab network and the backup LSP path was never used. As 
a resolution to the case JTAC has agreed to update the traceroute command 
documentation.

Serge



- Original Message 
From: Serge Vautour sergevaut...@yahoo.ca
To: Alex alex.arsen...@gmail.com; juniper-nsp@puck.nether.net
Sent: Tue, March 16, 2010 3:25:38 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs

Hello,

Well that command explains a few things. Thanks! I do want the LDP LSPs to 
follow the OSPF shortest path. I had never really noticed that the inet.3 table 
entries had a different metric than my inet.0 entries. That helped make the 
metrics match however I still have the same problem.

Note the matching metrics:

-
se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail 

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router
Next-hop reference count: 26
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
State: Active Int
Local AS:   855 
Age: 8:04   Metric: 2 
Area: 0.0.0.0
Task: OSPF
Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
AS path: I

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

10.10.80.2/32 (1 entry, 1 announced)
State: FlashAll
*LDPPreference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Label operation: Push 300064
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
Label operation: Push 30
State: Active Int
Local AS:   855 
Age: 8:04   Metric: 2  --- Matches inet.0
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
AS path: I
-

The same problem exists:


se36...@pe1-stjhlab-re0 show ldp route 10.10.80.2 logical-system PE10
Destination Next-hop intf/lspNext-hop address
10.10.80.2/32  xe-0/3/0.0   10.10.81.10
ge-1/3/3.0   10.10.81.23

se36...@pe1-stjhlab-re0 traceroute 10.10.80.2 no-resolve logical-system PE10 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
1  10.10.81.10  0.347 ms  0.268 ms  0.279 ms
2  10.10.80.2  36.471 ms  0.480 ms  0.436 ms

se36...@pe1-stjhlab-re0 traceroute mpls ldp 10.10.80.2 no-resolve 
logical-system PE10
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttlLabel  ProtocolAddress  Previous Hop Probe Status
1   300064  LDP 10.10.81.10  (null)   Success  
23  LDP 10.10.81.1   10.10.81.10  Egress

  Path 1 via xe-0/3/0.0 destination 127.0.0.64

  ttlLabel  ProtocolAddress  Previous Hop Probe Status
1   30  LDP 10.10.81.23  (null)   Success  
23  LDP 10.10.81.20  10.10.81.23  Egress

  Path 2 via ge-1/3/3.0 destination 127.0.1.64

-

Note that the LDP LSP is still taking both paths?!?

Thanks,
Serge




- Original Message 
From: Alex alex.arsen...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca; juniper-nsp@puck.nether.net
Sent: Tue, March 16, 2010 1:44:13 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs

Serge,
Do you have track-igp-metric configured under LDP? I am pretty sure it does 
not since your OSPF and LDP metrics are different but I'd like to confirm.
Please try to configure track-igp-metric for LDP and re-run MPLS traceroute.
Rgds
Alex


- Original Message - From: Serge Vautour sergevaut...@yahoo.ca
To: Clarke Morledge chm...@wm.edu; juniper-nsp@puck.nether.net
Sent: Tuesday, March 16, 2010 2:54 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs


 Hello,
 
 Thanks for your comments. I agree with your theory. It's my understanding as 
 well. What I don't get is why the traceroute mpls ldp command uses both 
 paths and yet traceroute ip uses 1 path. It's like the backup path is being 
 used by the LDP LSP when it shouldn't be...
 
 Serge
 
 
 
 - Original Message 
 From: Clarke Morledge chm...@wm.edu
 To: juniper-nsp@puck.nether.net
 Cc: Serge Vautour sergevaut...@yahoo.ca
 Sent: Tue, March 16, 2010 11:35:30 AM
 Subject: RE

Re: [j-nsp] What's the latest code you're running on a mx?

[Serge Vautour]

Hello,

I for one am happy to hear this. We're very close to deploying a new MPLS 
network all on MX960s. We did heavy testing on 10.0R2 earlier this year. Our 
lab gear has all been updated to 10.0R3 and so far everything seems to work. 
We're running:

-IGP: OSPF (1 area 0, no TED) with OSPF LFA
-L2VPN, VPLS, L3VPN with BGP signaling
-LDP for transport LSPs
-No RSVP
-Simple Core QoS model with edge BA pbit classifiers

Some interesting things to note:

-OSPF LFA: I had to open a case with JTAC on this. The traceroute mpls ldp 
command uses both the primary and backup LFA paths. JTAC thinks this is a 
problem with the traceroute command and not OSPF LFA. When I simulate traffic 
through the network, it does always appear to use the primary LFA path only. I 
wish I new their ECMP algorithm to know for sure...

-no-tunnel-services: I can consistently get the box to core dump by creating a 
VPLS Routing Instance without no-tunnel-services, adding no-tunnel-services and 
then doing a commit full. Case pending. Work around: using groups to make sure 
parameters like no-tunnel-services are always on first time around.

-l3vpn-composite: This is suppose to add efficiencies for L3VPN but it breaks 
VPLS  L2VPN. PR opened in 10.0R2. I don't think it's fixed yet.

-Egress PE custom MPLS exp Classifier is broke for VPLS  L3VPN. As a 
workaround, you have to apply your classifier like so:

show configuration class-of-service routing-instances 
all {
classifiers {
exp mpls-core-classifier;
}
}

Otherwise the default MPLS exp classifier is used. 

-We wanted to put fxp0 in a dedicated Logical System to solve return route 
problems (some traffic is InBand, some is Out of Band via fxp0 - don't ask). 
This solves the routing problem but breaks NSR. 


Everything else seems to be working as expected. The problems listed above are 
somewhat minor and we can work around them. 10.0R3 did core dump a few times 
during a training session. We had 8 people all making config changes at the 
same time in the same edit. JTAC is analyzing. It's the only item that's 
making me a bit nervous. I'm hoping to limit simultaneous access (edit 
exclusive) in Prod to limit this.

Does anyone else have anything to share? I'd certain like to know if there's 
anybody else beating up 10.0R3 in the lab or running it in Prod. If we have a 
similar setup, I'd even be willing to replicate a problem anyone else might be 
having. Ping me off list if necessary.

Thanks,
Serge





- Original Message 
From: David Ball davidtb...@gmail.com
To: mti...@globaltransit.net
Cc: Richard A Steenbergen r...@e-gerbil.net; juniper-nsp@puck.nether.net
Sent: Tue, May 25, 2010 12:58:06 PM
Subject: Re: [j-nsp] What's the latest code you're running on a mx?

  Just a followup on this thread.  I've been testing 10.0R3.10 in the
lab with MX240, 480 and T640 and have had (somewhat surprisingly) good
results.  L2VPN, L2ckt, BGP-signalled VPLS (all w/QoS), L3VPN, LDP 
RSVP w/FRR (haven't tested much TE yet, mind you), even dabbled in
loop-free alternates (on the MX240 only), and haven't hit any
show-stoppers *yet*.  We're definitely SP-focused, not enterprise, so
YMMV.  They've even fixed (?) the functionality which broke (?) around
late 9.2 to early 9.3 timeframe which prevented you from doing 802.1p
BA classification on an outer VLAN tag if you were removing the outer
tag on ingress (they added a flag somewhere where you can specify
'inner' if you need to).

  It's said to have several fixes for the now infamous KRT Queue
issues as well, which have been discussed at length on the list.  I'm
cautiously optimistic about that one.

  That saideverything works in the lab, right?

David


On 1 May 2010 12:57, Mark Tinka mti...@globaltransit.net wrote:
 On Sunday 02 May 2010 01:31:44 am Richard A Steenbergen
 wrote:

 Don't try to compare code between platforms, they're
  entirely different beasts. :) In my experience the
  answer for EX is almost always run the latest and
  greatest, and our deployment tests w/EX8216s and 10.1S1
  have actually been much better than I expected.

 In the end it all comes down to which features are you
  using, and what expectations do you have from your
  router. Layer 2 is dirt simple, hell even Foundry
  managed to mostly get that one right, so I have no doubt
  that if your configuration and network are simple enough
  you'll probably never see an issue. Try running a full
  routing service provider config with bgp isis mpls rsvp
  l2circuits firewalls etc and it's completely different
  story. :)

 I probably should have stated that any platform was
 confined to the latter case you describe, service provider
 routing and friends.

 We've had luck running code on core and edge switches in
 pure Layer 2 mode that have brought other networks to tears
 when Layer 3 services are turned on. Code stability
 requirements between either paradigm is sufficiently
 distinguishable, most times :-).

 Even though the platforms 

Re: [j-nsp] Load Balance in VRF by Junos

[Serge Vautour]

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 route x.x.x.x' and 'show route
  forwarding-table destination x.x.x.x' for the route you are trying to
  load-balance.
 
  Thanks,
 
 
  Stefan Fouant
 
  Sent from my Verizon Wireless BlackBerry
  --
  *From: * Gabriel Farias gabrielfaria...@gmail.com
  *Date: *Wed, 31 Mar 2010 18:51:04 -0300
  *To: *sfou...@shortestpathfirst.net
  *Cc: *juniper-nsp-boun...@puck.nether.net; 
 juniper-nsp@puck.nether.net
  
  *Subject: *Re: [j-nsp] Load Balance in VRF by Junos
 
  I'm not using EBGP external type in PE (M120)
 
  Reagards,
  Gabriel Farias
 
  2010/3/31 Stefan Fouant sfou...@shortestpathfirst.net
 
  Do you have multi-path enabled on your EBGP sessions?
 
  Stefan Fouant
 
  Sent from my Verizon Wireless BlackBerry
  --
  *From: * Gabriel Farias gabrielfaria...@gmail.com
  *Date: *Wed, 31 Mar 2010 18:32:18 -0300
  *To: *sfou...@shortestpathfirst.net
  *Cc: *juniper-nsp-boun...@puck.nether.net; 
  juniper-nsp@puck.nether.net
  *Subject: *Re: [j-nsp] Load Balance in VRF by Junos
 
  I have a section between EBGP VRF PE x CE via two physical connections
  (aggregate ethernet) and see the traffic unbalanced because the Junos
 uses
  the default flow.
 
  I need the traffic between the PE x CE is symmetrically balanced way,
 the
  previous setting and did not work, and within the configuration
  

Re: [j-nsp] ipv6 routing

[Serge Vautour]

This is very odd. The OSPF instance is not running message makes me wonder if 
there's a licensing problem. I haven't been able to find anything on the 
Juniper web site...

Are you able to ping your Cisco router's FF80 address? What do you see if you 
run monitor interface traffic fe-0/1/0 while you run your pings? Do you have 
any neighbors picked up by ND (show ipv6 neighbors)? Do you have any Firewall 
Filters attached to Loop0 that would block some traffic?

HTH,
Serge



- Original Message 
From: Ramesh Karki rameshka...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca
Cc: juniper-nsp@puck.nether.net
Sent: Thu, April 1, 2010 3:50:59 AM
Subject: Re: [j-nsp] ipv6 routing

Hi Serge,

The M10i is running on ipv4 (bgp, ospf, including static)from beginning with
neighbor Cisco routers, now the requirement is to add enable dual stacking
(v4 and v6) routing like ospf and bgp on the same platform. I haven’t faced
any vendor compatibility issues between them on ipv4. And still I don’t
think the problem is by multi vendors.

here, the output of M10i :

run show interfaces fe-0/1/0
Physical interface: fe-0/1/0, Enabled, Physical link is Up
  Interface index: 129, SNMP ifIndex: 123
  Description: Connected to Beetle for iBGP peering
  Link-level type: Ethernet, MTU: 1514, Link-mode: Full-duplex, Speed:
100mbps, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  CoS queues : 4 supported, 4 maximum usable queues
  Current address: 00:17:cb:77:00:1f, Hardware address: 00:17:cb:77:00:1f
  Last flapped   : 2010-03-15 11:23:26 NPT (2w3d 00:57 ago)
  Input rate : 126752 bps (22 pps)
  Output rate: 87384 bps (46 pps)
  Active alarms  : None
  Active defects : None

  Logical interface fe-0/1/0.0 (Index 69) (SNMP ifIndex 127)
Flags: SNMP-Traps Encapsulation: ENET2
Input packets : 31156647
Output packets: 18571460
Protocol inet, MTU: 1500
  Flags: None
  Addresses, Flags: Is-Preferred Is-Primary
Destination: x.x.193.0/28, Local: x.x.193.1, Broadcast: x.x.193.15
Protocol inet6, MTU: 1500
  Flags: None
  Addresses, Flags: Is-Preferred Is-Primary
Destination: abcd:3800:2:1::/126, Local: abcd:3800:2:1::1
  Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::217:cbff:fe77:1f


run show version
Hostname: host-m10i
Model: m10i
JUNOS Base OS boot [9.2R2.15]
JUNOS Base OS Software Suite [9.2R2.15]
JUNOS Kernel Software Suite [9.2R2.15]
JUNOS Crypto Software Suite [9.2R2.15]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.2R2.15]
JUNOS Packet Forwarding Engine Support (M7i/M10i) [9.2R2.15]
JUNOS Online Documentation [9.2R2.15]
JUNOS Routing Software Suite [9.2R2.15]

run show ospf3 overview
OSPF instance is not running

run show configuration protocols ospf3
preference 110;
area 0.0.0.10 {
interface fe-0/1/0.0;
interface ge-0/0/0.0;
interface lo0.0 {
passive;


Cisco output :

#show run | be ^ipv6 router

ipv6 router ospf 200
router-id x.x.192.10
log-adjacency-changes


#sh run int lo6
Building configuration...

Current configuration : 157 bytes
!
interface Loopback6
ip address x.x.192.10 255.255.255.255
ipv6 address abcd:3800::4/128
ipv6 enable
ipv6 ospf 200 area 10
no clns route-cache
end

sh run int fa0/0
Building configuration...

Current configuration : 264 bytes
!
interface FastEthernet0/0
description *** iBGP peering ***
ip address x.x.193.4 255.255.255.240
no keepalive
duplex full
ipv6 address abcd:3800:2:1::2/126
ipv6 enable
ipv6 ospf 200 area 10
no cdp enable
no clns route-cache
end


Thank you,


On Thu, Apr 1, 2010 at 3:26 AM, Serge Vautour sergevaut...@yahoo.ca wrote:

 Hello,

 Can you post the following to the mailing list?

 -show int ge-0/0/0
 -show version
 -show ospf3 overview

 From the Cisco router:
 -The interface and OSPF config

 I'm assuming IPv4 ping works over the interface?


 Thanks,
 Serge


 - Original Message 
 From: Ramesh Karki rameshka...@gmail.com
 To: Antonio Querubin t...@lava.net
 Cc: juniper-nsp@puck.nether.net
 Sent: Wed, March 31, 2010 4:54:29 PM
 Subject: Re: [j-nsp] ipv6 routing

 Hi,
 Similar ospf config between cisco to cisco is okay there is not any issue.
 But between cisco to M10i is not working.
 Here, I have listed my JunOS ospf config :
 run show configuration protocols ospf3
 preference 10;
 area 0.0.0.10 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0 {
metric 10;

 am I missing anything ??

 My curiosity : when I execute the command  run show ospf3 interface
 ge-0/0/0.0 it says -
 “OSPF instance is not running” ??

 Thank you,


 On Thu, Apr 1, 2010 at 1:12 AM, Antonio Querubin t...@lava.net wrote:

  On Thu, 1 Apr 2010, Ramesh Karki wrote:
 
   I have also tried to run ospf3 but no luck, the command  show ospf3
  interface ge-0/0/0.0 says
  “OSPF instance is not running”
 
 
   I have

Re: [j-nsp] ipv6 routing

[Serge Vautour]

I agree with Chris. Everything looks configured right. Since you can ping, the 
only problem seems to be with OSPFv3. Anything in the logs? I'd restart RPD as 
well... Do you have a lab box you can try it on?

Serge



- Original Message 
From: Ramesh Karki rameshka...@gmail.com
To: Chris Grundemann cgrundem...@gmail.com
Cc: juniper-nsp@puck.nether.net; Serge Vautour se...@nbnet.nb.ca
Sent: Thu, April 1, 2010 2:07:02 PM
Subject: Re: [j-nsp] ipv6 routing

Hi Serge,

Are you able to ping your Cisco router's FF80 address?
Yes I can ping both the link local address and the manually assigned
address.

What do you see if you run monitor interface traffic fe-0/1/0 while you
run your pings?

The captured output seems okay (I have tried with tcpdump from shell mode
too..)

22:02:36.895648 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 44, length 16
22:02:36.896282  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 44, length 16
22:02:37.89 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 45, length 16
22:02:37.896414  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 45, length 16
22:02:38.896466 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 46, length 16
22:02:38.901718  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 46, length 16
22:06:06.206997  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, neighbor advertisment, tgt is fe80::20c:31ff:fe95:a400, length 24
22:06:06.529913  In IP fe1-1.beetle.subisu.net.np  OSPF-ALL.MCAST.NET:
OSPFv2, Hello, length 60
22:06:06.865791  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, neighbor solicitation, who has fe80::217:cbff:fe77:1f, length 32
22:06:06.865867 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, neighbor advertisment[|icmp6]
22:06:06.866165 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 6, length 16
22:06:06.866752  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 6, length 16
22:06:07.866094 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 7, length 16
22:06:07.866812  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 7, length 16
22:06:08.866000 Out IP6 fe80::217:cbff:fe77:1f  fe80::20c:31ff:fe95:a400:
ICMP6, echo request, seq 8, length 16
22:06:08.866736  In IP6 fe80::20c:31ff:fe95:a400  fe80::217:cbff:fe77:1f:
ICMP6, echo reply, seq 8, length 16

Do you have any neighbors picked up by ND (show ipv6 neighbors)?

V6 neighbors are discovering :

IPv6 Address Linklayer Address  State   Exp Rtr
Interface
abcd:3800:1:1::2 00:18:73:46:12:32  stale   797 yes
ge-0/0/0.0
abcd:3800:2:1::2 00:0c:31:95:a4:00  stale   345 yes
fe-0/1/0.0
fe80::202:17ff:fed8:4c00 00:02:17:d8:4c:00  stale   57  yes
ge-0/0/0.0
fe80::20c:31ff:fe95:a400 00:0c:31:95:a4:00  stale   224 yes
fe-0/1/0.0
fe80::218:73ff:fe46:1232 00:18:73:46:12:32  stale   152 yes
ge-0/0/0.0

Do you have any Firewall Filters attached to Loop0 that would block some
traffic?
yes, I have applied a firewall filter policy on Lo0 to filter some specific
tcp/udp services rest are accepted.


I am not sure if it is a Licensing problem, I have not found any related doc
on the web too..

Chris,
This is my productions box, so I can restart the rpd process only on our
regular maintains day.

thank you,

Ramesh
On Thu, Apr 1, 2010 at 10:11 PM, Chris Grundemann cgrundem...@gmail.comwrote:

 On Thu, Apr 1, 2010 at 09:59, Serge Vautour sergevaut...@yahoo.ca wrote:
  This is very odd. The OSPF instance is not running message makes me
 wonder if there's a licensing problem. I haven't been able to find anything
 on the Juniper web site...

 There should be no issue with licensing - IPv6 has been a standard
 feature in Junos for quite some time. I don't have any experience with
 9.2R2 on an M10i specifically though - I guess it is possible there is
 a bug...

 
  Are you able to ping your Cisco router's FF80 address? What do you see if
 you run monitor interface traffic fe-0/1/0 while you run your pings? Do
 you have any neighbors picked up by ND (show ipv6 neighbors)? Do you have
 any Firewall Filters attached to Loop0 that would block some traffic?

 Good ideas.

 Also, is this a production or lab box Ramesh? if it's a lab box you
 might try restarting rpd - these problems seem to be quite odd indeed
 (from what I can tell you are configuring things properly).

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



 --
 @ChrisGrundemann
 weblog.chrisgrundemann.com
 www.burningwiththebush.com
 www.coisoc.org

[j-nsp] OSPF LFA and LDP LSPs

[Serge Vautour]

Hello,

We are testing MPLS in our lab using two MX960s with a few LS to add more 
routers. I'm using OSPF as the IGP and LDP for transport labels. We're on 10.0 
code so I've been testing OSPF LFA. It appears to be doing something strange 
and I can't tell if it's per design or a bug.

Here's a PE's route to a destination PE loopback:

--
se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router, Next hop index: 1192
Next-hop reference count: 40
Next hop: 10.10.81.10 via xe-0/3/0.0, selected
State: Active Int
Local AS:   855 
Age: 2  Metric: 2 
Area: 0.0.0.0
Task: OSPF
Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
AS path: I

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

10.10.80.2/32 (1 entry, 1 announced)
State: FlashAll
*LDPPreference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.10.81.10 via xe-0/3/0.0, selected
Label operation: Push 299776
State: Active Int
Local AS:   855 
Age: 2  Metric: 1 
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
AS path: I

{master}
se36...@pe1-stjhlab-re0 show ldp route logical-system PE10 10.10.80.2 
extensive
Destination Next-hop intf/lspNext-hop address
 10.10.80.2/32  xe-0/3/0.0   10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:10 ago

se36...@pe1-stjhlab-re0 traceroute 10.10.80.2 logical-system PE10 no-resolve 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.353 ms  0.274 ms  0.279 ms
 2  10.10.80.2  0.460 ms  0.455 ms  0.437 ms

{master}
se36...@pe1-stjhlab-re0 traceroute mpls ldp 10.10.80.2 logical-system PE10 
no-resolve
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttlLabel  ProtocolAddress  Previous Hop Probe Status
1   299776  LDP 10.10.81.10  (null)   Success   
23  LDP 10.10.81.1   10.10.81.10  Egress

  Path 1 via xe-0/3/0.0 destination 127.0.0.64
--

Everything is normal. IP packets are following the OSPF shortest path per the 
costs I've set. The LDP LSP is following OSPF.

Now I turn on OSPF LFA link-protection on the links and re-run the same tests:

---
se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail   
 

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router
Next-hop reference count: 26
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000   - 
Huh???
State: Active Int
Local AS:   855 
Age: 4  Metric: 2 
Area: 0.0.0.0
Task: OSPF
Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
AS path: I

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

10.10.80.2/32 (1 entry, 1 announced)
State: FlashAll
*LDPPreference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Label operation: Push 299776
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 - 
Huh???
Label operation: Push 299856
State: Active Int
Local AS:   855 
Age: 4  Metric: 1 
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
AS path: I

{master}
se36...@pe1-stjhlab-re0 show ldp route logical-system PE10 10.10.80.2 
extensive 
Destination Next-hop intf/lspNext-hop address
 10.10.80.2/32  xe-0/3/0.0   10.10.81.10
   Session ID 10.10.80.10:0--10.10.80.1:0
ge-1/3/3.0   10.10.81.23
   Session ID 10.10.80.10:0--10.10.80.14:0
   Bound to outgoing label 299840, Topology entry: 0x8e69980
   Ingress route status: Active, Last modified: 00:00:09 ago

{master}
se36...@pe1-stjhlab-re0 traceroute 10.10.80.2 logical-system PE10 no-resolve   
 
traceroute to 10.10.80.2 

Re: [j-nsp] OSPF LFA and LDP LSPs

[Serge Vautour]

Hello,

Thanks for your comments. I agree with your theory. It's my understanding as 
well. What I don't get is why the traceroute mpls ldp command uses both paths 
and yet traceroute ip uses 1 path. It's like the backup path is being used by 
the LDP LSP when it shouldn't be...

Serge



- Original Message 
From: Clarke Morledge chm...@wm.edu
To: juniper-nsp@puck.nether.net
Cc: Serge Vautour sergevaut...@yahoo.ca
Sent: Tue, March 16, 2010 11:35:30 AM
Subject: RE: [j-nsp] OSPF LFA and LDP LSPs

Serge,

Part of what you wrote included this:

 Now I turn on OSPF LFA link-protection on the links and re-run the same 
 tests:
 
 ---
 se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail
 
 inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
 10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router
Next-hop reference count: 26
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000   
 - Huh???
State: Active Int
Local AS:   855
Age: 4  Metric: 2
Area: 0.0.0.0
Task: OSPF
Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2
AS path: I
 
 inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
 
 10.10.80.2/32 (1 entry, 1 announced)
State: FlashAll
*LDPPreference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Label operation: Push 299776
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000 - 
 Huh???
Label operation: Push 299856
State: Active Int
Local AS:   855
Age: 4  Metric: 1
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2
AS path: I

I can not speak to your traceroute issue, but my understanding is that the 
next-hop 10.10.81.23 references are the alternate paths that get put in your 
routing table by the LFA algorithm.  These routes exist but only in stand-by 
mode.  So if the 10.10.81.10 next-hop ever goes away, traffic can immediately 
use this stand-by routing entry to forward the traffic while OSPF is 
recalculating new routes under the covers.  This is loosely analogous to how 
Detours work in RSVP/MPLS Fast ReRoute -- though, admittedly, Fast ReRoute is 
much more involved.  Then, once the OSPF recalculations are done in LFA, the 
routing table is updated with a new primary routing entry and another 
stand-by entry.

Therefore, LFA effectively doubles the size of your routing table to 
accommodate all of the stand-by routes.

Unless, I'm missing something, that is at least my understanding of how LFA 
actually works --- or at least how it is supposed to work.  In other words, per 
your routing table it is working as designed.  However, this does not 
necessarily mean that OSPF LFA currently solves all of the problems with 
microloops in some topologies.  If someone has a better explanation, I'd like 
to know, too.

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] OSPF LFA and LDP LSPs

[Serge Vautour]

Hello,

Well that command explains a few things. Thanks! I do want the LDP LSPs to 
follow the OSPF shortest path. I had never really noticed that the inet.3 table 
entries had a different metric than my inet.0 entries. That helped make the 
metrics match however I still have the same problem.

Note the matching metrics:

-
se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail 

inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router
Next-hop reference count: 26
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
State: Active Int
Local AS:   855 
Age: 8:04   Metric: 2 
Area: 0.0.0.0
Task: OSPF
Announcement bits (3): 2-LDP 3-KRT 5-Resolve tree 2 
AS path: I

inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

10.10.80.2/32 (1 entry, 1 announced)
State: FlashAll
*LDPPreference: 9
Next hop type: Router
Next-hop reference count: 3
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Label operation: Push 300064
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000
Label operation: Push 30
State: Active Int
Local AS:   855 
Age: 8:04   Metric: 2  --- Matches inet.0
Task: LDP
Announcement bits (2): 2-Resolve tree 1 3-Resolve tree 2 
AS path: I
-

The same problem exists:


se36...@pe1-stjhlab-re0 show ldp route 10.10.80.2 logical-system PE10 
Destination Next-hop intf/lspNext-hop address
 10.10.80.2/32  xe-0/3/0.0   10.10.81.10
ge-1/3/3.0   10.10.81.23

se36...@pe1-stjhlab-re0 traceroute 10.10.80.2 no-resolve logical-system PE10 
traceroute to 10.10.80.2 (10.10.80.2), 30 hops max, 40 byte packets
 1  10.10.81.10  0.347 ms  0.268 ms  0.279 ms
 2  10.10.80.2  36.471 ms  0.480 ms  0.436 ms

se36...@pe1-stjhlab-re0 traceroute mpls ldp 10.10.80.2 no-resolve 
logical-system PE10
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttlLabel  ProtocolAddress  Previous Hop Probe Status
1   300064  LDP 10.10.81.10  (null)   Success   
23  LDP 10.10.81.1   10.10.81.10  Egress

  Path 1 via xe-0/3/0.0 destination 127.0.0.64

  ttlLabel  ProtocolAddress  Previous Hop Probe Status
1   30  LDP 10.10.81.23  (null)   Success   
23  LDP 10.10.81.20  10.10.81.23  Egress

  Path 2 via ge-1/3/3.0 destination 127.0.1.64

-

Note that the LDP LSP is still taking both paths?!?

Thanks,
Serge




- Original Message 
From: Alex alex.arsen...@gmail.com
To: Serge Vautour se...@nbnet.nb.ca; juniper-nsp@puck.nether.net
Sent: Tue, March 16, 2010 1:44:13 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs

Serge,
Do you have track-igp-metric configured under LDP? I am pretty sure it does 
not since your OSPF and LDP metrics are different but I'd like to confirm.
Please try to configure track-igp-metric for LDP and re-run MPLS traceroute.
Rgds
Alex


- Original Message - From: Serge Vautour sergevaut...@yahoo.ca
To: Clarke Morledge chm...@wm.edu; juniper-nsp@puck.nether.net
Sent: Tuesday, March 16, 2010 2:54 PM
Subject: Re: [j-nsp] OSPF LFA and LDP LSPs


 Hello,
 
 Thanks for your comments. I agree with your theory. It's my understanding as 
 well. What I don't get is why the traceroute mpls ldp command uses both 
 paths and yet traceroute ip uses 1 path. It's like the backup path is being 
 used by the LDP LSP when it shouldn't be...
 
 Serge
 
 
 
 - Original Message 
 From: Clarke Morledge chm...@wm.edu
 To: juniper-nsp@puck.nether.net
 Cc: Serge Vautour sergevaut...@yahoo.ca
 Sent: Tue, March 16, 2010 11:35:30 AM
 Subject: RE: [j-nsp] OSPF LFA and LDP LSPs
 
 Serge,
 
 Part of what you wrote included this:
 
 Now I turn on OSPF LFA link-protection on the links and re-run the same 
 tests:
 
 ---
 se36...@pe1-stjhlab-re0 show route 10.10.80.2 logical-system PE10 detail
 
 inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
 10.10.80.2/32 (1 entry, 1 announced)
*OSPF   Preference: 10
Next hop type: Router
Next-hop reference count: 26
Next hop: 10.10.81.10 via xe-0/3/0.0 weight 0x1, selected
Next hop: 10.10.81.23 via ge-1/3/3.0 weight 0xf000

[j-nsp] RFC2544 on Juniper MX960 10G ports

[Serge Vautour]

Hello,

We recently used a traffic generator to run RFC2544 tests against a Juniper 
MX960. The 1G ports work flawlessly. 0% packet loss at all frame sizes. 

The 10G ports  (4x10G R card) didn't do as well. They dropped up to 25% 
packets with certain small frames (ex: 70 byte frames). The packet loss goes 
away almost completely for frames larger than 100 bytes. Our SE tells us this 
is normal and is due to how the MX chops the frames up into 64 byte cells 
inside the PFE. The 4x10G cards have 4 separate PFEs (1 per 10G port) and each 
of them has 10G of bandwidth. 10G of small frames essentially creates more than 
10G of traffic inside the PFE. That explanation may not be 100% correct but I 
think it paints the right picture.

Now the questions. Is this a problem on production networks with real world 
traffic? What about on VPN networks with alot of small frames like VoIP? Has 
anyone seen this problem creep it's head in production?

It seems very unlikely to me that a maxed 10Gbps link would carry 7.5Gbps of 
frame sizes less than 100 byte. I would expect larger frames to use up the 
majority of the bandwidth. Can anyone correlate this with real world traffic?

As usual, the help received on this distribution list is invaluable. Thanks in 
advance to anyone who replies.

Serge


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Static sub-interface MAC address

[Serge Vautour]

Hello,

Does anyone know if it's possible to assign a static MAC address on a per 
sub-interface basis? In my lab I'm using Virtual Routers on an MX to emulate 
CPEs. I'm using a dot1q trunk to split multiple VLANs into different VRs. I'm 
bridging those VLANs in my VPLS setup. This is causing a duplicate MAC problem 
as all the VLAN sub-interfaces are sharing the same MAC: 

us...@pe1-re0 show arp 
MAC Address   Address Name  Interface Flags
00:24:dc:9f:00:f8 172.16.4.2  172.16.4.2ge-1/2/1.200  none
00:24:dc:9f:00:f8 172.16.7.3  172.16.7.3ge-1/2/1.502  none
00:24:dc:9f:00:f8 172.16.8.3  172.16.8.3ge-1/2/1.503  none

You probably wouldn't see this in Prod but it should would help me do some 
testing :)

Thanks,
Serge



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] upgrading M120 directly from 8.5 to 9.3

[Serge Vautour]

Hello,

I actually tried jumping 5 releases on an M40e in our lab. The upgrade worked 
but when I began running my test plan, I had a few items that wouldn't work. 
The fix was to downgrade to the previous release and then upgrade with an 
interim release to avoid upgrading more than 3 releases at a time. It would 
take me a while to find the exact releases and problems. It was almost 2 years 
ago.

It may have been a one time thing but based on my experience, I never upgrade 
more than 3 releases at a time. If you are missing an interim release that is 
no longer on the Juniper web site, TAC can get you a copy.

Serge



- Original Message 
From: Chuck Anderson c...@wpi.edu
To: juniper-nsp@puck.nether.net
Sent: Mon, January 11, 2010 3:59:48 PM
Subject: [j-nsp] upgrading M120 directly from 8.5 to 9.3

Juniper recommends not upgrading more than 3 releases, but 8.5 to 9.3 
would be a 4-release upgrade (9.0 - 9.1 - 9.2 - 9.3).  Has anyone done 
this with success?  It seems strange to me that Juniper wouldn't test 
and support an upgrade from one E-EOL release to another without 
having to jump through a non-E-EOL release, and in fact a release that 
has actually reached EOL.

8.5 reaches EOL on 2011-05-15
9.2 has reached EOL as of 2009-11-15

How is one supposed to upgrade in a supported manner once 9.2 is 
removed from the web site?  Luckily, it is still there now.  But if I 
have a problem with 9.2 during this intermediate upgrade step, Juniper 
won't support it because it is EOL?  Seems like someone didn't think 
this through very well.

I'd like to avoid the pain and just go directly from 8.5 to 9.3.  What 
are your experiences?

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



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] bad packets

[Serge Vautour]

We run OSPF  BGP with no MPLS. Our standard protect RE filter does:

-Allow OSPF, BGP, VRRP, BFD
-Drop all first fragments  trailing fragments
-Allow ICMP, TACACS, SSH, Telnet, SNMP, DNS, FTP
-Drop everything else


Appropriate entries permit only certain source/destinations. This has been 
working fine for us.
Serge


- Original Message 
From: Bit Gossip bit.gos...@chello.nl
To: Juniper List juniper-nsp@puck.nether.net
Sent: Thursday, September 10, 2009 8:06:16 AM
Subject: [j-nsp] bad packets

Experts,
on the ground that only the following protocols are allowed to reach the
RE:
- BGP (runs PMTU so should not fragment packets)
- ISIS is only L2 so it is not blocked by a firewall filter
- OSPF, LDP, RSVP, PIM, IGMP, BFD, VRRP: don't know about them
- ssh, snmp, tacacs, ntp, Icmp, domain

Is it correct to assume that for none of them is necessary to allow
fragmens and packet with IP options?
This way it is possible and safe to immediately reject on a loopback
inbound filter all fragments and packets with IP options?

Thanks,
Bit.


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



  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Netflow

[Serge Vautour]

We do it this way and haven't seen a problem. We have a mix is Cisco and 
Juniper.

re0 show configuration forwarding-options 
sampling {
input {
family inet {
rate 400;
run-length 0;
max-packets-per-second 7000;
}
}
output {
cflowd x.x.x.x {
port 5000;
source-address y.y.y.y;
version 5;
}
}
}
family inet {
filter {
input CflowdSample;
}
}


re0 show configuration firewall filter CflowdSample 
term sampled_packets {
from {
source-address {
0.0.0.0/0;
}
}
then {
sample;
accept;
}
}

This does a 1/400 sample on every packet going through any interface.

Serge


- Original Message 
From: Servet ser...@doruk.net.tr
To: Stefan Fouant sfou...@gmail.com; juniper-nsp@puck.nether.net
Sent: Thursday, September 3, 2009 10:29:05 AM
Subject: Re: [j-nsp] Juniper Netflow

Sampling applied at the interface ...
i dont use firewall filter.


- Original Message - 
From: Stefan Fouant sfou...@gmail.com
To: Servet ser...@doruk.net.tr; juniper-nsp@puck.nether.net
Sent: Thursday, September 03, 2009 3:18 PM
Subject: Re: [j-nsp] Juniper Netflow


 Curious... Are you sampling via Firewall filter, or is sampling
 applied at the Interface?



 On 9/3/09, Servet ser...@doruk.net.tr wrote:


 Hi Guys

 i have a problem with juniper netflow traffic values, i think there is no
 problem about the config and flow-analyser. If i use a cisco device, the
 results of snmp polls and results of the flow-analyser are similar
 But in juniper; i get 180 mbit/s traffic value with SNMP requests from my
 juniper MX-960 router, but netflow says me it is 120mbit. Also my 
 sampling
 rate is 1.
 You can see config below, do you have any idea?  why i can't get similar
 results from snmp and netflow
 Kind regards



 sampling {
 input {
 family inet {
 rate 1;
 run-length 1;
 max-packets-per-second 65535;
 }
 }
 output {
 cflowd x.x.x.x {
 port 9996;
 version 5;
 autonomous-system-type origin;
 }
 flow-inactive-timeout 600;
 flow-active-timeout 60;
 interface sp-4/1/0 {
 source-address y.y.y.y;
 }
 }
 }
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


 -- 
 Sent from Gmail for mobile | mobile.google.com

 Stefan Fouant

 Stay the patient course.
 Of little worth is your ire.
 The network is down. 

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



  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Broken Per-Flow load sharing

[Serge Vautour]

For anyone curious, Juniper seems to have 3 ways to solve this problem:

http://www.juniper.net/techpubs/software/junos/junos93/swconfig-policy/configuring-per-flow-load-balancing-information.html#id-11352490

I can't say I understand all 3 (docs are a bit vague). We implemented the first 
and it worked perfectly:

[edit forwarding-options hash-key]
family inet {
  layer-3;
  layer-4;
}

Serge



- Original Message 
From: Serge Vautour sergevaut...@yahoo.ca
To: juniper-nsp@puck.nether.net
Sent: Thursday, August 20, 2009 11:44:25 AM
Subject: [j-nsp] Broken Per-Flow load sharing

Hello,

We have several M320s  T640s in our network running 8.5R4.3. They are all 
configured for per-flow load sharing:

RouterA show configuration routing-options forwarding-table 
export perDestinationLoadBalance;

RouterA show configuration policy-options policy-statement 
perDestinationLoadBalance 
/* Policy exported against forwarding-table configuration to ensure 
per-flow-destination load balance */
then {
load-balance per-packet;
}


The routers have 2x 10GEs via switches to reach Aggregation routers. OSPF sees 
2 equal cost paths to the BGP next hops and splits the traffic across the 
links. This has been working fine for a few years (it worked on 8.2 as well). 

We recently upgraded to 9.3R2.8 and load sharing is no longer working:

RouterA show interfaces xe-1/0/0 detail | match Output packets.*pps
   Output packets:  61838797 pps
 Output packets:00 pps
 Output packets:525426 pps
 Output packets:192790 pps
 Output packets: 31340 pps
 Output packets:00 pps

RouterA show interfaces xe-2/0/0 detail | match Output packets.*pps
   Output packets: 285078265156   228705 pps
 Output packets:00 pps
 Output packets: 280511288646   221803 pps
 Output packets:   4118406919 6075 pps
 Output packets:442607080  894 pps
 Output packets:00 pps

The first Output line is the 10GE aggregate. The other output lines are the 
VLANs on the 10GE. Note that the xe-1/0/0 interface has next to 0 pps on 
output!! We have upgraded two M320s and they are both showing the same problem.

My guess is that the per-flow load balancing hash has changed in the newer 
release. The 9.3 manual talks about setting something like this:

[edit forwarding-options hash-key]
family inet {
  layer-3;
  layer-4;
}

But it's a bit unclear as to what happens if it isn't set. Can anyone confirm 
that this will restore per-flow load sharing?

Any help would be appreciated. 

Thanks,
Serge


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NetConf - get_config filter

[Serge Vautour]

Just in case someone else has the same problem, here's the solution. 

get_configuration seems to be part of JunoScript. For NetConf, the method looks 
like:

'get_config' = {
'source' = $DOM_STRING,
'source_url' = $URL_STRING,
'filter' = $DOM
},

A DOM object is simply xml code. So to get this to work I did:

my $xml_string = 
filter type=\subtree\
configuration
  protocols
bgp/bgp
  /protocols
/configuration
/filter
; 

my %queryargs = (
 'source' = running,
 'filter' = $xml_string,
);

This generates the correct RPC request:

Server request: 
 rpc message-id='1'get-config sourcerunning/ /source
filter type=subtree
configuration
  protocols
bgp/bgp
  /protocols
/configuration
/filter
/get-config /rpc

Hope this helps someone. Could've saved me a few hours ;)

Serge


--- On Fri, 1/9/09, Serge Vautour sergevaut...@yahoo.ca wrote:

 From: Serge Vautour sergevaut...@yahoo.ca
 Subject: [j-nsp] NetConf - get_config filter
 To: juniper-nsp@puck.nether.net
 Received: Friday, January 9, 2009, 2:40 PM
 Hello,
 
 I'm trying to use the NetConf Perl API provided on the
 Juniper site. I can successfully create a connection to the
 router and retrieve the entire configuration using
 get_config.
 
 Does anyone know if the NetConf Perl API provides a way to
 filter the request to retrieve a certain part of the config?
 Per the NetConf docs, the RPC request should look like:
 
 rpc
  get-config
   source
 !- - tag specifying the source configuration -
 -
   /source
   filter type=subtree
configuration
 !- - opening tags for each parent of the requested
 object type - -
  object-type/
   !- - closing tags for each parent of the
 requested object type - -
/configuration
   /filter
  /get-config
 /rpc
 
 The get_configuration perl function only seems to have the
 following attributes:
 
 get_configuration = {
 configuration = $DOM,
 format = $ATTRIBUTE,
 inherit = $ATTRIBUTE,
 database = $ATTRIBUTE,
 },
 
 How does on request the filter
 type=subtree? Here's an example of
 the queryargs I use when calling get_config:
 
 my $parser = new XML::DOM::Parser;
 my %queryargs = (
  'source' = running,
  'format' = xml,
  'configuration' =
 $parser-parsefile(protocols.xml) ,
 );
 
 Where protocols.xml is a text file containing:
 
 configuration
   protocols
 bgp/bgp
   /protocols
 /configuration
 
 When I run the script and echo the request, we get:
 
 Server request: 
  rpc message-id='1'get-config
 sourcerunning/
 /source/get-config /rpc
 
 The API is creating the RPC call correctly for the
 source. How do I get it to create the filter
 section? I've tried:
 
 my $parser = new XML::DOM::Parser;
 my %queryargs = (
  'source' = running,
  'format' = xml,
  'filter' = subtree,
  'configuration' =
 $parser-parsefile(protocols.xml) ,
 );
 
 However this creates:
 
 Server request: 
  rpc message-id='1'get-config
 sourcerunning/
 /sourcesubtree/get-config /rpc
 
 This generates an error as the xml isn't formatted
 correctly. I've tried several other combinations without
 any luck. 
 
 Can anyone point me in the right direction to filter the
 config output to a certain section?
 
 Thanks,
 Serge Vautour
 sergevaut...@yahoo.ca
 
 
  
 __
 Yahoo! Canada Toolbar: Search from anywhere on the web, and
 bookmark your favourite sites. Download it now at
 http://ca.toolbar.yahoo.com.
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp