Re: [j-nsp] Question about ISO and ISIS family

[Felix Schueren]

Luis,


Hello ..
I´m working with isis using iso addressing, so now when i see the routes in
my EX  , it has the next:
juni...@junex.cvie.mgmt.01# run show route

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

  MultiRecv

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

49.77ff.0021.59cf.ebf0/72
   *[Direct/0] 03:11:44
> via lo0.0
49.77ff.0021.59cf.ebf1/72
   *[Direct/0] 02:46:39
> via lo0.0


so, my question is, how can i export via ISIS ( the adjacencies to the other
equipments are UP)  the  routes in the iso.0 table ?



I don't quite understand what you are trying to do? Export to where?

In any case:
- Junos can only propagate ip(4 + 6) routes via IS-IS, you cannot use 
run an ISO addressing network with Juniper boxes

- the ISO addressing is just for link-local communications so IS-IS works
- iso.0 routes are local and cannot be exported in any way

By default, any IP routes which are associated with IS-IS-speaking 
interfaces will be in the IS-IS database (and propagated throughout the 
IS-IS network).


kind regards,

Felix

--
Felix Schüren
Head of Network

---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller

(*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus
den dt. Mobilfunknetzen
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Question about ISO and ISIS family

[luis barrios]

Hello ..
I´m working with isis using iso addressing, so now when i see the routes in
my EX  , it has the next:
juni...@junex.cvie.mgmt.01# run show route

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

  MultiRecv

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

49.77ff.0021.59cf.ebf0/72
   *[Direct/0] 03:11:44
> via lo0.0
49.77ff.0021.59cf.ebf1/72
   *[Direct/0] 02:46:39
> via lo0.0


so, my question is, how can i export via ISIS ( the adjacencies to the other
equipments are UP)  the  routes in the iso.0 table ?

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

[j-nsp] Inter provider LDP based L2VPN between a Juniper network and a Cisco network

[Amos Rosenboim]

Hello All,

I'm trying to configure an inter provider LDP based L2VPN between a  
Juniper network and a Cisco network.

The topology is roughly as follows:

Cisco PE-Cisco P--Cisco P--Cisco ASBR--Juniper  
ASBR---Juniper P---Juniper P---Juniper PE.


In order to achieve this I need to establish the tunnel LSP between  
the PEs in both networks and than establish the LDP signaled VC on top  
of the tunnel LSP.
To establish the tunnel LSP the two ASBRs exchange IPv4+label (or  
labeled unicast in Junos language ) routes between them and advertise  
to each other the loopback IP of the PEs.
On the Cisco ASBR we simply redistribute the Juniper PE loopback into  
the igp and thus the PE has both a route and a label to reach the  
Juniper PE

However on the Juniper side I cannot do the same.
My question is what is the alternative method to achieve the same  
result on the Juniper side?
The solution I can think of is to use labeled unicast routes over iBGP  
between the Juniper ASBR and the Juniper PE but I'm not sure it will  
work (the Juniper network is not under my control so I cannot test).
If this is the solution than should the Juniper P routers also get  
this route or would the Juniper PE impose two labels for the address  
of the Cisco PE (the label derived from BGP for the Cisco PE + the  
label to reach the Juniper ASBR)



Thanks in advance.

Amos

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

Re: [j-nsp] SRX for access/core routing/MPLS duties?

[Tore Anderson]

* TCIS List Acct

> I've been reading past threads on the SRX line with interest.  It seems
> this box can do many of the things we are looking for (at a low price
> point), which include:
> 
> - MPLS
> - IPv4 routing (OSPF, BGP)
> - Runs JunOS
> - Could be used at the access layer
> - Future IPv6 support
> - If required, could be used as an edge device holding a full IPv4 table
> (at least, the SRX650 and above)
> 
> Can anyone comment on experiences with these devices, such as:
> 
> - Wire rate?  yea/nay?
> - Anyone ever tried to use one as an edge router w/a full BGP feed?
> - MPLS -- mainly EoMPLS type stuff, esp. at the access layer
> - Stability (we understand that this is highly specific to the JunOS
> release)

Hello,

I don't have any first-hand experience with the SRX but if you read back
in the archives of this list there's lots of messages saying it's
basically unusable because of lots of bugs and stability issues, and
even disregarding that there's the issue about it operating in flow-mode
with also is a big problem if you want to use it as a standard router
(as opposed to a security device/firewall).  I'm sure others will chime
in on these issues though.

However I do have first-hand experience of buying Juniper products with
«future IPv6 support».  I would NOT trust Juniper to deliver on that
promise in an honest manner if I were you.  I did, and while the JUNOS
support arrived shortly after my purchase, it required an «advanced
feature licence» with a hefty price tag (which they had neglected to
mention).  Juniper will tell you they have IPv4/IPv6 feature parity in
their licenses (
for instance), but it is simply not true.  So unless you can hold off
your purchase until you can support the support is definitively there in
the base licence, be very careful.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX for access/core routing/MPLS duties?

[Pavel Lunin]

Smaller ones as cheap access devices with or without (or even together 
with) MPLS—maybe. Check the latest thread on J-series. Just couple of 
days ago someone has given a good brief of how they use SRX100 in access 
with MPLS.


Full BGP, wire-rate—just forget. You can do full BGP on SRX650 though 
branch SRX have a bit slow control plane so… I would not recommend. 
Lower ones can't hold that hell of routes, they also can't be reflectors 
at all.


SRX3k and 5k—if you don't need a powerful firewall, just don't go there. 
It's cool as stateful device but as a packet router it will cost as at 
least two MX80 and have much less performance.


--
Pavel


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

Re: [j-nsp] SRX for access/core routing/MPLS duties?

[Michael Damkot]

I have two 5XXX series SRX boxes in an Active / Active cluster sitting in the 
middle of a network. They currently carry the following: (PIM goes up and down 
depending on downstream pulls)

inet.0: 322738 destinations, 968448 routes (322735 active, 2 holddown, 20 
hidden)
Restart Complete
  Direct: 12 routes, 11 active
   Local: 12 routes, 12 active
OSPF: 77 routes, 77 active
 BGP: 968344 routes, 322632 active
IGMP:  1 routes,  1 active
 PIM:  2 routes,  2 active

Convergence times are sub 4 minutes, but I completely agree that there are some 
new kid on the block issues that still crop up on a regular basis.

It's also worth note that I am only peering with internal BGP neighbors, no 
external neighbors at this time. 

On Jul 28, 2010, at 11:34 , Ben Dale wrote:

> 
>> I've been reading past threads on the SRX line with interest.  It seems this 
>> box can do many of the things we are looking for (at a low price point), 
>> which include:
>> 
>> - MPLS
>> - IPv4 routing (OSPF, BGP)
>> - Runs JunOS
>> - Could be used at the access layer
>> - Future IPv6 support
>> - If required, could be used as an edge device holding a full IPv4 table (at 
>> least, the SRX650 and above)
>> 
>> Can anyone comment on experiences with these devices, such as:
>> 
>> - Wire rate?  yea/nay?
> 
> The branch office models (100, 210, 240, 650) are all software-based 
> forwarding engines, so nay.  The 650 is pretty gutsy, but it's no EX.  Word 
> on the street is that there will be a model arriving soon that fits between 
> the 650 and the 3400, but will be based on the high-end hardware (SPC/NPC) 
> platform. 
> 
>> - Anyone ever tried to use one as an edge router w/a full BGP feed?
> 
> Yes.  Results were mixed, but generally avoid this scenario if you can.  As 
> discussed in other recent threads - flow-mode processing is not ideal for an 
> edge-router (you move from a PPS limitation with a normal router to a session 
> table limitation for starters), and performance-wise full-table updates are 
> nothing to write home about..  though you will have plenty of time to write 
> home about them while waiting for them to complete if you so wish..
> 
>> - MPLS -- mainly EoMPLS type stuff, esp. at the access layer
> 
> This IMHO is where the SRX really shines and the "One-OS" mantra really sees 
> the light of day.  Juniper didn't leave too much out of the SRX code - 
> EoMPLS, VPLS, L3VPN, Logical-Tunnel interfaces, it's all there - they really 
> are the swiss-army knife of access boxes, and at a very surprising price.  
> Just make sure you go high-memory for everything day one.  SRX240s will take 
> 2GB of 3rd party RAM quite happily too.
> 
>> - Stability (we understand that this is highly specific to the JunOS release)
> 
> You've got that right ; )  Seriously though, the MPLS-code in the SRXs seems 
> to be pretty tight - most of the bugs I come across seem to be related to the 
> security-processing and clustering side of things which is all (relatively) 
> new.  That said, since moving the majority of my customers to 10.0r3 my open 
> JTAC Cases have significantly decreased (the same can be said for EX).  
> That's not to say there aren't still some doozies out there though (turn on 
> HTTPS in 10.0r3 and browse to the web interface, now make some coffee, now 
> learn a foreign language, now log in).
> ___
> 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] SRX for access/core routing/MPLS duties?

