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

[Stacy W. Smith]

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

Re: [j-nsp] Ansible juniper_junos -add license module?

[Stacy W. Smith]

On Mar 28, 2018, at 9:24 AM, Sander Steffann  wrote:
> 
> I tried that, and git an error message back saying eta the license-add 
> command is only supported on cli and not over RPC :'(



—Stacy

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

Re: [j-nsp] Ansible juniper_junos -add license module?

[Stacy W. Smith]

Thanks Phil! 
I knew there was an RPC for this, but hadn’t had the chance to figure it out.

Adam,
Given the info from Phil, you can use a playbook similar to this:

---
- name: 'Add a license to a Junos device'
  hosts: junos-all
  connection: local
  gather_facts: no
  roles:
- Juniper.junos

  tasks:
- name: 'Add a license'
  juniper_junos_rpc:
rpc: 'request-license-add'
kwarg:
  key_data: ‘'


Alternatively, you can load the license from a file or URL with:

---
- name: 'Add a license to a Junos device'
  hosts: junos-all
  connection: local
  gather_facts: no
  roles:
- Juniper.junos

  tasks:
- name: 'Add a license'
  juniper_junos_rpc:
rpc: 'request-license-add'
kwarg:
  source: ‘'


You can also refer to the documentation here: 
http://junos-ansible-modules.readthedocs.io/en/2.0.2/juniper_junos_rpc.html 


> On Mar 28, 2018, at 3:28 AM, adamv0...@netconsultings.com wrote:
>  I could not find any juniper_junos module for amnesiac mode. (all the modules
> kind of assume working ssh and netconf).


The modules do have limited support for initial device configuration if you 
have a direct serial connection from the Ansible control machine to the Juniper 
device’s serial console or if you have the serial console connected to a 
terminal server which is reachable via an unauthenticated Telnet port. (If the 
console server is only reachable over SSH or adds additional authentication, 
that’s not currently supported.)

Performing NETCONF operations over the serial console is sometimes problematic 
because the NETCONF gets interspersed with any console logging. There’s not 
currently a way to disable this, so the best bet is to simply repeat any failed 
NETCONF operations over the serial console.

—Stacy



> On Mar 28, 2018, at 8:45 AM, Phil Shafer  wrote:
> 
> adamv0...@netconsultings.com writes:
>> The problem is I need to hit enter after the license is passed and then also
>> ^D (ctrl+D) at the end and I'm not sure how would I go about doing that in
>> junos_command. 
> 
> Not sure why these aren't documented but the functionality is there.
> Here's the JUNOS DDL (think "YANG"):
> 
>command add-license {
>help "Add license keys from file, local or from server";
>action acceptable mgd mgd_is_product_licensed;
>action execute mgd mgd_add_license_mgd;
>xml-name request-license-add;
>odl-tag add-license-results;
>argument source {
>help "URL of source license key file";
>type string;
>}
>argument key-data {
>help "License key data";
>type string;
>}
>}
>command save-license {
>help "Save license keys to file, local or to server";
>action acceptable mgd mgd_is_product_licensed;
>xml-name request-license-save;
>odl-tag none;
>action execute mgd mgd_save_license_mgd;
>argument destination {
>help "URL of destination license key file";
>type string;
>}
>}
> 
> The "xml-name" statement gives the name of the RPC used to access
> this command, which means the  RPC adds a
> license from either a  URL or a  string, and the
>  exports license data to a  URL.
> 
> In SLAX, that looks something like:
> 
>var $rpc =  {
> $my-data;
>}
> 
> Thanks,
> Phil
> ___
> 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] Ansible juniper_junos -add license module?

[Stacy W. Smith]

It has a module, juniper_junos_rpc, for sending any NETCONF RPC which could be 
used to add licenses.

Sorry, not at a computer right now to give you the exact syntax, but it should 
certainly be possible with this module.

--Stacy


> On Mar 25, 2018, at 7:59 AM,  
>  wrote:
> 
> Hi folks,
> 
> 
> 
> Does anyone know whether ansible (juniper_junos) has a module for adding
> licenses please?
> 
> If not how can I send ^D (ctrl+D a.k.a end of file) in expect script please?
> 
> Thanks
> 
> 
> 
> 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

Re: [j-nsp] Booting from tftpboot u-boot

[Stacy W. Smith]

> On Jul 30, 2016, at 5:07 AM, Lukasz Martyniak  
> wrote:
> 
> I’m looking for solution to tftpboot or usbboot from u-boot. 
> 
> My ex4300 stuck in u-boot and it can not find kernel. I can connect to tftp 
> but i do not have uImiage / kernel files. 
> 
> How can i load “loader>” to reinstall junos ? Do any of you have experience 
> with this?

https://kb.juniper.net/InfoCenter/index?page=content=KB20464=search

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

Re: [j-nsp] "replace pattern" Command & White Spaces

[Stacy W. Smith]

Can you show a specific example of the problem? What Junos release? What 
platform?

This appears to work for me on a vMX running 16.1R1.11:

[edit]
user@r0# replace pattern "foo bar" with "one two" 

[edit]
user@r0# show | compare 
[edit interfaces ge-0/0/0]
-   description "foo bar";
+   description "one two";

--Stacy


> On Jul 29, 2016, at 5:48 PM, Mark Tinka  wrote:
> 
> Hi all.
> 
> We are trying to replace text in the configuration that contains spaces.
> 
> Documentation suggests this can be done by surrounding the source text
> in quotes. But this does not work.
> 
> JTAC have no answer, which is odd.
> 
> Anyone know how to do this?
> 
> A "| match" works with quotes enclosed, but "replace pattern" does not.
> 
> All help appreciated.
> 
> Mark.
> ___
> 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] Unwanted newline characters in Netconf XML

[Stacy W. Smith]

> On Dec 2, 2015, at 2:31 AM, Dave Bell  wrote:
> 
> On 2 December 2015 at 07:04, Tore Anderson  wrote:
> 
>> Works fine for me? Even in JUNOS versions as old as 11.4. Try:
>> 
>> {master:1}[edit]
>> tore@lab-ex4200# load merge terminal
>> [Type ^D at a new line to end input]
>> /* This is a
>> * multi-line
>> * comment.
>> */
>> protocols{}
>> [edit]
>>  'protocols'
>>warning: statement has no contents; ignored
>> load complete
>> 
> 
> Ah, I was using 'annotate ' which doesn't appear to allow it. This
> method does.

[edit]
user@r0# annotate system "This is a\nmulti-line\ncomment"   

[edit]
user@r0# show | find ^} 
}
apply-groups [ global re0 ];
/* This is a
multi-line
comment */
system {
ports {
console log-out-on-disconnect;
}
}

[edit]
user@r0# show system | display xml 
http://xml.juniper.net/junos/15.1I0/junos;>

/* This is a
multi-line
comment */









[edit]




--Stacy

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

Re: [j-nsp] authentication failure in case of configuration archival over scp

[Stacy W. Smith]

> On Oct 21, 2015, at 10:16 AM, Martin T  wrote:
> 
> SSH server log tells that "error: PAM: Authentication failure for juniper 
> from r1".

> What might cause this?

Assuming the Junos version has not changed on the router, have there been any 
changes to the SSH server, or the OS, on backupserver (potentially including 
"security patches")?

Assuming OpenSSH, you may want to "man sshd_config" and look into the various 
Authentication settings as well as the UsePAM. I suspect some recent 
upgrade may have changed the default value of some of these settings.

I would normally suggest changing the client's config to interoperate with the 
server, but since that's not easy to do on a Junos device, you might look at 
changing the server config.

--Stacy

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

Re: [j-nsp] Disable telnet/ssh access from virtual routers

[Stacy W. Smith]

 On Jul 15, 2015, at 10:46 AM, Victor Sudakov v...@mpeks.tomsk.su wrote:
 
 Stacy W. Smith wrote:
 https://kb.juniper.net/InfoCenter/index?page=contentid=KB23547
 
 The article states it applies to VRFs, but it also applies to routing 
 instances of type virtual-router.
 
 
 This lo0.x interface does not have to have an IP address, does it?

I haven't tested it myself, but I don't believe it has to have an IP address 
configured. It does have to have family inet/inet6 configured because that's 
where you apply the filter, but I don't think it has to have an address 
configured.

--Stacy

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

Re: [j-nsp] Disable telnet/ssh access from virtual routers

[Stacy W. Smith]

https://kb.juniper.net/InfoCenter/index?page=contentid=KB23547

The article states it applies to VRFs, but it also applies to routing instances 
of type virtual-router.

--Stacy

 On Jul 15, 2015, at 10:11 AM, Victor Sudakov v...@mpeks.tomsk.su wrote:
 
 Colleagues,
 
 I have customers' networks connected to routing-instances of type
 virtual-router. These routing-instances are supposed to be isolated
 and use their own address space.
 
 However, a customer can telnet/ssh from their network to the
 virtual-router's IP address effectively telnetting to the main device. 
 
 Is there an elegant way to prevent this from happening, i.e. to permit
 telnet/ssh access from hosts in the inet.0 table but deny from hosts
 from the CUSTOMERXX.inet.0 table?
 
 Thanks in advance for any input.
 
 -- 
 Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
 sip:suda...@sibptus.tomsk.ru
 ___
 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] Comments display (annote command) via show command !!

[Stacy W. Smith]

 On Feb 17, 2015, at 4:20 PM, Harri Makela via juniper-nsp 
 juniper-nsp@puck.nether.net wrote:
 
 Hi There
 http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/swconfig-cli/topic-20962.html
 is there any command which can show us the comments which we have added via 
 annote command other than configuration mode ?
 ThanksHM

show configuration | match \/\*  

--Stacy


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

Re: [j-nsp] ng-mvpn problem

[Stacy W. Smith]

Do understand correctly that the source of the traffic is a logical-system on 
the same router? How are you generating the multicast traffic?

I believe the issue is running PIM on the first-hop interface facing the 
source. The router is expecting either PIM-register encapsulated traffic from 
upstream, or expecting to already have PIM join state.

Can you try removing PIM from lt-1/1/10.770 in routing-instance x and 
configuring lt-1/1/10.770 to forward multicast traffic without running PIM (set 
routing-instance x routing-options multicast interface lt-1/1/10.770)?

If that doesn't help, please provide config of the logical-system containing 
the source, and the outputs of show pim rps extensive [instance 
instance-name], show pim join extensive [instance instance-name], and show 
multicast route extensive [instance instance-name].

If you're still having issue, you may also want to try a different group 
address to avoid any peculiarities with adminstratively-scoped addresses.

--Stacy

On Oct 22, 2013, at 12:20 PM, Mihai mihaigabr...@gmail.com wrote:
 Hello,
 
 lo0.777 has the rp address, and the lt-1/1/10.770 is the link between PE and 
 multicast source (it's a single MX with logical-systems and I already tried 
 the same setup with physical interfaces between PE and CE with the same 
 result):
 
 
 x show configuration interfaces lo0 unit 777
 family inet {
address 20.20.20.111/32;
 }
 
 x show configuration interfaces lt-1/1/10.770
 description x-a;
 encapsulation ethernet;
 peer-unit 771;
 family inet {
address 10.100.1.1/24;
 }
 
 
 On 10/22/2013 08:07 PM, Antonio Sanchez-Monge wrote:
 Hi Mihai,
 
 Doesn't ring a bell at first sight. What's the configuration of interfaces
 lo0.777 and lt-1/1/10.770 ?
 
 Thanks,
 
 Ato
 
 
 
 
 On 10/22/13 6:56 PM, Mihai Gabriel mihaigabr...@gmail.com wrote:
 
 Hello,
 
 I have a basic setup with 2 PE's (X and Z) , one multicast source
 attached
 to X and one receiver attached to Z.
 I configured a NG-MVPN with rsvp-te between  PE's but X doesn't send SA
 autodiscovery to Z so the traffic is dropped.
 
 x show configuration routing-instances
 mvpn {
instance-type vrf;
interface lt-1/1/10.770;
interface lo0.777;
route-distinguisher 1:1;
provider-tunnel {
rsvp-te {
label-switched-path-template {
default-template;
}
}
}
vrf-target target:1:1;
vrf-table-label;
protocols {
pim {
rp {
local {
address 20.20.20.111;
}
}
interface all;
}
mvpn;
}
 }
 
 
 z show configuration routing-instances
 mvpn {
instance-type vrf;
interface lt-1/1/10.772;
route-distinguisher 1:2;
provider-tunnel {
rsvp-te {
label-switched-path-template {
default-template;
}
}
}
vrf-target target:1:1;
vrf-table-label;
protocols {
pim {
interface all;
}
mvpn;
}
 }
 
 
 x show multicast route instance mvpn extensive
 Instance: mvpn Family: INET
 
 Group: 239.1.1.1
Source: 10.100.1.2/32
Upstream interface: lt-1/1/10.770
Session description: Organisational Local Scope
Statistics: 10 kBps, 10 pps, 1291 packets
Next-hop ID: 0
Upstream protocol: PIM
Route state: Active
Forwarding state: Pruned
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 0
Uptime: 00:10:37
 
 Instance: mvpn Family: INET6
 
 x show route receive-protocol bgp 20.20.20.2 table mvpn.mvpn.0
 
 mvpn.mvpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix  Nexthop   MED LclprefAS path
  1:1:2:20.20.20.2/240
 * 20.20.20.2   100I
 
 z show route receive-protocol bgp 20.20.20.1 table mvpn.mvpn.0
 
 mvpn.mvpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
  Prefix  Nexthop   MED LclprefAS path
  1:1:1:20.20.20.1/240
 * 20.20.20.1   100I
 
 x show mpls lsp p2mp
 Ingress LSP: 1 sessions
 P2MP name: 1:1:mvpn:mvpn, P2MP branch count: 1
 To  FromState Rt P ActivePath   LSPname
 20.20.20.2  20.20.20.1  Up 0 *
 20.20.20.2:1
 :1:mvpn:mvpn
 Total 1 displayed, Up 1, Down 0
 
 Egress LSP: 1 sessions
 P2MP name: 1:2:mvpn:mvpn, P2MP branch count: 1
 To  FromState   Rt Style Labelin Labelout LSPname
 20.20.20.1  20.20.20.2  Up   0  1 SE  16-
 20.20.20.1:1:2:mvpn:mvpn
 Total 1 displayed, Up 1, Down 0
 
 Transit LSP: 0 sessions
 Total 0 displayed, Up 0, Down 0
 
 Am i doing something wrong?
 
 Thanks
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
 
 ___
 

Re: [j-nsp] ng-mvpn problem

[Stacy W. Smith]

On Oct 22, 2013, at 2:44 PM, Mihai mihaigabr...@gmail.com wrote:
 Removing PIM fromlt-1/1/10.770 is not a solution because the PE will not 
 learn about the source and the multicast group.

Actually, removing lt-1/1/10.770 from PIM would allow the source and multicast 
group to be learned, and fix the problem (as long as multicast routing was 
still enabled on the lt-1/1/10.770 interface).

The problem is that there's a PIM neighbor relationship between a and x. 
Because of your IP addressing, a is the DR for the a-x LAN.

Because you are injecting traffic with ping and bypass-routing interface 
lt-1/1/10.771 logical-system a is NOT the first-hop router. It's simply acting 
as a multicast source that's pumping traffic with destination IP 225.10.10.10 
out the lt-1/1/10.771 interface.

Logical-system x instance mvpn receives this traffic on lt-1/1/10.770 and does 
not forward it because it is not the DR.

Therefore, the logical-system x instance mvpn doesn't learn about the active 
(S,G).

Another way to solve this problem is disabling PIM on logical-system a. This 
will make lt-1/1/10.770 on logical-system x instance mvpn the DR, and cause it 
to learn about the active S,G (and therefore generate the NG-MVPN Type 5 route).

I have mocked up your configuration in the lab and confirmed that removing PIM 
from logical-system a fixes the issue.

--Stacy


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

Re: [j-nsp] ng-mvpn problem

[Stacy W. Smith]

Yes, that would also work, but since logical-system a is really just emulating 
a multicast source, there's really no need for it to run PIM. A typical 
multicast source would not be running PIM.

--Stacy

On Oct 22, 2013, at 4:44 PM, Antonio Sanchez-Monge amo...@juniper.net wrote:
 Solution would be setting a higher PIM priority in lt-1/1/10.770, so that
 it becomes the DR
 
 
 
 
 On 10/23/13 12:40 AM, Antonio Sanchez-Monge amo...@juniper.net wrote:
 
 That's a brilliant analysis Stacy, I think you nailed it (awaiting Mihai's
 confirmation).
 
 
 On 10/22/13 11:59 PM, Stacy W. Smith st...@acm.org wrote:
 
 On Oct 22, 2013, at 2:44 PM, Mihai mihaigabr...@gmail.com wrote:
 Removing PIM fromlt-1/1/10.770 is not a solution because the PE will
 not learn about the source and the multicast group.
 
 Actually, removing lt-1/1/10.770 from PIM would allow the source and
 multicast group to be learned, and fix the problem (as long as multicast
 routing was still enabled on the lt-1/1/10.770 interface).
 
 The problem is that there's a PIM neighbor relationship between a and x.
 Because of your IP addressing, a is the DR for the a-x LAN.
 
 Because you are injecting traffic with ping and bypass-routing interface
 lt-1/1/10.771 logical-system a is NOT the first-hop router. It's simply
 acting as a multicast source that's pumping traffic with destination IP
 225.10.10.10 out the lt-1/1/10.771 interface.
 
 Logical-system x instance mvpn receives this traffic on lt-1/1/10.770 and
 does not forward it because it is not the DR.
 
 Therefore, the logical-system x instance mvpn doesn't learn about the
 active (S,G).
 
 Another way to solve this problem is disabling PIM on logical-system a.
 This will make lt-1/1/10.770 on logical-system x instance mvpn the DR,
 and cause it to learn about the active S,G (and therefore generate the
 NG-MVPN Type 5 route).
 
 I have mocked up your configuration in the lab and confirmed that
 removing PIM from logical-system a fixes the issue.
 
 --Stacy
 
 
 
 
 
 


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

Re: [j-nsp] ng-mvpn problem

[Stacy W. Smith]

Agreed. 

The lt-1/1/10.770 interface which is in VRF mvpn on logical-system x must have 
PIM enabled (or multicast forwarding enabled). If running PIM, it must be the 
DR.

I wasn't suggesting disabling PIM on the lt-1/1/10.770 interface which is in 
VRF mvpn on logical-system x, just disabling PIM on the remote end of the a-x 
link (in logical-system a).

--Stacy

