Re: [j-nsp] vRR/L3VPN/Unusable
Hi,
There are a few different ways to resolve the MP-BGP routes on out of band
Juniper RR. Depends on how flexible you want to be, one can use static
route in inet.3, change of the resolution or rib-groups copying the routes
form inet.0 to inet.3.
Using the static route will work even without family mpls enabled on the
interfaces. However the other two ways require that family to be enabled on
the RR interfaces.
Ivan,
On Thu, Sep 13, 2018 at 10:28 AM Misak Khachatryan
wrote:
> Well i think that also a problem of copy/pasting :)
>
> Previously we had RR on a PE router and it seems i did simple copy/paste
> of relevant config.
> Can't remember any other reason to do that.
>
> But Jason has a problem having only
>
> set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
>
> on his VRR
>
> Best regards,
> Misak Khachatryan,
>
> On Thu, Sep 13, 2018 at 1:41 AM adamv0...@netconsultings.com adamv0...@netconsultings.com> adamv0...@netconsultings.com>> wrote:
> Hmm, these things are nasty you set them once and forget how they work :)
>
> Why to define the inet.3 table at all? I mean if you can have bgp.l3vpn.0
> resolve directly from inet.0 (which I seem to remember it would do without
> any help anyways):
> set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
>
> You can then do the same for v6, just need to leak all v4 routes to
> inet6.0 (well if you're not running v6 in IGP.
>
> Oh and don't forget the FIB filter.
>
> adam
>
> netconsultings.com<http://netconsultings.com>
> ::carrier-class solutions for the telecommunications industry::
>
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net juniper-nsp-boun...@puck.nether.net>] On Behalf
> > Of Misak Khachatryan
> > Sent: Wednesday, September 12, 2018 1:02 PM
> > To: jason-j...@lixfeld.ca<mailto:jason-j...@lixfeld.ca>
> > Cc: juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
> > Subject: Re: [j-nsp] vRR/L3VPN/Unusable
> >
> > Hi,
> >
> > I run two out of band vRR with all vpn flavors and families, and don't
> need to
> > have family mpls enabled on interfaces. It's version 17.4 but i don't
> think that
> > matters.
> >
> > This should be enough:
> >
> > routing-options {
> >rib inet.3 {
> >static {
> >route 0.0.0.0/0<http://0.0.0.0/0><http://0.0.0.0/0> discard;
> >}
> >}
> >rib inet6.3 {
> >static {
> >route ::/0 discard;
> >}
> >}
> >resolution {
> >rib bgp.l3vpn.0 {
> >resolution-ribs [ inet.3 inet.0 ];
> >}
> >}
> > }
> >
> >
> > Best regards,
> > Misak Khachatryan,
> >
> > On Wed, Sep 12, 2018 at 3:51 PM Jason Lixfeld > j...@lixfeld.ca<mailto:j...@lixfeld.ca><mailto:jason-j...@lixfeld.ca
> <mailto:jason-j...@lixfeld.ca>>> wrote:
> > Hi Ivan,
> >
> > I did not, and that did indeed fix it. I don’t understand why it’s
> necessary so
> > that’ll be my next read.
> >
> > Thanks!
> >
> > > On Sep 12, 2018, at 7:22 AM, Ivan Ivanov
> > mailto:ivanov.i...@gmail.com> ivanov.i...@gmail.com<mailto:ivanov.i...@gmail.com>>> wrote:
> > >
> > > Hi Jason.
> > >
> > > Do you have 'family mpls' configured for the vRR interfaces? Although
> the
> > RR is out of band you need that family configured on the RR interface.
> > >
> > > Ivan,
> > >
> > > On Wed, Sep 12, 2018 at 12:10 PM Jason Lixfeld > j...@lixfeld.ca<mailto:j...@lixfeld.ca><mailto:jason-j...@lixfeld.ca
> <mailto:jason-j...@lixfeld.ca>> <mailto:jason-<mailto:jason->
> > j...@lixfeld.ca<mailto:j...@lixfeld.ca><mailto:jason-j...@lixfeld.ca
> <mailto:jason-j...@lixfeld.ca>>>> wrote:
> > > Hi all,
> > >
> > > Trying to learn more about JunOS, I’m playing around with a vRR
> instance
> > (18.2R1-S1.5), and I haven’t been able to get something sorted.
> > >
> > > This vRR instance is running as an out-of-band RR for a few LDP enabled
> > PEs. vRR is not running LDP so inet.3 is empty, but as far as I
> understand, any
> > one of the two routing-options knobs configured below should be enough to
> > provide for the prefixes in bgp.l3vpn.0 to be able to resolve their
> respective
> > next-hops and bring the routes in the table out of hidden to active.
> However
> &g
Re: [j-nsp] vRR/L3VPN/Unusable
Hi Jason. Do you have 'family mpls' configured for the vRR interfaces? Although the RR is out of band you need that family configured on the RR interface. Ivan, On Wed, Sep 12, 2018 at 12:10 PM Jason Lixfeld wrote: > Hi all, > > Trying to learn more about JunOS, I’m playing around with a vRR instance > (18.2R1-S1.5), and I haven’t been able to get something sorted. > > This vRR instance is running as an out-of-band RR for a few LDP enabled > PEs. vRR is not running LDP so inet.3 is empty, but as far as I > understand, any one of the two routing-options knobs configured below > should be enough to provide for the prefixes in bgp.l3vpn.0 to be able to > resolve their respective next-hops and bring the routes in the table out of > hidden to active. However that’s not happening. > > jlixfeld@rr01# show routing-options | display set | match rib > set routing-options rib inet.3 static route 0.0.0.0/0 discard > set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 > > [edit] > jlixfeld@rr01# run show route table bgp.l3vpn.0 9.9.9.9/32 detail hidden > > bgp.l3vpn.0: 29 destinations, 49 routes (0 active, 0 holddown, 49 hidden) > 12345:4:9.9.9.9/32 (1 entry, 0 announced) > BGPPreference: 170/-391 > Route Distinguisher: 12345:4 > Next hop type: Unusable, Next hop index: 0 > Address: 0x27b17bc > Next-hop reference count: 53 > State: > Local AS: 12345 Peer AS: 12345 > Age: 1:52:31Metric: 0 > Validation State: unverified > Task: BGP_12345.10.15.48.11+179 > AS path: 11670 ? > Communities: 12345:2000 12345:2010 target:12345:4 > Accepted > VPN Label: 217 > Localpref: 390 > Router ID: 10.15.48.11 > > [edit] > jlixfeld@rr01# run show route table inet.0 10.15.48.11 > > inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) > + = Active Route, - = Last Active, * = Both > > 10.15.48.11/32 *[IS-IS/18] 01:51:14, metric 30 > > to 10.15.49.67 via em1.0 > > [edit] > jlixfeld@rr01# > > Is there something less obvious that needs to happen before one of those > two knobs above will work? > > FWIW, I haven’t played around with enabling LDP here, or configuring RIB > groups because I’m not really interested in exploring those as solutions if > I can help it; they seem a little too heavy handed when the aforementioned > two knobs should probably work fine? > > Thanks in advance! > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Fwd: BGP route-target filtering issue
Probably the knob from the link below configured towards the r1 will
prevent sending the default
https://www.juniper.net/documentation/en_US/junos/
topics/example/vpn-proxy-bgp-route-target-filtering-configuring.html
Ivan,
On Tue, Jun 6, 2017 at 10:55 PM, Mihai wrote:
> Hi,
>
> Why would a router advertise the default RT on behalf of other router in a
> full mesh IBGP? (The RR case is very clear)
>
> Regards,
> Mihai
>
> On 06/06/2017 09:42 PM, Ivan Ivanov wrote:
>
>> Hi,
>>
>> Check this link -
>> https://www.juniper.net/documentation/en_US/junos/topics/con
>> cept/vpn-proxy-bgp-route-target-filtering-understanding.html
>>
>> If you configure the rest of the routers with family route-target r3 and
>> r4 will stop sending the proxy route you see. Or just use RR.
>>
>> Ivan,
>>
>> On Tue, Jun 6, 2017 at 9:01 PM, Mihai > <mailto:mihaigabr...@gmail.com>> wrote:
>>
>> Update: using route policies with rtf-prefix-list works, but
>> rtf-prefix-lists are supported from Junos 12.2 and I have devices
>> with older software.
>> I am more interested if this is a 'normal' behavior.
>>
>> Regards,
>> Mihai
>>
>>
>> On 06/06/2017 07:41 PM, Mihai wrote:
>>
>> Hi,
>>
>> I have three routers (r1,r3,r4) and a full mesh IBGP between
>> them.
>> R1 is configured with inet-vpn , R3 and R4 with inet-vpn and
>> route-target.
>>
>> r1# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 1.1.1.1;
>> family inet-vpn {
>> unicast;
>> }
>> neighbor 3.3.3.3;
>> neighbor 4.4.4.4;
>> }
>>
>> r3# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 3.3.3.3;
>> family inet-vpn {
>> unicast;
>> }
>> family route-target;
>> neighbor 1.1.1.1;
>> neighbor 4.4.4.4;
>> }
>>
>> r4# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 4.4.4.4;
>> family inet-vpn {
>> unicast;
>> }
>> family route-target;
>> neighbor 1.1.1.1;
>> neighbor 3.3.3.3;
>> }
>>
>> I don't understand why R3 and R4 are advertising the default rt
>> route
>> (0:0:0/0) in this topology as I am not using route reflectors.
>>
>> r3# run show table bgp.rt
>> Jun 06 18:10:05
>>
>> bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0
>> hidden)
>>
>> + = Active Route, - = Last Active, * = Both
>>
>> 0:0:0/0
>>*[RTarget/5] 00:10:46
>> Type Default
>> Local
>> [BGP/170] 00:10:42, localpref 100, from
>> 4.4.4.4
>> AS path: I, validation-state: unverified
>> > to 10.0.2.6 via ge-0/0/4.34
>>
>> r4# run show table bgp.rt
>>
>> bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0
>> hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 0:0:0/0
>>*[RTarget/5] 00:11:13
>> Type Default
>> Local
>> [BGP/170] 00:11:09, localpref 100, from
>> 3.3.3.3
>> AS path: I, validation-state: unverified
>> > to 10.0.2.5 via ge-0/0/3.34
>>
>> If I want to create a VRF/L2VPN/VPLS on R3 (first) and R4
>> (later) the
>> service will be down because R3 will not readvertise the
>> VRF/L2VPN/VPLS
>> when is receiving the VPN RT/ROUTE from R4.
>> The only solution to get the R3 VPN route on R4 is by requesting
>> it with
>> a ROUTE REFRESH (clear soft-inbound) from R4.
>>
>> This has been tested on Junos 13.3 and 14.1.
>>
>> PS: I don't want to configure R3/R4 with "keep all" and I can't
>> make any
>> configuration that will reset the BGP sessions.
>>
>> Does this look like a BUG?
>>
>> Regards,
>> Mihai
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> <mailto:juniper-nsp@puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> <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 route-target filtering issue
Hi,
Check this link -
https://www.juniper.net/documentation/en_US/junos/topics/concept/vpn-proxy-bgp-route-target-filtering-understanding.html
If you configure the rest of the routers with family route-target r3 and r4
will stop sending the proxy route you see. Or just use RR.
Ivan,
On Tue, Jun 6, 2017 at 9:01 PM, Mihai wrote:
> Update: using route policies with rtf-prefix-list works, but
> rtf-prefix-lists are supported from Junos 12.2 and I have devices with
> older software.
> I am more interested if this is a 'normal' behavior.
>
> Regards,
> Mihai
>
>
> On 06/06/2017 07:41 PM, Mihai wrote:
>
>> Hi,
>>
>> I have three routers (r1,r3,r4) and a full mesh IBGP between them.
>> R1 is configured with inet-vpn , R3 and R4 with inet-vpn and route-target.
>>
>> r1# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 1.1.1.1;
>> family inet-vpn {
>> unicast;
>> }
>> neighbor 3.3.3.3;
>> neighbor 4.4.4.4;
>> }
>>
>> r3# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 3.3.3.3;
>> family inet-vpn {
>> unicast;
>> }
>> family route-target;
>> neighbor 1.1.1.1;
>> neighbor 4.4.4.4;
>> }
>>
>> r4# show protocols bgp
>> group IBGP {
>> type internal;
>> local-address 4.4.4.4;
>> family inet-vpn {
>> unicast;
>> }
>> family route-target;
>> neighbor 1.1.1.1;
>> neighbor 3.3.3.3;
>> }
>>
>> I don't understand why R3 and R4 are advertising the default rt route
>> (0:0:0/0) in this topology as I am not using route reflectors.
>>
>> r3# run show table bgp.rt
>> Jun 06 18:10:05
>>
>> bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
>>
>> + = Active Route, - = Last Active, * = Both
>>
>> 0:0:0/0
>>*[RTarget/5] 00:10:46
>> Type Default
>> Local
>> [BGP/170] 00:10:42, localpref 100, from 4.4.4.4
>> AS path: I, validation-state: unverified
>> > to 10.0.2.6 via ge-0/0/4.34
>>
>> r4# run show table bgp.rt
>>
>> bgp.rtarget.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 0:0:0/0
>>*[RTarget/5] 00:11:13
>> Type Default
>> Local
>> [BGP/170] 00:11:09, localpref 100, from 3.3.3.3
>> AS path: I, validation-state: unverified
>> > to 10.0.2.5 via ge-0/0/3.34
>>
>> If I want to create a VRF/L2VPN/VPLS on R3 (first) and R4 (later) the
>> service will be down because R3 will not readvertise the VRF/L2VPN/VPLS
>> when is receiving the VPN RT/ROUTE from R4.
>> The only solution to get the R3 VPN route on R4 is by requesting it with
>> a ROUTE REFRESH (clear soft-inbound) from R4.
>>
>> This has been tested on Junos 13.3 and 14.1.
>>
>> PS: I don't want to configure R3/R4 with "keep all" and I can't make any
>> configuration that will reset the BGP sessions.
>>
>> Does this look like a BUG?
>>
>> Regards,
>> Mihai
>>
>> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS Telemetry
> > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospf rid lo0 stub advertisement
Hi Aaron, Although the JNCx Sybex books are valuable study guide, they are quite old now. I quickly checked the JUNOS version that the book is based on, and it shows 5.x It is not a surprise that you can achieve what you have quoted from the book. This was changed at some point in the JUNOS evolution and the lo0.0 address is not anymore automatically advertised. One other thing that was changed, after the books were released, is the way the BGP routes that failed as-path loop check are treated. In the book, it might be JNCIE rather the JNCIP, is stated that those routes are discarded and can't be seen with any operational command. This behavior was changed, and now they show as hidden routes. Ivan, On Tue, Feb 28, 2017 at 7:20 PM, Aaron wrote: > I am using logical systems in my lab and trying to see the > auto-advertisement of the lo0 interface working and it's not. Any ideas ? > > > > > > https://www.juniper.net/assets/us/en/local/pdf/study- > guide/study-guide-jncip > .pdf > > > > page 178 of 708 (page is actually labeled page 156) mentions the following. > > > > By default JUNOS software will obtain the OSPF router ID from the first > interface that is detected with a non-Martian address. Because lo0 is > always > the first interface examined when rpd starts, explicit configuration of the > RID under routing-options is rarely necessary. Simply assigning the desired > IP address to the lo0 interface results in a stable and deterministic > router > ID. > > > > JUNOS software automatically advertises a stub route to the interface from > which the RID is obtained; therefore it is not actually necessary to > explicitly configure lo0 as an OSPF interface to meet the lo0 connectivity > requirements of this configuration example. > > > > Manually configuring the RID under routing-options will affect connectivity > to the lo0 address, as the router will no longer include a stub route for > its lo0 interface. You will have to enable OSPF on the lo0 interface, as > done in the previous example, if lo0 connectivity is required and you have > assigned the RID manually. > > > > Omitting the lo0 interface from your OSPF configuration results in the lo0 > address being advertised as a stub network in the router LSAs (type 1 LSAs) > that are generated and flooded into all areas to which a given router > attaches. > > > > > > -Aaron > > _______ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Limit content of bgp.l3vpn.0
Hi, This is a solution to your problem: http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/family-edit-protocols-bgp-route-target-vp.html Give it a try first in a lab test first. If you use RR you should copy its loopback address to inet.3 on all PEs. HTH, Ivan, On Wed, Sep 28, 2016 at 11:01 AM, Johan Borch wrote: > Hi > > Lets say i have two PE-routers, router1 and router2. > > They run MP-BGP, MPLS and so on, the usual stuff. I have one VRF with a lot > of routes in (DFZ). Router2 is not importing the vrf-target for this VRF. > My problem is that router2 is dead slow and even if I'm not importing this > perticual vrf-target it still takes ages to go through all routes, can I > somehow limit what router1 sends to router2 in the bgp.l3vpn.0 table? > > Johan > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX asymmetric routing on WAN side
Hi Rolf, The traffic in your case will be accepted by default regardless of the interface. You don't need to do anything to permit it. You have to permit explicitly only if the traffic is transmitted between two interfaces even they are in the same zone. I cannot find a link for a proof, though. HTH, Ivan, On Wed, Nov 11, 2015 at 4:07 PM, "Rolf Hanßen" wrote: > Hi, > > I have a quite simple setup, SRX with a WAN connection and some LAN stuff. > WAN is single-homed. > I now want to add a second uplink interface and put it into the existing > WAN/untrust zone. > So the traffic may flow async (interface point of view) but sync (zone > point of view). > Will this require any other changes or break functions? > I especially think of the connection tracking because I see that flows > contain interface information (looking at "show security flow session") as > well as zones. > > I found dozens of sites related to similar topics telling to set > no-syn-check / no-sequence-check but always with some special setups (like > 2 WAN zones). So I am unsure if this is related to my setup at all. > If this is related to a minimum software version please let me know. > > kind regards > Rolf > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] jtree0 Memory full on MX480?
Hi, The size of the firewall configuration could be concern if you use the box for subscriber management and have tons of dynamic interface with filters attached. Otherwise you should be safe to use that knob. At the moment you have 11.5MB in segment 1, when you enable that know it will go down to 6MB or 7MB. And you will be able to accommodate two full feeds in the FIB. 11650408 bytes available (11609600 bytes from free pages) I would recommend to check for any know PR using that feature with 11.4 Ivan, On Wed, Jul 22, 2015 at 4:31 PM, Jeff Meyers wrote: > Hi, > > thanks for the hint, didn't know about that option. This will certainly > safe us if we are running in to limits. We don't have too many filters, > mostly the basic stuff to protect the RE and a few filters on some vlans > with basic white- and/or blacklisting. So really nothing fance although I > have no idea mow many "many" filters are on a box like the MX. Is it 1,000 > terms or more like 1,000,000 terms? > > > Best, > Jeff > > Am 22.07.2015 um 13:06 schrieb Ivan Ivanov: > >> Hi, >> >> The 'route' option on 'memory-enhanced' will give you some time before >> upgrade to MPC. Actually you should be okay for quite a long time >> considering the size of the table you have at the moment. >> >> >> https://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html >> < >> https://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/junos-software-jtree-memory-repartitioning.html >> > >> >> Note, that this will use the part of the memory reserved for filters >> (Jtree segment 1) for storing route information. You that feature only >> if don't have many filters configured. >> >> Ivan, >> >> >> On Wed, Jul 22, 2015 at 7:52 AM, Mark Tinka > <mailto:mark.ti...@seacom.mu>> wrote: >> >> >> >> On 22/Jul/15 02:59, Chris Kawchuk wrote: >> > I know that a ton of fixes on BGP convergence time son MX80 is >> definitely a reason to be 'moving up'... however as you're on RE-2000s on >> MX480 may not be applicable. >> > >> > I see you're running DPC cards, have you considered shifting those >> links onto an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda >> yadda yadda =)..) DPC was EOL a while ago, and everything has been Trio >> (and now Trio-NG on the new -NG cards coming out now). As the FIB is pushed >> to hardware, it may be some silly DPC thing you're running into. >> > >> > For things like Fusion or BNG or any other >> new/advanced/this-is-what-PLM-is-thinking functions, we're already putting >> in 14.2 on any new device we turn up, and have already started testing 15.1 >> for the new NG cards we will likely be buying. Rest of our network is now >> on 12.3R8 or 13.3 in many cases. (lots of BFD bugs have been squashed, some >> HQoS issues fixed, host-outbound-traffic for BFD keepalives now honour the >> c-o-s knobs, and are finally out of Queue 3 and into the Queue we want (7), >> etc... preventing starvation if you happen to have re-used Queue 3 as >> "not-so-high" priority, etc)... the list goes on. >> > >> > It's not a case of "if it aint broke, don't fix it" once you get >> 4-5 years behind. You'll benefit from the years of "Oh, we finally fixed >> LLDP ascii decoding" stuff that ends up getting traction; plus JTAC would >> really really like it if you weren't on 11.4 =) >> >> We've been on 14.2 for a while now, and settling into 14.2R3.8. >> >> Happy, to be honest. Only real problem is policing on LAG's, but it's >> manageable. >> >> Mark. >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> <mailto:juniper-nsp@puck.nether.net> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> >> >> -- >> Best Regards! >> >> Ivan Ivanov >> > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] jtree0 Memory full on MX480?
Hi, The 'route' option on 'memory-enhanced' will give you some time before upgrade to MPC. Actually you should be okay for quite a long time considering the size of the table you have at the moment. https://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/ junos-software-jtree-memory-repartitioning.html Note, that this will use the part of the memory reserved for filters (Jtree segment 1) for storing route information. You that feature only if don't have many filters configured. Ivan, On Wed, Jul 22, 2015 at 7:52 AM, Mark Tinka wrote: > > > On 22/Jul/15 02:59, Chris Kawchuk wrote: > > I know that a ton of fixes on BGP convergence time son MX80 is > definitely a reason to be 'moving up'... however as you're on RE-2000s on > MX480 may not be applicable. > > > > I see you're running DPC cards, have you considered shifting those links > onto an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda yadda > yadda =)..) DPC was EOL a while ago, and everything has been Trio (and now > Trio-NG on the new -NG cards coming out now). As the FIB is pushed to > hardware, it may be some silly DPC thing you're running into. > > > > For things like Fusion or BNG or any other > new/advanced/this-is-what-PLM-is-thinking functions, we're already putting > in 14.2 on any new device we turn up, and have already started testing 15.1 > for the new NG cards we will likely be buying. Rest of our network is now > on 12.3R8 or 13.3 in many cases. (lots of BFD bugs have been squashed, some > HQoS issues fixed, host-outbound-traffic for BFD keepalives now honour the > c-o-s knobs, and are finally out of Queue 3 and into the Queue we want (7), > etc... preventing starvation if you happen to have re-used Queue 3 as > "not-so-high" priority, etc)... the list goes on. > > > > It's not a case of "if it aint broke, don't fix it" once you get 4-5 > years behind. You'll benefit from the years of "Oh, we finally fixed LLDP > ascii decoding" stuff that ends up getting traction; plus JTAC would really > really like it if you weren't on 11.4 =) > > We've been on 14.2 for a while now, and settling into 14.2R3.8. > > Happy, to be honest. Only real problem is policing on LAG's, but it's > manageable. > > Mark. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports
Hi, Look at newly released PTX1000 from Juniper. It comes with latest J custom silicon and unlike the first version it comes also with full blow routing. PTX1000 <https://www.juniper.net/us/en/products-services/routing/ptx-series/ptx1000/> For cheaper option you can check ACX5000. ACX5000 <https://www.juniper.net/us/en/products-services/routing/acx-series/acx5000/> Ivan, On Mon, Jul 13, 2015 at 3:54 PM, Aaron wrote: > Hi everyone, > > > > I'm needing more 10 gig ports in my CO's for purposes of upgrading my FTTH > OLT shelves with 10 gig. I currently use Cisco ME3600's and do a lot of > core ospf, and MP-iBGP over that for MPLS L2VPN's (eline, elan, etree) and > L3VPN's (VPNv4 and testing VPNv6) > > > > I'm thinking about Cisco ASR920's for (4) 10 gig ports and several (1) gig > ports. Would this be good ? > > > > What are some comparable Juniper products that would fit here ? Is Juniper > better in that area ? > > > > Aaron > > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Upgrading firmware on an EX 4300 virtual chassis?
Hi, You might want to upgrade to latest service release for EX4300 (see the link below) http://kb.juniper.net/InfoCenter/index?page=content&id=S:TSB16691&smlogin=true HTH Ivan, On Wed, May 27, 2015 at 4:00 PM, Scott Granados wrote: > Hi, > I’ve downloaded the latest recommended firmware from the web site which is > indicated as jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz. I’ve been > googling and keep finding procedures for upgrading that involve NSSU which > I’ve seen go very badly all be it quite a while ago, before the feature was > supported. Will the normal method work? Will something like the following > do the job > > >request system software add > /var/tmp/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz validate no-copy > Once completed and valided > >request system reboot > > Will this fit the bill or do I have to use the new procedures? If this > will work is there any need to define all members or is that assumed? > What’s my best upgrade procedure to proceed? Also, any comments on the > version that the site presented as acceptable, should I go with this > release or is something else more preferred? > > I’m presently running a buggy version of 13.2 that was shipped with the > devices. > > Any pointers would be most appreciated. > > Thank you > Scott > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Quick way to Shift MPLS traffic away from an interface
Hi, I assume that you are talking for RSVP signaled LSPs. clear mpls optimize aggressive-optimize - will work only on the ingress PE. There are some scripts that you can use to find out what LSPs are transiting particular interface - like this one script <http://juniper.cluepon.net/index.php/Show-lsp-interface.slax>. You can use clear rsvp session to force all transit LSPs to reoptimze after you increase the metric on the router you want to steer the traffic away. This could cause some traffic loss, but you don't need to go on every ingress PE to run clear mpls optimize. You can try to script it and run it on all PEs. Ivan, On Thu, May 21, 2015 at 7:00 PM, Dave Bell wrote: > Hi Tim, > > If you are using LDP then traffic will automatically switch to follow the > IGP. No clearing of LSPs required. > > Regards, > Dave > On 21 May 2015 18:49, "tim tiriche" wrote: > > > Hello, > > > > What is the quick way to shift LSP traffic from an interface after > > increasing the igp metric? > > > > question: > > > > - What command can I use to find all lsp traversing the iface and a good > > way to clear them? I am assuming I would need to run clear mpls > > optimize-aggressive on the lsp's on that particular router only? Is my > > understanding correct? > > > > - Is it a good idea to turn on optimize-aggressive? > > > > Any best practices or pointers would be appreciated! > > > > -Tim > > ___ > > 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE RR & next-hop resolution best practices
Hi Adam, I am not sure if your solution will do the job. Do you have this in production? Table bgp.inet6.0 is a IPv6 table of routing-instance called 'bgp' or? Routes from label-unicast inet6 family are put in inet6.0 table not in bgp.inet6.0. James will confirm that after he tests it. It might be that I am wrong. Ivan, On Mon, May 18, 2015 at 7:24 AM, Adam Vitkovsky wrote: > Hi James > > > James Jun > > Sent: 16 May 2015 16:20 > > > > The problem however is that I'm using the P's also as route-reflectors > for > > distributing BGP throughout the network. So, I need the RR's to make > > correct BGP best-path decisions, but they can't do that on 6PE routes > without > > having inet6.3 table to reference the ipv4-mapped-in-v6 next-hops > against. > > > I'm sorry I misunderstood the problem so the problem isn't that the P's > are trying to do IPv6 lookup instead of label-switch the packets between > PEs but the problem is that RRs are not advertising the IPv6 prefixes > because they can't select the best paths so the IPv6 prefixes are not being > exchanged between the PEs right? > > To resolve the NHs you can do: > set routing-options rib-groups 0-to-6 import-rib inet.0 > set routing-options rib-groups 0-to-6 import-rib inet6.0 > set routing-options rib-groups 0-to-6 import-policy loopbacks > > set protocols isis/ospf rib-group inet 0-to-6 > > This should create the ipv4-mapped-in-v6 (::ipv4) addresses in inet6 > And then you tell BGP to resolve the NHs in inet.6: > > set routing-options resolution rib bgp.inet6.0 resolution-ribs inet6.0 > > > adam > > --- > This email has been scanned for email related threats and delivered > safely by Mimecast. > For more information please visit http://www.mimecast.com > > --- > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE RR & next-hop resolution best practices
Hi James,
Importing from inet.0 to inet6.3 with rib-groups should do the trick. See
the example below (replace OSPF with IS-IS if needed):
routing-options {
rib-groups {
to-inet.3-inet6.3 {
import-rib [inet.0 inet.3 inet6.3];
import-policy loopbacks-only
}
}
}
protocols {
ospf {
rib-group to-inet.3-inet6.3;
}
}
policy-options {
policy-statement loopbacks-only {
term 1 {
from {
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
to rib inet.3;
then accept;
}
term 2 {
from {
route-filter 0::0/0 prefix-length-range /128-/128;
}
to rib inet6.3;
then accept;
}
term last {
then reject;
}
}
}
Ivan,
On Sat, May 16, 2015 at 4:20 PM, James Jun wrote:
> Hey Adam,
>
> Thanks for your reply.
>
> On Sat, May 16, 2015 at 06:45:45AM +, Adam Vitkovsky wrote:
>
> [ .. snip.. ]
>
> > If you say that the RRs act as "thru-traffic boxes for the transiting
> LSPs between PE's" then they should just perform pure label switching and
> no IPv6 lookup.
> > Are you sure your IPv6 traffic is labelled correctly indeed?
>
> Yes, traffic is labelled correctly, and P's are doing what they're
> supposed to.
>
> The problem however is that I'm using the P's also as route-reflectors for
> distributing BGP throughout the network. So, I need the RR's to make
> correct BGP best-path decisions, but they can't do that on 6PE routes
> without having inet6.3 table to reference the ipv4-mapped-in-v6 next-hops
> against.
>
> I've tried importing the PE loopbacks (which are my 6PE next-hops) from
> inet.0 into inet.3 using rib-groups, but that doesn't create the
> ipv4-mapped-in-v6 (::ipv4) conversions into inet6.3 table (yes,
> ipv6-tunneling under [ protocols mpls ] is enabled on the RR/P's).
>
>
> > And are you sure the RRs are enabled for MPLS forwarding i.e. the label
> switched path between PEs crossing RRs is operational?
> > I mean this could have gone unnoticed for IPv4 as the RRs happened to
> have all the routing information necessary for the IPv4 traffic to be
> forward traffic across.
>
> Yup absolutely, mpls forwarding is working correctly on the P's. The
> issue I'm having is route-reflectors running on the same P boxes being
> unable to make best-path decisions on 6PE routes having
> quad-F's/ipv4-mapped-inv6 next-hops-- they don't exist in inet6.3 unless
> RR's themselves have LSPs heading out to PE's..
>
> I suppose other people doing 6PE with 'bgp-free core' or topologies of
> similar import (i.e. oob route-reflectors) probably have dealt with similar
> situations, when it comes to RR's having to make best-path decision on 6PE
> prefixes having v4-mapped-in-v6 next-hops.
>
> James
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF route leaking on EX4550
Hi Raphael, Check that link for differences between auto-export and rib-groups: http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349 I don't see why to not use rib-groups except if they are not support too. HTH Ivan, On Thu, Apr 16, 2015 at 6:12 PM, Raphael Mazelier wrote: > Hello, > > I've got a network with multiple customers vrf, defined mostly on EX4550. > I have to leak some route (from a 'admin/service' instance) on all > customers vrf. This work well with vrf-import/export. > > I've rectenly notice that auto-export is not implemented in EX junos code > :( how I missed that on the initial design ? :) > > So leaking is currently not made localy, but this is working because all > my vrf are double defined on two EX. > > The problem is if I lost one my EX, the leaked route will be widhdraw... > (the other problem is that the traffic made ping pong) > > Any idea ? Am I forced to use rib-group ? and how it will inter-operate > with mbgp import/export ? > > Regards, > > -- > Raphael Mazelier > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF route leaking on EX4550
Hi Raphael, Check that link for differences between auto-export and rib-groups: http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349 I don't see why to not use rib-groups except if they are not support too. HTH Ivan, On Thu, Apr 16, 2015 at 6:12 PM, Raphael Mazelier wrote: > Hello, > > I've got a network with multiple customers vrf, defined mostly on EX4550. > I have to leak some route (from a 'admin/service' instance) on all > customers vrf. This work well with vrf-import/export. > > I've rectenly notice that auto-export is not implemented in EX junos code > :( how I missed that on the initial design ? :) > > So leaking is currently not made localy, but this is working because all > my vrf are double defined on two EX. > > The problem is if I lost one my EX, the leaked route will be widhdraw... > (the other problem is that the traffic made ping pong) > > Any idea ? Am I forced to use rib-group ? and how it will inter-operate > with mbgp import/export ? > > Regards, > > -- > Raphael Mazelier > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Sukhjit, The idea with local templates is that you configure couple of them or more with different privileges. Then using the ACS you control which user which template to inherit. If you look in the link you will see that those local templates look like users but they do not have authentication attached. So he only way to be used is if they are pushed from authentication server. For example you configure two templates with different privileges and assign hundred users from ACS to one of them and other hundred to the other. That is why they are called templates. This is usually how is done on Junos to have users with different privileges authenticated via RADIUS or TACACS+ servers. I hope now is more clear to you! Ivan, On Tue, Apr 14, 2015 at 11:08 AM, Sukhjit Hayre < sukhjit.ha...@googlemail.com> wrote: > > > Hi Ivan > > The goal is for ACS to be able to control this otherwise I can argue > what's the point in using ACS at all? > > There are attributes which are supposed to be working for which I don't > understand technically why they are not i.e allowed-commands (check the > link) > > > > On 14 Apr 2015, at 10:49, Ivan Ivanov wrote: > > Hi Sukhjit, > > Why don't you use local template accounts to accomplish that? > > > http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html > > ACS should be able to push 'local-username' attribute via tacacs+. > > HTH, > Ivan, > > On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre < > sukhjit.ha...@googlemail.com> wrote: > >> >> >> yeah I've used this too and depending on the local profile it shows what >> I expect it too, but what it doesn't show is minus the ACS attributes if at >> all I would see that here... >> >> I think a deeper packet inspection can identify what the messages are >> saying, will try to do that at some point >> >> >> >> > On 13 Apr 2015, at 23:42, Chris Kawchuk wrote: >> > >> > Show cli authorization. Should show you the current login credentials >> and such. >> > >> >> On 14 Apr 2015, at 8:23 am, Sukhjit Hayre < >> sukhjit.ha...@googlemail.com> wrote: >> >> >> >> hi Chris >> >> >> >> thanks for the reply, actually I did not see any user file in /var/tmp >> >> whilst logged-in im running vSRX firefly 12.1X47-D10.4 >> >> >> >> On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow >> >> wrote: >> >> >> >>> >> >>> >> >>>> On 04/13/2015 11:01 AM, Eduardo Barrios wrote: >> >>>> When I tested this a while back I could not get the "allow-commands" >> >>>> attribute to work. The deny-commands attribute does work however. So >> >>>> our ACS shell-profile read only group we had to start with a junos >> >>>> login with a super-user class then use the "deny-commands" attribute >> >>>> to strip the access ...request, restart, configure, etc. >> >>> >> >>> it might help you to look in /var/tmp on the juniper when the affected >> >>> user is logged in.. there will be a file named per the user's login >> PID >> >>> which has their access requirements outlined. You can probably reverse >> >>> engineer the right answer from that data. >> >>> ___ >> >>> 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 >> > > > > -- > Best Regards! > > Ivan Ivanov > > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper authorization with tacacs+
Hi Sukhjit, Why don't you use local template accounts to accomplish that? http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html ACS should be able to push 'local-username' attribute via tacacs+. HTH, Ivan, On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre < sukhjit.ha...@googlemail.com> wrote: > > > yeah I've used this too and depending on the local profile it shows what I > expect it too, but what it doesn't show is minus the ACS attributes if at > all I would see that here... > > I think a deeper packet inspection can identify what the messages are > saying, will try to do that at some point > > > > > On 13 Apr 2015, at 23:42, Chris Kawchuk wrote: > > > > Show cli authorization. Should show you the current login credentials > and such. > > > >> On 14 Apr 2015, at 8:23 am, Sukhjit Hayre > wrote: > >> > >> hi Chris > >> > >> thanks for the reply, actually I did not see any user file in /var/tmp > >> whilst logged-in im running vSRX firefly 12.1X47-D10.4 > >> > >> On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow > >> wrote: > >> > >>> > >>> > >>>> On 04/13/2015 11:01 AM, Eduardo Barrios wrote: > >>>> When I tested this a while back I could not get the "allow-commands" > >>>> attribute to work. The deny-commands attribute does work however. So > >>>> our ACS shell-profile read only group we had to start with a junos > >>>> login with a super-user class then use the "deny-commands" attribute > >>>> to strip the access ...request, restart, configure, etc. > >>> > >>> it might help you to look in /var/tmp on the juniper when the affected > >>> user is logged in.. there will be a file named per the user's login PID > >>> which has their access requirements outlined. You can probably reverse > >>> engineer the right answer from that data. > >>> ___ > >>> 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Help with an IPSec scenario
Hi Tom, Try with 'general-ikeid' on SRX side under the definition of ike gateway. You might need to upgrade Junos to have that option. host@srx# set security ike gateway general-ikeid HTH, Ivan, On Fri, Mar 13, 2015 at 3:35 PM, Tom Storey wrote: > Hi everyone, > > Trying to establish an IPSec tunnel (route based) between a Juniper > SRX and a Cisco IOS router. > > The topology is two routers with DSL services, the SRX is on a dynamic > IP, the Cisco on a static. No NAT is involved in the path between the > two routers. > > Heres the configs Im working on: http://pastebin.com/gUEFVTau > > Basically what Im getting is this... > > In main mode, phase 1 is OK, and I get probably 99% of the way in > phase 2, but it doesnt quite complete, with errors like "proxy > identities not supported". > > I can fix this by configuring Tunnel0's destination as the IP of the > SRX /at the time/ and can then ping across the tunnel. But this > obviously isnt a long term solution because if the IP of the SRX > changes (and it does, frequently, because the DSL is notoriously > unstable) then the VPN stops working. > > So I try to go aggressive mode, but this is even worse, with phase 1 > not completing with errors like "IKE packet from x.x.x.x was not > encrypted and it should've been", and never really making it past > AG_INIT_EXCH. > > This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE > > Based on my supplied configs, can anyone help me come up with a > solution that allows the SRX to initiate a connection from any random > IP, and the Cisco accepts it but I dont have to configure the IP of > the SRX on the Cisco in order for it to work? I feel like Im > tantalisingly close, but after several hours at it so far and copious > amounts of googling, I just cant see the solution... > > Thanks. > ___ > cisco-nsp mailing list cisco-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ntpd vulnerability
Hi, Check this out! https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR931184 HTH, Ivan, On Tue, Dec 23, 2014 at 5:01 PM, Jean Benoit wrote: > Hello, > > Does anyone know if Juniper has issued a patched version > of JunOS for the following vulnerabilities in ntpd ? > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9295 > > Multiple stack-based buffer overflows in ntpd in NTP before 4.2.8 > allow remote attackers to execute arbitrary code via a crafted > packet, related to (1) the crypto_recv function when the Autokey > Authentication feature is used, (2) the ctl_putdata function, > and (3) the configure function. > > (1) > http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_crypto_recv > (2) > http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_ctl_putdata > (3) > http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_configure > > Buffer overflows (2) and (3) have no mitigation except upgrading > ntp to 4.2.8 or filtering ntp packets. (1) depends on having "crypto > ..." directives in ntp.conf. > > ntpd on JunOS 11.4 seems to be based on ntpd 4.2.0 and is likely > vulnerable. > > $strings ntpd |grep ntpd.4 > ntpd 4.2.0-a Fri Mar 1 08:50:44 UTC 2013 (1) > > -- > Jean BENOIT > Université de Strasbourg > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MVPN and tunnel interfaces.
id 16834686 > 17 P2MP root-addr 10.255.255.6, lsp-id 16838480 > 17 P2MP root-addr 10.255.255.6, lsp-id 16853606 > 17 P2MP root-addr 10.255.255.6, lsp-id 16857676 > 17 P2MP root-addr 10.255.255.6, lsp-id 16859121 > 17 P2MP root-addr 10.255.255.6, lsp-id 16859585 > 17 P2MP root-addr 10.255.255.6, lsp-id 16859908 > 17 P2MP root-addr 10.255.255.6, lsp-id 16860311 > 17 P2MP root-addr 10.255.255.6, lsp-id 16860520 > 17 P2MP root-addr 10.255.255.6, lsp-id 16860563 > > Output label database, 10.255.255.25:0--10.255.255.33:0 > > misak@MX80-HRAZDAN> > > Best regards, > Misak Khachatryan, > Network Administration and Monitoring Manager, > GNC-Alfa CJSC. > > > - Original Message - > From: "Bikram Singh" > To: "Misak Khachatryan" , "juniper-nsp" < > juniper-nsp@puck.nether.net> > Sent: Friday, May 16, 2014 7:57:33 PM > Subject: RE: [j-nsp] Juniper MVPN and tunnel interfaces. > > ok . Can you share below output from both the PEs > show ldp database p2mp . > > > > Date: Fri, 16 May 2014 18:57:04 +0400 > > From: m.khachatr...@gnc.am > > To: sbik...@live.com; juniper-nsp@puck.nether.net > > Subject: Re: [j-nsp] Juniper MVPN and tunnel interfaces. > > > > Hi Bikram, > > > > Yes, it's transit, but others too. I use LDP P2MP. > > > > misak@MX80-HRAZDAN> show mpls lsp p2mp > > Ingress LSP: 0 sessions > > Total 0 displayed, Up 0, Down 0 > > > > Egress LSP: 0 sessions > > Total 0 displayed, Up 0, Down 0 > > > > Transit LSP: 0 sessions > > Total 0 displayed, Up 0, Down 0 > > > > misak@MX80-HRAZDAN> > > > > > > > > Bikram Singh wrote: > > > > > > > > > > > > > Date: Fri, 16 May 2014 16:28:56 +0400 > > > > From: m.khachatr...@gnc.am > > > > To: juniper-nsp@puck.nether.net > > > > Subject: [j-nsp] Juniper MVPN and tunnel interfaces. > > > > > > > > > > > > > Is this PE also acting as a transit to other PE for Multicast traffic ? > > > > > > can u share below > > > > > > show mpls lsp p2mp ? > > > > > > > > > > > > > > > -bs > > > > > > > > > > > > > -- > > Best regards, > > Misak Khachatryan, > > Network Administration and Monitoring Manager, > > GNC-Alfa CJSC. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF external routes in database but not in routing table
Hi, Yes, the vpn-tag is 0 from the output. But side effect of the command "domain-vpn-tag 0" is to remove the DN bit from Type 5 and Type 7 LSAs. This could help in that case on CE side. You can give a shoot, it will not hurt. But just in case you can do it in maintenance window. HTH Ivan, On Tue, Apr 29, 2014 at 1:08 PM, Krasimir Avramski wrote: > Hello, > You should ask service provider to clear D/N bit from LSA advertisements > (equal to "domain-id disable" in case juniper equipment is used). It is > also desirable SP to set domain-vpn-tag to 0(junos by default encode own > AS number here) since the sanity check rule is matching own AS against AS > encoded in tag. > > Krasi > > > On 29 April 2014 12:50, Mohammad Salbad wrote: > > > Thank you Krasi > > > > > > > > So, setting domain-vpn-tag to 0 on the providers PE will not help... :( > > > > Is that mean there is no solution or workaround for this neither on my MX > > nor Provider PE :( > > > > And the only solution is to revert back the instance type to be VR > instead > > of VRF. > > > > > > > > I really hoped there is a workaround for this... > > > > > > > > However, thank you all for your help > > > > > > > > BR > > > > M. Salbad > > > > > > > > From: Krasimir Avramski [mailto:kr...@smartcom.bg] > > Sent: Tuesday, April 29, 2014 1:32 PM > > To: Mohammad Salbad > > Cc: Juniper-Nsp > > Subject: Re: [j-nsp] OSPF external routes in database but not in routing > > table > > > > > > > > domain vpn tag(external route tag) is already set to 0 - the problem is > > that D/N bit is set as per RFC4576 (0x82 from your output lsa options). > > > > > > > > Krasi > > > > > > > > On 29 April 2014 11:05, Mohammad Salbad > masal...@gmail.com> > wrote: > > > > Thank you all experts for your support and help > > > > > > > > Based on what I understood from you: > > > > In order to be able to add the ospf external routes into the routing > table > > I > > shall ask the service provider to set the domain-vpn-tag value to 0 on > his > > PE. > > > > And there nothing to be done on my MX router (CE) to ignore the DN bit > set > > by the service provider PE. > > > > > > > > Thank you again > > > > M. Salbad > > > > > > > > From: Ivan Ivanov [mailto:ivanov.i...@gmail.com > ivanov.i...@gmail.com> ] > > Sent: Tuesday, April 29, 2014 11:01 AM > > To: Amos Rosenboim > > Cc: Mohammad Salbad; juniper-nsp@puck.nether.net > juniper-nsp@puck.nether.net> > > > > Subject: Re: [j-nsp] OSPF external routes in database but not in routing > > table > > > > > > > > > > Hi, > > > > > > > > Try to configure under the OSPF stanza for removing DN bit in Type 5 LSA > - > > 'domain-vpn-tag 0' > > > > If you want to disable DN bit checks for Type 3 LSA add - 'domain-id > > disable' > > > > HTH, > > > > Ivan, > > > > > > > > > > > > On Tue, Apr 29, 2014 at 8:49 AM, Amos Rosenboim > a...@oasis-tech.net> > > > > <mailto:a...@oasis-tech.net <mailto:a...@oasis-tech.net> > > wrote: > > > > Hi, > > > > I know Cisco have a configuration knob for this, I believe it's called > > vrf-capability. > > I am not sure If Juniper have something similar. > > > > Amos > > > > Sent from my iPhone > > > > > > On 29 Apr 2014, at 02:21, "Mohammad Salbad" > masal...@gmail.com> > > > > <mailto:masal...@gmail.com <mailto:masal...@gmail.com> > > masal...@gmail.com <mailto:masal...@gmail.com> > > > > <mailto:masal...@gmail.com <mailto:masal...@gmail.com> > >> wrote: > > > > 1.1.1.1 is PE router id > > > > so far we believe the issue is due to DN bit is set by the provider and > > hence the external routes are not injected in the routing table...as per > > Alberto Santos below reply to me: > > > > " as expected in rfc4577, Type 5 LSA must set DN bit, if the router does > > not > > set it, domain tag should be used instead. I believe the PE router is > > setting the DN bit and because of the routing instance was config as VRF > it > > is not installing the route, I think you should change to VR type > instead." > > > >
Re: [j-nsp] OSPF external routes in database but not in routing table
Hi, Try to configure under the OSPF stanza for removing DN bit in Type 5 LSA - 'domain-vpn-tag 0' If you want to disable DN bit checks for Type 3 LSA add - 'domain-id disable' HTH, Ivan, On Tue, Apr 29, 2014 at 8:49 AM, Amos Rosenboim wrote: > Hi, > > I know Cisco have a configuration knob for this, I believe it's called > vrf-capability. > I am not sure If Juniper have something similar. > > Amos > > Sent from my iPhone > > On 29 Apr 2014, at 02:21, "Mohammad Salbad" masal...@gmail.com>> wrote: > > 1.1.1.1 is PE router id > > so far we believe the issue is due to DN bit is set by the provider and > hence the external routes are not injected in the routing table...as per > Alberto Santos below reply to me: > > " as expected in rfc4577, Type 5 LSA must set DN bit, if the router does > not > set it, domain tag should be used instead. I believe the PE router is > setting the DN bit and because of the routing instance was config as VRF it > is not installing the route, I think you should change to VR type instead." > > So I'm wondering if there is any way to ignore the DN bit for the external > routes received from the provider ospf link? That I don't want to keep the > instance type to be vrf NOT VR... > > Regards > M. Salbad > > -Original Message- > From: Payam Chychi [mailto:pchy...@gmail.com] > Sent: Tuesday, April 29, 2014 2:17 AM > To: Mohammad Salbad; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net> > Subject: Re: [j-nsp] OSPF external routes in database but not in routing > table > > Hi Mohammad, > > - Any route-maps preventing the prefix from being installed? > - How are you learning 1.1.1.1? > > > Payam > > On 2014-04-28, 2:13 PM, Mohammad Salbad wrote: > Dear Experts > > > > we have an MX router connected to a service provider network which > provides us with OSPF L3VPN connectivity with remote branches. > > > > at the beginning we used to have our connection with the provider into > a routing instance with type virtual router and we were able to > receive external routes from remote branches from our provider ospf > link. > > for special purposes we decided to change the instance type to be vrf > in our MX router. > > once we have changed the instance type to be vrf external routes > received through our provider connection are no longer in the routing > table although they are in the ospf data base > > > > Below is a sample of ospf database for one of the external routes > which were not injected in routing table > > > > Extern 10.10.10.10 1.1.1.1 0x80003a74 893 0x82 0x347d 36 > > mask 255.255.255.252 > > Topology default (ID 0) > > Type: 2, Metric: 1, Fwd addr: 0.0.0.0, Tag: 0.0.0.0 > > Aging timer 00:45:07 > > Installed 00:14:52 ago, expires in 00:45:07 > > Last changed 01:03:59 ago, Change count: 1 > > > > Any Ideas??? > > > > Regards > > M. Salbad > > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet access from VRF issue
gt; > Alexey S. > > Leading engineer > > Network solutions team > > CCIE R&S > > > > alexey.saz...@yandex.ru > > > > 04.06.2013, 21:09, "Mihai" : > > > > >for R3, sorry :) > > > > > > On 06/04/2013 07:56 PM, Mihai wrote: > > >> Hello, > > >> > > >> Maybe I am wrong, but as long as R1,R3,R4 are internal bgp > neighbors, > > R4 > > >> should be route reflector for R4. > > >> > > >> Regards, > > >> Mihai > > >> > > >> On 06/04/2013 06:44 PM, Alexey wrote: > > >>> Hi guys, > > >>> > > >>> Now I'm preparing for JNCIE-SP certification, and faced with > problem > > >>> providing internet-access for VPN users. > > >>> > > >>> I attach my test topology to email. > > >>> R4 and R3 are PE routers which holds vrf table "Customer", R1 > router > > >>> holds ipv4 static route 8.8.8.8/32 to represent Internet routes. > > >>> Between R4 and R3 there is vpnv4 IBGP session and Between R4 and > R1 - > > >>> ipv4 IBGP. > > >>> > > >>> I use rib-group to import IPv4 routes received from R1 also in > table > > >>> Customer.inet.0. Routes are imported as expected and I see > > 8.8.8.8/32 > > >>> in vrf Customer: > > >>> R4# run show route table Customer 8.8.8.8 > > >>> > > >>> Customer.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 > > >>> hidden) > > >>> + = Active Route, - = Last Active, * = Both > > >>> > > >>> 8.8.8.8/32 *[BGP/170] 00:50:35, localpref 100, from 172.27.255.1 > > >>> AS path: I > > >>>> to 172.27.0.10 via ge-1/3/0.41, label-switched-path r4-to-r1 > > >>> [edit] > > >>> R4@M7i-2# > > >>> > > >>> But the problem is that R4 doesn't pass this route from VRF to R3 > via > > >>> MP-BGP. > > >>> R4@M7i-2# run show route advertising-protocol bgp 172.27.255.3 > > >>> > > >>> Customer.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 > > >>> hidden) > > >>> Prefix Nexthop MED Lclpref AS path > > >>> * 2.2.2.2/32 Self 100 1 I > > >>> * 172.27.0.4/30 Self 100 I > > >>> > > >>> [edit] > > >>> R4@M7i-2# > > >>> > > >>> The same task was in bootcamp lab guide book, and according to it, > > >>> other members of VRF do receive internet routes. I also tried to > use > > >>> VRF export policy;vrf-table-label - nothing helps. > > >>> Please help, may be there is some knob to make it work? > > >>> > > >>> PS:All routers are real equipment (no logical systems). > > >>> PSS:I also attach relevant parts of config. > > >>> > > >>> ___ > > >>> juniper-nsp mailing list juniper-nsp@puck.nether.net > > >>> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Inter-racks switch routing recommended practice
Hi, Here you check some ideas for using BGP in datacenter routing. http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-04 HTH Ivan, On Wed, Jun 5, 2013 at 5:24 AM, Ihsan Junaidi Ibrahim wrote: > Hi, > > I'm building an infrastructure which comprises of a few tens of racks with > Hadoop, Supermicro MicroCloud and whatnot running. Each rack probably will > have EX4200 or EX3300 ToR switch, individually at the moment, not > VC-chained. These switches will have a couple of EX4550 aggregating the > circuits. > > My question is what would be the best routing protocol in this kind of > scenario? > > I'm thinking multi-areas OSPF/v3 but would a flat OSPF area 0 topology > with BGP make more sense? I don't have a lot of exposure in dense > datacenter routing so I'm bringing the conventional WAN routing thinking > cap into the picture. > > Thanks. > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] (no subject)
Jailbreaked iPhone, even you can use RDP in ssh tunnel. Upcoming iPhone OS 4 will support SSL VPN from Juniper. I haven't tried Android, but iPhone is good enough when you used to use shell with touch screen. [?] 2010/6/5 Tomasz Mikołajek > Ok, so if we are talking about mobile phones/smartphones, which one in the > best for network engineer? I am befor changing my phone to new one. I need > SSH and VPN. > > W dniu 4 czerwca 2010 13:55 użytkownik Chris Evans < > chrisccnpsp...@gmail.com > > napisał: > > > You know how to tell when someone has an apple product? > > > > They tell you they do. :) > > > > On Jun 4, 2010 7:34 AM, "Tomasz Mikołajek" wrote: > > > > Someone has IPhone. > > Sent from my MacBook. ;-) > > > > 2010/6/4 Shane Short > > > > > > > It's the answer to the universe! > > > > > > > > > *faints* > > > > > > On 04/06/2010, at 11:08 AM, Tommy Pernici... > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov <<330.gif>>___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problems with Link Aggregation
Hi, http://kb.juniper.net/InfoCenter/index?page=content&id=KB10926&actp=search&viewlocale=en_US&searchid=136661818 Here is written that it uses layer 2,3 and 4 for load balancing hash algorithm. And yes, the "forwarding-options hash" is not configurable on EX-series. HTH, Ivan, On Sun, Apr 21, 2013 at 6:11 PM, Mark Tinka wrote: > On Wednesday, March 06, 2013 04:15:45 PM Filippo Cugini > wrote: > > > However, when we send traffic on the aggregated link, > > just one ge works, and we experience packet loss when we > > exceed the throughput of 1000mbps. Indeed, the > > statistics of all interfaces show that only the > > ge-0/0/12 is utilized to forward the data traffic, while > > the other two interfaces send and receive only signaling > > packets. > > We've seen this when flows are non-IP, i.e., in our case, > the flows were MPLS-based. > > TAC came back to say the system won't load share if the > flows aren't direct IP (unlike Cisco switches, it can't look > beyond the MPLS frames to reveal the IP packets and hash on > that). > > Not sure if this was your traffic type. > > We saw the issue on the EX4200's. > > Mark. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] WAN input prioritization on MX
Hi, In that case you try Tricolor marking policer to mark the excessive traffic and drop it on output. It is not exactly the same but could help. http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway-pages/cos/tricolor-marking-policers.html HTH, Ivan, On Wed, Oct 17, 2012 at 12:23 AM, Gustavo Santos wrote: > Krasimir, > > Just finished the reading the class of service section from Juniper MX > Series: A Comprehensive Guide to Trio Technologies , and you are righ. What > I´m trying to do is an ingress queuing and the book talks that it´s still > unsuported on 11.4 and I checked the changelogs and on 12.2 is still > unsuported. > > > gustavo@BRD01# commit check > [edit class-of-service interfaces ge-1/1/4 unit 0] > 'input-shaping-rate' > cannot configure bandwidth (pic has no CoS queuing) > error: configuration check-out failed > > > Gustavo Santos > Analista de Redes > CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER > > > > 2012/10/16 Krasimir Avramski > > > > > > > On Mon, Oct 15, 2012 at 4:40 PM, Gustavo Santos >wrote: > > > >> > >> For instance: If the current wan ingress traffic total is 450mbits and > >> high > >> priority traffic is 100mbits, and low priority is 350mbits = no packet > >> discard, but if traffic towards high priority subnet is 300mbits and low > >> priority is 300mbits, then the queuing / scheduler will drop the low > >> priority traffic until the sources traffic gets shaped to 200mbits for > the > >> low priority and the high priority gets 300mbits. > >> > >> On Linux it's quite simple to achieve. > >> > >> > > AFAIK this is only possible with ingress queuing (EQ2, DPC-EQ hardware, > > ingress CoS not enabled by default) and simple filters: > > > > > http://www.juniper.net/techpubs/en_US/junos10.4/topics/usage-guidelines/cos-configuring-ingress-hierarchical-cos-on-enhanced-queuing-dpcs.html > > > > > http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/mf-classifiers-simple-filters-overview-cos-config-guide.html > > > > > http://www.juniper.net/techpubs/en_US/junos10.4/topics/example/mf-classifiers-example-simple-filters-cos-config-guide.html > > > > Unfortunately MPCs are still not supported > > > > Best Regards, > > Krasi > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange OSPF Issue over MPLS VPN with PE-CE as OSPF !
Hi, Yes, this is because the 'domain-vpn-tag 0'. The other thing that it is doing is to zeroes the tag. What type of routing-instance you are using on the CE? To not have the check on the CE you can use 'routing-instance type virtual-router' instead of 'routing-instance type vrf' Then you will not need 'domain-vpn-tag 0'. HTH, Ivan, On Wed, Jul 25, 2012 at 10:14 AM, vaibhava varma wrote: > Hi Ivan > > I could not get the manual loop prevention thing working as whenever I > tried to set any tag while redistributing mp-ibgp to OSPF and then > match the same on other PE while importing into OSPF it did not work. > I was not able to see any tag being set. > > However I have found a fix for this solution by increasing the OSPF > protocol preference value to higher than BGP on the PEs under the > ROuting-Instance. > > Regards > Varma > > On Mon, Jul 23, 2012 at 4:35 PM, Ivan Ivanov > wrote: > > Hi, > > > > You can prevent this by implementing manual loop prevention. You can use > the > > tag field in the external LSA to tag the routes and based on that to > filter > > them on the other PE. > > > > Regards, > > Ivan, > > > > > > On Mon, Jul 23, 2012 at 1:08 PM, vaibhava varma > wrote: > >> > >> Hi Ivan > >> > >> I finally got the routes on the VRF-Lite CE by using two commands on the > >> PE > >> > >> domain-id disable > >> domain-vpn-tag 0 > >> > >> > >> I have a dual homed setup with two PE and 2 VRF-Lite CE. Will this not > >> cause routing loop because the CEs will share the route and will send > >> the routes back to other PE which will have an MP-iBGP route with > >> preference 170 and OSPF route with preference 10/150. > >> > >> Regards > >> Varma > >> > >> On Fri, Jul 13, 2012 at 4:16 PM, Ivan Ivanov > >> wrote: > >> > Hi, > >> > > >> > Yes, this could be the case. > >> > > >> > domain-vpn-tag 0 > >> > > >> > This will delete the DN bit option in Junos. (This works only on Type > 5 > >> > and > >> > Type 7 LSAs) > >> > > >> > HTH, > >> > Ivan, > >> > > >> > On Fri, Jul 13, 2012 at 1:29 PM, Arun Kumar > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> If its a VRF lite CE with OSPF running, then the same loop prevention > >> >> mechanism is applied i.e. if Downbit or Domain tag is set, then VRF > >> >> lite CE > >> >> do not accept it. In case of Cisco as CE, there is a command to > disable > >> >> this > >> >> "capability vrf-lite". But with Juniper as CE, I am not aware but if > >> >> there > >> >> is a CLI to disable this Down bit check that should do. > >> >> > >> >> thanks, > >> >> Arun > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> Regards > >> Vaibhava Varma > > > > > > > > > > -- > > Best Regards! > > > > Ivan Ivanov > > > > -- > Regards > Vaibhava Varma > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange OSPF Issue over MPLS VPN with PE-CE as OSPF !
Hi, You can prevent this by implementing manual loop prevention. You can use the tag field in the external LSA to tag the routes and based on that to filter them on the other PE. Regards, Ivan, On Mon, Jul 23, 2012 at 1:08 PM, vaibhava varma wrote: > Hi Ivan > > I finally got the routes on the VRF-Lite CE by using two commands on the PE > > domain-id disable > domain-vpn-tag 0 > > > I have a dual homed setup with two PE and 2 VRF-Lite CE. Will this not > cause routing loop because the CEs will share the route and will send > the routes back to other PE which will have an MP-iBGP route with > preference 170 and OSPF route with preference 10/150. > > Regards > Varma > > On Fri, Jul 13, 2012 at 4:16 PM, Ivan Ivanov > wrote: > > Hi, > > > > Yes, this could be the case. > > > > domain-vpn-tag 0 > > > > This will delete the DN bit option in Junos. (This works only on Type 5 > and > > Type 7 LSAs) > > > > HTH, > > Ivan, > > > > On Fri, Jul 13, 2012 at 1:29 PM, Arun Kumar > wrote: > >> > >> Hi, > >> > >> If its a VRF lite CE with OSPF running, then the same loop prevention > >> mechanism is applied i.e. if Downbit or Domain tag is set, then VRF > lite CE > >> do not accept it. In case of Cisco as CE, there is a command to disable > this > >> "capability vrf-lite". But with Juniper as CE, I am not aware but if > there > >> is a CLI to disable this Down bit check that should do. > >> > >> thanks, > >> Arun > >> > >> > > > > > > -- > Regards > Vaibhava Varma > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange OSPF Issue over MPLS VPN with PE-CE as OSPF !
Hi, Yes, this could be the case. domain-vpn-tag 0 This will delete the DN bit option in Junos. (This works only on Type 5 and Type 7 LSAs) HTH, Ivan, On Fri, Jul 13, 2012 at 1:29 PM, Arun Kumar wrote: > Hi, > > If its a VRF lite CE with OSPF running, then the same loop prevention > mechanism is applied i.e. if Downbit or Domain tag is set, then VRF lite CE > do not accept it. In case of Cisco as CE, there is a command to disable > this "capability vrf-lite". But with Juniper as CE, I am not aware but if > there is a CLI to disable this Down bit check that should do. > > thanks, > Arun > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ospf and policy import/export
Hi,
Probably because those policies are only for filtering summary LSAs, not
for changing their metric. I did not find anything mentioned about metric
in the examples.
HTH,
Ivan,
On Thu, Jul 5, 2012 at 4:43 PM, Piotr wrote:
> Hello,
>
> I have routers in area2 and area0, srx 11.4R1.6
> .
> R1-area1---R2--area0
>
> I try to filter out or change metrics for some prefixes on ABR (R2), but
> it didn't work. I try on both direction: import or export but nothing
> change. Metrics are the same, all prefixes available in routing table..
>
> What i doing wrong ?
>
> br
> Pet
>
>
> i made config according this:
>
> http://www.juniper.net/**techpubs/en_US/junos12.1/**
> topics/example/ospf-export-**network-summary-routing-**
> policy-configuring.html<http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/ospf-export-network-summary-routing-policy-configuring.html>
>
> http://www.juniper.net/**techpubs/en_US/junos12.1/**
> topics/example/ospf-import-**network-summary-routing-**
> policy-configuring.html<http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/ospf-import-network-summary-routing-policy-configuring.html>
>
>
>
> R2:
>
> # show protocols ospf
> area 0.0.0.0 {
> interface ge-0/0/5 {
>
> }
> interface ge-0/0/4.0;
> interface lo0.0 {
> passive;
> }
> }
> area 0.0.0.1 {
> network-summary-export ospf-area-2-export;
> interface ge-0/0/6.1 {
> metric 300;
> }
> }
>
>
> show policy-options policy-statement ospf-area-2-export
> term term1 {
> from {
> route-filter 10.27.1.120/30 prefix-length-range /30-/30;
> }
> then {
> metric 50;
> accept;
> }
> }
> term term2 {
> from {
> route-filter 6.6.6.6/32 exact;
> }
> then {
> metric 60;
> accept;
> }
> }
> ______**_
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange OSPF Issue over MPLS VPN with PE-CE as OSPF !
hidden) > + = Active Route, - = Last Active, * = Both > > 1.1.1.1/32 *[OSPF/10] 00:00:05, metric 1 > > to 10.26.66.193 via em1.0 > 10.1.26.116/30 *[OSPF/150] 00:00:05, metric 0, tag 3489725441 > > to 10.26.66.193 via em1.0 > 10.26.4.1/32 *[OSPF/150] 00:00:05, metric 0, tag 3489725441 > > to 10.26.66.193 via em1.0 > 10.26.66.192/30*[Direct/0] 03:09:42 > > via em1.0 > 10.26.66.194/32*[Local/0] 03:09:42 > Local via em1.0 > 10.26.251.1/32 *[Direct/0] 03:09:39 > > via lo0.0 > 10.200.32.4/30 *[OSPF/150] 00:00:05, metric 0, tag 3489725441 > > to 10.26.66.193 via em1.0 > 224.0.0.5/32 *[OSPF/10] 03:09:58, metric 1 > MultiRecv > > [edit] > root@SAPC# > > > Any pointers would be much appreciated. > > > Regards > Vaibhava Varma > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Controlling routes between OSPF areas
Hi,
If you want to summarize from area 0 to area 1 you should put the
'area-range' in area 0. Did you try that? Don't forget the restrict to
filter the route.
HTH
Ivan,
On Thu, May 10, 2012 at 5:06 AM, Morgan McLean wrote:
> Also, just to add to this, if I try to deny a route by neighbor or
> next-hop, the entire route is denied regardless of where it comes from.
>
> If I try to deny the export of a route from protocol static on the
> announcing router, again it doesn't matter to which neighbor, it denies the
> entire route.
>
> Am I just SOL? BGP is so much easier to work with
>
> Morgan
>
> On Wed, May 9, 2012 at 3:58 PM, Morgan McLean wrote:
>
> > Will,
> >
> > You mean the export policy restricting 0/0 from area 0 to area 1 must be
> > on the srx that has an interface from area 0, and an interface from area
> 1.
> > Correct?
> >
> > I've tried this with no luck on my ospf export policy:
> >
> > +term deny-test {
> > +from {
> > +area 0.0.0.0;
> > +route-filter 192.168.30.156/30 exact;
> > +}
> > +to area 0.0.0.1;
> > +then reject;
> > +}
> >
> >
> > On Wed, May 9, 2012 at 3:50 PM, Morgan McLean wrote:
> >
> >> I tried the restrict statement under area 1 for another route as a test:
> >>
> >> [edit protocols ospf area 0.0.0.1]
> >> + area-range 192.168.30.156/30 {
> >> + restrict;
> >> + exact;
> >> + }
> >>
> >> And I still see it on the other end:
> >>
> >>
> >> 192.168.30.156/30 *[OSPF/10] 22:22:03, metric 2
> >> > to 192.168.30.110 via ge-7/0/0.0
> >>
> >> Morgan
> >>
> >>
> >> On Wed, May 9, 2012 at 3:18 PM, OBrien, Will >wrote:
> >>
> >>> Your export policy must be applied at the announcement router. For
> >>> example, my area 0 router only announces a default route and nothing
> else.
> >>> Set a match and don't forget the reject.
> >>>
> >>> Will
> >>>
> >>> On May 9, 2012, at 4:30 PM, "Morgan Mclean" wrote:
> >>>
> >>> > Hi everyone,
> >>> >
> >>> > I have a two network segments, OSPF area 0 and 1. I have a firewall
> >>> cluster with interfaces in both areas. I need to stop say a default
> route
> >>> from area 0 making its way into area 1.
> >>> >
> >>> > I've tried import and export policies but nothing seems to really
> >>> work. Can anybody please give me an example? Is this against how OSPF
> works?
> >>> >
> >>> > Thanks,
> >>> > Morgan
> >>> > ___
> >>> > 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
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] redistributing label between rsvp and ldp
Hi Andrew, You should consider using 'labeld-BGP'. Look at this example: http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/vpn-interprovider-vpn-example-multihop-mp-ebgp-with-p-routers.html HTH, On Sun, Apr 29, 2012 at 09:52, Uzi Be wrote: > > hi - > yeah p3 and p4 support both ldp and rsvp, but pe1 can only run rsvp and pe > 2 can only run ldp. > > ce - pe1 - p1 - p2 - p3 -p4 -pe2 - ce > thanks > Andrew > > > Date: Sun, 29 Apr 2012 13:04:06 +0800 > > Subject: Re: [j-nsp] redistributing label between rsvp and ldp > > From: diogo.montag...@gmail.com > > To: go...@live.com > > > > Does p3 and p4 support both LDP and RSVP ? > > > > ./diogo -montagner > > JNCIE-M 0x41A > > > > > > On Sun, Apr 29, 2012 at 12:45 PM, Uzi Be wrote: > > > > > > hi, > > > I was just testing out to swap labels between two different signaling > protocols (ldp and rsvp). lets say we have two different network, one is > running ldp and the other one is running rsvp (same AS, so no inter-as > options). > > > ce - pe1 - p1 - p2 - p3 -p4 -pe2 - ce > > > so pe1 - p1 - p2 -p3 are running rsvp and p4-pe2 are running ldp, and > edge ce's are using l3vpn. what are the options to have a labeled path from > pe2 to pe1 (considering that pe1 is not going to run ldp protocol, and pe2 > can't use rsvp so ldp tunneling is not an option here). > > > thanks in advance for your comments. > > > Andrew > > > ___ > > > 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hidden IPv4 iBGP routes
Hi,
Harry, in JNCIP study guide is written that if route is discarded because
of AS loop it's not stored in RIB. So it should not be visible with
'hidden' switch.
Or I am wrong and the case here is different.
Thanks!
On Wed, Mar 14, 2012 at 01:29, John Neiberger wrote:
> Thanks! I just heard from another one of our engineers who is much
> more familiar with Juniper than I am. He already knew about this, so I
> was just a little slow on the uptake. lol
>
> Thanks to all for the help.
>
> On Tue, Mar 13, 2012 at 6:05 PM, Harry Reynolds wrote:
> > Yes, I believe that is enough to cause your issue.
> >
> > I believe that independent domain might help with the global as loop
> check, but it too is global and needs to be carefully tested.
> >
> > Else use as loops, which should also be tested. ;) Adding will flap bgp
> IIRC.
> >
> > Regards
> >
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: John Neiberger [mailto:jneiber...@gmail.com]
> > Sent: Tuesday, March 13, 2012 4:55 PM
> > To: Harry Reynolds
> > Cc: Mohammad; juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] Hidden IPv4 iBGP routes
> >
> > We do have the following configured under bgp:
> >
> > group SomeGroupName {
> >type external;
> >traceoptions {
> >file ipv4-ebgp-customer-logs size 10m files 10;
> >flag state;
> >}
> >description "SomeGroup";
> >family inet {
> >unicast;
> >}
> >remove-private;
> >local-as X private;
> > }
> >
> > I wish I could post that stuff without editing. hehe Is that enough
> > to break things? And if so, what is the fix?
> >
> > Thanks!
> >
> >
> > On Tue, Mar 13, 2012 at 5:21 PM, Harry Reynolds
> wrote:
> >> Are there any vrfs on this box using AS ?
> >>
> >> In JUNOS AS loop check is global, so also applies to any vrfs and their
> configured asns.
> >>
> >> HTHs
> >>
> >>
> >>
> >> -Original Message-
> >> From: juniper-nsp-boun...@puck.nether.net [mailto:
> juniper-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
> >> Sent: Tuesday, March 13, 2012 4:17 PM
> >> To: Mohammad
> >> Cc: juniper-nsp@puck.nether.net
> >> Subject: Re: [j-nsp] Hidden IPv4 iBGP routes
> >>
> >> Okay, there is no local AS configured under protocols bgp, and the AS
> >> configured under routing options is correct.
> >>
> >> On Tue, Mar 13, 2012 at 5:11 PM, John Neiberger
> wrote:
> >>> I'll do that right now. I checked the AS under routing-options, but
> >>> didn't check for a local-as. Thanks! I'm very new to Juniper, so I'm
> >>> still pretty lost.
> >>>
> >>> On Tue, Mar 13, 2012 at 4:29 PM, Mohammad wrote:
> >>>> I think you need to check the autonomous-system under the
> routing-options
> >>>> hierarchy; and the local-as under protocols bgp group hierarchy;
> >>>>
> >>>>
> >>>>
> >>>> Mohammad Salbad
> >>>>
> >>>> ___
> >>>> 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
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Route origination in Junos
HI, You can see what you are advertising to specific neighbor with: show route advertising-protocol bgp HTH, Ivan, On Thu, Jan 5, 2012 at 12:41, Affandi Indraji wrote: > Hi, > > I understand that doing the origination from Junos is slightly different > from Cisco. > > Cisco: > - configure the network statement in the "router bgp" > - configure the null route (or as long as the routes is in the routing > table) it will be available in the BGP routing table > - when we do the "sh ip bgp x.x.x.x" in the cisco router where we originate > x.x.x.x, it will be shown in the BGP routing table > > Junos: > - configure discard static routes in "routing option" > - configure the policy statement to match the prefix that we configure in > the discard static route > - configure the policy statement into the "export" policy to the bgp > session that we want that origin routes to be announced > - if we do "show route protocol bgp x.x.x.x" in the router where we > originate the routes, we won't be able to see it int the BGP table. > > Question: > 1. Is there a way to put the routes that we originate in to the BGP routing > table in the same router? what i mean is, if i originate > 100.100.100.0/24from router A, i also want to see > 100.100.100.0/24 inside the BGP table in router A too (like cisco). Is > this > possible? > 2. Is there any best practice to originate routes in Junos since it behave > differently compare to cisco? > > Thank you. > > Regards, > Affandi > _______ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MPLS VPN using PE-P and P-PE LSPs !
gt;Task: RT >Announcement bits (1): 0-KRT >AS path: I > OSPF Preference: 10 >Next hop type: Router >Next-hop reference count: 6 >Next hop: 10.0.10.2 via ge-0/0/0.0 >Next hop: 10.0.10.10 via ge-0/0/1.0, selected >Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1 >Label-switched-path to_core1.pop1 >Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1 >Label-switched-path to_core1.pop2 >State: >Inactive reason: Route Preference >Local AS: 64513 >Age: 4:19 Metric: 2 >Area: 0.0.0.0 >Task: OSPF >AS path: I >Secondary Tables: inet.3 > > inet.3: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden) > > 10.0.6.1/32 (1 entry, 1 announced) >*OSPF Preference: 10 >Next hop type: Router >Next-hop reference count: 6 >Next hop: 10.0.10.2 via ge-0/0/0.0 >Next hop: 10.0.10.10 via ge-0/0/1.0, selected >Next hop: 10.0.10.2 via ge-0/0/0.0 weight 0x1 >Label-switched-path to_core1.pop1 >Next hop: 10.0.10.10 via ge-0/0/1.0 weight 0x1 >Label-switched-path to_core1.pop2 >State: >Local AS: 64513 >Age: 4:19 Metric: 2 >Area: 0.0.0.0 >Task: OSPF >Announcement bits (1): 2-Resolve tree 1 >AS path: I >Primary Routing Table inet.0 > > Thanks & Regards > Vaibhava Varma > On Sun, Dec 25, 2011 at 9:39 PM, Mark Tinka > wrote: > > On Sunday, December 25, 2011 09:35:52 PM vaibhava varma > > wrote: > > > >> Thanks a lot for your response..I have everything working > >> fine withLDP without any issues..I just wanted to deploy > >> RSVP-TE for fasterfailover in the backbone.. > > > > Ah okay. Got you. > > > >> And there I > >> got stuck up with the full-meshof TE among PEs or using > >> Broken Static LSPs between PE-P and P-PE.. > > > > What we've done, in one of our networks, to scale MPLS-TE > > was to enable RSVP only in the core, run LDP everywhere else > > and tunnel LDP in RSVP in the core. > > > > This was mostly to create single-hop LSP's so that we can > > solve unequal-cost path issues in the IGP to better utilize > > previously idle core links. > > > > That said, "MPLS-Enabled Applications" by Ina Minei & Julian > > Lucek is one place where I've seen RFC 4206 mechanisms > > documented in some form: > > > > > http://books.google.com.my/books?id=3MszQLz2cdwC&pg=PT66&lpg=PT66&dq=mpls+enabled+applications+label+operations+are+analogous+to+those+in+the+ldp&source=bl&ots=Abxedzafk8&sig=ZlvuaQ0PLqpMmZIqQVp5tL_Zppw&hl=en&sa=X&ei=00j3TtXzDMnOrQePvexD&ved=0CB0Q6AEwAA#v=onepage&q&f=false > > > > > > Page 30 is what you're after. Maybe that can help - I can > > theorize its operations, but we haven't deployed this > > particular architecture in the field. > > > >> Thanks for > >> sharing the rib-import methodology to get rid of > >> staticroutes for inet.3 resolution for BGP-Next Hops.. > > > > Most welcome. > > > >> Just a clarification on the "ldp-tunneling" part..Do I > >> need to applythis at all the PE/P routers to run LDP > >> over broken LSPs between PEs..Is there a provision in > >> Junos without using LDP Tunneling to passtraffic between > >> PEs when using broken LSPs ? > > > > I usually recommend that LDPoRSVP always be enabled on > > ingress routers for all LSP's. I also encourage them to be > > enabled on P routers that are also acting as ingress routers > > for RSVP LSP's. > > > > Otherwise, if a P router is merely a transit node for an > > LSP, then you wouldn't even be able to enabled LDPoRSVP, as > > you wouldn't have an LSP or tunnel under which to do that, > > both in IOS and Junos. > > > > Cheers > > > > Mark. > > > > -- > Regards > Vaibhava Varma > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2vpn problem
Hi Paul,
Try to add 'remote-site-id '
site dis1.millbrook1 {
site-identifier 1;
interface ge-1/3/5.512 {
remote-site-id 2;
}
}
Hope this helps!
Ivan,
On Tue, Oct 18, 2011 at 22:24, Paul Stewart wrote:
> We are starting to work on migrating many layer2 LAN connections over to
> our
> MPLS environment. I did a lab on l2vpn and it worked fine - trying it now
> as a test on a production network and it's not working ;)
>
>
>
> A pair of MX80's directly connected to one another - each MX80 has a
> trunked
> Ethernet port connected to a notebook computer for testing (each notebook
> supports dot1q VLAN and the proper VLAN is assigned).
>
>
>
> Trying to figure out why this won't work and pretty sure it's config
> related
> or my lack of understanding on something I thought I understood ;)
>
>
>
> Between the MX80's is iBGP and LSP's established (remote end example):
>
>
>
> xx.xx.100.72 11666 15798 15787 0 1 5d
> 0:11:59 Establ
>
> inet.0: 0/0/0/0
>
> bgp.l3vpn.0: 0/0/0/0
>
> bgp.l2vpn.0: 1/1/1/0
>
> inet6.0: 0/0/0/0
>
> bgp.l3vpn-inet6.0: 0/0/0/0
>
> customer-1.l2vpn.0: 1/1/1/0
>
>
>
> paul@dis1.millbrook1# run show route receive-protocol bgp xx.xx.100.72
>
>
>
> inet.0: 381163 destinations, 511426 routes (381163 active, 0 holddown, 0
> hidden)
>
>
>
> inet.3: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
>
>
>
> mpls.0: 44 destinations, 44 routes (44 active, 0 holddown, 0 hidden)
>
>
>
> inet6.0: 55308 destinations, 56716 routes (55308 active, 0 holddown, 0
> hidden)
>
>
>
> bgp.l2vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
>
> Prefix Nexthop MED LclprefAS path
>
> xx.xx.100.72:1:2:1/96
>
> * xx.xx.100.72 0 I
>
>
>
> customer-1.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
> hidden)
>
> Prefix Nexthop MED LclprefAS path
>
> xx.xx.100.72:1:2:1/96
>
> * xx.xx.100.72 0 I
>
>
>
>
>
> Router #1 is xx.xx.100.71 for loopback
>
> Router #2 is xx.xx.100.72 for loopback
>
>
>
> RSVP/LSP is fully established and appears operational.
>
>
>
> I keep getting "local site signaled down" status on the l2vpn:
>
>
>
> paul@dis1.millbrook1> show l2vpn connections
>
> Instance: customer-1
>
> Local site: dis1.millbrook1 (1)
>
>connection-site Type St Time last up # Up trans
>
>2 rmt LD
>
>
>
> Configuration on router #1 looks like this:
>
>
>
> interfaces {
>
>ge-1/3/5 {
>
>description TEST_l2vpn;
>
>vlan-tagging;
>
>unit 512 {
>
>vlan-id 512;
>
>}
>
> }
>
> }
>
>
>
> policy-options {
>
>community vpn-A members target:11666:9000;
>
> }
>
>
>
> routing-instances {
>
>customer-1 {
>
>instance-type l2vpn;
>
>interface ge-1/3/5.512;
>
>route-distinguisher xx.xx.100.71:1;
>
>vrf-target target:11666:9000;
>
>protocols {
>
>l2vpn {
>
>encapsulation-type ethernet-vlan;
>
>interface ge-1/3/5.512;
>
>site dis1.millbrook1 {
>
>site-identifier 1;
>
>interface ge-1/3/5.512;
>
>}
>
>}
>
>}
>
>}
>
> }
>
>
>
>
>
>
>
> Router #2 configuration looks like this:
>
>
>
> interfaces {
>
>ge-1/3/5 {
>
>description TEST_l2vpn;
>
>vlan-tagging;
>
>unit 512 {
>
>vlan-id 512;
>
>}
>
>}
>
> }
>
>
>
> policy-options {
>
>community vpn-A members target:11666:9000;
>
> }
>
>
>
> routing-instances {
>
>customer-1 {
>
> instance-type l2vpn;
>
>interface ge-1/3/5.512;
>
>route-distinguisher xx.xx.100.72:1;
>
>vrf-target target:11666:9000;
>
>protocols {
>
>l2vpn {
>
>encapsulation-type ethernet-vlan;
>
>interface ge-1/3/5.512;
>
>site dis2.millbrook1 {
>
>site-identifier 2;
>
>interface ge-1/3/5.512;
>
>}
>
>}
>
>}
>
>}
>
> }
>
>
>
> Thanks for any input,
>
>
>
> Paul
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Force IP traffic not to use the LSP path when enabling ISIS Traffic Engineering with Shortcuts
Hi Peter, IGP shortcuts should import more routes in inet.3 for the purposes of BGP resolving, as is described in the link below. http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/mpls-igp-shortcuts.html?searchid=1318793088423 It will not copy anything to inet.0. Do you have eventually 'set protocols mpls traffic-engineering bgp-igp' in the configuration, as this command will do exactly what you described? Hope this will help you! Ivan, On Sat, Oct 15, 2011 at 00:12, Peter K wrote: > We are in the process of enabling traffic engineering with shortcuts for > ISIS on an IP\MPLS based network. As a result of enabling ISIS traffic > engineering with shortcuts, IP traffic will utilize the LSP paths (inet.3) > for the forwarding decision. Is there a configuration feature so the IP > traffic will continue to used inet.0 as we enable the ISIS traffic > engineering feature. > > We observed a disruption in our IP traffic when we enabled the traffic > engineering feature possibly due to the fact in the change of the > forwarding > path to the LSP. > > Regards, > > Peter > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS TE Question
Hi Paul, Those two commands moves the LSP routes from inet.3 to inet.0. As the first one leaves them in inet.3, the second one not. In this way they are used for all IP traffic, because by default the LSP routes are with lower metric. In normal VPN MPLS core you don't need this as all you need to be resolved by LSP routes are the iBGP next-hop. That is why the default command is 'mpls traffic-engineering bgp' which is not seen in the configuration. This means that only BGP routes are resolved by inet.3 first and then by inet.0. Hope this helps! Cheers! On Sun, Oct 16, 2011 at 16:27, Paul Stewart wrote: > Hi there. > > > > I'm trying to understand the advantage of using "mpls traffic-engineering > bgp-igp-both-ribs" versus "mpls traffic-engineering bgp-igp". Is there an > advantage to loading up both tables that I am missing? > > > > Our goal is LSP mesh, iBGP, OSPF, OSPFv3, l2vpn, and l3vpn. With what I > can > understand so far in our partial deployment there is no need to loading up > both RIB tables . ? > > > > Thanks folks, > > > > Paul > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: bridge-domains and l2circuit
Thank you,
It seams that the problem is that I am trying to stitch from one side
'encapsulation vlan-bridge' and from the other 'encapsulation vlan-vpls'.
vlan-vpls on both ends again returns 'encapsulation mismatch'
Maybe this is not supported between two bridge domains.
Thank you again!
On Thu, Oct 13, 2011 at 23:25, Jonas Frey (Probe Networks) <
j...@probe-networks.de> wrote:
> Hello Ivan,
>
> as Humair already pointed out you need to have encapsulation vlan-bridge
> and vlan-ccc on one of each of the lt- interfaces.
>
> Best regards,
> Jonas
>
> Am Donnerstag, den 13.10.2011, 22:20 +0300 schrieb Ivan Ivanov:
> > Hello Jonas,
> >
> >
> > Could you share with us working configuration? Because when I try to
> > stitch both units of lt- interface I got error 'encapsulation
> > mismatch'.
> >
> >
> > Thanks!
> >
> > On Thu, Aug 18, 2011 at 21:26, Jonas Frey (Probe Networks)
> > wrote:
> > Thanks to all who replied, i got this working the way Chris
> > described
> > (via lt tunnels).
> >
> > I also tried the new iw0 interfaces as per juniper
> > documentation but it
> > didnt work. Bridge-domains wont let me add a iw0.x interface
> > to the
> > bridge and i was unable to find anymore information on howto
> > correctly
> > configure this (probably because its pretty new).
> >
> > Best regards,
> > Jonas
> >
> > Am Donnerstag, den 18.08.2011, 07:37 -0500 schrieb OBrien,
> > Will:
> >
> > > To implement tagged interfaces with bridge domains, I use
> > irb interfaces. This is directly from my production box with a
> > little scrubbing.
> > >
> > > xe-0/0/0 {
> > > description "blah uplink";
> > > per-unit-scheduler;
> > > flexible-vlan-tagging;
> > > encapsulation flexible-ethernet-services;
> > > unit 200 {
> > > encapsulation vlan-bridge;
> > > vlan-id 200;
> > > }
> > > unit 201 {
> > > encapsulation vlan-bridge;
> > > vlan-id 201;
> > > }
> > > }
> > >
> > > irb {
> > > unit 200 {
> > > family inet {
> > > inactive: filter {
> > > input I2Inbound;
> > > output I2Outbound;
> > > }
> > > service {
> > > input {
> > > service-set i2-napt service-filter
> > i2-nat-in;
> > > }
> > > output {
> > > service-set i2-napt service-filter
> > i2-nat-out;
> > > }
> > > }
> > > address x.x.x.x/30;
> > > }
> > > }
> > > unit 201 {
> > > family inet {
> > > filter {
> > > input PolicerIn;
> > > output PolicerOut;
> > > }
> > > service {
> > > input {
> > > service-set i1-napt service-filter
> > i1-nat-in;
> > > }
> > > output {
> > > service-set i1-napt service-filter
> > i1-nat-out;
> > > }
> > > }
> > > address x.x.x.x/30;
> > > }
> > > }
> > > }
> > >
> > > show configuration bridge-domains
> > >
> > > vlan-200 {
> > > domain-type bridge;
> > > vlan-id 200;
> > > interface xe-0/0/0.200;
> > > routing-interface irb.200;
> > > }
> > > vlan-201 {
> > > domain-type bridge;
> > > vlan-id 201;
> > > interface xe-0/0/0.201;
> > >
Re: [j-nsp] MX: bridge-domains and l2circuit
t-1/3/10.2;
> > >.other access interfaces go here;
> > >}
> > > }
> > >
> > > neighbor xxx {
> > > interface lt-1/3/10.1 {
> > > virtual-circuit-id 20;
> > > ...
> > > ...
> > > }
> > > }
> > >
> > > - Chris.
> > >
> > >
> > > On 2011-08-18, at 4:37 PM, Jonas Frey (Probe Networks) wrote:
> > >
> > >> Hi Chris,
> > >>
> > >> that does not work...
> > >>
> > >> edge# show interfaces xe-1/0/0
> > >> vlan-tagging;
> > >> encapsulation flexible-ethernet-services;
> > >> unit 0 {
> > >> family bridge {
> > >> interface-mode trunk;
> > >> vlan-id-list [ 20 30 40 ];
> > >> }
> > >> }
> > >> unit 1 {
> > >> encapsulation vlan-ccc;
> > >> vlan-id 20;
> > >> }
> > >>
> > >> If i do commit now, this fails as the vlan 20 is already used for the
> > >> bridge on unit 0. If i remove the vlan 20 from unit 0 then the vlan is
> > >> no longer member of the bridge (show bridge domain). But i need it to
> be
> > >> member of that bridge since that vlan goes out on other ports to local
> > >> switches.
> > >>
> > >>
> > >> edge# show bridge-domains testbridge
> > >> domain-type bridge;
> > >> vlan-id 20;
> > >>
> > >> What i need to do is to get the VLAN 20 working locally on the bridge
> > >> (various ports) as well as getting it connected to a somewhat pseudo
> > >> interface to attached it as a l2circuit.
> > >>
> > >> --
> > >> Mit freundlichen Grüßen / Best regards,
> > >> Jonas Frey
> > >>
> > >>
> > >> Probe Networks Jonas Freye-Mail: j...@probe-networks.de
> > >> Auf Strützberg 26D-3 Merzig
> > >> Tel: +(49) (0) 180 5959723* Fax: +(49) (0) 180 5998480*
> > >> * (14 Ct./min Festnetz, Mobilfunk ggf. abweichende Preise)
> > >> Internet: www.probe-networks.de Hotline: 0800 1656531
> > >>
> > >>
> > >> Diese E-Mail enthaelt moeglicherweise vertrauliche und/oder rechtlich
> > >> geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind
> > >> oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte
> > >> sofort den Absender und vernichten Sie diese Mail. Das unerlaubte
> > >> Kopieren sowie die unbefugte Weitergabe dieser Mail ist strengstens
> > >> untersagt.
> > >>
> > >> This e-mail may contain confidential and/or privileged information.
> > >> If you are not the intended recipient (or have received this e-mail in
> > >> error) please notify the sender immediately and destroy this e-mail.
> Any
> > >> unauthorised copying, disclosure or distribution of the contents of
> this
> > >> e-mail is strictly prohibited.
> > >>
> > >> --
> > >>
> > >>
> > >> Am Donnerstag, den 18.08.2011, 16:22 +1000 schrieb Chris Kawchuk:
> > >>> You'll need to declare your xe- port with flexible-ethernet-services,
> so you can do per-unit encapsulations.
> > >>>
> > >>> interfaces {
> > >>> xe-1/0/0 {
> > >>> vlan-tagging;
> > >>> encapsulation flexible-ethernet-services;
> > >>> unit 20 {
> > >>> encapsulation vlan-ccc;
> > >>> vlan-id 20;
> > >>> }
> > >>> unit 100 {
> > >>> encapsulation vlan-bridge;
> > >>> vlan-id 100;
> > >>> }
> > >>> }
> > >>> }
> > >>>
> > >>> neighbor xxx {
> > >>> interface xe-1/0/0.20 {
> > >>> virtual-circuit-id 20;
> > >>> ...
> > >>> ...
> > >>> }
> > >>> }
> > >>>
> > >>>
> > >>>
> > >>> On 2011-08-18, at 4:03 PM, Jonas Frey (Probe Networks) wrote:
> > >>>
> > >>>> Hello all,
> > >>>>
> > >>>> i am trying to build a l2circuit on a MX. The problem is that the
> vlan
> > >>>> that needs to be included in the l2circuit comes via xe-1/0/0 which
> is
> > >>>> configured in bridge mode:
> > >>>> unit 0 {
> > >>>> family bridge {
> > >>>> interface-mode trunk;
> > >>>> vlan-id-list [ 20 30 40 ];
> > >>>> }
> > >>>>
> > >>>> I need to build this l2circuit with vlan 20.
> > >>>>
> > >>>> However when configuring the l2circuit i do not have a interface to
> use
> > >>>> as the bridge doesnt create any subinterface for the vlan.
> > >>>>
> > >>>> neighbor xxx {
> > >>>> interface ??? {
> > >>>> virtual-circuit-id 20;
> > >>>>
> > >>>>
> > >>>> I cant configure any subinterface on xe-1/0/0 (like unit 1)
> because
> > >>>> bridge mode prohibits that.
> > >>>>
> > >>>> How can i get this to work?
> > >>>>
> > >>>> Best regards,
> > >>>> Jonas
> > >>>> ___
> > >>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
> > >>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >>>
> > >
> > >
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Best Regards!
Ivan Ivanov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] load balancing in Route reflector scenario
Hello, On this link http://goo.gl/6FgnZ from Cisco site you can find the below quote: "Route Reflector Limitation When multiple iBGP paths installed in a routing table, a route reflector will advertise only one paths (next hop). If a router is behind a route reflector, all routers that are connected to multihomed sites will not be advertised unless a different route distinguisher is configured for each VRF." To be honest I don't why is like this, but I think that with 'multipath' it won't work. HTH On Wed, Aug 10, 2011 at 23:32, Humair Ali wrote: > just to clarify , > > you have : > > PE2 with 2 link , 1 to RR1 (let's call it link 1) and 1 to RR2 (link 2) > PE3 with 2 link , 1 to RR1 (let's call it Link 3) and 1 to RR2 (link4) > > you could set local pref to link to PE2 to 150 (RR1 to PE2 will be > preferred), and link 2 (PE2 to RR2) as standard 100 > then set link 3 standard 100 (PE3 to RR1) but set link 4 with 150 (RR2 to > PE3 will be preferred) > > then RR1 has prefered path via PE2 (via link 1 high local pref), RR2 have > prefered path via PE3( via link 4 high local pref) , Each RR may advertise > both route to PE1 > > then on PE1 , u need load balancing configured , I can't guarantee either , > but need to be tested. > > On 10 August 2011 21:06, Stefan Fouant >wrote: > > > Have you tried the advertise-inactive knob on the RR? I can't guarantee > > that this will work but it just might also advertise the route towards > PE3 > > as well. > > > > Of course, if this works, then you would need to enable multipathing on > PE1 > > accordingly. > > > > Stefan Fouant > > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > > Technical Trainer, Juniper Networks > > http://www.shortestpathfirst.net > > http://www.twitter.com/sfouant > > > > Sent from my iPad > > > > On Aug 10, 2011, at 2:44 PM, biwa net wrote: > > > > > Dear All > > > > > > I have a setup where I need to load balancing routes received from 2 RR > > in > > > IPV4 environment (not VPN-IPV4) > > > > > > I have my PE (let's called PE1) connected to 2 RR (cluster), my > > destination > > > subnet eg: 10.1.1.1/24 is behind 2 PE (PE-2 and PE3) which are also > > client > > > of the same 2RR > > > > > > PE-2 and PE3 are sending the same route 10.1.1.1/24 to the RR , which > > as > > > per normal behavior is selecting the best route to PE1 , > > > > > > My issue is that RR is always advertising the route 10.1.1.1/24through > > PE2 > > > (due to lower router id) as best path and I would like to load balanced > > it > > > through PE2 and PE3 > > > > > > Anyone can recommend a way to load balance ? > > > > > > Unfortunately I dont have a lab to test any solution and there are live > > > traffic on this ,so all I can do is guessing is whether the below 2 > > option > > > would work or not. > > > > > > 2 option I have > > > > > > 1.So here I am trying to thinking about testing the multipath command > > under > > > the RR configuration to see if I am receiving routes from both PE or > not > > , > > > > > > 2. try to put all devices them in routing instance VRF , with the BGP > > > configuration under it (both RR and client) , and RD configured in the > > VRF > > > (but not putting any vpn family under bgp) so that it stays IPV4 routes > , > > > maybe I could cheat the RR to believe these are 2 differentes routes > due > > to > > > the RD, but dont know if this works or not . > > > > > > anyone has had similar issue and found a workaround ? > > > > > > does the 2 option above actually work or not ? > > > > > > thanks for any input > > > ___ > > > 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 > > > > > > -- > Humair > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SRX 3400 Clustering
Hello. SRX3K-CRM Module is needed if you want to have redundant control link. For 5k series you need an other RE for the same functionality. This is not related if you need second fabric link just for secondary control link. To summarize if you do not need redundant control link you can go without CRM module. And Stefan is more than correct as usual. The book that he pointed to is highly useful. Hope this helps! On Sun, May 15, 2011 at 18:10, Altaf Ahmad wrote: > > > Thanks for your feedback. > > > > From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sent: Sunday, May 15, 2011 6:14 PM > To: Altaf Ahmad; Farid Bouzemarene; juniper-nsp > Subject: Re: [j-nsp] Juniper SRX 3400 Clustering > > > > The book 'Junos Security' by Rob Cameron, Brad Woodberg, Tim Eberhard, et > al. has excellent coverage of the subject matter. I highly recommend this > book for anyone involved in day to day operations of SRX devices. The > chapter on 'High Availability' is well worth the price tag. > > Stefan Fouant > GPG Key ID: 0xB4C956EC > > Sent from my HTC EVO. > > - Reply message - > From: "Altaf Ahmad" > Date: Sun, May 15, 2011 5:39 am > Subject: [j-nsp] Juniper SRX 3400 Clustering > To: "Farid Bouzemarene" , "juniper-nsp" < > juniper-nsp@puck.nether.net> > > It would be great if you could please share any reference document for the > same.? > > > BR > > -Original Message- > From: Farid Bouzemarene [mailto:farid.bouzemar...@magirus.com] > Sent: Sunday, May 15, 2011 12:47 PM > To: Altaf Ahmad; juniper-nsp > Subject: Re: [j-nsp] Juniper SRX 3400 Clustering > > Its purpose is for the redundancy of the RE ! > > > > - Message d'origine - > De : "Altaf Ahmad" [aah...@bmc.com.sa] > Envoyé : 15.05.2011 10:32 ZE3 > À : > Objet : [j-nsp] Juniper SRX 3400 Clustering > > > > Hi Experts, > > > > I did configure the clustering of SRX 3400 chassis without installing > SRX3K-CRM Module and it went successful. Could anyone please let tell me > that then what is the purpose of CRM? Even in Juniper SRX3400 hardware guide > I read that this module is necessary for the clustering. But I am achieving > the clustering feature without installing the module. > > > > > > Kind Regards, > > > > Altaf Ahmad > > ___ > 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Validation failed warning message
Hi, Check what is doing 'request system snapshot' on the link below: http://www.juniper.net/techpubs/software/junos/junos92/swcmdref-basics-services/request-system-snapshot.html Ans then how to rollback (read the additional information, because it is important and platform specific) http://www.juniper.net/techpubs/software/junos/junos92/swcmdref-basics-services/request-system-software-rollback.html HTH, On Wed, Mar 16, 2011 at 10:16, medrees wrote: > Hi Stefan > > Thanks a lot for your valuable reply. > > So this message isn't actual dangerous? > How can I rollback if I faced any issue using this snapshot. > > Confirm the steps please > 1- request system snapshot > Verifying compatibility of destination media partitions... > Running newfs (899MB) on hard-disk media / partition (ad2s1a)... > Running newfs (100MB) on hard-disk media /config partition (ad2s1e)... > Copying '/dev/ad0s1a' to '/dev/ad2s1a' .. (this may take a few minutes) > Copying '/dev/ad0s1e' to '/dev/ad2s1e' .. (this may take a few minutes) > The following filesystems were archived: / /config > > 1- request system software add no-validate re1 > jinstall-10.1R4.4-export-signed.tgz reboot --< For the backup > Routing-Engine > 2- request system software add no-validate re0 > jinstall-10.1R4.4-export-signed.tgz reboot --< For the Mater > Routing-Engine > > -Original Message- > From: Stefan Fouant [mailto:sfou...@shortestpathfirst.net] > Sent: Wednesday, March 16, 2011 9:24 AM > To: 'medrees'; juniper-nsp@puck.nether.net > Subject: RE: [j-nsp] Validation failed warning message > > > -Original Message- > > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > > boun...@puck.nether.net] On Behalf Of medrees > > Subject: [j-nsp] Validation failed warning message > > > >I faces strange Warning message when I tried to validate > > the new JUNOS version 10.1, 10.2, 10.4 before upgrade my M120 router > > from V9.5 to any upper version so I’m afraid to go with this > > upgrading, so please if anyone has experience with this message reply > > me if it is really message prevent to go with this upgrading or it is > > normal message don’t mean any real issue. > > > > The Warning message(attached in the email the whole output from the > > two validation check) > > > > Validation failed > > WARNING: Current configuration not compatible with > > /var/home/remote/jinstall-10.1R4.4-export-signed.tgz > > You can ignore that and proceed with the upgrade by using the 'no-validate' > option. As a precautionary measure, you might want to take a snapshot of > the system prior to upgrading, in order to ensure proper rollback should > hell ensue - 'request system snapshot'. > > HTHs. > > Stefan Fouant, CISSP, JNCIEx2 > www.shortestpathfirst.net > GPG Key ID: 0xB4C956EC > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP strange Next hop behavior (in JNCIP)
Hello, If you follow the topology and the tasks from the book you should not have such issue. To help you we will need more information. You are saying that the agg received from R5 is causing the IBGP session on R3 to flap or? Does not R3 have the R5 lo0.0 like inter area route? It should not be resolved by the agg. The same should be for the IBGP session between R3 and R4. HTH On Wed, Mar 16, 2011 at 10:30, medrees wrote: > Hi Ivan > >Thanks, I'm understanding this and know the solution, but I'm asking why > there are difference In behavior in different routers for the same issue. > > the confusion came where there are another router R3 receive the same > route > which include lo0.0 of its IBGP sessions' peers R3 and R4 and instead of > make the same as R6 by insert the route in the Hidden and keep the BGP > session up, it used it as prefer which leaded to keep the sessions flap > many > time. > > > From: Ivan Ivanov [mailto:ivanov.i...@gmail.com] > Sent: Wednesday, March 16, 2011 11:18 AM > To: medrees > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] BGP strange Next hop behavior (in JNCIP) > > Hi, > > You probably have the lo0.0 of R5 in level-2. So the IBGP session is using > the attached default route on R6 from R5 to reach the IBGP peer. When R6 > gets the aggregate it contains the lo0.0 also. And the router is falling in > the situation where it has to use this agg for keeping the IBGP session > UP instead of the default, because the agg is more specific. In other words > to resolve the NH via the route itself, recursive. So JUNOS behavior is to > put the route as hidden and keep the IBGP session via the default. > > To resolve this you can advertise the agg from R5 with the NH IP address of > the interface towards the R6. > The explanation is on page 537 in the Study guide. Several pages before is > described the problem. > > HTH, > > > On Wed, Mar 16, 2011 at 08:09, medrees wrote: > Hi Expertise > > I’m wondering from strange behavior for two IBGP session included in > JNCIP_StudyGuide, I have one router make aggregation for the whole network > 10/8(R5 in case study of EBGP) and where the routers inside the other ISIS > are level-1 routers (R1 & R6) so they reach the Level1-2 router R5 Lo0 > through the default route. > > We have two scenarios: > > 1- when this route inserted in their BGP table the R1 which receive this > aggregated subnet (with Protocol NH of the router which created the > aggregated route R5) through another Level1-2 router R3 will simply choose > this subnet more preferred than the default route and the session of the > BGP > between R1 & R3 will flap and it is normal behavior . > 2- The abnormal behavior appear in the other Level-1 area which has direct > physical connection with the aggregated router R5 the route won’t be > inserted in the BGP active table but it will be inserted as Hidden route > which cause the Level-1 router R6 keep the IBGP session up. > > The two issues solved by use static route for the next hop of this > aggregated route toward the neighbor while sent this update to be preferred > more than even the aggregated BGP route or the Default ISIS route. > > But the question is why the remote router choose this route as active one > while the direct connected router (Route-reflector client ) flagged this > route as hidden route?? > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > Best Regards! > > Ivan Ivanov > > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP strange Next hop behavior (in JNCIP)
Hi, You probably have the lo0.0 of R5 in level-2. So the IBGP session is using the attached default route on R6 from R5 to reach the IBGP peer. When R6 gets the aggregate it contains the lo0.0 also. And the router is falling in the situation where it has to use this agg for keeping the IBGP session UP instead of the default, because the agg is more specific. In other words to resolve the NH via the route itself, recursive. So JUNOS behavior is to put the route as hidden and keep the IBGP session via the default. To resolve this you can advertise the agg from R5 with the NH IP address of the interface towards the R6. The explanation is on page 537 in the Study guide. Several pages before is described the problem. HTH, On Wed, Mar 16, 2011 at 08:09, medrees wrote: > Hi Expertise > > I’m wondering from strange behavior for two IBGP session included in > JNCIP_StudyGuide, I have one router make aggregation for the whole network > 10/8(R5 in case study of EBGP) and where the routers inside the other ISIS > are level-1 routers (R1 & R6) so they reach the Level1-2 router R5 Lo0 > through the default route. > > We have two scenarios: > > 1- when this route inserted in their BGP table the R1 which receive this > aggregated subnet (with Protocol NH of the router which created the > aggregated route R5) through another Level1-2 router R3 will simply choose > this subnet more preferred than the default route and the session of the > BGP > between R1 & R3 will flap and it is normal behavior . > 2- The abnormal behavior appear in the other Level-1 area which has direct > physical connection with the aggregated router R5 the route won’t be > inserted in the BGP active table but it will be inserted as Hidden route > which cause the Level-1 router R6 keep the IBGP session up. > > The two issues solved by use static route for the next hop of this > aggregated route toward the neighbor while sent this update to be preferred > more than even the aggregated BGP route or the Default ISIS route. > > But the question is why the remote router choose this route as active one > while the direct connected router (Route-reflector client ) flagged this > route as hidden route?? > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] FW: SRX Debug Commands.
Hello, check out this KB http://kb.juniper.net/InfoCenter/index?page=content&id=KB16110 HTH, On Tue, Jan 18, 2011 at 12:44, Braham Pal Singh < brahampal.si...@ericsson.com> wrote: > Hi All, > > We recently have SRX 3600 In the network and In the Earlier Netscreen > Firewall there was a very Good utlity to Capture and debug comand ( debug > flow basic , get dbuff stream etc ) to see the movement of the packet. Does > some one has idea as how this function has been transferred to SRX since it > is Junos Based Firewall. > > Thanks in advance > > Best Regards > > Brahampal singh > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX 3k A/P and IDP
Hi Will, I have some but with A/A. We have some problems but we are not sure if this is caused from IDP or from A/A misbehaver. We have open ticket and working on that. You need licenses on both nodes fist of all. Also the signature database should be downloaded and update to each node. You need Internet access to do that, but only first node is able to use the interfaces which are used for forwarding data. So second node has no way to download the signature database. We are using NSM and it succeeds to update the database on both nodes. So I suppose that fxp0 could be used from both nodes to download it from Internet, but I don't know how good idea is to provide Internet access to the management interface. Regarding the signatures tunning we are relying on Recommended set provided from Juniper. These templates are also download from Internet. Hope this helps! regards, On Fri, Oct 1, 2010 at 06:19, Will McLendon wrote: > Aloha, > > does anyone out there have any experience deploying an SRX3k series (3400 > cluster strictly A/P), with IDP services? Anyone know of any A/P > IDP-specific gotchas? or recommendations on running IDP in an A/P > configuration? > > we are looking to deploy this setup for a customer in the next month or > two, and just curious to hear some real-life deployment stories (horror or > otherwise!). Currently i'm looking at deploying the current JTAC > recommended code of 10.1R3. > > We have our fair share of battle scars from last year with some of the > branch boxes (9.5-9.6 timeframe) even without the hassle of UTM or IDP > features. Needless to say we've learned our lesson on selling a 'branch > box' even though the stated speeds/feeds seem more than sufficient (ready > for the SRX1400 to come out...). i've read and heard that the 3k/5k are > much more stable . . . here's to hoping! > > Thanks, > > Will > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX to SRX VPN
Hi Fahad, Could you paste your 'ike' and 'ipsec' part of the configuration? And maybe the policy configuration? Most probably the problem is somewhere around 'proxy-identiy'. regards, On Wed, Sep 15, 2010 at 14:27, Fahad Khan wrote: > Hi folks, > > I am trying to establish route based VPN between SRX3600(in Ch cluster) and > SRX210, but stuck in phase 2 (no proposal chosen).. > > has any one experienced it?? > > thanks in adv > > regards, > > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-301-8247638 > Skype: fahad-ibm > http://pk.linkedin.com/in/muhammadfahadkhan > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper firewall that does HA, "contexts" and VPN?
Hello, SRX-HE models could do that. Not sure about PPTP. I am finding only PPTP ALG functionality. You can terminate each customer VPN in different VRF, it is officially supported in 10.0R3.10. I think Stefan is talking for the same functionality. Then you can have overlapping IP addresses at both ends. And for example to play with rib-groups if you want Internet access at same time . The good thing with SRX is that you have the powerful JUNOS for routing and in the same time firewall functionality, which will become better and better in the future. HTH On Thu, Aug 5, 2010 at 15:18, Stefan Fouant wrote: > > -Original Message- > > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > > boun...@puck.nether.net] On Behalf Of Martin Barry > > Sent: Thursday, August 05, 2010 12:51 AM > > To: juniper-nsp@puck.nether.net > > Subject: [j-nsp] Juniper firewall that does HA, "contexts" and VPN? > > > > So, we're a Cisco shop but we need a firewall that can handle both > > "contexts" and VPNs (which it appears ASAs can't) and be run HA. > > > > Basically: > > > > - redundant pair running HA > > - IPSEC and PPTP VPN termination on a single external VLAN > > - separate ACLs and routing for each customer which dumps them into > > their > > own VLAN > > - must handle overlapping RFC1918 subnets at remote IPSEC endpoints > > > > Anyone have any recommendations? > > Most of the traditional ScreenOS products or the newer SRX line should be > able to meet most of your needs as they can do both stateful firewalling, > VPN functions, and most support high availability (all SRX products do, > whereas only some of the ScreenOS platforms do). > > You'll have problems with PPTP however because as far as I can remember > there is no PPTP tunneling support on either of these platforms, however > there is L2TP support if that's a viable alternative. > > On the older ScreenOS platforms you should have no problem dropping various > IPsec tunnels into a customer VSYS, and you can also do PBR functions to > route traffic into the appropriate VLAN based on layer 3 and layer 4 > characteristics. > > On the newer SRX line, you can dump different customer traffic into their > own VLAN in several ways - if it's IPsec encrypted traffic, you can either > bind the tunnel to the customers respective zone, or you can do Firewall > Based Filtering (FBF) on the traffic after it's been decrypted (I suppose > you could probably do FBF on encrypted traffic if you had a unique tunnel > endpoint for each customer and you matched on that unique endpoint but I'm > not sure)... You'll have no problem supporting RFC1918 subnets at the > remote IPsec endpoints. For the naysayers who say that there isn't the > equivalent of a VSYS capability in the SRX, you can get similar > functionality out of VRFs... although this is not a "supported" > configuration at this time, I've done it for several customers and it > works. > > HTHs. > > Stefan Fouant, CISSP, JNCIEx2 > www.shortestpathfirst.net > GPG Key ID: 0xB5E3803D > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Traffic drops on IPSEC - SRX3600
Hm, this sounds more than scary! Soon I will now if there is the same problem with 10.0R3.10 on 3600 cluster. So now I have good experience with router-based VPNs starting from routing-instance. Policy-based are working also, but I found router-based more scalable. But no with real traffic tested, until end of the week I will let you know. Ivan, On Mon, Aug 2, 2010 at 23:58, Amos Rosenboim wrote: > As far as I know the code you are running is the recommended version by > Juniper. > However it's important to mention that I have no experience with the high > end SRX boxes. > The stuff mentioned below by quoc sounds a little scary to me. > > Amos > > Sent from my iPhone > > On 2 Aug 2010, at 23:44, "Fahad Khan" fahad.k...@gmail.com>> wrote: > > I have 3 SPCs and 3 NPCs and running Junos 10.0R3.10, should I need to > upgrade junos? > > regards, > > > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com<mailto:fa...@pk.ibm.com> > +92-301-8247638 > Skype: fahad-ibm > http://pk.linkedin.com/in/muhammadfahadkhan > > > On Tue, Aug 3, 2010 at 12:02 AM, Quoc Hoang quocho...@yahoo.com>> wrote: > > I've deployed IPSEC VPNs between a pair of SRX3600 and NS5400 without > issue. SRX was running Junos 9.5r3. Performance wasn't great then. > > We recently ran into another vpn performance issue on more recent code, > 10.0r2. Avoid running ipsec vpns on the high end SRX till Juniper resolves > the issue unless you are planning to run with a single SPC. The fix will > require an architectural change. > > Problem description: > Low throughput is experienced on the Juniper high-end SRX line with systems > that have multiple SPC’s. The issue occurs when a tunnel anchor SPU and the > clear text session SPU are different. The problem exists because hash and > SEQ bit values in the switch header are not accounted for properly when > forwarding the packet to alternative SPU’s. > > > Quoc > > --- On Mon, 8/2/10, Fahad Khan fahad.k...@gmail.com>> wrote: > > From: Fahad Khan mailto:fahad.k...@gmail.com>> > Subject: [j-nsp] Traffic drops on IPSEC - SRX3600 > To: <mailto:juniper-nsp@puck.nether.net> juniper-nsp@puck.nether.net > <mailto:juniper-nsp@puck.nether.net> > Date: Monday, August 2, 2010, 4:48 AM > Hi folks, > > I am seeing very strange issue on SRX3600 when the traffic > is flown through > an IPSEC VPN tunnel (established with ISG2000), the tunnel > gets up and the > traffic flows properly, but suddenly traffic drops, while > the tunnel remains > up. > > And it continues to flow after 15 to 20 time out but again > it starts > droping. I am sure that there is no issue at physical > layer. > > Has any body faced it yet?? > > Please reply ASAP. > > Thanks in adv > > regards > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com<mailto:fa...@pk.ibm.com> > +92-301-8247638 > Skype: fahad-ibm > http://pk.linkedin.com/in/muhammadfahadkhan > ___ > juniper-nsp mailing list <mailto:juniper-nsp@puck.nether.net> > juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > ___ > juniper-nsp mailing list <mailto:juniper-nsp@puck.nether.net> > juniper-nsp@puck.nether.net<mailto: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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Traffic drops on IPSEC - SRX3600
Hello, We also experienced almost the same problem. If you do not need some of the new features from 10.1 try with 10.0R3.10. Do you try to send traffic (PING) from the SRX via the tunnel of from PC attached to SRX? Because in the first case there are time outs from time to time. But with traffic flowing trough the device no problems. We experience that with ISG and also with Cisco on the other end. HTH Ivan On Mon, Aug 2, 2010 at 4:45 PM, Fahad Khan wrote: > You mean although you were using recommended Junos but u had the same issue > and you upgraded to latest junos? > > Can you tell me which Junos version are u using currently?? > > awaiting for urgent response. > > regards, > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-301-8247638 > Skype: fahad-ibm > http://pk.linkedin.com/in/muhammadfahadkhan > > > On Mon, Aug 2, 2010 at 6:26 PM, Amos Rosenboim > wrote: > > > We had a the exact same thing on the lower end SRX (240 if I remember > > correctly). > > This was resolved by a software upgrade to the latest SRX image at the > > time. > > > > Amos > > > > On Aug 2, 2010, at 2:48 PM, Fahad Khan wrote: > > > > > Hi folks, > > > > > > I am seeing very strange issue on SRX3600 when the traffic is flown > > through > > > an IPSEC VPN tunnel (established with ISG2000), the tunnel gets up and > > the > > > traffic flows properly, but suddenly traffic drops, while the tunnel > > remains > > > up. > > > > > > And it continues to flow after 15 to 20 time out but again it starts > > > droping. I am sure that there is no issue at physical layer. > > > > > > Has any body faced it yet?? > > > > > > Please reply ASAP. > > > > > > Thanks in adv > > > > > > regards > > > Muhammad Fahad Khan > > > JNCIP - M/T # 834 > > > IT Specialist > > > Global Technology Services, IBM > > > fa...@pk.ibm.com > > > +92-301-8247638 > > > Skype: fahad-ibm > > > http://pk.linkedin.com/in/muhammadfahadkhan > > > ___ > > > 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 > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper support site and Chrome
Hi, Same here with 5.0.375.70 beta 64-bit on Ubuntu. I was forced to use IE and even then it is not working flawless. This happed after they migrated the Case Manager on their main web site, or at least changed the design of old one. Br, On Mon, Jun 7, 2010 at 1:35 AM, Chuck Anderson wrote: > On Sun, Jun 06, 2010 at 05:51:18PM -0400, Mark Kamichoff wrote: > > On Sun, Jun 06, 2010 at 03:04:04PM -0500, Richard A Steenbergen wrote: > > > Has anybody else noticed problems with the Juniper support website and > > > the Google Chrome browser? At least for the last couple days (and > > > maybe longer) it kicks me back to the main screen as soon as I try to > > > type anything in any box when updating a case. It works fine in > > > firefox, but it seems like they did something to break it in chrome > > > (I'm assuming javascript related). > > > > Same behavior, here. Actually, if I just click in the text box to give > > it focus, I'm kicked back to the case details page. > > > > Google Chrome 5.0.307.11-r39572 on Linux x86_64. > > Same behavior confirmed on Chromium 6.0.417.0 (Developer Build 0) as > well. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRRP in Olive?
Hello, Check this link, maybe it will help. http://www.mail-archive.com/qemu-de...@nongnu.org/msg11306.html Br, On Thu, Aug 6, 2009 at 12:25 PM, Patrik Olsson wrote: > If you run Olive on VMWare it wont work at all since multicast dont work > well at all on the virtual ethernet. > > Sounds great if QEMU fixes this little caveat... > > Cheers > Patrik > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Best Regards! Ivan Ivanov ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
