Hi!, Please note that PPPoE internal test clients on same Line card does not work , You have initiate from one Line Module and terminate on other line module ,with PPPoA there is not such restrictions. This info for PPPoE internal test clients is missing in KA-200 Regards Amin On Tue, 18 Apr 2006 juniper-nsp-request@puck.nether.net wrote : >Send juniper-nsp mailing list submissions to > juniper-nsp@puck.nether.net > >To subscribe or unsubscribe via the World Wide Web, visit > http://puck.nether.net/mailman/listinfo/juniper-nsp >or, via email, send a message with subject or body 'help' to > juniper-nsp-request@puck.nether.net > >You can reach the person managing the list at > juniper-nsp-owner@puck.nether.net > >When replying, please edit your Subject line so it is more >specific >than "Re: Contents of juniper-nsp digest..." > > >Today's Topics: > > 1. [ERX] Help needed simulating ppp users (Guillet, David >(David)) > 2. Re: Applying firewall filter to pfe (Erdem Sener) > 3. Re: Very disappointed with Juniper (Michael Loftis) > 4. Re: Very disappointed with Juniper (Michael Loftis) > 5. Re: Very disappointed with Juniper (Gustavo Rodrigues >Ramos) > 6. Re: Very disappointed with Juniper (Saku Ytti) > 7. Re: Very disappointed with Juniper (Sabri Berisha) > 8. Re: [ERX] Help needed simulating ppp users > (Guillet, David (David)) > 9. M320 FPC 3 (Manu Chao) > 10. Re: M320 FPC 3 (sthaug@nethelp.no) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 17 Apr 2006 18:13:39 +0200 > From: "Guillet, David (David)" >Subject: [j-nsp] [ERX] Help needed simulating ppp users >To: juniper-nsp@puck.nether.net >Message-ID: > ><0280BFD60641D51180C500508BB89AC10C668061@fr0024exch001u.fr.lucent.com> > >Content-Type: text/plain; charset="iso-8859-1" > >Hi, > I'm trying to simulate a PPP user using a PPPoE connection >according >to KA 200. > > I put the following configuration on my router but I could not >make >it work : > > On ATM port 2/3 my simulated user is configured while in slot >2/2 I >create a static pppoe subinterface. Here is the conf detail : > > >int atm 2/3.0 >atm pvc 100 0 100 aal5snap >encap pppoe >pppoe allow-client >pppoe subint atm 2/3.0.1 >encap ppp >ip addr 11.11.11.11 255.255.255.255 >pppoe test-client >ppp client chap hostname user1@pppoe_dyn.lab password dynamic >ppp client ip-address 0.0.0.0 > >int atm 2/2.0 >atm pvc 101 0 100 aal5snap >encap pppoe >pppoe subint atm 2/2.0.1 >encap ppp >ppp auth chap >ip add 22.22.22.22 255.255.255.0 >ip access-route > >Does anyone have an idea of why this is not working ? I also >tried to use >the atm int 2/3.0.1 and atm in 2/3.0.1 commands for creating the >pppoe sub >interface but it's not working either. > >Regards > >David > > >------------------------------ > >Message: 2 >Date: Mon, 17 Apr 2006 19:58:03 +0300 > From: "Erdem Sener" >Subject: Re: [j-nsp] Applying firewall filter to pfe >To: jnsp >Message-ID: > <392c91050604170958n32b4cd6bn30496158c9d90fd@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > > Thanks, I believe this'll do the trick :) > > For the case of discard routes, there's always trouble of >'readvertising or not' withing the backbone, the reason I'm >trying to >avoid most of the times. > > Erdem > >On 4/17/06, Domiciano Alonso Fern?ndez > wrote: > > You could try applying a filter at [forwarding-options family >inet filter] > > level > > hth > > > > > > On 4/17/06, Chris Morrow wrote: > > > > > > > On Mon, 17 Apr 2006, Erdem Sener wrote: > > > I mean, let's assume we have an M series router with a bunch >of > > > interfaces. Let's add a source address 1.2.3.4/32 that we >don't want > > > to transit via any interface over the router. > > > > > > any ideas besides applying a firewall filter to _all_ >interfaces? > > > > how about a local discard route and uRPF? > > _______________________________________________ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > http://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > > > >------------------------------ > >Message: 3 >Date: Mon, 17 Apr 2006 16:22:10 -0600 > From: Michael Loftis >Subject: Re: [j-nsp] Very disappointed with Juniper >To: "W. Kevin Hunt" , > juniper-nsp@puck.nether.net >Message-ID: > >Content-Type: text/plain; charset=us-ascii; format=flowed > > > >--On April 8, 2006 12:09:56 PM -0500 "W. Kevin Hunt" > wrote: > > > Hmm... > > I've been lurking for 3 weeks trying to decide if our next >border router > > should be another Cisco 12k or a Juniper. We acquired a >Juniper M20 > > during the acquisition of a defunct carrier's assets, so I'd >like to use > > it but I'm not "comfortable" enough with it yet to put it on >the border > > and "learn it" while it's there. > > > > I manage 2 - 12012's right now and am somewhat disappointed in >the > > feature set available on them. > > I have a few questions regarding Juniper as I've never had the >pleasure > > of sitting at the console of one : > > > > 1.) JUNOS seems steeped in BSD, one of my favorite OS's, is it >true you > > can run FreeBSD compiled binaries on JUNOS ? > >Up to 7.5 -- they went/are going to signed bins. > > > 2.) How is "controller redundancy" handled on the Juniper >platform? > >Ahh, I'll leave that to others as I'm not 100% clear. The Juni >has an RE >(Routing Engine), one or more FEBs or CFEBs(M7i, M10i) (either in >a load >sharing or redundant config). > > > > > 3.) Anyone here had to deal with 6-8 mpps ddos attacks on a >Juniper, and > > if so, was the juniper cli responsive during the attacks, >and what > > mitigation abilities did the Juniper give you? I'm accustomed >to just > > plain ios acl's for mitigation which is tough when there are >8-9 hundred > > sources. > >Yes. It works fine. Because there's a REAL CONTROL PLANE. >Unlike Cisco. >One of my three main filters for all inbound and outbound traffic >is 800 >lines by itself. I've others of something like 200-500 each, >probably 2k >entries total. 'ACLs' (prefix-lists, or firewall rules in >juniland) are >done in hardware when applied as a filter. There's almost no >practical >limit. There are individuals who've reduced an entire 165k BGP >table to >firewall terms. There isn't really a concept of a 'software >switched' >packet in JunOS. Everything is done "in hardware" (actually >micro engines >or FPGA in some cases) either on the PICs, or FEBs, or ASM. > >You still have to have a clear pipe to the Routing Engine >(control plane) >either IB or OOB, but even if it's being directly attacked all >incoming >traffic can easily be rate limited, and in fact is by default, in >the >hardware at the packet forwarding plane. You can go take a look >at the >Secure JunOS template at Cymru >http://www.cymru.com/gillsr/documents/junos-template.pdf -- any >filter >applied to lo0 applies to the whole RE, but is done *in >hardware*. > >General packet flow in a Juniper M series is documented at >juniper >clue....can't remember URL right now but I'm sure someone will. >Thing of >any M series as a really fully distributed 7k or 12k ish chassis. >Packets >can't get punted to the RE unless they're destined for the >RE...OK well >that's not 100% true, 99%, but they're rate limited to such an >extent that >you won't experience performance issues. Also the REs are >generally a LOT >faster than the CPUs in the Cisco gear, and, they're ONLY there >to handle >control plane. Heck, an RE can go deadlock and the FEBs will >keep routing >packets. You lose all your control plane though in a situation >like that. > > > 4.) What are the support and upgrade options on equipment that >one did > > not purchase "new". i.e. we acquired this M40, it seems to >have JUNOS > > 4.1 on it. What kind of expense am I looking at to get the >latest JUNOS > > on it and basic telephone support for it? > >There won't be any unsual upgrade costs, a support license >includes >software. > > > > >------------------------------ > >Message: 4 >Date: Mon, 17 Apr 2006 16:26:30 -0600 > From: Michael Loftis >Subject: Re: [j-nsp] Very disappointed with Juniper >To: Luke Parrish , Chris Cappuccio > , juniper-nsp@puck.nether.net >Message-ID: > <39D6C1C5B2C6CD40D505B75D@d216-220-25-20.dynip.modwest.com> >Content-Type: text/plain; charset=us-ascii; format=flowed > > > >--On April 10, 2006 3:47:44 PM -0500 Luke Parrish > >wrote: > > > Also, your default support answer will not be "please upgrade >your IOS". > > You will find much deeper troubleshooting and "root cause" >instead of > > just patching the problem with software. > > > >I'll second that. JTAC actually researches a problem, and *IFF* >the >problem is solved by upgrading, then that's what will be >suggested, but >only after it's verified that they've found your problem and have >a fix in >hand. > > >------------------------------ > >Message: 5 >Date: Mon, 17 Apr 2006 21:41:44 -0300 > From: Gustavo Rodrigues Ramos >Subject: Re: [j-nsp] Very disappointed with Juniper >To: juniper-nsp@puck.nether.net >Message-ID: <444435C8.204@acmesecurity.org> >Content-Type: text/plain; charset=ISO-8859-1 > > > >Michael Loftis wrote: > > > > General packet flow in a Juniper M series is documented at >juniper > > clue....can't remember URL right now but I'm sure someone >will. > >http://juniper.cluepon.net/index.php/Main_Page > > >------------------------------ > >Message: 6 >Date: Tue, 18 Apr 2006 09:46:35 +0300 > From: Saku Ytti >Subject: Re: [j-nsp] Very disappointed with Juniper >To: juniper-nsp@puck.nether.net >Message-ID: <20060418064635.GA25424@mx.ytti.net> >Content-Type: text/plain; charset=us-ascii > >On (2006-04-17 16:22 -0600), Michael Loftis wrote: > > > Yes. It works fine. Because there's a REAL CONTROL PLANE. >Unlike Cisco. > > I'm not sure which Cisco you're talking about. But this is >rather >harsh simplification of the problematics when comparing the two >vendors, it's not really that easy. You can pick Cisco that will >do >what Juniper will not do (eg RFC3682 in hardware). And of >course >it's easy vice versa to pick up GSR with IOS and say 'it sucks, >as it doesn't do control-plane protection in hardware'. > As we've all seen from various test raports, when you know >enought of the platform you're testing, you can make it look >bad. > > But yes, generally in real-life JNPR out-performans on >avarage >the deployed Cisco's. I'd mainly say thats due to people are >running rather old Cisco gear, and JNPR doesn't have that much >history, >so random JNPR you're end up working with will most probably be >more >powerful work horse, giving the feeling that JNPR is superior >box. > > > firewall terms. There isn't really a concept of a 'software >switched' > > packet in JunOS. Everything is done "in hardware" (actually >micro engines > > or FPGA in some cases) either on the PICs, or FEBs, or ASM. > > There is exception CPU, just like GSR has LC CPU. > > > http://www.cymru.com/gillsr/documents/junos-template.pdf -- >any filter > > applied to lo0 applies to the whole RE, but is done *in >hardware*. > > CoPP (control plane policing) as cisco likes to call it, is >done >in hardware in newer gear. Such as SUP720, GSR or CRS-1 with >IOS-XR. >GSR with IOS will do it in LC CPU, because it has to support >CoPP >in line cards that do not have forwarding asics at all, which >IOS-XR >will not do. > > > General packet flow in a Juniper M series is documented at >juniper > > clue....can't remember URL right now but I'm sure someone >will. Thing of > > any M series as a really fully distributed 7k or 12k ish >chassis. Packets > > 'M series' is really not appropriate here, they're not all >fully >distributed. But yeah I guess if you'd have to compare M to >some >cisco architecture 12k would be closest. > > > can't get punted to the RE unless they're destined for the >RE...OK well > > that's not 100% true, 99%, but they're rate limited to such an >extent that > > you won't experience performance issues. Also the REs are >generally a LOT > > faster than the CPUs in the Cisco gear, and, they're ONLY >there to handle > > control plane. Heck, an RE can go deadlock and the FEBs will >keep routing > > packets. You lose all your control plane though in a >situation like that. > > And this is one of my major griefs in Juniper, when >control-plane >fails, it keeps on either blackholing or forwarding traffic to >wrong (unupdated) destinations. Effectively even if I engineer >network to survive failure, I can't route around the problem >always. Think of GSR running out of memory in LC without >'external overload >signalling' configured. Very undesired for me. Much harder to >troubleshoot >box that is 'sort of working', but you never know which prefix is >going >where, and why. At least thats my experience of troubleshooting >JNPR with low memory condition compared to GSR. > My second worst grief is the 20 USD HDD's, that are not specced >to 24/7 >failing, and for some reason can bring whole RE down, but may or >may >not keep forwarfing up (you really want forwarding down, when >control >is down) > And lack of innivation and progress in JNPR routing portfolio >scares me, >it was really kick-ass innovation in 1999, but I haven't seen >anything >much change since that. I'd really love to see 7600ish box with >JunOS >CLI, without the few oddities I've mentioned, and IPII updated >for multiple lookups, GTSM, etc. > > > > 4.) What are the support and upgrade options on equipment >that one did > > > not purchase "new". i.e. we acquired this M40, it seems to >have JUNOS > > > 4.1 on it. What kind of expense am I looking at to get the >latest JUNOS > > > on it and basic telephone support for it? > > > > There won't be any unsual upgrade costs, a support license >includes > > software. > > Expect IPv6 feature license, license per ASM/AS-PIC feature >(one >included in price). So Firewall/NAT/NetFlow are all separately >billed features in it. > > > Having said that. JNPR is good box, there is reason why we have >both >in our network. Personally I belive JNPR's biggest assest is not >the >hardware, reliability, predictability but it's the CLI with >policy-language >and all, that's in my opinion where Cisco has most catching up to >do. > Hopefully they will back-port policy language from IOS-XR to >IOS. > >-- > ++ytti > > >------------------------------ > >Message: 7 >Date: Tue, 18 Apr 2006 11:08:28 +0200 > From: Sabri Berisha >Subject: Re: [j-nsp] Very disappointed with Juniper >To: Saku Ytti >Cc: juniper-nsp@puck.nether.net >Message-ID: <20060418090828.GA37581@cluecentral.net> >Content-Type: text/plain; charset=us-ascii > >On Tue, Apr 18, 2006 at 09:46:35AM +0300, Saku Ytti wrote: > >Hello all, > > > > control plane. Heck, an RE can go deadlock and the FEBs >will keep routing > > > packets. You lose all your control plane though in a >situation like that. > > > > And this is one of my major griefs in Juniper, when >control-plane > > fails, it keeps on either blackholing or forwarding traffic >to > > wrong (unupdated) destinations. Effectively even if I >engineer > > network to survive failure, I can't route around the problem > > always. Think of GSR running out of memory in LC without >'external overload > > signalling' configured. Very undesired for me. Much harder to >troubleshoot > > box that is 'sort of working', but you never know which prefix >is going > > where, and why. > >The forwarding-engine will continue to forward packets for 300 >seconds when >it loses connectivity with the routing-engine. This will give >adjacent >routers the opportunity to have their routing-protocols >"time-out" on >the affected node. > >A forwarding-engine which has lost connectivity to the >routing-engine >will not forward packets for ever. > >Thanks, > >-- >Sabri > >please do not throw salami pizza away > > >------------------------------ > >Message: 8 >Date: Tue, 18 Apr 2006 12:25:58 +0200 > From: "Guillet, David (David)" >Subject: Re: [j-nsp] [ERX] Help needed simulating ppp users >To: juniper-nsp@puck.nether.net >Message-ID: > ><0280BFD60641D51180C500508BB89AC10C6681DF@fr0024exch001u.fr.lucent.com> > >Content-Type: text/plain > >Hi nobody has an idea on this ? > >regards > >david > > > -----Original Message----- > > From: juniper-nsp-bounces@puck.nether.net > > [mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of > > Guillet, David > > (David) > > Sent: lundi 17 avril 2006 18:14 > > To: juniper-nsp@puck.nether.net > > Subject: [j-nsp] [ERX] Help needed simulating ppp users > > > > > > Hi, > > I'm trying to simulate a PPP user using a PPPoE > > connection according > > to KA 200. > > > > I put the following configuration on my router but I > > could not make > > it work : > > > > On ATM port 2/3 my simulated user is configured while > > in slot 2/2 I > > create a static pppoe subinterface. Here is the conf detail >: > > > > > > int atm 2/3.0 > > atm pvc 100 0 100 aal5snap > > encap pppoe > > pppoe allow-client > > pppoe subint atm 2/3.0.1 > > encap ppp > > ip addr 11.11.11.11 255.255.255.255 > > pppoe test-client > > ppp client chap hostname user1@pppoe_dyn.lab password >dynamic > > ppp client ip-address 0.0.0.0 > > > > int atm 2/2.0 > > atm pvc 101 0 100 aal5snap > > encap pppoe > > pppoe subint atm 2/2.0.1 > > encap ppp > > ppp auth chap > > ip add 22.22.22.22 255.255.255.0 > > ip access-route > > > > Does anyone have an idea of why this is not working ? I also > > tried to use > > the atm int 2/3.0.1 and atm in 2/3.0.1 commands for creating > > the pppoe sub > > interface but it's not working either. > > > > Regards > > > > David > > _______________________________________________ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > http://puck.nether.net/mailman/listinfo/juniper-nsp > > > > >------------------------------ > >Message: 9 >Date: Tue, 18 Apr 2006 12:38:09 +0200 > From: "Manu Chao" >Subject: [j-nsp] M320 FPC 3 >To: juniper-nsp@puck.nether.net >Message-ID: > <7100ed370604180338p40f42604n2698d86e636c79e4@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Can a M320 FPC 3 support a type 2 PIC (1-port-OC-48) ? > > >------------------------------ > >Message: 10 >Date: Tue, 18 Apr 2006 12:45:15 +0200 (CEST) > From: sthaug@nethelp.no >Subject: Re: [j-nsp] M320 FPC 3 >To: linux.yahoo@gmail.com >Cc: juniper-nsp@puck.nether.net >Message-ID: <20060418.124515.74688695.sthaug@nethelp.no> >Content-Type: Text/Plain; charset=us-ascii > > > Can a M320 FPC 3 support a type 2 PIC (1-port-OC-48) ? > >According to the documentation FPC 3 only supports type 3 PICs. > >Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > >------------------------------ > >_______________________________________________ >juniper-nsp mailing list >juniper-nsp@puck.nether.net >http://puck.nether.net/mailman/listinfo/juniper-nsp > > >End of juniper-nsp Digest, Vol 41, Issue 18 >******************************************* Warm Regards Ehtesham Amin