On Oct 22, 2013, at 4:49 PM, Antonio Sanchez-Monge amo...@juniper.net wrote:
 You need PIM in the interface towards the source IMHO
 
 
 
 On 10/23/13 12:47 AM, Stacy W. Smith st...@acm.org wrote:
 
 Yes, that would also work, but since logical-system a is really just
 emulating a multicast source, there's really no need for it to run PIM. A
 typical multicast source would not be running PIM.
 
 --Stacy
 
 On Oct 22, 2013, at 4:44 PM, Antonio Sanchez-Monge amo...@juniper.net
 wrote:
 Solution would be setting a higher PIM priority in lt-1/1/10.770, so
 that
 it becomes the DR
 
 
 
 
 On 10/23/13 12:40 AM, Antonio Sanchez-Monge amo...@juniper.net
 wrote:
 
 That's a brilliant analysis Stacy, I think you nailed it (awaiting
 Mihai's
 confirmation).
 
 
 On 10/22/13 11:59 PM, Stacy W. Smith st...@acm.org wrote:
 
 On Oct 22, 2013, at 2:44 PM, Mihai mihaigabr...@gmail.com wrote:
 Removing PIM fromlt-1/1/10.770 is not a solution because the PE will
 not learn about the source and the multicast group.
 
 Actually, removing lt-1/1/10.770 from PIM would allow the source and
 multicast group to be learned, and fix the problem (as long as
 multicast
 routing was still enabled on the lt-1/1/10.770 interface).
 
 The problem is that there's a PIM neighbor relationship between a and
 x.
 Because of your IP addressing, a is the DR for the a-x LAN.
 
 Because you are injecting traffic with ping and bypass-routing
 interface
 lt-1/1/10.771 logical-system a is NOT the first-hop router. It's
 simply
 acting as a multicast source that's pumping traffic with destination
 IP
 225.10.10.10 out the lt-1/1/10.771 interface.
 
 Logical-system x instance mvpn receives this traffic on lt-1/1/10.770
 and
 does not forward it because it is not the DR.
 
 Therefore, the logical-system x instance mvpn doesn't learn about the
 active (S,G).
 
 Another way to solve this problem is disabling PIM on logical-system
 a.
 This will make lt-1/1/10.770 on logical-system x instance mvpn the DR,
 and cause it to learn about the active S,G (and therefore generate the
 NG-MVPN Type 5 route).
 
 I have mocked up your configuration in the lab and confirmed that
 removing PIM from logical-system a fixes the issue.
 
 --Stacy
 
 
 
 
 
 
 
 
 
 
 


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

Re: [j-nsp] Correct config for SRX port channel - Cisco

[Stacy W. Smith]

In general, I see no problems with your AE configuration.

Could you define never comes up? Is it the ae0 interface, or the ae0.999 unit 
that is in a down state?

The output of show interfaces terse (at least for the member and ae 
interfaces)

and the output of show lacp interfaces might be helpful.

FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and 
192.168.1.2/31 are not in the same subnet.

--Stacy


On Jul 24, 2013, at 7:27 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 If I have a single SRX3600 device (NOT a cluster), what config (if any...) 
 can I use to match a config on the Cisco side:
 
 int member
  lacp rate fast
  channel-group 20 mode active
 int Po20
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 999
 int Vlan999
  ip address 192.168.1.1 255.255.255.254
 
 I would have thought it would be something like:
 
 chassis {
aggregated-devices {
ethernet {
device-count 2;
}
}
 }
 interfaces {
xe-1/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-1/0/1 {
disable;
}
xe-4/0/0 {
gigether-options {
802.3ad ae0;
}
}
xe-4/0/1 {
disable;
}
ae0 {
vlan-tagging;
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}
unit 999 {
vlan-id 999;
family inet {
address 192.168.1.2/31;
}
}
}
 }
 
 ...but this never comes up. I've seen this before, and I think it's because 
 there's something in the LACP PDUs which disagrees about trunk/access mode. 
 The config works if I set the Cisco side to access, but obviously that's 
 not what I want.
 
 Can you even do this on SRX? I see lots of documents talking about reth 
 interfaces, but AFAICT those are all for chassis clustering, which we don't 
 want to use.
 ___
 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 BGP performance after reboot

[Stacy W. Smith]

On Feb 21, 2013, at 2:31 AM, Sebastian Wiesinger juniper-...@ml.karotte.org 
wrote:
 * Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 13:57]:
 Yes, I agree. But that's a design decision so ATAC is not
 interested. I'll try to get this to Juniper trough my SE but I don't
 know if that'll do any good.
 
 So Juniper is aware that this is a problem (at least for some people)
 and there are people working on it. It's not trivial so I don't expect
 any short-term solutions / improvement.
 
 There is also a NANOG discussion regarding this:
 
 http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html
 
 The current PR seems to be PR836197
 
 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR836197

Sebastian,

PR 836197 is a problem that some customers are seeing, but it is not the 
problem that you reported in this thread. Your issue appears to be (primarily) 
an issue with sampled.

--Stacy


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

Re: [j-nsp] MX80 BGP performance after reboot

[Stacy W. Smith]

Do the KRT error messages go away if you unconfigure sampling? Any change in 
the KRT installation time with sampling turned off?

--Stacy


On Feb 11, 2013, at 4:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org 
wrote:
 Hi,
 
 I noticed that a MX80 takes quite a long time after reboot to put all
 routes into the KRT. Is that normal for that box? It takes around 10
 minutes after BGP is established to get all the routes into the KRT
 and in the meantime we get messages like that every few seconds:
 
 /kernel: rt_pfe_veto: Possible slowest client is sampled. States processed - 
 953500. States to be processed - 21526
 rpd[1298]: RPD_KRT_Q_RETRIES: Route Update: No buffer space available
 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2, rtsm_id 5, 
 msg type 2
 /kernel: rt_pfe_veto: Possible slowest client is sampled. States processed - 
 953500. States to be processed - 21545
 rpd[1298]: RPD_KRT_Q_RETRIES: Route Update: No buffer space available
 /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2, rtsm_id 5, 
 msg type 2
 /kernel: rt_pfe_veto: Possible slowest client is sampled. States processed - 
 953500. States to be processed - 21558
 /kernel: rt_pfe_veto: Possible second slowest client is xdpc0. States 
 processed - 1064571. States to be processed - 23
 
 Oh and DDOS protection is also acting up:
 
 jddosd[1323]: DDOS_PROTOCOL_VIOLATION_SET: Protocol TTL:aggregate is violated 
 at fpc 0 for 1 times, started at 2013-02-11 23:50:39 CET, last seen at 
 2013-02-11 23:50:39 CET
 jddosd[1323]: DDOS_PROTOCOL_VIOLATION_CLEAR: Protocol TTL:aggregate has 
 returned to normal. Violated at fpc 0 for 1 times, from 2013-02-11 23:58:14 
 CET to 2013-02-11 23:58:14 CET
 
 Any experiences from anyone else here?
 
 Regards
 
 Sebastian
 
 -- 
 GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
 '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] i suck at bgp import policy - help?

[Stacy W. Smith]

Ryan,

You're causing unnecessary complication for yourself by using policy 
subroutines (from policy policy name). Here's why you're seeing the behavior 
you reported...

When a policy is called as a subroutine, it simply returns a true or false 
value to the calling policy. A true value means the from clause in the 
calling policy matches, a false value means the from clause in the calling 
policy does not match. In the context of the called policy, a then accept is 
defined as true and a then reject is defined as false. All good so far.

The catch is that the called policy must determine a true or false value 
for every prefix that is evaluated against that policy. In your example, the 
DEFAULT-ROUTE policy returns true for 0.0.0.0/0, but what does it do for all 
other prefixes? The answer is it evaluates all other prefixes against the 
protocol's default policy. In your case, because this is applied as a BGP 
import policy, the BGP default policy is applied. The BGP default policy is 
essentially:

term 1 {
from protocol bgp;
then accept;
}
term 2 {
then reject;
}

This means that any BGP routes will be accepted by your DEFAULT-ROUTE policy. 
Since all the routes it gets evaluated against are BGP routes, the 
DEFAULT-ROUTE policy is always returning a true valued to the calling policy. 
This means every BGP route is matching your DENY-BASICS term and is being 
rejected.

I recommend using a prefix list instead:

[edit policy-options]
user@host# show 
prefix-list DEFAULT-ROUTE {
0.0.0.0/0;
}
policy-statement ALL-TRANSIT-IN {
term DENY-BASICS {
from {
prefix-list DEFAULT-ROUTE;
}
then reject;
}
term GENERAL-ACCEPT {
then {
local-preference 200;
community set COMM-TRANSIT;
accept;
}
}
}


If you really insist on using policy subroutines, then you should always write 
any called policy to return an explicit true or false for all prefixes so 
you don't fall into this trap where the protocol's default policy is evaluated. 
In your case, it would look like this:

[edit policy-options]
user@host# show 
policy-statement ALL-TRANSIT-IN {
term DENY-BASICS {
from policy DEFAULT-ROUTE;
then reject;
}
term GENERAL-ACCEPT {
then {
local-preference 200;
community set COMM-TRANSIT;
accept;
}
}
}
policy-statement DEFAULT-ROUTE {
term 1 {
from {
route-filter 0.0.0.0/0 exact;
}
then accept;
}
term 2 {
then reject;
}
}   


Hope this helps,
--Stacy


On Jan 19, 2013, at 4:30 PM, ryanL ryan.lan...@gmail.com wrote:
 hi. i am certainly doing something wrong.
 
 on a bgp neighbor i have the following policy:
 
 import ALL-TRANSIT-IN;
 
 i've reduced it to basics, which says:
 
 term DENY-BASICS {
from policy DEFAULT-ROUTE;
then reject;
 }
 term GENERAL-ACCEPT {
then {
local-preference 200;
community set COMM-TRANSIT;
accept;
}
 }
 
 where policy DEFAULT-ROUTE is:
 
 from {
route-filter 0.0.0.0/0 exact;
 }
 then accept;
 
 accept AND reject = reject, right? i performed a no-term basic test
 for a reject AND reject, which accepted all routes, so i'm pretty sure
 my head isn't too far up my...
 
 anyways, the above policies unfortunately result in all routes being
 received, but not accepted.
 
 Peer AS  InPkt OutPktOutQ   Flaps Last
 Up/Dwn State|#Active/Received/Accepted/Damped...
 removed  removed 163888184   0   0
 1:15:38 0/431093/0/0 0/0/0/0
 
 if i remove the DENY-BASICS term, all routes go active and get stamped
 with my community and local-pref value.
 
 i've tried other DENY related terms, such as filtering out long
 as-paths, or just RFC1918, or even just spoofs of my own netblock.
 normal stuff. routes stay hidden due to:
 
   State: Hidden Ext
   Inactive reason: Unusable path
 
 so, what am i screwing up on here? this is on 12.2R2.4. i'm
 effectively trying to follow the cymru secure junos bgp template,
 among others.
 
 thanks.
 
 ryan
 ___
 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 VC PFE crashes

[Stacy W. Smith]

On Jan 15, 2013, at 2:57 AM, Dennis Krul | Tilaa den...@tilaa.nl wrote:
 Can you tell the PR number you tried to avoid initially ?
 
 I wasn't trying to avoid it. I just thought it wouldn't be interesting, 
 because it's an internal PR. But here it is: PR843475

I suspect you may have answered a different question than Tima asked.

It looks like you gave us the internal PR number (843475) tracking your current 
issue in 11.4R5 code.

Please also give us the PR number which JTAC claimed would be fixed by your 
upgrade from 10.4 to 11.4R5 per this comment:

 JTAC analysed our core dumps and told us this was a known issue (null pointer 
 exception). It would not be resolved in 10.4 but was resolved in 11.2R5.5, 
 the recommended JTAC release for EX4200. 


Thanks,
--Stacy


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

Re: [j-nsp] Multicast - interop with Cisco

[Stacy W. Smith]

Yes, Auto-RP in the VRF should work.

It's been a while since I've done Rosen configs, but try removing the  
vpn-tunnel-source from the PIM config in your VRF.

--Stacy

On Dec 10, 2012, at 10:14 AM, Peder Bach pederb...@gmail.com wrote:
 Thanks! It works :-)
 
 
 Should this also work in the vrf?
 
 
 Global:
 
 pe...@ar100.nn# run show pim rps
 Instance: PIM.master
 
 address-family INET
 RP address  TypeMode   Holdtime Timeout Groups Group prefixes
 10.224.0.255auto-rp sparse  181 175  1 224.0.0.0/4
 
 
 pe...@ar100.nn show pim rps instance iptv
 Instance: PIM.bynett
 
 address-family INET
 
 address-family INET6
 
 We should get another RP.
 
 
 [edit routing-instances iptv]
 pe...@ar100.nn# show
 instance-type vrf;
 interface ge-0/0/0.0;
 interface lo0.1;
 route-distinguisher 65339:50;
 provider-tunnel {
 pim-asm {
 group-address 239.1.1.1;
 }
 }
 vrf-target target:65339:50;
 vrf-table-label;
 protocols {
 pim {
 dense-groups {
 224.0.1.39/32;
 224.0.1.40/32;
 }
 vpn-tunnel-source 10.224.0.96;
 vpn-group-address 239.1.1.1;
 rp {
 auto-rp discovery;
 }
 }
 interface lo0.1 {
 mode sparse-dense;
 }
 interface ge-0/0/0.0 {
 mode sparse-dense;
 }
 }
 }
 
 
 Add this to your config:
 
 [edit protocols pim]
 user@host# set dense-groups 224.0.1.39/32
 user@host# set dense-groups 224.0.1.40/32
 
 Further info can be found here:
 http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/mcast-pim-auto-rp.html
 


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

Re: [j-nsp] Multicast - interop with Cisco

[Stacy W. Smith]

Auto-RP requires groups 224.0.1.39/32 and 224.0.1.40/32 to operate in dense 
mode. That operation is not automatic in JunOS; it must be configured.

Add this to your config:

[edit protocols pim]
user@host# set dense-groups 224.0.1.39/32
user@host# set dense-groups 224.0.1.40/32

Further info can be found here:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/mcast-pim-auto-rp.html

--Stacy

On Dec 9, 2012, at 9:14 AM, Peder Bach pederb...@gmail.com wrote:
 Hi all..
 
 
 We try to interop draft-rosen with Cisco for IPTV distribution.
 
 Cisco setup run draft-rosen with auto-rp.
 
 show ip pim rp
 Group: 239.1.1.1, RP: 10.224.0.255, v2, uptime 1y30w, expires 00:02:32
 Group: 239.1.1.3, RP: 10.224.0.255, v2, uptime 1y30w, expires 00:02:32
 Group: 239.2.71.15, RP: 10.224.0.255, v2, uptime 1y30w, expires 00:02:32
 Group: 239.2.71.18, RP: 10.224.0.255, v2, uptime 1y30w, expires 00:02:32
 
 Cisco interface towards Juniper P
 
 ip pim query-interval 1
 ip pim sparse-mode
 
 
 After reading this doc, it now seems that Juniper support auto-rp and
 draft-rosen.
 
 http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/mcast-mvpns-draft-rosen-interop.html.
 
 [edit protocols pim]
 pe...@ar99.nn# show
 rp {
auto-rp discovery;
}
 }
 interface all {
mode sparse;
version 2;
 }
 interface fxp0.0 {
disable;
 }
 
 pe...@ar99.nn# run show pim rps
 Instance: PIM.master
 
 address-family INET
 
 address-family INET6
 
 
 
 If I put a static RP it works.
 
 
 Any advice?
 
 Peder
 ___
 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] Error while validating a JunOS

[Stacy W. Smith]

Can you share the current version and existing config? If it really is as 
simple as you say, then I would not expect a problem, but it would be 
interesting to investigate why it's complaining.

--Stacy 

On Nov 29, 2012, at 6:33 PM, Ali Sumsam ali+juniper...@eintellego.net wrote:
 but that will kinda bypass it.
 Should i worry about it or just ignore it?
 
 Regards,
 *Ali Sumsam CCIE*
 *Network Engineer - Level 3*
 eintellego Pty Ltd
 a...@eintellego.net ; www.eintellego.net
 
 Phone: 1300 753 383 ; Fax: (+612) 8572 9954
 
 Cell +61 (0)410 603 531
 
 facebook.com/eintellego
 PO Box 7726, Baulkham Hills, NSW 1755 Australia
 
 The Experts Who The Experts Call
 Juniper - Cisco – Brocade - IBM
 
 
 
 On Fri, Nov 30, 2012 at 12:30 PM, OBrien, Will obri...@missouri.edu wrote:
 
 no-validate
 
 That is, request system software install no-validate blah
 
 
 On Nov 29, 2012, at 7:25 PM, Ali Sumsam wrote:
 
 Hi,
 I have a brand new MX5 router for one of my customers. The only
 configuration I have on this router is
 
 1, one login name and password
 2, IP address on FXP0
 3, telnet and ftp service.
 
 I have uploaded Junos jinstall-ppc-11.2R5.4-export-signed.tgz, which is
 the
 recommended one for MX5 on juniper site.
 
 
 When i try to validate this JunOS, it gives me following error.
 
 mgd: error: configuration check-out failed
 Validation failed
 WARNING: Current configuration not compatible with
 /var/tmp/jinstall-ppc-11.2R5.4-export-signed.tgz
 
 Any suggestion. Can I just ignore this error and live with it?
 
 Regards,
 
 
 *Ali Sumsam CCIE*
 *Network Engineer - Level 3*
 eintellego Pty Ltd
 a...@eintellego.net ; www.eintellego.net
 
 Phone: 1300 753 383 ; Fax: (+612) 8572 9954
 
 Cell +61 (0)410 603 531
 
 facebook.com/eintellego
 PO Box 7726, Baulkham Hills, NSW 1755 Australia
 
 The Experts Who The Experts Call
 Juniper - Cisco – Brocade - IBM
 ___
 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] rib-group requirement for master rib

[Stacy W. Smith]

Configure interface-routes at the [edit routing-instances CUSTOMER-A 
routing-options] hierarchy rather than the [edit routing-options] hierarchy. 
Continue to define rib-groups at the [edit routing-options] hierarchy.

[edit]
root@srx210# show routing-options 
rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
}

[edit]
root@srx210# show routing-instances 
CUSTOMER-A {
instance-type virtual-router;
routing-options {
interface-routes {
rib-group inet FBF-PBR;
}
}
}

[edit]
root@srx210# commit check 
configuration check succeeds


--Stacy


On Nov 28, 2012, at 5:39 PM, Ben Dale bd...@comlinx.com.au wrote:
 Hi All,
 
 I have a requirement for performing Filter-based Forwarding on traffic that 
 is ingressing via a routing-instance (instance-type virtual-router):
 
 show routing-options:
 
 interface-routes {
rib-group inet FBF-PBR;
 }
 
 rib-groups {
FBF-PBR {
import-rib [ CUSTOMER-A.inet.0 FBF-PBR.inet.0 ];
}
 }
 
 Problem I have is that I can't seem to commit without including inet.0 in the 
 rib-group:
 
 root@srx240-lab# commit check 
 [edit routing-options interface-routes]
  'rib-group'
FBF-PBR: primary rib for instance master was not found in ribgroup 
 configuration.
 error: configuration check-out failed
 
 Putting inet.0 in the rib-group isn't desirable, as it exposes direct routes 
 into the RI which I'm trying to hide in the first place.  is there a 
 better/different way to be doing this?
 
 Cheers,
 
 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] pim sparse mode - part 2

[Stacy W. Smith]

We need a lot more information to provide any useful answer.

Please share the relevant config of the three routers and switch.

What IPv6 multicast group address are you using?

Please share the output of the following commands from each of the three 
routers:

show pim join extensive
show pim rps extensive
show multicast route extensive
show route source ip extensive
show mld group detail

--Stacy

On Nov 24, 2012, at 3:16 PM, Giuliano Cardozo Medalha giuli...@wztech.com.br 
wrote:
 people
 
 we did a setup lab for ipv6 multicast routing using juniper srx210 boxea and 
 12.1R4 release
 
 3 routers connected by a switch (ex2200) - star topology
 
 basically we did the configurarion with mld and pim using static rp 
 configuration using loopback of one of the routers
 
 the unicast routes were dynamic learning using is-is 
 
 after create a streaming using vlc in one of the lan interface of router a 
 other clients could not be able to join the multicast v6 group using the same 
 software
 
 is there some special config to be able to do it work fine ?
 
 the ssm mode must be a better config ?
 
 using ipv4 it works ok
 
 if we connect one host directly to another it is possible to join the group 
 and see multicast streaming
 
 does anyone has some similar config that works on this kind of environment ?
 
 thanks a lot
 
 giuliano


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