[Ben Dale]

> I've been reading past threads on the SRX line with interest.  It seems this 
> box can do many of the things we are looking for (at a low price point), 
> which include:
> 
> - MPLS
> - IPv4 routing (OSPF, BGP)
> - Runs JunOS
> - Could be used at the access layer
> - Future IPv6 support
> - If required, could be used as an edge device holding a full IPv4 table (at 
> least, the SRX650 and above)
> 
> Can anyone comment on experiences with these devices, such as:
> 
> - Wire rate?  yea/nay?

The branch office models (100, 210, 240, 650) are all software-based forwarding 
engines, so nay.  The 650 is pretty gutsy, but it's no EX.  Word on the street 
is that there will be a model arriving soon that fits between the 650 and the 
3400, but will be based on the high-end hardware (SPC/NPC) platform. 

> - Anyone ever tried to use one as an edge router w/a full BGP feed?

Yes.  Results were mixed, but generally avoid this scenario if you can.  As 
discussed in other recent threads - flow-mode processing is not ideal for an 
edge-router (you move from a PPS limitation with a normal router to a session 
table limitation for starters), and performance-wise full-table updates are 
nothing to write home about..  though you will have plenty of time to write 
home about them while waiting for them to complete if you so wish..

> - MPLS -- mainly EoMPLS type stuff, esp. at the access layer