Re: [j-nsp] Same multicast group from the source

[Stacy W. Smith]

You might want to look at ssm-map-policy.

http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/multicast-ssm-map-for-different-groups-to-different-sources.html

I think it meets your needs, but depending on how dynamic your customer's 
requirements are, it may be cumbersome to maintain.

Here's an example:

[edit]
user@host# show protocols igmp 
interface ge-0/0/0.0 {
ssm-map-policy S1-only;
}
interface ge-0/0/1.0 {
ssm-map-policy S1-and-S2;
}
interface ge-0/0/2.0 {
ssm-map-policy S2-only;
}

[edit]
user@host# show policy-options 
policy-statement S1-and-S2 {
term 1 {
from {
route-filter 224.1.1.1/32 exact;
}
then {
ssm-source [ 1.1.1.1 2.2.2.2 ];
accept;
}
}
}
policy-statement S1-only {
term 1 {
from {
route-filter 224.1.1.1/32 exact;
}
then {
ssm-source 1.1.1.1;
accept;
}
}
}
policy-statement S2-only {
from {  
route-filter 224.1.1.1/32 exact;
}
then {
ssm-source 2.2.2.2;
accept;
}
}



On Nov 22, 2012, at 9:54 AM, Riccardo S dim0...@hotmail.com wrote:
 
 no failover, are completely different data...
 
 Let's imagine we're talking of TV broadcasting and my customer wants receive 
 today only channel S1 but tomorrow also, maybe, channel S2...
 
 Ric
 
 Date: Thu, 22 Nov 2012 17:51:07 +0100
 From: ch...@chrishellberg.com
 To: dim0...@hotmail.com
 CC: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Same multicast group from the source
 
 It depends on what you want to do. Should the receiver receive both 
 sources simultaneously and demultiplex the two? Or do you need failover 
 of some kind?
 
 /Chris
 
 On 22/11/12 5:40 PM, Riccardo S wrote:
 
 
 
 Hi expert team,
 
 I’ve a generic multicast question.
 
 
 
 Let’s say I’ve two different source
 sending different multicast traffic over the same multicast group, how can I
 solve the problem for a customer receiver ?
 
 
 
 S1=1.1.1.1 G1=224.1.1.1
 
 S2=2.2.2.2 G2=224.1.1.1
 
 
 
 Customer receiver is usually running
 IGMPv2 and I cannot force to use IGMPv3.
 
 
 
 Network in the middle between source
 and receiver is not MPLS.
 
 
 
 I’ve thought to NAT multicast group,
 but I’m not sure it works and if anyone has already implemented it…
 
 
 
 Any different solution is
 appreciated…
 
 Tks
 
 Ric
 
 ___
 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] R: Re: R: Re: Same multicast group from the source

[Stacy W. Smith]

Since it is IGMP v2, the receiver will send a (*,G) membership report. This 
will cause traffic for both S1
and S2 to be received and the receiver will have to ignore the unwanted channel.

My understanding of the OPs request was to be able to have the receiver receive 
S1, and not receive S2. That can be accomplished by using the ssm-map-policy to 
convert the (*,224.1.1.1) membership report to a (1.1.1.1,224.1.1.1) PIM join.

--Stacy


On Nov 22, 2012, at 3:15 PM, ch...@chrishellberg.com wrote:

 Almost right. The bit that ssm mapping does is take a igmpv2 group reports 
 and maps them into a PIM-SSM towards the source(s). Thus no need for an 
 RPas if the request were igmpv3
 
 Been years since I've looked at this but from memory you don't even need to 
 do ssm mapping since the rp should join both sources and you'll get a 
 multiplexed stream, which is what you want. If I understand correctly.
 
 /chris
 ---
 
 -Original Message-
 From: Riccardo S dim0...@hotmail.com
 Date: Thu, 22 Nov 2012 21:47:24 
 To: ch...@chrishellberg.com; Stacy W. Smithst...@acm.org
 Cc: juniper-nsp@puck.nether.net
 Subject: R: Re: R: Re: [j-nsp] Same multicast group from the source
 
 As far as i know ssm works with igmp3
 With igmp2 you need to go through rp...
 
 sent with Android
 
 ch...@chrishellberg.com ha scritto:
 
 Yes it does
 ---
 
 -Original Message-
 From: Riccardo S dim0...@hotmail.com
 Date: Thu, 22 Nov 2012 20:56:43 
 To: Stacy W. Smithst...@acm.org
 Cc: ch...@chrishellberg.com; juniper-nsp@puck.nether.net
 Subject: R: Re: [j-nsp] Same multicast group from the source
 
 I cannot force my customer to use igmpv3
 Do not think it works with igmpv2
 
 sent with Android
 
 Stacy W. Smith st...@acm.org ha scritto:
 
 You might want to look at ssm-map-policy.
 
 http://www.juniper.net/techpubs/en_US/junos12.2/topics/topic-map/multicast-ssm-map-for-different-groups-to-different-sources.html
 
 I think it meets your needs, but depending on how dynamic your customer's 
 requirements are, it may be cumbersome to maintain.
 
 Here's an example:
 
 [edit]
 user@host# show protocols igmp 
 interface ge-0/0/0.0 {
  ssm-map-policy S1-only;
 }
 interface ge-0/0/1.0 {
  ssm-map-policy S1-and-S2;
 }
 interface ge-0/0/2.0 {
  ssm-map-policy S2-only;
 }
 
 [edit]
 user@host# show policy-options 
 policy-statement S1-and-S2 {
  term 1 {
  from {
  route-filter 224.1.1.1/32 exact;
  }
  then {
  ssm-source [ 1.1.1.1 2.2.2.2 ];
  accept;
  }
  }
 }
 policy-statement S1-only {
  term 1 {
  from {
  route-filter 224.1.1.1/32 exact;
  }
  then {
  ssm-source 1.1.1.1;
  accept;
  }
  }
 }
 policy-statement S2-only {
  from {  
  route-filter 224.1.1.1/32 exact;
  }
  then {
  ssm-source 2.2.2.2;
  accept;
  }
 }
 
 
 
 On Nov 22, 2012, at 9:54 AM, Riccardo S dim0...@hotmail.com wrote:
 
 no failover, are completely different data...
 
 Let's imagine we're talking of TV broadcasting and my customer wants 
 receive today only channel S1 but tomorrow also, maybe, channel S2...
 
 Ric
 
 Date: Thu, 22 Nov 2012 17:51:07 +0100
 From: ch...@chrishellberg.com
 To: dim0...@hotmail.com
 CC: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Same multicast group from the source
 
 It depends on what you want to do. Should the receiver receive both 
 sources simultaneously and demultiplex the two? Or do you need failover 
 of some kind?
 
 /Chris
 
 On 22/11/12 5:40 PM, Riccardo S wrote:
 
 
 
 Hi expert team,
 
 I’ve a generic multicast question.
 
 
 
 Let’s say I’ve two different source
 sending different multicast traffic over the same multicast group, how 
 can I
 solve the problem for a customer receiver ?
 
 
 
 S1=1.1.1.1 G1=224.1.1.1
 
 S2=2.2.2.2 G2=224.1.1.1
 
 
 
 Customer receiver is usually running
 IGMPv2 and I cannot force to use IGMPv3.
 
 
 
 Network in the middle between source
 and receiver is not MPLS.
 
 
 
 I’ve thought to NAT multicast group,
 but I’m not sure it works and if anyone has already implemented it…
 
 
 
 Any different solution is
 appreciated…
 
 Tks
 
 Ric
 
 ___
 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] next-hop self and RR

[Stacy W. Smith]

Yes, it's a violation of RFC 1966, but RFC 1966 is obsoleted by RFC 4456.

RFC 4456 now includes the wording:

In addition, when a RR reflects a route, it SHOULD NOT modify the
   following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
   Their modification could potentially result in routing loops.

The must not is now a SHOULD NOT.

This is one of those areas where JunOS gives you plenty of rope to hang 
yourself.

You probably want to modify your nh-self policy to only match EBGP learned 
routes.

I can't remember off the top of my head if you do that with from external or 
from route-type external.

--Stacy

On Nov 8, 2012, at 8:45 AM, Mihai Gabriel mihaigabr...@gmail.com wrote:
 Hello,
 
 Is Juniper's implementation of next-hop self on a RR a violation of
 RFC1966?
 
  In some implementations, modification of the BGP path attribute,
   NEXT_HOP is possible. For example, there could be a need for a RR to
   modify NEXT_HOP for EBGP learned routes sent to its internal peers.
   However, it must not be possible for an RR to set on reflected IBGP
   routes as this breaks the basic principle of Route Reflection and
   will result in potential black holeing of traffic.
 
 Testing this feature in a topology with 3 routers, r1 (client) - r3 (rr) -
 r2 (client) , a route originated from r1 and advertised to r2 via  it's RR
 will have a next-hop of RR when an export policy is applied to r2:
 
 mihai@mx5t# run show route receive-protocol bgp 10.0.6.1 logical-system r3
 192.168.10.0
 
 inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
  Prefix  Nexthop   MED LclprefAS path
 * 192.168.10.0/24 10.0.6.1 100I
 
 mihai@mx5t# show protocols bgp group 65000 neighbor 10.0.6.2
 export nh-self;
 
 show policy-options policy-statement nh-self
 from {
protocol bgp;
neighbor 10.0.6.1;
 }
 then {
next-hop self;
 }
 
 mihai@mx5t# run show route advertising-protocol bgp 10.0.6.2 logical-system
 r3 match-prefix 192.168.10.0
 
 inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
  Prefix  Nexthop   MED LclprefAS path
 * 192.168.10.0/24 Self 100I
 ___
 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] IPv6 static default route in routing instance?

[Stacy W. Smith]

Please provide the output of

show route table dmz.inet6.0 :a500:0:2::1

Thanks,
--Stacy

On Jun 12, 2012, at 11:48 PM, Gordon Smith wrote:
 Hi,
 
 Just wondering if anybody's come across this before - default IPv6 static not 
 appearing in the routing instance inet6 table...
 
 Instance is a VRF:
 
 instance-type vrf;
 interface ge-1/1/0.503;
 interface ge-1/1/0.504;
 route-distinguisher 56263:101;
 vrf-import [ reject-all ];
 vrf-export [ reject-all ];
 vrf-table-label;
 routing-options {
graceful-restart;
rib dmz.inet6.0 {
static {
route ::/0 next-hop :a500:0:2::1;
}
}
static {
route 0.0.0.0/0 {
next-hop xxx.x.216.54;
no-readvertise;
}
}
 }
 
 
 Looking at the dmz.inet6.0 table shows directly connected routes, but not the 
 default.
 In contrast, dmz.inet.0 has a v4 default as expected.
 
 I must be doing something wrong here
 
 ___
 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

[Stacy W. Smith]

On May 8, 2012, at 11:58 AM, Alex D. 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.
 
 Regards,
 Alex

I believe this is expected behavior. When you have interfaces with different 
MTUs configured, you will see one of these messages for each PMTU timeout 
period for locally-generated IPv6 multicast traffic (in this case ff02::0005 or 
OSPFv3 hellos) as the new PMTU is discovered for the traffic. 

--Stacy


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

Re: [j-nsp] M-VPN for IPv6

[Stacy W. Smith]

Yes. Juniper has supported BGP-signalled multicast MPLS VPNs (aka NG-MVPN) for 
IPv6 since 10.0.

Only real extra requirement is:

{master}[edit protocols bgp group ibgp]
regress@aslan# set family inet6-mvpn 

in the core, and configuring normal IPv6 unicast/multicast routing in the 
routing-instance.

--Stacy


On May 10, 2012, at 9:08 AM, Muhd Safwan wrote:

 Dear Juniper Expert,
 
 I would like to ask if there are any draft/actual implementation for
 Multicast IPv6 support on MPLS VPN network.
 
 I've been trying to find resource/reference for this subject and i
 would like to deploy this feature if it already exist.
 
 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] Advertising Aggregate route without contributed route

[Stacy W. Smith]

Why not just use a static route for this purpose?

--Stacy

On Apr 1, 2012, at 12:29 PM, Abdul 2012 wrote:

 Hello,
 
 Is it possible to advertise aggregate route to OSPF through export policy
 even when there is no contributing route to this aggregate?
 
 
 I tried to make the aggregate router as Passive but still not advertised to
 routing peer. It's only installed in local routing table when Passive used
 with the aggregate.
 
 
 Thanks
 
 Abdulla
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] JNCIP-SP latest dumps

[Stacy W. Smith]

On Mar 30, 2012, at 11:53 AM, Patrick Okui wrote:
 Dumps aside, most training outfits give a couple of sample exams - 
 they're one of the few ways you can get a feel for the actual exam plus 
 evaluate your own level of preparedness.

and there are practice exams available for this, and other, Juniper exams.

http://www.juniper.net/us/en/training/certification/service_provider_track.html

--Stacy


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

Re: [j-nsp] NG-MVPN flow prob

[Stacy W. Smith]

I can't find documentation to back up my memory, but I vaguely remember that 
J-series wasn't officially supported when RSVP TE P2MP PMSI support was added 
to 8.5. I would begin by trying a more recent JUNOS release on the J6350.

--Stacy

On Feb 20, 2012, at 10:23 PM, Ahsan Khan wrote:

 Yes, you are right.
 
 
 BR/Ahsan
 
 On Tue, Feb 21, 2012 at 10:01 AM, Mark Tinka mti...@globaltransit.netwrote:
 
 On Monday, February 13, 2012 07:54:24 PM Ahsan Khan wrote:
 
 Problem occurs when CE1 (Connected with J6350) source
 starts sending multicast traffic but CE2 (Connected with
 M7i) receiver doesnot receive it
 
 So if I understand you correctly, when the M7i is the Sender
 PE router (and the J6350 is the Receiver PE router), all is
 fine.
 
 But when the J6350 is the Sender PE router (and the M7i is
 now the Receiver PE router), things don't work even though
 the control plane (and data plane signaling, i.e., p2mp
 RSVP-TE) looks good.
 
 Is that about right?
 
 Mark.
 
 ___
 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] next hop behavior within between VRFs

[Stacy W. Smith]

Hi Ido,

Thanks to Harry Reynolds, I also figured out how to accomplish what you wanted 
even for traffic entering from a remote PE.

The trick is to apply the filter-based forwarding policy to the vrf-a 
forwarding table rather than to a specific interface.

This requires to firewall filters with the exact same content (fbf and fbf2 in 
my example). That's because the same firewall filter can not be applied to a 
forwarding table and an interface.

The links below have been updated with the new configs.

--Stacy

On Feb 14, 2012, at 2:09 PM, Stacy W. Smith wrote:

 Hi Ido,
 
 I have a setup that accomplishes most of what you were asking. Take a look at 
 my topology and configs.
 
 Topology: 
 http://dl.dropbox.com/u/13293084/j-nsp_topology/Topology.png
 
 pe1 config
 http://dl.dropbox.com/u/13293084/j-nsp_topology/pe1-config.txt
 
 pe2 config
 http://dl.dropbox.com/u/13293084/j-nsp_topology/pe2-config.txt
 
 In my topology, server, ce-a1, r1, ce-a2, and r2 are all virtual routers on 
 pe2. (That's just because I only had two physical routers to set this up). 
 ce-a1 in my topology would be equivalent to your BRAS device.
 
 In my topology, I use lt interfaces between vrf-b and inet.0, and I run a 
 iBGP session across those lt interfaces from vrf-b to inet.0. The inet.0 side 
 is configured as a route-reflector for the session to vrf-b. There are no lt 
 interfaces between vrf-a and vrf-b. I use filter-based forwarding to force 
 the traffic to the proxy server. My topology and configuration allows me to 
 force the traffic from ce-a1 to the Internet through the proxy server, and 
 also allows me to force the traffic from the Internet to ce-a1 back though 
 the proxy server.
 
 The good news is this doesn't require any changes to the ce-a1 (BRAS) config. 
 There's a single iBGP session from ce-a1 to vrf-a in pe1.
 
 The only thing that doesn't work in my topology is forcing traffic from ce-a2 
 to the Internet through the proxy server. The problem is that there's no 
 interface on pe1 on which to apply filter-based forwarding for the traffic 
 that comes in from a remote PE and is destined for the Internet. The return 
 traffic from the Internet to ce-a2, however, does pass through the proxy 
 server as desired.
 
 FYI, I used the following match conditions in my filter-based forwarding 
 firewall filter:
 
from {
address {
172.16.255.1/32;
172.16.255.2/32;
}
}
 
 This allowed me to test with traceoute and sourcing the different traffic 
 from different IPs.
 
 In your setup, you would probably want something like this instead:
 
from {
protocol tcp;
   port [ http https];
}
 
 I hope this helps. Let me know if you have any questions about my setup.
 
 --Stacy
 
 
 On Feb 13, 2012, at 1:25 PM, Ido Szargel wrote:
 On Feb 9, 2012, at 12:07 AM, Ido Szargel wrote:
 
 Hi Stacy,
 
 Almost all the traffic must go through the servers, those are web 
 filtering proxies and the base requirement of our customer, as this is 
 the service they are selling.
 I'm using FBF as I do not want to maintain static routes to determine 
 that IP x should go through the servers or not but I want this to be 
 dynamic and updated via BGP from VRF A (which is where the LNS routers 
 are) Once the traffic has entered into VRF B then I can use FBF to 
 throw all traffic to the servers , they will do their magic and return 
 it back to the MX which will forward it according to its routing table.
 Traffic in both direction should pass through the servers.
 Currently there is only one site, and only one VRF to catch but there 
 might be more VRFs soon.
 
 Thanks,
 Ido
 
 
 
 -Original Message-
 From: Stacy W. Smith [mailto:st...@acm.org]
 Sent: Thursday, February 09, 2012 7:42 AM
 To: Ido Szargel
 Subject: Re: [j-nsp] next hop behavior within between VRFs
 
 Even more questions...
 
 Are their remote sites that are members of the same VPN as VRF A?
 
 If so, is there a set of servers (VRF B) in each site, or a single hub
 site?
 
 If so, is there Internet access in each site, or a single hub site?
 
 --Stacy
 
 On Feb 8, 2012, at 7:16 PM, Stacy W. Smith wrote:
 
 Ido,
 
 Sorry for the delay in getting back to this.
 
 I think I understand what you're trying to accomplish, but just a 
 couple more questions.
 
 I'm assuming this traffic has a source IP in vrf A and a destination 
 IP in
 inet.0, and that's why you're using FBF to detour the traffic through 
 the servers in vrf B. Is that correct?
 
 Is there anything in vrf B besides the servers that need to catch 
 the
 traffic?
 
 Are the servers in vrf B being used to catch traffic for any other 
 vrfs,
 or only vrf A?
 
 Does traffic from inet.0 also need to pass through the servers in vrf 
 B on
 it's way to vrf A or is it only the traffic in the other direction
 vrfA-vrfB servers-inet.0 that passes through the servers

Re: [j-nsp] NG-MVPN flow prob

[Stacy W. Smith]

I think we will need to see the configs. 

Have you configured non-default PIM SSM ranges? If not, which router(s) are 
acting as the RP(s)? 

--Stacy


On Feb 13, 2012, at 4:54 AM, Ahsan Khan wrote:

 Hi,
 
 I am working on NG-MVPN, my topology is as under:
 
 
 
 – CE1 – PE1 – P – PE2 – CE2 –
 
  |___|
 
   |
 
 Routing instance “test”
 
 
 
 CE1: Cisco 3845   (Source IP: 192.168.1.2)
 
 PE1: J6350 (JUNOS 8.5R3.4) Lo0: 3.3.3.3
 
 P: M7i (JUNOS 8.5R3.4)Lo0: 1.1.1.1
 
 PE2: M7i (JUNOS 8.5R3.4)Lo0: 2.2.2.2
 
 CE2: Cisco 2800   (Source IP: 192.168.2.2)
 
 
 
 I am using p2mp rsvp based tunnel (default template). Everything is working
 fine when a source attached with CE2 (connected with Juniper M7i) starts
 sending multicast traffic, receiver at CE1 (Connected with J6350) end
 receives it perfectly.
 
 Problem occurs when CE1 (Connected with J6350) source starts sending
 multicast traffic but CE2 (Connected with M7i) receiver doesnot receive it
 
 Type 1 and 7 routes are present in route table test.mvpn but traffic is
 unable to flow from PE1-PE2.
 
 
 
 Anyone else faces this issue before or am I missing something here? (“Show
 route table test.mvpn” is attached )
 
 I can share configurations if it helps. Any assist will be appreciated.
 
 
 
 BR/Ahsan
 route table test mvpn.txt___
 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] next hop behavior within between VRFs

[Stacy W. Smith]

Ido,

Sorry for the delay in getting back to this…

I think I understand what you're trying to accomplish, but just a couple more 
questions…

I'm assuming this traffic has a source IP in vrf A and a destination IP in 
inet.0, and that's why you're using FBF to detour the traffic through the 
servers in vrf B. Is that correct?

Is there anything in vrf B besides the servers that need to catch the traffic?

Are the servers in vrf B being used to catch traffic for any other vrfs, or 
only vrf A?

Does traffic from inet.0 also need to pass through the servers in vrf B on it's 
way to vrf A or is it only the traffic in the other direction vrfA-vrfB 
servers-inet.0 that passes through the servers?

Thanks,
--Stacy


On Feb 5, 2012, at 3:16 AM, Ido Szargel wrote:

 Hi Stacy,
 
 Our  topology is
 
 LNS --- MX vrf A --- logical tunnel --- MX vrf B --- logical tunnel --- MX
 inet.0
 
 What we're trying to accomplish is pretty simple, due to special needs of
 our customer most traffic should be forwarded to servers in vrf B,
 In order to do that we advertise a default route from inet.0 into vrf B and
 from vrf B into vrf A, we also advertise the customers routes the other way
 around (from vrf A to vrf B and from vrf B to inet.0)
 Then we need to catch the traffic as it enters vrf B to redirect it to the
 servers, this is what the lt is for.
 
 
 Regards,
 Ido
 
 
 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net
 [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Stacy W. Smith
 Sent: Saturday, February 04, 2012 11:28 PM
 To: Amos Rosenboim
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] next hop behavior within between VRFs
 
 Hi Amos,
 
 I'm not sure I completely understand what you're trying to accomplish. Could
 you give us an example topology diagram?
 
 Thanks,
 --Stacy
 
 On Feb 4, 2012, at 1:20 PM, Amos Rosenboim wrote:
 
 Hi All,
 
 I have a router with two VRFs.
 I need to apply FBF on traffic flowing between the two VRFs so I created a
 logical tunnel that connects the two VRFs.
 The problem is that when importing routes from one VRF to the other the
 next hop is obviously not through the tunnel.
 I am trying to apply an import map that will change the next-hop of
 imported routes to the tunnel interface, but it doesn't work (traffic still
 bypasses the tunnel).
 
 I can obviously skip the VRF import method and simply run BGP over the
 tunnels but I would like to avoid this as it forces me to use route
 refection (the routes I need to announce are learnt via iBGP) and so on.
 Any ideas how to achieve the goal of sharing routes between the VRFs but
 controlling the next hop in each VRF differently ?
 
 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


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

Re: [j-nsp] next hop behavior within between VRFs

[Stacy W. Smith]

Hi Amos,

I'm not sure I completely understand what you're trying to accomplish. Could 
you give us an example topology diagram?

Thanks,
--Stacy

On Feb 4, 2012, at 1:20 PM, Amos Rosenboim wrote:

 Hi All,
 
 I have a router with two VRFs.
 I need to apply FBF on traffic flowing between the two VRFs so I created a 
 logical tunnel that connects the two VRFs.
 The problem is that when importing routes from one VRF to the other the next 
 hop is obviously not through the tunnel.
 I am trying to apply an import map that will change the next-hop of imported 
 routes to the tunnel interface, but it doesn't work (traffic still bypasses 
 the tunnel).
 
 I can obviously skip the VRF import method and simply run BGP over the 
 tunnels but I would like to avoid this as it forces me to use route refection 
 (the routes I need to announce are learnt via iBGP) and so on.
 Any ideas how to achieve the goal of sharing routes between the VRFs but 
 controlling the next hop in each VRF differently ?
 
 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] Filter-based forwarding outside of inet.0?

[Stacy W. Smith]

Hi Clarke,

1) The rib group must be defined under the main instance [edit routing-options 
rib-groups] .
2) The import-rib line in the rib group definition must list the VRF routing 
table first, and the FBF routing table second.
3) The rib group must be applied within the VRF [edit routing-instances VRF 
[edit routing-options interface-routes rib-group inet].


Here's an example, using instance-type virtual-router, but the same principles 
should apply to instance-type vrf:

1) Traffic enters the foo routing-instance on fe-2/0/2.10.
2) If traffic is sourced from 192.168.1.3/32 the next hop is 192.168.3.2 via 
fe-2/0/2.30.
3) If traffic is source from any other address, the next hop is 192.168.2.2 via 
fe-2/0/2.20.

user@host show configuration interfaces fe-2/0/2 
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
filter {
input bar;  firewall filter applied to ingress 
traffic
}
address 192.168.1.1/24;
}
}
unit 20 {
vlan-id 20;
family inet {
address 192.168.2.1/24;
}
}
unit 30 {
vlan-id 30;
family inet {
address 192.168.3.1/24;
}
}

user@host show configuration routing-options
rib-groups {
fbf {   rib group defined in 
master instance
import-rib [ foo.inet.0 fbf.inet.0 ];   vr table 1st, fbf 
table 2nd
}
}

user@host show configuration routing-instances  
fbf {  forwarding instance
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.3.2;   next-hop only 
reachable via foo.inet.0
}
}
}
foo {vr instance
instance-type virtual-router;
interface fe-2/0/2.10;  ingress interface
interface fe-2/0/2.20;  1st egress interface
interface fe-2/0/2.30;  2nd egress interface
routing-options {
interface-routes {
rib-group inet fbf;   copy interface routes to 
fbf.inet.0 using the fbf rib group 
}
static {
route 0.0.0.0/0 next-hop 192.168.2.2;   default route for 
traffic that's accepted by the bar firewall filter
}
}
}

user@host show configuration firewall 
family inet {
filter bar {
term 1 {
from {  criteria for traffic that 
should be forwarded via FBF
source-address {
192.168.1.3/32;
}
}
then {
routing-instance fbf;using fbf.inet.0 for forwarding 
lookup
}
}
term 2 {
then accept;accept everything else and use default 
foo.inet.0 for forwarding lookup
}
}
}

user@host show route table foo 

foo.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0  *[Static/5] 00:45:34
 to 192.168.2.2 via fe-2/0/2.20default 
route for non fbf traffic
192.168.1.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.10
192.168.1.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.10
192.168.2.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.20
192.168.2.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.20
192.168.3.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.30
192.168.3.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.30


user@host show route table fbf

fbf.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0  *[Static/5] 00:37:17
 to 192.168.3.2 via fe-2/0/2.30   default route 
for fbf traffic
192.168.1.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.10
192.168.1.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.10
192.168.2.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.20
192.168.2.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.20
192.168.3.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.30
192.168.3.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.30


Hope this helps. If the FBF next-hop is across the MPLS core and learned via 
MP-BGP, you might have to get a little more creative in the application of your 
rib-group, but otherwise the same concepts should apply.

Let me know if you hit any more roadblocks.

--Stacy


On Jan 31, 2012, at 4:16 PM, Clarke Morledge wrote:

 I am still trying to wrap my head around FBF, and I am stuck on how to 
 achieve a Cisco-like PBR forcing a packet that matches a set of conditions to 
 go to a different next-hop inside a VRF.  The problem I have is when the new 
 next-hop can only be resolved within the VRF, NOT the default routing 
 instance (inet.0).
 
 Let's say I am trying to create this forwarding 

Re: [j-nsp] PIM neighbor not coming up on MVPN

[Stacy W. Smith]

Rosen or BGP-signalled MVPN?

If BGP-signalled, what type of provider tunnel?

Which PIM neighbor is not coming up?

--Stacy


On Nov 30, 2011, at 8:46 AM, Jose María Carrera wrote:

 Hello Experts
 
 One questions regarding the use of MVPN (JUNOS 10.4)
 
 I read that the tunnel-services statement has to be configured under the 
 [chassis hardware pic]
 But the question is: does it have to be configured on all the routers along 
 the path to the other PE router?
 The setup is like this:
 
 CE (receiver) PE1--P1P2-PE2--CE (RP)---source
 
 Does it need to be configured on PE1, P1, P2 and PE2? Or only on the PE 
 routers, which are running the MVPN ?
 
 Thanks for your help. Really appreciated
 
 Jose Maria
 
 
 
 
 Por favor, antes de imprimir este correo, valore si es estrictamente 
 necesario. La naturaleza y el medio ambiente lo agradecerán.
 
 
 
 Le informamos, como destinatario de este mensaje, que el correo electrónico y 
 las comunicaciones por medio de Internet no permiten asegurar ni garantizar 
 la confidencialidad de los mensajes transmitidos, así como tampoco su 
 integridad o su correcta recepción, por lo que TELECABLE DE ASTURIAS, S.A.U 
 no asume responsabilidad alguna por tales circunstancias.
 Si no consintiese en la utilización del correo electrónico o de las 
 comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro 
 conocimiento de manera inmediata. Este mensaje va dirigido, de manera 
 exclusiva, a su destinatario y contiene información confidencial y sujeta al 
 secreto profesional, cuya divulgación no está permitida por la ley. En caso 
 de haber recibido este mensaje por error, le rogamos que, de forma inmediata, 
 nos lo comunique mediante correo electrónico remitido a nuestra atención o a 
 través del teléfono (+ 34) 984191000 y proceda a su eliminación, así como a 
 la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la 
 distribución, copia o utilización de este mensaje, o de cualquier documento 
 adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la 
 ley.
 
 
 
 
 ___
 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] L2VPN Active Route Selection

[Stacy W. Smith]

Hi Zaid,

Apparently I sent this answer only to Eric instead of the rest of the list.

--Stacy


 -Original Message-
 From: Stacy W. Smith [mailto:st...@acm.org]
 Sent: Wednesday, June 29, 2011 12:32 PM
 To: Eric Van Tol
 Subject: Re: [j-nsp] L2VPN Active Route Selection
 
 Eric,
 
 FYI, I think I figured out the answer to this. Seems the path
 selection algorithm for the L2VPN address family is completely
 different from the normal path selection algorithm (Section 9.1.2.2
 from RFC4271).
 
 The L2VPN route selection algorithm can be found in Section 3.4.1 of
 http://tools.ietf.org/html/draft-kompella-l2vpn-vpls-multihoming-02.
 
 --Stacy




On Nov 2, 2011, at 3:12 PM, Zaid Hammoudi wrote:

 Eric,
 
 Did you figure this out? I am having the same problem except with VPLS...
 
 
 Thanks,
 
 -Zaid
 
 
 On Mon, Jun 27, 2011 at 10:51, Eric Van Tol e...@atlantech.net wrote:
 
 -Original Message-
 From: Stacy W. Smith [mailto:st...@acm.org]
 Sent: Monday, June 27, 2011 12:34 PM
 To: Eric Van Tol
 Cc: 'Juniper-Nsp'
 Subject: Re: [j-nsp] L2VPN Active Route Selection
 
 Do you have anything configured under [edit protocols bgp path-
 selection]? Specifically, do you happen to have cisco-non-
 deterministic configured?
 
 --Stacy
 
 No, I do not.  The BGP config on the PE is pretty bare - no options
 besides the family:
 
 admin@lab.router# show protocols bgp | display inheritance
 local-address 10.18.20.46;
 group 65000-dr {
   type internal;
   family inet {
   unicast;
   }
   family inet-vpn {
   unicast;
   }
   family l2vpn {
   signaling;
   }
   export ibgp-car_to_dr;
   peer-as 7784;
   neighbor 10.18.20.72;
   neighbor 10.18.20.73;
 }
 group 65000-vpn {
   type internal;
   family inet-vpn {
   unicast;
   }
   family l2vpn {
   signaling;
   }
   neighbor 10.18.20.10;
 }
 
 I thought about configuring 'bgp-always-compare-med' or
 'cisco-non-deterministic', but figured it would be pointless, because the
 MEDs are all equal, and thus, the options wouldn't have any effect.
 
 Thanks,
 evt
 
 ___
 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] Problem with IGMP on MX480 10.4R7

[Stacy W. Smith]

In your output, I see:

Upstream protocol: MVPN


Is the core of your network a Rosen MVPN or NG-MVPN? If NG-MVPN, is it 
operating in rpt-spt mode, or the default spt-only mode?

--Stacy


On Nov 2, 2011, at 3:16 AM, Jerzy Pawlus wrote:

 
 
 Hi,
 
 I have a problem with explicit joining of a multicast group if such
 group is already created on the switch. MX seems to reject IGMP joins
 and only after router igmp query to all host this group can be joined.
 There is no problem if the group does not exist yet.
 
 1. There is no 239.239.2.2 and the group can be joined:
 
 09:36:20.969250 IP 10.202.71.229  239.239.2.2: igmp v2 report 239.239.2.2
 
 Group: 239.239.2.2
Source: 10.200.200.203/32 
Upstream interface: ge-5/1/4.0
Session description: Organization-Local Scope
Statistics: 454 kBps, 337 pps, 7845 packets
Next-hop ID: 0
Upstream protocol: PIM
Route state: Active
Forwarding state: Pruned
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 0
 
 
 2. When the group 239.239.2.1 exists:
 
 Group: 239.239.2.1
Source: (null)/0  
Upstream interface: ge-5/1/4.0
Downstream interface list: 
xe-4/1/0.0
Session description: Organization-Local Scope
Statistics: 0 kBps, 0 pps, 0 packets
Next-hop ID: 1048926
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 6
 
 Group: 239.239.2.1
Source: 10.200.200.203/32 
Upstream interface: ge-5/1/4.0
Downstream interface list: 
xe-4/1/0.0
Session description: Organization-Local Scope
Statistics: 637 kBps, 474 pps, 350407 packets

 
 09:39:55.236311 IP 10.202.71.229  239.239.2.1: igmp v2 report 239.239.2.1
 09:39:55.236311 IP 10.202.71.229  239.239.2.1: igmp v2 report 239.239.2.1
 
 above joins are ignored and the:
 
 Wrong incoming interface notifications: 6 counter is increased.
 
 
 3.  When the MX sends 
 
 09:41:15.136068 IP 10.202.71.225  224.0.0.1: igmp query v3
 
 and the host responds with:
 
 09:41:24.071645 IP 10.202.71.229  224.0.0.22: igmp v3 report, 4 group 
 record(s)
 
 
 239.239.2.1 is joined 
 
 Group: 239.239.2.1
Source: (null)/0  
Upstream interface: ge-5/1/4.0
Downstream interface list: 
ge-5/0/0.797 xe-4/1/0.0
Session description: Organization-Local Scope
Statistics: 0 kBps, 0 pps, 0 packets
Next-hop ID: 1048806
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 6
 
 Group: 239.239.2.1
Source: 10.200.200.203/32 
Upstream interface: ge-5/1/4.0
Downstream interface list: 
ge-5/0/0.797 xe-4/1/0.0
Session description: Organization-Local Scope
Statistics: 637 kBps, 948 pps, 6602 packets
Next-hop ID: 1048807
Upstream protocol: MVPN 
Route state: Active 
 
 
 Can you help?
 
 
 Jurek
 
 ___
 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] ping: sendto: Operation not permitted in LAN

[Stacy W. Smith]

Martin,

I think the fact that any of the pings are succeeding is accidental.

Based on my initial glance at your firewall filter, you are not permitting ICMP 
echo request messages and the final term drop is discarding traffic. I would 
therefore, expect all pings to fail completely. The reason some pings are 
succeeding is due to the term established in your firewall filter.

One of the peculiarities of JunOS firewall filters is that specifying a match 
condition for a higher-level protocol does NOT automatically assume the 
corresponding lower-level protocol. So, you have:

...
term established {
   from {
   tcp-established;
   }
   then {
   count established;
   accept;
   }
 }
…

Because you did not ALSO specify from protocol tcp in this term, this 
condition is applied to all IPv4 traffic, not just TCP traffic. Therefore, any 
packet that has the either bit set in what would be the position for the ACK or 
RST TCP flags, if it were actually a TCP packet, will match this term.

The bit positions that would be the ACK or RST TCP flags on a TCP packet are in 
the data portion of an ICMP echo request packet. If the data in the ICMP echo 
request packet happen's to have one of these two bit positions set, it will be 
accepted by term established. If it doesn't it will be denied by term drop. 
Those denies will result in the ping: sendto: Operation not permitted message 
you are seeing. I believe JunOS increments the data pattern in each ICMP echo 
request message, and that is why you are seeing some packets succeed and other 
fail.

Bottom line:

Add protocol tcp to the from clause of term established

If you also want to permit ICMP echo request messages, add an additional term 
to do so.

--Stacy


On Aug 18, 2011, at 6:21 AM, Martin T wrote:

 I have a ge-0/0/0 interface in Juniper M20(JUNOS 9.4R4.5), which has
 unit 10 configured to it. Configuration of the interface is basically
 following:
 
ge-0/0/0 {
unit 10 {
family inet {
rpf-check;
mtu 1500;
filter {
output fw-out;
}
address 192.168.1.14/28;
}
}
}
 
 
 As you can see, there is a firewall applied to ge-0/0/0.10.
 Configuration of the fw-out is following:
 
 firewall {
filter fw-out {
term GoogleDNS {
from {
source-address {
8.8.8.8/32;
8.8.4.4/32;
}
protocol udp;
source-port 53;
}
then {
count GoogleDNS;
accept;
}
}
term established {
from {
tcp-established;
}
then {
count established;
accept;
}
}
term management {
from {
source-address {
10.10.10.0/24;
}
}
then {
count management;
accept;
}
}
term drop {
then {
count drop;
discard;
}
}
}
 }
 
 
 In case I ping between servers in 192.168.1.0/28 network, the
 connection is fine. There is no packet loss between them. However, if
 I ping for example 192.168.1.3 from M20, the results are following:
 
 
 PING 192.168.1.3 (192.168.1.3): 1400 data bytes
 1408 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=2.301 ms
 ping: sendto: Operation not permitted
 1408 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=1.440 ms
 1408 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=1.454 ms
 1408 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=1.491 ms
 1408 bytes from 192.168.1.3: icmp_seq=5 ttl=64 time=1.433 ms
 1408 bytes from 192.168.1.3: icmp_seq=6 ttl=64 time=1.411 ms
 ping: sendto: Operation not permitted
 1408 bytes from 192.168.1.3: icmp_seq=8 ttl=64 time=1.540 ms
 ping: sendto: Operation not permitted
 1408 bytes from 192.168.1.3: icmp_seq=10 ttl=64 time=1.762 ms
 1408 bytes from 192.168.1.3: icmp_seq=11 ttl=64 time=1.972 ms
 1408 bytes from 192.168.1.3: icmp_seq=12 ttl=64 time=1.451 ms
 ping: sendto: Operation not permitted
 1408 bytes from 192.168.1.3: icmp_seq=14 ttl=64 time=1.450 ms
 ping: sendto: Operation not permitted
 1408 bytes from 192.168.1.3: icmp_seq=16 ttl=64 time=46.920 ms
 1408 bytes from 192.168.1.3: icmp_seq=17 ttl=64 time=1.428 ms
 
 
 The same applies to every host in 192.168.1.0/28 network. If I ping
 the M20(192.168.1.14) from servers there is same amount of packet
 loss. Any ideas, what might cause this ping: sendto: Operation not
 permitted? If additional information is needed, please ask :)
 
 
 regards,
 martin
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Matching communities in 'show route receive-protocol bgp' command

[Stacy W. Smith]

I just tried to replicate your problem (on an old version of JunOS), and the 
community knob works as expected for me.

root@j6300 show version 
Hostname: j6300
Model: j6300
JUNOS Software Release [9.3S9]

root@j6300 show route receive-protocol bgp 192.168.0.1 detail table R1.inet.0  


R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 192.168.200.0/25 (1 entry, 1 announced)
 Accepted
 Nexthop: 192.168.0.1
 AS path: 1 I
 Communities: 1:1

root@j6300 show route receive-protocol bgp 192.168.0.1 community 1:1   


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

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 
hidden)

R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix  Nexthop  MED LclprefAS path
* 192.168.200.0/25192.168.0.1 1 I

 
What version of JunOS are you using? What platform?

Can you also provide us with the output 'show route ams-ix.net extensive table 
World.inet.0'?

Thanks,
--Stacy

On Jul 6, 2011, at 8:29 AM, Alexander Shikoff wrote:

 Hello,
 
 I have a problem with matching communities in 'show route receive-protocol 
 bgp' command.
 For example, I have a route:
 
 minot...@br1-gdr.ki show route ams-ix.net receive-protocol bgp 77.88.200.133 
 detail table World.inet.0 
 
 World.inet.0: 362279 destinations, 720396 routes (358851 active, 9 holddown, 
 3907 hidden)
 * 91.200.16.0/22 (2 entries, 1 announced)
 Accepted
 Nexthop: 77.88.200.133
 AS path: 21011 1200 I
 AS path: Recorded
 Communities: 21011:400 21011:6777 21011:64528 31445:400
 
 Now I'm trying to filter all routes from 77.88.200.133 peer with 21011:64528
 community:
 
 minot...@br1-gdr.ki show route receive-protocol bgp 77.88.200.133 community 
 21011:64528  
 
 And output is empty.
 
 Then I tried to match community via policy: 
 minot...@br1-gdr.ki show configuration policy-options community Netherlands 
 members 21011:64528;
 
 minot...@br1-gdr.ki show route receive-protocol bgp 77.88.200.133 
 community-name Netherlands
 
 And output is empty again.
 
 Could please someone give an example of right command?
 Thanks in advance!
 
 -- 
 MINO-RIPE
 ___
 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] Matching communities in 'show route receive-protocol bgp' command

[Stacy W. Smith]

OK. Thanks for the additional details. That allows me to replicate the behavior 
you are seeing.

It seems the 'community' argument to 'show route' always evaluates post import 
policy even when 'receive-protocol' is specified.

Here's an example.

Route is received with community 1:1.

root@j6300 show route receive-protocol bgp 192.168.0.1 detail 

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

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 
hidden)

R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
* 192.168.200.0/25 (1 entry, 1 announced)
 Accepted
 Nexthop: 192.168.0.1
 AS path: 1 I
 Communities: 1:1

My import policy uses 'community set' to replace the community with 2:2.

root@j6300 show route protocol bgp detail 

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

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 
hidden)

R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
192.168.200.0/25 (1 entry, 1 announced)
*BGPPreference: 170/-101
Next hop type: Router, Next hop index: 568
Next-hop reference count: 2
Source: 192.168.0.1
Next hop: 192.168.0.1 via lt-0/0/0.1, selected
State: Active Ext
Local AS: 2 Peer AS: 1
Age: 2:24 
Task: BGP_1_2.192.168.0.1+179
Announcement bits (1): 0-KRT 
AS path: 1 I
Communities: 2:2
Accepted
Localpref: 100
Router ID: 192.168.255.254


Now I can no longer match on 1:1.

root@j6300 show route receive-protocol bgp 192.168.0.1 community 1:1

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

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 
hidden)

R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)


But I can match on 2:2, even when 'receive-protocol' is specified.

root@j6300 show route receive-protocol bgp 192.168.0.1 community 2:2

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

__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2 
hidden)

R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  Prefix  Nexthop  MED LclprefAS path
* 192.168.200.0/25192.168.0.1 1 I


I suspect this is because each argument to 'show route' is evaluated 
independently. I'm not aware of a way to change this behavior.

Would it be acceptable to change your import policies to use 'community add' 
rather than 'community set'? That would be a potential workaround.

--Stacy

On Jul 6, 2011, at 10:04 AM, Alexander Shikoff wrote:

 On Wed, Jul 06, 2011 at 09:50:55AM -0600, Stacy W. Smith wrote:
 I just tried to replicate your problem (on an old version of JunOS), and the 
 community knob works as expected for me.
 
 root@j6300 show version 
 Hostname: j6300
 Model: j6300
 JUNOS Software Release [9.3S9]
 
 root@j6300 show route receive-protocol bgp 192.168.0.1 detail table 
 R1.inet.0  
 
 R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
 * 192.168.200.0/25 (1 entry, 1 announced)
 Accepted
 Nexthop: 192.168.0.1
 AS path: 1 I
 Communities: 1:1
 
 root@j6300 show route receive-protocol bgp 192.168.0.1 community 1:1

 
 inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
 
 __juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 
 2 hidden)
 
 R1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
  PrefixNexthop  MED LclprefAS path
 * 192.168.200.0/25192.168.0.1 1 I
 
 
 What version of JunOS are you using? What platform?
 JunOS 10.3R3.7
 Juniper MX80-48T
 
 Can you also provide us with the output 'show route ams-ix.net extensive 
 table World.inet.0'?
 minot...@br1-gdr.ki show route ams-ix.net extensive table World.inet.0 
 
 World.inet.0: 362220 destinations, 720282 routes (358772 active, 30 holddown, 
 3907 hidden)
 91.200.16.0/22 (2 entries, 1 announced)
 TSI:
 KRT in-kernel 91.200.16.0/22 - {77.88.200.133}
 Destination class: to-World
 Source class: from-World
*BGPPreference: 170/-111
Next hop type: Router, Next hop index: 711
Next-hop reference count: 760367
Source: 77.88.200.133
Next hop: 77.88.200.133 via ge-1/0/1.1252, selected
State: Active Ext
Peer AS: 21011
Age: 1w3d 5:47:14 
Task: BGP_21011.77.88.200.133+56251
Announcement bits (4): 0-RT 1-KRT 2-rt-export 4-Resolve tree 2 
AS path: 21011 1200 I
AS path

Re: [j-nsp] Static AnyCast PIM + MSDP not working

[Stacy W. Smith]

Hi Doug,

Disable PIM completely on SRX100-1. That device is the source of your multicast 
traffic, but doesn't need to participate in PIM, just like a normal mcast 
source would not participate in PIM.

Your output shows that SRX100-1 has become the DR for the link between SRX100-1 
and J1. Since J1 is not the DR on the interface where it's receiving the mcast 
traffic, it's not going to forward mcast traffic and in-turn is not going to 
establish PIM/MSDP state. Disabling PIM on SRX100-1 will avoid this problem.

Also, make sure you add the interface option to the ping you are originating 
on SRX100-1 to force the traffic out the appropriate interface toward J1.

If you still have problems, please include the output of: show multicast route 
extensive, show pim rps extensive, and show pim join extensive on all the 
routers.

--Stacy


On Jun 28, 2011, at 3:50 PM, Doug Hanks wrote:

 Hello experts,
 
 I'm new to multicast and I'm having some configuration issues.  I'm 
 configuring a static anycast PIM with 2 RPs.  I'm using msdp between the 2 
 RPs.  I have a directly attached multicast source to the first RP, and a 
 directly attached multicast receiver on the other RP.  The goal is to create 
 a successful POC demonstrating static anycast RPs with multicast source and 
 listener using different RPs.
 
 I am unable to ping from SRX100-1 (ping bypass-routing ttl 10 225.0.0.1) to 
 the receiver SRX100-2 (igmp static group 225.0.0.1 and sap listener 
 225.0.0.1).
 
 One thing I noticed is that the RP attached to the multicast source shows the 
 S,G, but it isn't using msdp to transfer the group information to the other 
 RP.
 
 What am I doing wrong?
 
 Topology http://i.imgur.com/pU31g.png
 J1 http://pastebin.com/8x87Jgy3
 J2 http://pastebin.com/SHRKyWBB
 SRX100-1 http://pastebin.com/0ug1kZcC
 SRX100-2 http://pastebin.com/JL4KeGRw
 
 Thank you,
 
 
 Doug Hanks
 Systems Engineer
 JNCIP-M/T #1441
 
 
 
 ___
 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 LLDP issue with vlan-tagging

[Stacy W. Smith]

I hate trying to read IEEE standards, but after a cursory glance I would agree 
that the behavior your seeing on the vlan-tagged family inet interface is not 
correct.

I didn't see anything specifying one way or another in the 802.1AB-2005 (LLDP) 
standard, but the 802.1Q-2005 standard says this in Table 9-2: The null VLAN 
ID. Indicates that the tag header contains only priority information; no VLAN 
identifier is present in the frame. This VID value shall not be configured as a 
PVID or a member of a VID Set, or configured in any Filtering Database entry, 
or used in any Management operation.

I interpret or used in any Management operation to exclude the use of a vlan 
tag value of 0 for LLDP frames.

Of course the simple fact that the two different configuration are producing 
different frame formats should be enough to get JTAC to investigate more 
thoroughly.

--Stacy

On May 10, 2011, at 3:11 AM, Jeff Wheeler wrote:

 I find that EX4200 with interfaces configured with vlan-tagging and
 layer-3 sub-interfaces, as opposed to family ethernet-switching and
 routed VLAN interfaces, transmit LLDP frames differently.  I do not
 think this is the correct behavior, but I would appreciate comments.
 
 The interfaces configured as follows:
 interface xe-1/1/1 {
  vlan-tagging;
  unit 3911 {
vlan-id 3911;
family inet {
  address 192.0.2.1/24;
}
  }
 }
 produces LLDP frames that appear like this:
 08:39:23.892264 Out 00:19:e2:51:86:99  01:80:c2:00:00:0e, ethertype
 802.1Q (0x8100), length 68: vlan 0, p 0, ethertype LLDP, LLDP,0
 
 Notice the outer-ethertype 0x8100 rather than 0x88CC.  Surely this is
 not correct.
 
 Changing the configuration to something like:
 interface xe-1/1/1 {
  unit 0 {
family ethernet-switching {
  port-mode trunk;
  vlan {
members 3911;
  }
}
  }
 }
 interface vlan.3911 {
  family inet {
address 192.0.2.1/24;
  }
 }
 vlan v3911 {
  vlan-id 3911;
  l3-interface vlan.3911;
 }
 produces LLDP frames which appear normal:
 08:50:01.121422 Out 00:19:e2:51:86:bf  01:80:c2:00:00:0e, ethertype
 LLDP (0x88cc), length 74: LLDP, name J3K3.1250RL, length 60
 
 In the first case, my neighboring devices are dropping the LLDP
 frames, and thus they do not learn about the advertising device.  In
 the later case, everything works as expected.  With both
 configurations, the EX4200 itself does detect the neighboring
 LLDP-speakers correctly.
 
 -- 
 Jeff S Wheeler j...@inconcepts.biz
 Sr Network Operator  /  Innovative Network Concepts
 
 ___
 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] Searching by prefix length

[Stacy W. Smith]

One way you could do this would be to write and commit a policy that matches 
the conditions you want and accepts them, then discards everything else. Then, 
use the 'test policy' command to display the output.

user@router test policy foo 0/0 

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

10.210.58.0/26 *[Direct/0] 1w1d 01:48:38
 via ge-2/0/0.0

Policy foo: 1 prefix accepted, 1 prefix rejected


Note that the first argument to 'test policy' is the name of the policy to 
test. The second argument is the range of active prefixes in your local routing 
table which should be used as input to the routing policy. By using 0/0, your 
evaluating the policy against all active IPv4 routes in your routing table. 
Only routes that are accept by the policy will be displayed in the output.

Note, use 'test policy foo ::/0' to evaluate the policy against active IPv6 
prefixes in inet6.0.

--Stacy


On May 5, 2011, at 3:51 PM, Bill Blackford wrote:

 I want to be able to search the route table for prefixes announced
 from a certain peer and of a range of lengths. ex, give me all routes
 announced from and through HE but filter by 'upto' /19.
 
 so,
 
 show route aspath-regex .*6939.* terse  upto /19
 
 or,
 
 show route receive-protocol bgp ###.###.###.### aspath-regex .*6939.*
 terse upto /19
 
 Is there way to do this?
 
 The best I've come up with is 'sh route aspath-regex .*6939.* | except
 /2' This is obviously not a very flexible approach.
 
 Thank you,
 
 -b
 
 
 -- 
 Bill Blackford
 Network Engineer
 
 Logged into reality and abusing my sudo privileges.
 ___
 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] selecting 2ndary addresses to advertise in OSPF

[Stacy W. Smith]

You can actually specify an IP as an argument to the 'interface' command under 
[edit protocols ospf area area] instead of the normal interface name. When 
you do so, it only advertises the single prefix.

Something like this should meet your need:

user@host show configuration interfaces lo0 
unit 0 {
family inet {
address 100.252.3.2/32 {
primary;
preferred;
}
address 100.252.3.1/32;
address 100.255.196.1/32;
address 100.253.246.1/32;
}
}

user@host show configuration protocols ospf 
area 0.0.0.3 {
interface 100.252.3.2 {
passive;
}
interface 100.252.3.1 {
passive;
}
}

user@host show ospf database detail 

OSPF link state database, Area 0.0.0.3
 Type   ID   Adv Rtr   Seq  Age  Opt  Cksum  Len 
Router  *100.252.3.2  100.252.3.2  0x800333  0x22 0xfb8c  48
  bits 0x0, link count 2
  id 100.252.3.2, data 255.255.255.255, Type Stub (3)
  TOS count 0, TOS 0 metric 0
  id 100.252.3.1, data 255.255.255.255, Type Stub (3)
  TOS count 0, TOS 0 metric 0


Unfortunately, I don't believe you can do anything equivalent for OSPF3.

--Stacy


On Feb 22, 2011, at 1:43 PM, Bit Gossip wrote:

 Experts,
 in a setup like this one, once lo0.0 is put in ospf ALL of it addresses
 are advertised by OSPF. Is it possible to select which addresses to
 advertise?
 Redistributing direct is not an option because will make them external.
 Thanks,
 bit.
 
lo0 {
unit 0 {
family inet {
address 100.252.3.2/32 {
primary;
preferred;
}
address 100.252.3.1/32;
address 100.255.196.1/32;
address 100.253.246.1/32;
 
 ospf {
area 0.0.0.3 {
interface lo0.0 {
passive;
 
 
 ___
 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] Taking full BGP table and filtering on SRX210

[Stacy W. Smith]

On Jan 25, 2011, at 8:16 AM, Mark Kamichoff wrote:
 
 BGP routes on Junos are stored in the adjacency-rib-in table (show route
 receive-protocol bgp $peer) even if you filter them from being installed
 into inet.0 or inet6.0.

You are correct that this is the default behavior of JUNOS. You can disable 
this with 'keep none'. I suspect this would be necessary to have any hope of 
the OP's objective of dealing with a full feed on an SRX210.

--Stacy


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

Re: [j-nsp] multicast questions

[Stacy W. Smith]

My first guess is that traffic is not making it on the RPT from the RP to the 
receiver's DR, and therefore the receiver's DR is not attempting to join the 
SPT.

Can you provide the output of show multicast route extensive at the RP and 
the receiver's DR?

As Nilesh suggested, this might also be due to the receiver's DR not having an 
RPF entry to the source. The output of show multicast rpf src on the 
receiver's DR would also be useful.

--Stacy



On Apr 19, 2010, at 6:02 PM, snort bsd wrote:

 Hi all:
 
 I have an active multicast receiver looking for source 225.0.0.1:
 
 -
 u...@hs3# run show pim join extensive
 Instance: PIM.master Family: INET
 
 Group: 225.0.0.1
Source: *
RP: 10.100.3.4
Flags: sparse,rptree,wildcard
Upstream interface: so-0/1/0.0
Upstream neighbor: 10.100.2.10
Upstream state: Join to RP
Downstream neighbors:
Interface: fe-1/3/0.0
172.20.30.1 State: Join Flags: SRW  Timeout: Infinity
 
 Nothing here.
 
 Instance: PIM.master Family: INET6
 
 
 from above data, it doesn't seem to find the source. but I took a look at RPS:
 
 ---
 u...@rp# run show pim join extensive
 Instance: PIM.master Family: INET
 
 Group: 225.0.0.1
Source: *
RP: 10.100.3.4
Flags: sparse,rptree,wildcard
Upstream interface: Local 
Upstream neighbor: Local
Upstream state: Local RP
Downstream neighbors:
Interface: so-0/1/1.0 
10.1000.2.9 State: Join Flags: SRW Timeout: 191
 
 Group: 225.0.0.1
Source: 10.100.5.200
Flags: sparse,spt
Upstream interface: fe-0/0/2.0
Upstream neighbor: 10.100.4.18
Upstream state: Local RP, Join to Source
Keepalive timeout: 32   - No downstream neighbor
 
 Instance: PIM.master Family: INET6
 -
 
 It seems that RP knows the source of group 225.0.0.1 but somehow the source 
 and receiver just won't connect. Somehow RP doesn't work?
 
 here is the RP config:
 
 u...@rr# show protocols pim
 rp {
bootstrap-priority 10;
local {
address 10.100.3.4;
}
 }
 interface fe-0/0/0.0 {
mode sparse;
 }
 interface fe-0/0/1.0 {
mode sparse;
 }
 interface fe-0/0/2.0 {
mode sparse;
 }
 interface fe-0/0/3.0 {
mode sparse;
 }
 interface so-0/1/0.100 {
mode sparse;
 }
 interface so-0/1/1.0 {
mode sparse;
 }
 
 
 any ideas?



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

Re: [j-nsp] multicast questions

[Stacy W. Smith]

Are PR and hs1 directly connected to each other via PR so-0/1/1.0 to hs1 
so-0/1/0.0? Can you try checking counters using monitor interface if on 
each side and confirm that the traffic is really being sent out so-0/1/1.0 on 
PR and really being received by so-0/1/0.0 on hs1?

I'd also be interested in seeing the output of show pim statistics and show 
route forwarding-table multicast extensive destination 225.0.0.1 on both PR 
and hs1.

--Stacy


On Apr 20, 2010, at 1:34 PM, snort bsd wrote:

 Thanks.
 
 I think the source and PR are connected:
 
 --
 u...@pr# run show multicast route extensive
 Family: INET
 
 Group: 225.0.0.1
Source: 10.0.5.200/32 ---
Upstream interface: fe-0/0/2.0---
Downstream interface list: 
so-0/1/1.0---
Session description: MALLOC   
Statistics: 18 kBps, 200 pps, 1001490 packets
Next-hop ID: 262151
Upstream protocol: PIM
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 0
 
 Family: INET6
 
 u...@pr# run show pim rps extensive  
 Instance: PIM.master
 Address family INET
 
 RP: 10.100.3.4
 Learned from 10.100.2.9 via: bootstrap
 Time Active: 19:35:16
 Holdtime: 150 with 97 remaining
 Device Index: 138
 Subunit: 32769
 Interface: pd-1/2/0.32769
 Group Ranges:
224.0.0.0/4
 Active groups using RP:
225.0.0.1 
 
total 2 groups active
 Register State for RP:
 Group   Source  FirstHopRP Address  State
 Timeout
 225.0.0.1   10.100.5.200  10.100.6.210.100.3.4Receive 
  258
 
 RP: 10.100.3.4
 Learned via: static configuration
 Time Active: 19:37:51
 Holdtime: 0
 Device Index: 138
 Subunit: 32769
 Interface: pd-1/2/0.32769
 Group Ranges:
224.0.0.0/4
 
 Address family INET6
 -
 
 For the simplicity, I have only one router hs1 on the receiver segment:
 
 ---
 u...@hs1# run show pim interfaces 
 Instance: PIM.master
 
 Name   Stat Mode   IP V State Count DR address
 at-0/2/1.50Up   Sparse  4 2 P2P   1
 fe-1/3/0.0 Up   Sparse  4 2 DR0 172.20.30.1  --
 pe-1/2/0.32769 Up   Sparse  4 2 P2P   0
 pe-1/2/0.32770 Up   Sparse  4 2 P2P   0
 so-0/1/0.0 Up   Sparse  4 2 P2P   1
 
 u...@hs1# run show igmp group 225.0.0.1 detail 
 Interface: fe-1/3/0.0
Group: 225.0.0.1
Source: 0.0.0.0  ---
Last reported by: 172.16.30.2---
Timeout: 182 Type: Dynamic   ---
 
 u...@hs1# run show pim rps extensive
 Instance: PIM.master
 Address family INET
 
 RP: 10.100.3.4   ---
 Learned from 10.100.3.4 via: bootstrap
 Time Active: 19:06:49
 Holdtime: 150 with 107 remaining
 Device Index: 137
 Subunit: 32769
 Interface: pe-1/2/0.32769
 Group Ranges:
224.0.0.0/4
 Active groups using RP:
225.0.0.1---
 
total 2 groups active
 
 Address family INET6
 
 u...@hs1# run show multicast rpf 10.100.5.200 
 Multicast RPF table: inet.0 , 78 entries
 
 10.100.5.0/24---
Protocol: IS-IS
Interface: so-0/1/0.0
Neighbor: 10.100.2.10
 -
 
 As Stacy pointed out, the receiver's DR doesn't seem to connect to PR via RPT:
 
 ---
 u...@hs1# run show pim join extensive 
 Instance: PIM.master Family: INET
 
 Group: 225.0.0.1
Source: *   ---
RP: 10.100.3.4
Flags: sparse,rptree,wildcard   ---
Upstream interface: so-0/1/0.0
Upstream neighbor: 10.100.2.10
Upstream state: Join to RP
Downstream neighbors:
Interface: fe-1/3/0.0   ---
172.20.30.1 State: Join Flags: SRW  Timeout: Infinity
 
 Instance: PIM.master Family: INET6
 
 u...@hs1# run show multicast route extensive  
 Family: INET
 
 Family: INET6
 ---
 
 Thanks.
 
 --- On Tue, 20/4/10, Nilesh Khambal nkham...@juniper.net wrote:
 
 From: Nilesh Khambal nkham...@juniper.net
 Subject: Re: [j-nsp] multicast questions
 To: snort bsd snort...@yahoo.com.au, juniper-nsp 
 juniper-nsp@puck.nether.net
 Received: Tuesday, 20 April, 2010, 6:08 PM
 Do you know if Source is registered
 with the RP? SPT flag is set on (S,G) on
 the RP so it must have but just in case check show pim rps
 extensive on
 both source DR and RP. Does the SPT path from receiver DR
 to the Source DR
 goes via RP or does it take an alternate path?
 
 One more thing to check is, are there more than one PIM
 routers 

Re: [j-nsp] multicast questions

[Stacy W. Smith]

This is the expected PIM join state at the RP if the receiver's DR has not yet 
joined the S,G.

Your previous output of show multicast extensive shows that the PR router was 
forwarding (or at least attempting to forward) traffic over the RPT. Your 
outputs from hs1 showed that it was not receiving the traffic over the RPT, and 
was therefore not joining the SPT.

Seems we need to figure out why the traffic being forwarded over the RPT from 
PR is not being received by hs1.

--Stacy

On Apr 20, 2010, at 3:16 PM, snort bsd wrote:

 from the PR, it seems that receiver's DR connecting to PR:
 
 
 u...@pr# run show pim join extensive
 Instance: PIM.master Family: INET
 
 Group: 225.0.0.1
Source: * ---
RP: 10.100.3.4
Flags: sparse,rptree,wildcard
Upstream interface: Local 
Upstream neighbor: Local
Upstream state: Local RP
Downstream neighbors:
Interface: so-0/1/1.0 ---
10.100.2.9 State: Join Flags: SRW Timeout: 177
 
 Group: 225.0.0.1
Source: 10.100.5.200
Flags: sparse,spt
Upstream interface: fe-0/0/2.0
Upstream neighbor: 10.100.4.18
Upstream state: Local RP, Join to Source
Keepalive timeout: 309
 --- no downstream neighbor
 Instance: PIM.master Family: INET6
 --
 
 It seems that the first Group: 225.0.0.1 was from receiver's DR and the 
 second Group: 225.0.0.1 was from the source.
 
 But receiver's DR doesn't seem to be aware of this:
 
 
 u...@hs1# run show pim join extensive
 Instance: PIM.master Family: INET
 
 Group: 225.0.0.1
Source: *
RP: 10.100.3.4
Flags: sparse,rptree,wildcard
Upstream interface: so-0/1/0.0
Upstream neighbor: 10.100.2.10
Upstream state: Join to RP--- 
Downstream neighbors:
Interface: fe-1/3/0.0
172.20.30.1 State: Join Flags: SRW  Timeout: Infinity
 -
 
 Am I missing something?
 
 
 
 --- On Wed, 21/4/10, snort bsd snort...@yahoo.com.au wrote:
 
 From: snort bsd snort...@yahoo.com.au
 Subject: Re: [j-nsp] multicast questions
 To: juniper-nsp juniper-nsp@puck.nether.net, Nilesh Khambal 
 nkham...@juniper.net
 Received: Wednesday, 21 April, 2010, 5:34 AM
 Thanks.
 
 I think the source and PR are connected:
 
 --
 u...@pr# run show multicast route extensive
 Family: INET
 
 Group: 225.0.0.1
 Source: 10.0.5.200/32 

---
 Upstream interface: fe-0/0/2.0   

 ---
 Downstream interface list: 
 so-0/1/1.0 

   ---
 Session description:
 MALLOC   
 Statistics: 18 kBps, 200 pps, 1001490
 packets
 Next-hop ID: 262151
 Upstream protocol: PIM
 Route state: Active
 Forwarding state: Forwarding
 Cache lifetime/timeout: 360 seconds
 Wrong incoming interface notifications: 0
 
 Family: INET6
 
 u...@pr# run show pim rps extensive  
 Instance: PIM.master
 Address family INET
 
 RP: 10.100.3.4
 Learned from 10.100.2.9 via: bootstrap
 Time Active: 19:35:16
 Holdtime: 150 with 97 remaining
 Device Index: 138
 Subunit: 32769
 Interface: pd-1/2/0.32769
 Group Ranges:
 224.0.0.0/4
 Active groups using RP:
 225.0.0.1 


 
 total 2 groups active
 Register State for RP:
 Group   
Source 
 FirstHopRP Address   
   StateTimeout
 225.0.0.1   10.100.5.200 
 10.100.6.2   
 10.100.3.4Receive   
   258
 
 RP: 10.100.3.4
 Learned via: static configuration
 Time Active: 19:37:51
 Holdtime: 0
 Device Index: 138
 Subunit: 32769
 Interface: pd-1/2/0.32769
 Group Ranges:
 224.0.0.0/4
 
 Address family INET6
 -
 
 For the simplicity, I have only one router hs1 on the
 receiver segment:
 
 ---
 u...@hs1# run show pim interfaces 
 Instance: PIM.master
 
 Name   
Stat Mode   
IP V State Count DR address
 at-0/2/1.50   
 Up   Sparse  4 2 P2P 
  1
 fe-1/3/0.0 
Up   Sparse   
   4 2 DR0 172.20.30.1 
 --
 pe-1/2/0.32769 
Up   Sparse   
   4 2 P2P   0
 pe-1/2/0.32770 
Up   Sparse   
   4 2 P2P   0
 so-0/1/0.0 
Up   Sparse   
   4 2 P2P   1
 
 u...@hs1# run show igmp group 225.0.0.1 detail 
 Interface: fe-1/3/0.0
 Group: 225.0.0.1
 Source: 0.0.0.0   

   ---
 Last reported by:
 172.16.30.2---
 Timeout: 
182 Type: Dynamic   
---
 
 u...@hs1# run show pim rps extensive 
   
 Instance: PIM.master
 Address family INET
 
 RP: 10.100.3.4   

Re: [j-nsp] Juniper best path selection process

[Stacy W. Smith]

On Apr 2, 2010, at 9:13 AM, Joe Metzger wrote:
 I made a mistake yesterday when I said both black-hole BGP sessions were 
 IBGP. I
 didn't notice that the particular router I was looking at is using a private 
 AS
 for other reasons, so both black-hole BGP sessions are EBGP multi-hop, not 
 iBGP.

That helps explain things. I just assumed they were EBGP and didn't notice your 
statement that they were IBGP. :-)

 BTW, the quote you provided is not on the page I referenced. Google found it 
 at:
 http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/how-the-active-route-is-determined.html

Yes. I'm sorry. I got confused. The statement was not in the URL you 
referenced, but in the URL that Richard referenced in his e-mail on this 
thread. I mixed the two.

 I am not sure the rule your citing applies in this case. I interpreted 
 different
 to mean the 2 routes were learned from neighbors in different AS's, and not 
 that the
 AS of the local router differed from the AS of the external peer because that 
 is always
 true. In my case, both of the routes in question are from the same external 
 AS.
 
 But after poking around a bit more in the 9.4 route selection  configuration 
 pages, I discovered the following sentence which does describe the behavior I 
 am seeing:  By default, router ID comparison is not performed if one of the 
 external paths is active.
 
 This sentence, plus the one you found seem to clearly indicate that current 
 versions of
 Junos take age into account by default in the selection process.

I agree the documentation could be more explicit. I believe the part of the 
reason the documentation is confusing is because the path selection algorithm 
has changed slightly over time.

The statement I referenced in the documentation does indeed only apply when the 
two external routes are from differing neighbor ASs. This change was introduced 
by PR 37158 in JUNOS 6.1R1. As the release note for this PR states, this change 
was introduced to avoid route oscillations that could occur due to MED values 
in very specific topologies.

Later, this change to prefer the active route was expanded to include routes 
from the same external AS. That's where the documentation statement that you 
quoted came from. This change was performed under PR 392819 and was introduced 
in JUNOS 9.3R3, 9.4R3, 9.5R2, 9.6R1. This makes the default JUNOS path 
selection algorithm compliant with RFC 5004.

If you prefer to include the router ID in the path selection algorithm (pre 
JUNOS 6.1R1 default behavior), you can configured the 'external-router-id' 
path-selection knob.

--Stacy





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

Re: [j-nsp] Juniper best path selection process

[Stacy W. Smith]

Joe,

This is actually documented at the link you quoted below:
 
For EBGP only, prefer the current active route when a route is received from 
different neighboring ASs, by default. To disable this default behavior, 
specify the external-router-id option at the [edit protocols bgp 
path-selection] hierarchy level.

--Stacy

On Apr 1, 2010, at 4:53 PM, Joe Metzger wrote:

 Does anybody have a reference to the real best path
 selection process actually used by an M7i running 9.3
 that documents all of the tie-breaking criteria, and
 when it might decide to just blow off recomputing a new
 best route if the important attributes didn't change?
 
 I was poking around today on a router that is excepting
 2 identical iBGP feeds of routes to black hole. Approximately 70%
 of the routes from 1 server were marked as best and 30%
 from the other.
 
 The published selection algorithm docs only include deterministic
 criteria, and so I would have expected deterministic results and
 that the routes from the black-hole server with the lowest router
 ID would be preferred 100% of the time.
 
 http://www.juniper.net/techpubs/en_US/junos/information-products/topic-collections/nog-baseline/topic-20357.html
 
 The underlying system feeding routes to the 2 black hole
 servers guarantees that both servers are sending identical
 lists of prefixes, with identical local-pref, as-path,
 origin code, med value, source protocol, etc. The import
 policy explicitly sets the next-hop to discard for all
 routes from both servers so IGP distance shouldn't be a factor.
 
 The only differences between the routes announced from each
 black hole server visible in show route extensive are router
 ID, Task, and the time that the route was announced. It appears
 that it is showing the oldest route as the 'best' one.
 
 This isn't causing me any trouble, but it looks wrong, and making
 routing decisions based on age has bit me in the past. :-(
 
 
 
 Joe Metzger
 metz...@es.net
 
 
 
 ___
 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] logical routers on M10i

[Stacy W. Smith]

I believe configuring tunnel-services is only applicable to MX-series DPCs. 
While you may be able to apply this config to an AS PIC, I don't believe it 
will provide you with an lt interface. On M/T-series you need a tunnel PIC to 
provide an lt interface.

--Stacy


On Mar 20, 2010, at 5:51 PM, Stefan Fouant wrote:

 You have to enable tunnel services on the PIC:
 
 chassis {
fpc 0 {
pic 0 {
tunnel-services {
bandwidth 1g;
}
}
}
network-services ip;
 }
 
 That should take care of it.
 
 Stefan Fouant
 Sent from my Verizon Wireless BlackBerry
 
 -Original Message-
 From: Fahad Khan fahad.k...@gmail.com
 Date: Sun, 21 Mar 2010 01:41:31 
 To: sth...@nethelp.no
 Cc: sfou...@shortestpathfirst.net; juniper-nsp@puck.nether.net; 
 juniper-nsp-boun...@puck.nether.net
 Subject: Re: [j-nsp] logical routers on M10i
 
 But i can not see any lt interfaces in show interfaces terse ?? why??
 
 regards,
 Muhammad Fahad Khan
 JNCIP - M/T # 834
 IT Specialist
 Global Technology Services, IBM
 fa...@pk.ibm.com
 +92-321-2370510
 +92-301-8247638
 Skype: fahad-ibm
 http://www.linkedin.com/in/muhammadfahadkhan
 http://fahad-internetworker.blogspot.com
 http://www.visualcv.com/g46ptnd
 
 
 On Sun, Mar 21, 2010 at 1:26 AM, sth...@nethelp.no wrote:
 
 but now i got it, i need tunnel PIC , but not AS PIC II
 
 The AS PIC should be able to do anything the tunnel PIC can do (and
 more).
 
 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

Re: [j-nsp] logical routers on M10i

[Stacy W. Smith]

On Mar 22, 2010, at 10:37 AM, Eric Van Tol wrote:
 Our AS II PIC provides tunnel services, even when running in layer-2 mode:
 
 u...@router1-re0 show chassis hardware detail | match PIC 3  
  PIC 3  REV 03   750-012924   x AS2 Layer-2 Services
 
 u...@router1-re0 show interfaces lt-0/2/0
 Physical interface: lt-0/2/0, Enabled, Physical link is Up
 ...

That doesn't look like the lt interface is being supplied by the AS PIC. You're 
AS PIC is in PIC slot 3 and your lt interface is in PIC slot 2.

--Stacy


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

Re: [j-nsp] J2320 as BGP router

[Stacy W. Smith]

On Feb 18, 2010, at 9:49 AM, Florian Weimer wrote:

 * Shane Short:
 
 I think the BGP licensing for JunOS is quite ridiculous..
 
 I've been looking at upgrading our small network to some J series
 routers and simply haven't, because as you said-- the price of the
 license is almost as much as the unit itself. what gives?
 
 As far as I can tell, everything you need to run a regular BGP router
 is there, even without the advanced BGP license.  It's likely that you
 don't have to pay the additional licensing fee.

I think you are correct. I believe the advanced BGP license is only needed if 
the router will be configured as a route reflector.

--Stacy

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

Re: [j-nsp] read-only config account, rancid user

[Stacy W. Smith]

How 'bout this:

ran...@breakme show configuration system 
login {
class rancid {
permissions view-configuration;
allow-commands show configuration.*|quit;
deny-commands .*;
}
user rancid {
uid 2003;
class rancid;
authentication {
encrypted-password /* SECRET-DATA */; ## SECRET-DATA
}
}
}

ran...@breakme ?
Possible completions:
  quit Exit the management session
  show Show system information
ran...@breakme show ?
Possible completions:
  configurationShow current configuration
ran...@breakme show configuration ?
Possible completions:
  [Enter]Execute this command
 access   Network access configuration
 accounting-options   Accounting data configuration
 applications Define applications by protocol characteristics
+ apply-groups Groups from which to inherit configuration data
 chassis  Chassis configuration
 class-of-service Class-of-service configuration
 firewall Define a firewall configuration
 forwarding-options   Configure options to control packet forwarding
 groups   Configuration groups
 interfaces   Interface configuration
 logical-systems  Logical systems
 policy-options   Routing policy option configuration
 protocolsRouting protocol configuration
 routing-instancesRouting instance configuration
 routing-options  Protocol-independent routing option configuration
 security Security configuration
 services Service PIC applications settings
 snmp Simple Network Management Protocol configuration
 system   System parameters
  |Pipe through a command
ran...@breakme

--Stacy


On Feb 4, 2010, at 10:14 AM, matthew zeier wrote:

 Not clear how to create a dumbed down read-only user who can just view the 
 config.  
 
 In a Cisco world I'd use privilege exec level .  In JunOS, a read-only 
 class can't run show configuration.
 
 What's the nugget of info I'm missing?
 ___
 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 routing issue

[Stacy W. Smith]

It sounds like the forwarding table may not be in sync with the routing table 
during this time. You can check the Routing Engine's view of the forwarding 
table with:

show route forwarding-table destination 10.10.134.0 extensive

That output may help you determine if it's the Routing Engine or the PFE that 
has an incorrect forwarding entry.

--Stacy

On Feb 3, 2010, at 12:53 PM, Cord MacLeod wrote:

 I have a very strange routing issue in progress.  The short of it is, I am 
 advertising 10.10.134.0/24 from gsw1.xxx with BGP, which is an ex4200 6 
 member switch.  I advertise this to crs1.xxx which is an ex4200 2 member 
 switch and a route reflector.  When one of the crs1.xxx member switches dies, 
 all routing dies as expected.  However when routing re-establishes for some 
 reason 10.10.134.0/24 is no longer reachable even though a route exists for 
 this network in BGP through out the whole network.  crs1.xxx even claims no 
 route to host even when showing a route in it's routing table.
 
 When the 2nd member of crs1.xxx comes back online, everything is fixed.  
 Obviously this is a major issue because I now essentially have no redundancy 
 at my aggregation layer, crs1.xxx.
 
 
 Here's normal operation:
 
 r...@crs1.xxx show virtual-chassis
 
 Virtual Chassis ID: 0026.8868.4080
  MastershipNeighbor List  
 Member ID  Status   Serial NoModelpriorityRole  ID  Interface
 0 (FPC 0)  PrsntBM0x0 ex4200-24t  200  Master*1  vcp-0
   
 1 (FPC 1)  PrsntBM0x2 ex4200-24t  200  Backup 0  vcp-1
   
 
 r...@crs1.xxx show virtual-chassis 
 
 r...@crs1.xxx show route 10.10.134.0 
 
 inet.0: 20 destinations, 21 routes (20 active, 0 holddown, 0 hidden)
 Restart Complete
 + = Active Route, - = Last Active, * = Both
 
 10.10.134.0/24 *[BGP/170] 00:20:46, localpref 100, from 10.10.135.47
  AS path: I
 to 10.10.135.58 via ge-1/0/23.0
  to 10.10.135.62 via ge-0/0/23.0
 
 r...@crs1.xxx show bgp summary 
 Groups: 2 Peers: 3 Down peers: 0
 Table  Tot Paths  Act Paths SuppressedHistory Damp State
 Pending
 inet.0 4  4  0  0  0   0
 Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
 State|#Active/Received/Accepted/Damped...
 10.10.135.13  11XXX 27 29   0   0   10:53 
 1/1/1/0  0/0/0/0
 10.10.135.14  11XXX 26 29   0   0   10:47 
 1/1/1/0  0/0/0/0
 10.10.135.47  11XXX 28 28   0   0   10:56 
 2/2/2/0  0/0/0/0
 
 
 r...@crs1.xxx ping 10.10.134.1 
 PING 10.10.134.1 (10.10.134.1): 56 data bytes
 64 bytes from 10.10.134.1: icmp_seq=0 ttl=64 time=1.324 ms
 64 bytes from 10.10.134.1: icmp_seq=1 ttl=64 time=1.570 ms
 64 bytes from 10.10.134.1: icmp_seq=2 ttl=64 time=1.285 ms
 64 bytes from 10.10.134.1: icmp_seq=3 ttl=64 time=1.297 ms
 
 
 Here's abnormal operation:
 
 Virtual Chassis ID: 0026.8868.4080
  MastershipNeighbor List  
 Member ID  Status   Serial NoModelpriorityRole  ID  Interface
 0 (FPC 0)  PrsntBM0x0 ex4200-24t  200  Master*  
 1 (FPC 1)  NotPrsnt BM0x2 ex4200-24t
 
 r...@crs1.xxx show bgp summary
 Groups: 2 Peers: 3 Down peers: 0
 Table  Tot Paths  Act Paths SuppressedHistory Damp State
 Pending
 inet.0 4  4  0  0  0   0
 Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
 State|#Active/Received/Accepted/Damped...
 10.10.135.13  11XXX  3  5   0   0   8 
 1/1/1/0  0/0/0/0
 10.10.135.14  11XXX  2  5   0   0   2 
 1/1/1/0  0/0/0/0
 10.10.135.47  11XXX  4  3   0   0  11 
 2/2/2/0  0/0/0/0
 
 r...@crs1.xxx show route 10.10.134.0 
 
 inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
 Restart Complete
 + = Active Route, - = Last Active, * = Both
 
 10.10.134.0/24 *[BGP/170] 00:03:35, localpref 100, from 10.10.135.47
  AS path: I
 to 10.10.135.62 via ge-0/0/23.0
 
 {master:0}
 r...@crs1.xxx ping 10.10.134.1 
 PING 10.10.134.1 (10.10.134.1): 56 data bytes
 ping: sendto: No route to host
 ping: sendto: No route to host
 ping: sendto: No route to host
 ping: sendto: No route to host
 ping: sendto: No route to host
 ping: sendto: No route to host
 
 
 ___
 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

Re: [j-nsp] Enabling IRB on Juniper EX Series Switches

[Stacy W. Smith]

On Oct 26, 2009, at 4:03 AM, Abhi wrote:
 Does Junos support IRB Integrated routing and bridging(or a similar feature) 
 on L3 interfaces and especially on EX8200 platform. and also how to enable 
 the same.

You might want to refer to the free JUNOS as a Switching Language elearning.

http://www.juniper.net/us/en/training/elearning/junos_switching.html

This 110-minute program is designed to teach network engineers who have 
experience configuring and managing Ethernet switches using Cisco's IOS how to 
use the new enterprise Ethernet switching features of the JUNOS software on 
EX-series devices.

--Stacy

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

Re: [j-nsp] question about policy-statement

[Stacy W. Smith]

3,2,1

u...@host show configuration groups groupA
protocols {
bgp {
group * {
neighbor * {
import policy-1;
}
}
}
}

u...@host show configuration groups groupB
protocols {
bgp {
group * {
neighbor * {
import policy-2;
}
}
}
}

u...@host show configuration protocols bgp
group MyGroup {
apply-groups groupA;
neighbor 10.0.0.1 {
apply-groups groupB;
import policy-3;
peer-as 6500;
}
}

u...@host show configuration protocols bgp | display inheritance
group MyGroup {
neighbor 10.0.0.1 {
##
## 'policy-2' was inherited from group 'groupB'
## 'policy-1' was inherited from group 'groupA'
##
import [ policy-3 policy-2 policy-1 ];
peer-as 6500;
}
}

--Stacy


On Aug 26, 2009, at 10:18 PM, Li Zhu wrote:


All,

In configuration below, groupA and groupB import policy-statement 1  
and 2,
respectively. So, what is the sequence of import policy neighbor  
10.0.0.1

should go through? Should it be
1. policy-statement-3, then 2, then 1? or
2. policy-statement-3 only? or
3 something else?

group MyGroup {
 apply-groups [groupA];
 neighbor 10.0.0.1 {
  apply-groups groupB;
  import policy-statement-3;
 }
}

Thanks,

Li
___
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] Sanitising m/t series routers?

[Stacy W. Smith]

On Jul 6, 2009, at 11:42 PM, Andrew Cheng wrote:


Hi There

I have to sanitise a large number of routers (ie, remove all configs,
logs.. everything), and
was wondering if there was a magic way of doing it remotely?

There is the tedious way of going through and deleteing /var/log, all
configs.. etc etc, but surely
there must be a better way?



The best way would be to re-install JUNOS from install media, but  
that's not a very remote-friendly method because it requires hands to  
insert the install media. Otherwise, I am not aware of any supported,  
easy, or foolproof method.


The least cumbersome method I can think of is:

1) Connect via console and login to cli
2) start shell
3) su -
4) mount /altconfig
5) rm -rf /config/*
6) rm -rf /altconfig/*
7) umount /altconfig
8) exit
9) exit
10) request system partition hard-disk
11) request system reboot

The method above is totally unsupported. Use at your own risk. Do not  
pass 'Go'. Do not collect $200, etc.



FWIW, J-series offers a slightly easier method of:

1) Connect via console and login to cli
2) request system snapshot factory media alternate media
3) request system reboot media alternate media
4) request system snapshot factory media compact-flash
5) request system reboot media compact-flash

--Stacy



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

Re: [j-nsp] Sanitising m/t series routers?

[Stacy W. Smith]

On Jul 7, 2009, at 8:36 AM, Chris Adams wrote:


Once upon a time, Stacy W. Smith st...@acm.org said:

FWIW, J-series offers a slightly easier method of:

1) Connect via console and login to cli


If you can connect to the console, you can also just paperclip the  
reset

button for 15 seconds, which resets to factory defaults.


I believe that resets the config to factory-default, but I don't  
believe that deletes old configs, logs, home directories, etc.


--Stacy


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

Re: [j-nsp] Prefix prioritization support on Juniper

[Stacy W. Smith]

Prefix prioritization for OSPF-learned prefixes is supported since  
JUNOS 9.3, and the order in which LDP-learned prefixes are installed  
corresponds to the order in which the corresponding OSPF-learned  
prefixes were installed.


See the bottom of this page for configuring prefix prioritization for  
OSPF:


http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/id-11721665.html#id-11721665

You can confirm the results of your routing policy by checking the  
output of 'show ospf route detail'.


u...@host show ospf route detail | match Network|priority
10.0.3.0/30Intra  Network IP   10  so-2/1/2.0
  area 0.0.0.0, origin 10.255.70.17, priority medium 
10.1.3.0/30Intra  Network IP5  so-2/1/2.0
  area 0.0.0.0, origin 10.255.70.19, priority medium 

--Stacy


On May 12, 2009, at 8:24 AM, Jeff Tantsura wrote:


Hi,

Does Juniper support prefix prioritization (provides a way to  
prioritize

which prefixes converge first, based on the network administrator's
guidelines)?

Thanks,
Jeff

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


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

Re: [j-nsp] 9.3 and M20 FPC

[Stacy W. Smith]

From the 9.3 release notes:

On M20 routers running JUNOS Release 9.3 and later, nonenhanced FPCs do
not come online because of memory limitations. These FPCs appear as  
FPC in
the Description column of the output from the show chassis hardware  
command.
As announced in Technical Bulletin PSN-2004-08-024, these FPCs have  
not been

supported since 31 December 2004. (To access the bulletin, log in at
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2004-08-024actionBtn=Search.)
[PR/291610]

--Stacy

On May 6, 2009, at 8:14 AM, Eric Van Tol wrote:


Hi all,
Is anyone out there running 9.3 with an M20 FPC (not FPC-E).  I have  
a lab box that I've upgraded to 9.3R2.8 and the FPC won't come up.   
The only PIC in this FPC is a P-4CHDS3 PIC.  The FPC basically goes  
from Present state to Offline within a few minutes of booting:


May  5 15:07:06  m20 ssb CM(0): Slot 0: No response from FPC  
interface manager
May  5 15:07:06  m20 chassisd[4671]: CHASSISD_FRU_EVENT:  
scb_recv_slot_detach: detached FPC 0
May  5 15:07:06  m20 ssb CM(0): Slot 0: No response from FPC chassis  
manager
May  5 15:07:06  m20 chassisd[4671]: CHASSISD_IFDEV_DETACH_FPC:  
ifdev_detach(0)
May  5 15:07:06  m20 ssb CM(0): Slot 0: Unrecoverable error; probe  
failed


I would normally open a ticket, but this is a lab box not under  
contract that I'm using to test some stuff out on.  Everything works  
fine with 9.0R2.10.  Juniper support site says FPC and this PIC are  
a valid combination for 9.3, so I'm at a loss here.


-evt
___
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] display mpls table

[Stacy W. Smith]

Because they were installed by some protocol other than 'mpls'. Likely  
'ldp' and/or 'rsvp'.


If you want to see all of the active routes in the mpls.0 table  
regardless of the protocol that installed them, then simply execute  
'show route table mpls.0'.


--Stacy

On Apr 28, 2009, at 1:49 PM, Andrew Jimmy wrote:

When you run the following command, why you can't see the 679 active  
routes.




junos show route protocol mpls table mpls.0



mpls.0: 679 destinations, 679 routes (679 active, 0 holddown, 0  
hidden)


+ = Active Route, - = Last Active, * = Both



0  *[MPLS/0] 4w5d 13:23:40, metric 1

 Receive

1  *[MPLS/0] 4w5d 13:23:40, metric 1

 Receive

2  *[MPLS/0] 4w5d 13:23:40, metric 1

 Receive



{master}

junos

___
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] Interconnecting logical routers via FPC3-E

[Stacy W. Smith]

On Apr 17, 2009, at 10:57 PM, Robert Kern wrote:


Hi Guys,

I have a question about interconnection logical-routers on M320 via  
FPC3-E.
Interconnection should be internal (not via physical ports) and  
limited to

10Ge for example.

What kind of configuration do I need for such logical connection - I  
belive

no other HW is needed for that.

Tnx for answers.

Robert


You need a logical tunnel (lt) interface. That requires either a  
tunnel PIC, AS PIC, or MS PIC.


Assuming you have an lt interface, the configuration looks like this:

logical-systems {
R11 {
interfaces {
lt-1/1/0 {
unit 2 {
description R11 LR to Default LR on unit 1;
encapsulation vlan;
vlan-id 1;
peer-unit 1;
family inet {
address 192.168.21.6/30;
}
}
}
}
}
}
interfaces {
lt-1/1/0 {
unit 1 {
description Default LR to R11 LR on unit 2;
encapsulation vlan;
vlan-id 1;
peer-unit 2;
family inet {
address 192.168.21.5/30;
}
}
}
}

--Stacy

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

Re: [j-nsp] v6 BGP Policy Bug?

[Stacy W. Smith]

Are you certain you don't see this same behavior for an IPv4 BGP  
export policy?  I believe what you describe is the expected behavior  
and is consistent across all (or at least most) applications of  
routing policy on JUNOS.


--Stacy

On Apr 14, 2009, at 5:47 PM, Mark Tinka wrote:


Hi all.

We recently experienced a situation where an M7i (JunOS
9.4R1.8), on which we applied an export policy for a v6 BGP
session, was leaking more v6 routes than it should have
been.

We realized that if the final term in the BGP policy was
'accept', not only did the router export the BGP v6 routes,
but it also exported all other v6 routes learned from other
sources, i.e., IS-IS and Direct, to its BGP peers, which
said BGP peers installed in their BGP table.

To resolve this issue, we added a 'from protocol bgp' option
along with the 'accept' in the final term.

Obviously, for policies whose final term is 'reject' (we
have a number of those), this issue does not present.

This seems like odd behaviour as:

a) We don't see this for v4.

b) One would expect that the policy would only affect routes
  from which protocol it's been applied to.

Is this a bug or a feature?

Although I think it's a good idea that the final term in a
BGP policy should specify the source of the route, folk that
do not like this should rest in the fact that policies
applied to a specific routing protocol would, by default,
affect routes learned only by that protocol.

Has anyone else seen this? Considering opening a case with
JTAC.

Cheers,

Mark.

___
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] v6 BGP Policy Bug?

[Stacy W. Smith]

On Apr 14, 2009, at 8:53 PM, Mark Tinka wrote:


On Wednesday 15 April 2009 10:19:24 am Stacy W. Smith wrote:


Are you certain you don't see this same behavior for an
IPv4 BGP export policy?


Yes, perhaps that's the bug :-). I'll take a closer look at
it and figure out what's going on. We only have one or two
of these policies. It's more than the exception than the
norm.


Yes, I believe if you're not seeing this behavior for IPv4 BGP export  
policy, that would be a bug. Please provide more detail (version,  
relevant config, and 'show' outputs) if that's the case.


You probably already know this, but it's worth stating for the  
archives...


There's a difference between a final term of:

term foo {
then accept;
}

and the protocol-specific implicit default policy. In the case of BGP,  
the default policy is equivalent to:


policy foo {
term bar {
from protocol bgp;
then accept;
}
}

--Stacy

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

Re: [j-nsp] bgp route advertisements

[Stacy W. Smith]

On Nov 5, 2008, at 11:44 AM, Mike Johnson wrote:
Is there any good docs for understanding the setup an/or conversion  
from

Cisco?


http://www.juniper.net/training/elearning/jsl.html

--Stacy

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

Re: [j-nsp] RE CPU on MX

[Stacy W. Smith]

[EMAIL PROTECTED] show chassis hardware models | match Routing
Routing Engine 0 REV 07   740-015113   1000741009RE- 
S-1300-2048-S
Routing Engine 1 REV 07   740-015113   1000741008RE- 
S-1300-2048-S


[EMAIL PROTECTED] show system boot-messages | find CPU
CPU: Intel(R) Celeron(R) M processor 1300MHz (1296.76-MHz 686- 
class CPU)

  Origin = GenuineIntel  Id = 0x695  Stepping = 5
   
Features 
= 
0xa7e9fbbf 
 
FPU 
,VME 
,DE 
,PSE 
,TSC 
,MSR 
,MCE 
,CX8 
,APIC 
,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE


[EMAIL PROTECTED] show chassis hardware models | match Routing
Routing Engine 0 REV 07   740-013063   1000731639RE- 
S-2000-4096-S
Routing Engine 1 REV 07   740-013063   1000745282RE- 
S-2000-4096-S


[EMAIL PROTECTED] show system boot-messages | find CPU
CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6d8  Stepping = 8
   
Features 
= 
0xafe9fbff 
 
FPU 
,VME 
,DE 
,PSE 
,TSC 
,MSR 
,PAE 
,MCE 
,CX8 
,APIC 
,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE

  Features2=0x180EST,TM2
  AMD Features=0x10NX

--Stacy


On Oct 29, 2008, at 5:54 PM, Marlon Duksa wrote:

Thanks. What about  RE-S-2000  (S instead of A)Also what command did  
you run

to show this info?
Thanks


On Wed, Oct 29, 2008 at 4:48 PM, Richard A Steenbergen [EMAIL PROTECTED] 
wrote:



On Wed, Oct 29, 2008 at 04:36:04PM -0700, Marlon Duksa wrote:

Does anyone know what is the CPU type on MX Routing Engine?Thanks,


Celeron 1.3GHz (RE-1300) or Pentium M 2.0GHz (RE-A-2000).

Intel(R) Pentium(R) M processor 2.00GHz (1995.01-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x6d8 Stepping = 8
Features 
=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,

MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE
Features2=0x180EST,TM2
AMD Features=0x10NX

Don't have the details on the 1.3GHz version, I heard it was a  
Celeron
but its unclear if its a Celeron M or not. Anybody own one of these  
and

wanna paste?

--
Richard A Steenbergen [EMAIL PROTECTED]   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] Lying about BGP capabilities

[Stacy W. Smith]

set disable-4byte-as at the BGP, group, or neighbor level.

--Stacy


On Oct 3, 2008, at 11:59 AM, Rob Evans wrote:


Hi folks,

I've recently upgraded a few routers to JUNOS 9.1R2, which has
introduced four byte ASNs (this is a good thing).

Within BGP, this feature is announced as a new capability (65) in the
BGP OPEN message.

However, one of our customers has a less than ideal (aka broken)
router which, when it sees this capability, tears the session down.

Now, I know they should just be ignoring it, but whilst they take this
issue up with their vendor, is there any way I can tell the Juniper
not to advertise the four-byte ASN capability in the BGP OPEN?  I've
had a look, and can't see anything *documented*... :)

All the best,
Rob
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] Bizaare bug of the year award

[Stacy W. Smith]

Richard,

I've filed PR 389794 to track this issue.

--Stacy
aka [EMAIL PROTECTED]

On Sep 25, 2008, at 3:17 PM, Richard A Steenbergen wrote:


Ok, I just found a Juniper bug that is so strange I can't even bring
myself to open a case for it. Not only because I can just imagine  
trying

to explain it to JTAC, but because it is so freaking bizaare and funny
that I just have to share it with others. :)

It seems that in 9.1+ code there is a bug in the traceroute  
application,

which causes it to query the incorrect reverse DNS for certain IP
addresses. The nameservers and the resolv lib on the router itself are
fine, you can do a host x.x.x.x and get correct results, it is only
the traceroute application which is broken. JUNOS 9.0 and earlier is
confirmed to be working correctly, JUNOS 9.1/9.2 is confirmed to be
broken on all versions.

Here is an example:

traceroute to ytti.fi (62.236.255.178), 30 hops max, 40 byte packets
...
7  te0-2-0-0-10G.alb2nqh1.ip.tele.dk (83.88.20.25)  148.334 ms   
126.819 ms  126.299 ms
8  pos0-0-0-0-10G.stkm3nqh1.ip.tele.dk (83.88.27.6)  156.377 ms   
127.819 ms  126.253 ms
9  Wimax-Cali-190-0-0-61.orbitel.net.co (62.236.181.189)  126.271  
ms  126.310 ms  126.189 ms
10  Wimax-Cali-190-0-0-16.orbitel.net.co (62.236.181.16)  130.327  
ms  126.542 ms  126.455 ms
11  Wimax-Cali-190-0-0-29.orbitel.net.co (62.236.182.29)  126.178  
ms  126.272 ms  126.346 ms


As you can see, it seems to be querying the incorrect IP for hops 9,  
10,

and 11. Here is a tcpdump from the router itself showing that the
traceroute app is actually querying for the wrong ptr:

IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto: UDP (17),
length: 119) ns1.mynameserverhere.net.domain 
lo0.myrouterhere.net.56079: [udp sum ok] 11052 q: PTR?
29.0.0.190.in-addr.arpa. 1/0/0 29.0.0.190.in-addr.arpa. PTR
Wimax-Cali-190-0-0-29.orbitel.net.co. (91)

As you can see, hops 10 and 11 are directly mapping of the last  
octet to

a query of 190.0.0.x, but hop 9 is not. However, since 189-61=128, you
can clearly see that hop 9 is actually zeroing out the top bit (or  
bits)

of the last octet.

Here is another example of the brokenness:

traceroute to www.telekom.de (217.6.10.34), 30 hops max, 40 byte  
packets

...
6  Wimax-Cali-190-0-0-42.orbitel.net.co (62.154.16.234)  13.428 ms
   Wimax-Cali-190-0-0-46.orbitel.net.co (62.154.16.238)  15.618 ms
   Wimax-Cali-190-0-0-42.orbitel.net.co (62.154.16.234)  15.574 ms

Only thing in common here is the 62 first octet, though you can now  
see

that its zeroing out the top 2 bits when doing its lookup. No clue if
there are any other patterns of IPs where this happens also, if all of
62.0.0.0/8 is broken, etc, but its definitely been confirmed on many
routers.

Bonus points to any jnpr developer who can tell me how you guys  
actually

managed to break this, because this is an award winner in my book. :)

--
Richard A Steenbergen [EMAIL PROTECTED]   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] JNCIP-M Preparation

[Stacy W. Smith]

On Sep 23, 2008, at 6:46 AM, Jens Hoffmann wrote:


Hi,

in preparation fort he JNCIP-M certification I'm using the  JNCIP  
Study

Guide (Harry Reynolds).

But this book is about 5 years old.

Is this book nevertheless useful considering the content of the  
current

JNCIP certification ?


Yes, I believe Harry's book is still very applicable to the content of  
the current JNCIP-M exam. To confirm, you can compare the current exam  
topic list at http://www.juniper.net/training/certification/resources_jncipm.html 
 to the contents of Harry's book.


--Stacy

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

Re: [j-nsp] Reliable Static Routing

[Stacy W. Smith]

Does BFD for static routes address your requirement?

http://www.juniper.net/techpubs/software/junos/junos91/swconfig-routing/configuringbidirectional-forwarding-detection.html#id-10372527

--Stacy

On Jun 24, 2008, at 9:58 PM, Farhan Jaffer wrote:


Thanks Phil.

So we need to escalate this issue to JUNOS developers :)

-FJ

On Tue, Jun 24, 2008 at 8:06 PM, Phil Bedard [EMAIL PROTECTED]  
wrote:
I think there are things coming with regards to event triggers,  
etc. that
may allow this but not as of today, and not as easy to do as on a  
Cisco.  I
think this is like the 5th time I've seen someone ask this  
question, sounds

like a feature request.

You can accomplish conditional route advertisements by using  
generated
routes with a policy that matches on a specific contributing route,  
but you

can't say ping a remote address.

Phil

On Jun 24, 2008, at 12:35 AM, Farhan Jaffer wrote:


Hi,

Is there any way of reliable static routing in Juniper Routers?
Similar as Object Tracking in Cisco.

Many Thanks in advance.

-FJ
___
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] ICMPv6 6PE network

[Stacy W. Smith]

On Jun 3, 2008, at 7:46 PM, snort bsd wrote:


Hello all:

I used MPLS LSP connecting two different IPv6 domains (6PE,  
RFC4798). Both sides (IPv6 domains) see each other IPv6 routes,  
which means my IPv4 MPLS based backbone successfully delivered the  
IPv6 routes. But for some reasons, both customers can't ping each  
other even though they can see each other IPv6 routes. Somehow the  
IPv4 MPLS backbone is blocking the ICMP traffic.


Any ideas?


Is family mpls enabled on all interfaces that the LSP traverses? On  
the PE routers, do you have family inet6 configured on both the CE- 
facing interfaces and the core-facing interfaces? family inet6 is  
required on the core-facing interfaces in order to process the IPv6  
packets received with MPLS label 2.


http://www.juniper.net/techpubs/software/junos/junos83/feature-guide-83/html/fg-ipv6-over-mpls6.html

--Stacy

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

Re: [j-nsp] Cisco-Juniper RSVP aggregate interop

[Stacy W. Smith]

I believe you may be hitting a Cisco bug. Specifically, CSCsj51007.

This is also documented in Juniper PR 232909. The release not for that  
PR states:

In JUNOS 8.x we put all the RSVP submessages inside the RSVP  
aggregate bundle including the RSVP PATH messages. This is done only  
on the ethernet interface but not on the PT-to-PT links. So each  
submessage has TTL value that decrements independently of the TTL  
value of the bundle header. When RSVP aggregation (refresh reduction)  
is turned ON between a Juniper and Cisco on an ethernet interface,  
Cisco compares the IP TTL and the submessage TTL. Instead of comparing  
IP TTL and the bundle header TTL. This causes the MPLS LSP to not come  
up when LSP is trying to setup between a Juniper and CISCO with a  
Juniper router being the ingress and the Cisco as the Egress connected  
by a Ethernet interface.

--Stacy


On May 16, 2008, at 3:15 PM, Richard A Steenbergen wrote:

 I'm trying to set up RSVP on a path that goes Cisco-Juniper-Cisco, but
 running into what appears to be some type of interop problem with RSVP
 when using aggregate.

 Basically the Cisco on either end (this happens on both devices  
 depending
 on the direction of the LSP) thinks the Juniper in the middle isn't  
 RSVP
 capable, and constantly generates patherr's:

 May 16 19:05:25.683 UTC: RSVP: x.x.x.x_92-x.x.x.x_1001[x.x.x.x]:  
 PATH:
 non-RSVP-capable hop between prev-hop and me (ip ttl=254, rsvp  
 ttl=253)
 for new path

 The Juniper and Cisco both think that refresh reduction is supported  
 and
 the remote end is using it as well:

 Address: x.x.x.x via: blah status: Up
  Last changed time: 49:58, Idle: 10 sec, Up cnt: 1, Down cnt: 0
  Message received: 694
  Hello: sent 331, received: 329, interval: 9 sec
  Remote instance: 0xf6ee3e98, Local instance: 0xcb19f014
  Refresh reduction:  operational
Remote end: enabled, Ack-extension: enabled

 And I can even do rsvp Cisco-Juniper w/aggregate just fine, but as  
 soon as
 the path goes Cisco-Juniper-Cisco RSVP breaks. If I turn on  
 interface blah
 no-aggregate (reliable doesn't seem to have any effect) the problem  
 goes
 away and everything signals correctly.

 Relevent Cisco side config:

 ip rsvp signalling refresh reduction
 ip rsvp signalling hello
 ip rsvp signalling hello statistics
 ip rsvp policy preempt

 interface Tunnel1001
 ip unnumbered Loopback0
 load-interval 30
 tag-switching ip
 tunnel destination x.x.x.x
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng affinity 0x0 mask 0x1
 tunnel mpls traffic-eng path-option 10 dynamic
 tunnel mpls traffic-eng record-route
 tunnel mpls traffic-eng fast-reroute
 tunnel mpls traffic-eng auto-bw

 interface blah
 ...
 mpls traffic-eng tunnels
 tag-switching ip
 ip rsvp bandwidth 1000
 ip rsvp signalling hello
 ip rsvp signalling hello refresh interval 1000

 Juniper config:

 rsvp {
interface blah {
aggregate;
reliable;
subscription 95;
bandwidth 9g;
update-threshold 3;
link-protection;
}
 }

 Is there something I'm missing here?

 -- 
 Richard A Steenbergen [EMAIL PROTECTED]   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] J-Series and USB storage

[Stacy W. Smith]

On Apr 4, 2008, at 2:07 PM, Chris Adams wrote:
 Once upon a time, Chris Adams [EMAIL PROTECTED] said:
 I'm trying to snapshot a J2300 to a USB key.  I got a Kingston 1G USB
 (listed on the supported page) but it still doesn't work.  I do:

 [EMAIL PROTECTED] request system snapshot as-primary partition swap- 
 size 0 media usb
 error: usb media missing or invalid

 I discovered if I reboot the router after inserting the USB drive, it
 sees it (I don't see this listed in the docs anywhere as a  
 requirement).
 However, it didn't boot from the resulting USB key - it just said
 missing OS (and then after a timeout booted from CF).

 I was trying to upgrade to 8.5 (which requires more CF space),  
 following
 these directions:

 http://www.juniper.net/techpubs/software/jseries/junos85/rn-jseries-85/increasing-the-compact-flash-space.html#increase-cf-space-section

It shouldn't require a reboot to recognize the USB, but assuming a  
reboot makes it show up in the show chassis hardware detail output,  
you should then be able to proceed with the request system snapshot  
partition swap-size 0 media usb command in step 2 of those directions.

In this case, you do want to keep the swap-size 0 argument in order  
to remove the swap partition. I still think the as-primary keyword  
is unnecessary.

--Stacy

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

Re: [j-nsp] Can Record Route uses reverse DNS

[Stacy W. Smith]

I think 'show mpls lsp egress | resolve' may give you what you're  
looking for.

--Stacy

On  4 Feb 2008, at 9:08 PM, wang dong bei wrote:

 Hi Talented list members,

 I have updated all my interfaces IP with reverse DNS. Is that  
 possible for
 the output of show mpls lsp egress to make use of those in the  
 Record
 route: field instead of the numeric IP addresses?

 thanks in advance.

 dong bei
 ___
 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] How to retain annotations in | display set

[Stacy W. Smith]

Alternatively, you can use \n in the annotate command to create  
line breaks.

[edit snmp]
[EMAIL PROTECTED] annotate community public Where\nthe\nship\nresides...

[edit snmp]
[EMAIL PROTECTED] show
/* Where
the
ship
resides... */
community public;

--Stacy


On  17 Jan 2008, at 1:56 AM, Alain Briant wrote:

 Furthermore, if you want to add several lines to your comment you  
 can do
 it the same way via copy/paste and try for example to load merge
 terminal this

 [EMAIL PROTECTED] load merge terminal
 [Type ^D at a new line to end input]
 /* Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides...
 Where the ship resides... */
 snmp {
 community public;
 }
 load complete


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

Re: [j-nsp] New to Juniper (re-try)

[Stacy W. Smith]

[edit]
[EMAIL PROTECTED] show | compare rollback 0

shameless plugYou might also want to view the free training course  
at http://www.juniper.net/training/elearning/jsl.html. /shameless plug

--Stacy


On  27 Dec 2007, at 12:06 PM, Wayne Lansdowne wrote:

 Hello all,

 I apologize..my first posting attempt did not come through correctly.

 I'm new to the Juniper routers having previously worked with  
 Riverstone.
 Within the Riverstone CLI I had the ability to preview all the pending
 (non-committed) changes via a 'scratchpad' command.  Does the Juniper
 have a similar feature?  I'm unable to find anything thus far to  
 display
 a list of yet to be committed changes.  Thus far I'm simply doing a
 'commit check' then 'commit' and hoping I had remembered to implement
 all my changes.  I'm basically looking for a way to review all the
 pending changes before making that commit.

 I've done some searching and have come up empty.  Is there a CLI  
 command
 I'm missing?

 Regards,

 Wayne



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

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

Re: [j-nsp] Junos version for current JNCIE exam

[Stacy W. Smith]

Erwin,

The JNCIP-M and JNCIE-M exams are currently delivered using JUNOS 7.2  
software. However, both exams strive to avoid testing version- 
specific skills.

--Stacy

On  27 Dec 2007, at 12:19 AM, Erwin D wrote:

 Hi everyone,

 Anyone know the Junos version used for the current JNCIE-M exam? Is  
 it the
 same with JNCIP-M?


 Thank you,

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

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

Re: [j-nsp] BGP Configuration on J6350

[Stacy W. Smith]

Sounds like it's working as designed. Remember that a BGP neighbor  
only advertises the routes it's selected as best. In your case it  
sounds like the J6350 has only selected 6141 prefixes that it  
received from ISP3 as the best path, and is therefore only re- 
advertising those 6141 prefixes to the GSR. Presumably the J6350 has  
selected the path via the GSR for the remainder of its prefixes. If  
you want a different behavior you would need to modify which paths  
are being preferred via policy on one or both of your BGP-speaking  
routers.

--Stacy

On  3 Oct 2007, at 10:08 AM, Eric Van Tol wrote:

 Try doing a 'show route advertising-protocol bgp x.x.x.x', where  
 x.x.x.x
 is the GSR address.  It's quite possible that it is already sending a
 full table and the GSR just isn't showing the inactive routes.  I  
 can't
 remember what the default behavior is of Cisco, in terms of showing
 routes received in 'show ip bgp summary'.

 If you want to be sure, however, you can do the following:

 policy-statement internal {
 term term1 {
 from protocol bgp;
 }
 then nexthop self;
 }
 }

 That will re-advertise all routes learned through BGP to any peer on
 which you've applied this policy.

 -evt


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Matthew Crocker
 Sent: Wednesday, October 03, 2007 12:03 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] BGP Configuration on J6350


 Hello,

   I'm new to JUNOS please bear with me.

 I have the following network setup

 ISP1 (AS7018)  connected via OC-3 to GSR
 ISP2 (AS1239) connected via GigE to GSR
 ISP3 (AS16657) connected via GigE to J6350

 I have a GigE between the J6350  GSR,  My AS7849

 BGP with full tables running to all 3 ISPs

 ISP1 shows 227638 prefixes received (GSR)
 ISP2 shows 228612 prefixes received (GSR)
 ISP3 shows 227904 prefixes received (GSR)

 The J6350 is seeing 225992 prefixes from the GSR
 The GSR is only seeing 6141 prefixes from  the J6350

 How do I configure the J6350 to send the full table to its IGP peer?

 show bgp summary shows
 show bgp summary
 Groups: 2 Peers: 2 Down peers: 0
 Table  Tot Paths  Act Paths SuppressedHistory Damp
 StatePending
 inet.0453826 229366  0  0
 0  0
 Peer   AS  InPkt OutPktOutQ   Flaps Last Up/
 Dwn State|#Active/Received/Damped...
  7849  72875  14981   0   6   45:22
 223250/225922/0  0/0/0
  16657  41920113   0   2   53:53
 6116/227904/00/0/0

 show configuration protocols bgp
 path-selection always-compare-med;
 local-as 7849;
 group internal-within-AS7849 {
  type internal;
  local-address ge-0/0/0.0 IP address;
  export internal;
  graceful-restart;
  neighbor GSR IP ADDRESS;
 }
 group FiberTech {
  type external;
  export pl-announce;
  peer-as 16657;
  neighbor FIBERTECH IP ADDRESS;
 }

 show policy internal
 Policy internal:
  Term term1:
  then nexthop self




 ___
 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] Third party compact flash on the J6350.

[Stacy W. Smith]

There are definitely issues with the junos-jseries-cf images  
working on any CF that's not on the supported list. See: http:// 
www.juniper.net/techpubs/software/jseries/junos84/rn-jseries-84/rn- 
supported-IIIparty-hw.html#rn-supported-IIIparty-hw

Not sure if your Kingston cf's match the ones on the list, but it  
looks like the SanDisk ones do not.

That being said, you MAY be able to use the snapshot command on an  
existing J6350 router to prepare you current CFs. Use the supported  
SanDisk—ImageMate USB 2.0 Reader/Writer for CompactFlash Type I and  
II device to connect the CFs via USB. Then do request system  
snapshot media usb partition as-primary You can also add the  
factory keyword if you don't want to copy the configs with the  
snapshot.

HTH,
--Stacy

On  11 Sep 2007, at 11:39 AM, [EMAIL PROTECTED] wrote:

 Hi all,

 I'm in the process of setting up our second J6350, and part of that
 includes making spare compact flash disks loaded with JunOS in case  
 the
 flash in the chassis fails.  I have tried multiple flash sizes and
 manufacturers, with two different JunOS versions.  All fail to load  
 on the
 new J6350 I am testing each on.

 Versions:

   junos-jseries-8.3R2.8-export-cf512.gz
   junos-jseries-8.3R2.8-export-cf1024.gz
   junos-jseries-8.4R1.13-export-cf1024.gz

 Media:

   SanDisk 256MB
   Kingston 512MB CF/512 3.3V/5V 9930294-011.A00LF
   Kingston 1GB CF/1GB-S 3.3V/5V 9904168-006.A00LF
   SanDisk Ultra II 2GB

 Thoughts?

 -- Stephen.

 ___
 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] j2300 cf upgrade

[Stacy W. Smith]

Mike,

Try leaving off the as-primary keyword when doing the snapshot to  
the USB.

The as-primary keyword is only necessary if the destination of your  
snapshot will be used in the primary CF slot. So, don't use it when  
doing the snapshot to the USB device, but once you're booted off the  
USB with the new blank CF installed, you'll then want to do request  
system snapshot media compact-flash partition as-primary to get  
JUNOS onto the new primary CF.

Also, can you tell me what version of JUNOS you're using?

--Stacy

On Jun 20, 2007, at 11:50 AM, Michael Long wrote:

 I'm trying to upgrade the CF card in a j2300 from 128M to 2gig. I know
 it can be done but for some reason I'm having problems with this. I  
 have
 a 256meg usb drive plugged in and do a 'request system snapshot media
 usb as-primary partition' then 'request system halt media usb',  
 swap out
 the cf cards, boot and it should boot up on the usb right? It doesn't
 seem to work. It tries to boot from the usb, fails and then fails  
 on the
 CF.

 AMIBIOS(C)2003 American Megatrends, Inc.

 BIOS Date: 03/18/04 14:17:20 Ver: 08.00.10

 CPU : Intel(R) Celeron(R) CPU 1.60GHz

   Speed : 1.6 GHz



 Press DEL to run Setup (F4 on Remote Keyboard)

 Checking NVRAM..

 Initializing USB Controllers .. Done.

 1280MB OK

 USB Device(s): 1 Storage Device

 Auto-Detecting Pri Master..IDE Hard Disk

 Pri Master: SanDisk SDCFH-2048  HDX 4.04

 Auto-detecting USB Mass Storage Devices ..

 Device #01 : SanDisk Cruzer Micro

 01 USB mass storage devices found and configured.



 Booted because of Watch DOG timer timeout


 I'm not sure if it's even seeing the usb drive during boot.

 Am I doing something wrong or is there a better way to do this?

 Mike
 ___
 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] j2300 cf upgrade

[Stacy W. Smith]

Not all Juniper-labeled swag is on the supported USB list. Please  
confirm your USB flash drive on this list: http://www.juniper.net/ 
techpubs/software/jseries/junos82/rn-jseries-82/frameset.html

--Stacy

On Jun 20, 2007, at 2:01 PM, Chris Adams wrote:

 Once upon a time, Michael Long [EMAIL PROTECTED] said:
 doh silly me. Thank god for juniper swag. I used a usb drive that
 actually was labeled juniper and it seems to be booting off it fine.

 I've been trying this (as a learning experience) with a J2300 and my
 Juniper 512MB USB flash drive and I can't get it to work. :-(
 -- 
 Chris Adams [EMAIL PROTECTED]
 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