This IMHO is where the SRX really shines and the "One-OS" mantra really sees 
the light of day.  Juniper didn't leave too much out of the SRX code - EoMPLS, 
VPLS, L3VPN, Logical-Tunnel interfaces, it's all there - they really are the 
swiss-army knife of access boxes, and at a very surprising price.  Just make 
sure you go high-memory for everything day one.  SRX240s will take 2GB of 3rd 
party RAM quite happily too.

> - Stability (we understand that this is highly specific to the JunOS release)

You've got that right ; )  Seriously though, the MPLS-code in the SRXs seems to 
be pretty tight - most of the bugs I come across seem to be related to the 
security-processing and clustering side of things which is all (relatively) 
new.  That said, since moving the majority of my customers to 10.0r3 my open 
JTAC Cases have significantly decreased (the same can be said for EX).  That's 
not to say there aren't still some doozies out there though (turn on HTTPS in 
10.0r3 and browse to the web interface, now make some coffee, now learn a 
foreign language, now log in).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX for access/core routing/MPLS duties?

[Scott T. Cameron]

BGP is slow.  Painfully so.

I have 2x SRX3400 in a chassis cluster config getting 2 full BGP tables.  I
would say it takes at least 5 minutes for the BGP updates to complete and
for the device to be usable.

IPv6 support will be in 10.2 for SRX3400 and higher.  10.2R1 exists today
but has a number of interesting bugs.

I wouldn't really recommend this device as a router.  I just purchased some
MX240s to take over the routing role from my SRX3400s.

Scott

On Wed, Jul 28, 2010 at 10:05 AM, TCIS List Acct
wrote:

> I've been reading past threads on the SRX line with interest.  It seems
> this box can do many of the things we are looking for (at a low price
> point), which include:
>
> - MPLS
> - IPv4 routing (OSPF, BGP)
> - Runs JunOS
> - Could be used at the access layer
> - Future IPv6 support
> - If required, could be used as an edge device holding a full IPv4 table
> (at least, the SRX650 and above)
>
> Can anyone comment on experiences with these devices, such as:
>
> - Wire rate?  yea/nay?
> - Anyone ever tried to use one as an edge router w/a full BGP feed?
> - MPLS -- mainly EoMPLS type stuff, esp. at the access layer
> - Stability (we understand that this is highly specific to the JunOS
> release)
>
> TIA.
>
> --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] Juniper MX80 IRB

[Tim Vollebregt]

All,

Thanks a lot for your comments, seems that there are more occasions 
where this problem is occurring.

We are having the MX80-48T which has the Trio chip.

It was a bit strange while building the configuration, at some point it 
seemed to work the 10.x way. There was ARP, but no connectivity.

The system is now live with the following configuration and performing well:

ge-1/0/0 {
encapsulation ethernet-bridge;
gigether-options {
no-flow-control;
}
unit 0;

  irb {
description med-srvrs;
unit 0 {
description ALL;
family inet {
address x.x.x.x/29;
address x.x.x.x/27;

bridge-domains {
all {
domain-type bridge;
vlan-id none;
interface ge-1/0/0.0;
routing-interface irb.0

Regards,

Tim







On 28-07-10 15:49, Addy Mathur wrote:

On Wednesday, July 28, 2010, Mark Tinka  wrote:
   

On Tuesday, July 27, 2010 10:31:18 pm Chuck Anderson wrote:

 

Finally, JTAC/ATAC can't even figure out the above!!!  I
have a case open and they *still* haven't come to the
solution because they haven't realized that "Today Trio
only supports the old style config" and what that really
means.
   

The disconnect between JTAC and the core of the development
team has always been there, in my opinion. It took a whole
year of back-and-forth with JTAC on a case that, when it was
finally escalated to a senior engineer within Juniper, was
resolved in 30 minutes. No, seriously...

It's easy to assume that just because JTAC work for Juniper,
they're familiar with JUNOS and the Juniper hardware. But
this, as I've seen time&  time again, really isn't the case.

Mark.

 

Although it doesn't answer the specific question raised via this
thread, the following link dose offer some general guidance on Trio
chipset features.  Should mostly be applicable to the MX80 as well.

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-features.html

Regards,
Addy.

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

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

[j-nsp] GRE tunnel with dynamic IP address

[Markus]

On an M7i with builtin tunnel PIC running 8.0R2.8, is it possible to
create a GRE tunnel where the destination is at a dynamic IP address? The
destination is on a .dyndns.org hostname.

There is dynamic-tunnels under routing-options but I don't see how that
could help me.

What I want to achieve is to route a subnet of static IP addresses to the
endpoint of the tunnel behind a dynamic IP address.

Can anyone help?

Thanks,
Markus


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

[j-nsp] SRX for access/core routing/MPLS duties?

[TCIS List Acct]

I've been reading past threads on the SRX line with interest.  It seems this box 
can do many of the things we are looking for (at a low price point), which include:


- MPLS
- IPv4 routing (OSPF, BGP)
- Runs JunOS
- Could be used at the access layer
- Future IPv6 support
- If required, could be used as an edge device holding a full IPv4 table (at 
least, the SRX650 and above)


Can anyone comment on experiences with these devices, such as:

- Wire rate?  yea/nay?
- Anyone ever tried to use one as an edge router w/a full BGP feed?
- MPLS -- mainly EoMPLS type stuff, esp. at the access layer
- Stability (we understand that this is highly specific to the JunOS release)

TIA.

--Mike

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

Re: [j-nsp] Juniper MX80 IRB

[Addy Mathur]

On Wednesday, July 28, 2010, Mark Tinka  wrote:
> On Tuesday, July 27, 2010 10:31:18 pm Chuck Anderson wrote:
>
>> Finally, JTAC/ATAC can't even figure out the above!!!  I
>> have a case open and they *still* haven't come to the
>> solution because they haven't realized that "Today Trio
>> only supports the old style config" and what that really
>> means.
>
> The disconnect between JTAC and the core of the development
> team has always been there, in my opinion. It took a whole
> year of back-and-forth with JTAC on a case that, when it was
> finally escalated to a senior engineer within Juniper, was
> resolved in 30 minutes. No, seriously...
>
> It's easy to assume that just because JTAC work for Juniper,
> they're familiar with JUNOS and the Juniper hardware. But
> this, as I've seen time & time again, really isn't the case.
>
> Mark.
>

Although it doesn't answer the specific question raised via this
thread, the following link dose offer some general guidance on Trio
chipset features.  Should mostly be applicable to the MX80 as well.

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/general/mpc-mx-series-features.html

Regards,
Addy.

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

Re: [j-nsp] Juniper MX80 IRB

[Mark Tinka]

On Tuesday, July 27, 2010 10:31:18 pm Chuck Anderson wrote:

> Finally, JTAC/ATAC can't even figure out the above!!!  I
> have a case open and they *still* haven't come to the
> solution because they haven't realized that "Today Trio
> only supports the old style config" and what that really
> means.

The disconnect between JTAC and the core of the development 
team has always been there, in my opinion. It took a whole 
year of back-and-forth with JTAC on a case that, when it was 
finally escalated to a senior engineer within Juniper, was 
resolved in 30 minutes. No, seriously...

It's easy to assume that just because JTAC work for Juniper, 
they're familiar with JUNOS and the Juniper hardware. But 
this, as I've seen time & time again, really isn't the case.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp