Re: [j-nsp] Juniper MX SCBE-MX-R
On Thu, Aug 11, 2011 at 07:33:20AM -0400, Chuck Anderson wrote: > > I'd rather they slip and put out well tested, stable code than to just > release what they have on a specific time schedule. Don't worry, they can still find a way to fail at both. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Radius - Static IP / ERX
Thanks.. yeah the MTU statement is legacy and in place for some other Radius authentications;) I thought our entries had the Framed-IP-Netmask in them so will have to check again as you're right it's not there obviously... wouldn't think that would stop the IP from getting assigned but could be wrong... Take care, Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chris Adams Sent: August-11-11 2:26 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Radius - Static IP / ERX Once upon a time, Paul Stewart said: > Getting ready to cut an ERX into production shortly and the only thing not > working is static IP assignments via Radius. According to the docs, you can > use "Framed-IP-Address" the same as we do in Cisco land today.. but it > doesn't' work. Your example entry doesn't have a Framed-IP-Netmask set, which may be required. Also, Framed-MTU is pretty much useless; since PPP is already negotiated before RADIUS authentication occurs, link MTU is already established before your Framed-MTU entry can have any affect (this has always been the case with PPP+RADIUS, but lots of examples show Framed-MTU anyway). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX SCBE-MX-R
Agreed. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chuck Anderson Sent: Thursday, August 11, 2011 7:33 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX SCBE-MX-R On Thu, Aug 11, 2011 at 07:16:19PM +1000, Julien Goodwin wrote: > On 08/11/11 19:00, Daniel Roesen wrote: > > On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: > >> What I got from juniper is that the enhanced SCB will only be > >> supported in 11.4 which is April 2012. > > > > We're hearing 11.4 is due end of 2011. > > At the rate Juniper is slipping these days... > > 11.2 finally came out last week, just over a month late. > > Juniper staff at various levels keep assuring me things are being put > in place to improve this, yet the trend is backwards. I'd rather they slip and put out well tested, stable code than to just release what they have on a specific time schedule. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Radius - Static IP / ERX
Once upon a time, Paul Stewart said: > Getting ready to cut an ERX into production shortly and the only thing not > working is static IP assignments via Radius. According to the docs, you can > use "Framed-IP-Address" the same as we do in Cisco land today.. but it > doesn't' work. Your example entry doesn't have a Framed-IP-Netmask set, which may be required. Also, Framed-MTU is pretty much useless; since PPP is already negotiated before RADIUS authentication occurs, link MTU is already established before your Framed-MTU entry can have any affect (this has always been the case with PPP+RADIUS, but lots of examples show Framed-MTU anyway). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Radius - Static IP / ERX
Hey folks.. Getting ready to cut an ERX into production shortly and the only thing not working is static IP assignments via Radius. According to the docs, you can use "Framed-IP-Address" the same as we do in Cisco land today.. but it doesn't' work. Is this a Radius attribute issue or is it something missing in my profile that allows Radius to do the assignment? Dynamic IP pools are done locally on the box itself currently. Radius Entry (FreeRadius): pstewartAuth-Type = System Service-Type = Framed-User, Framed-IP-Address = xx.xxx.58.253, Framed-MTU = 1500, Idle-Timeout = 6000 Thanks, Paul ___ 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
Hi All, My be this info will help understand!! Juniper - Default Administrative Distance - preference Direct/Local : 0 Static : 5 RSVP : 7 Resource Reservation Protocol LDP : 9 Label Distribution Protocol OSPF internal route : 10 IS-IS Level 1 internal route : 15 IS-IS Level 2 internal route : 18 Default : 20 RIP : 100 RIPng : 100 PIM : 105 DVMRP : 110 Aggregate routes: 130 OSPF AS external routes : 150 IS-IS Level 1 external route : 160 IS-IS Level 2 external route : 165 BGP : 170 MSDP: 175 Cisco - Default Administrative Distance Routing Source Administrative Distance Connected interface or static route that identifies the outgoing interface rather than the next hop0 Static route 1 EIGRP summary route 5 External BGP 20 EIGRP 90 IGRP 100 OSPF 110 RIP 120 External EIGRP 170 Internal BGP 200 An unknown network 255 or infinity Cheers, Dusan On Thu, Aug 11, 2011 at 5:09 PM, Harry Reynolds wrote: > Juniper does not have a specific preference for ebgp vs ibgp. The active > route selection process does prefer e over i, so in that regard IOS and JUNI > are the same. > > Where in my message did I say "IBGP"? I was referring to an EBGP route vs > an OSPF/IGP route. In which case the cisco will select the EBGP, and > readvertise it downstream, while a JUNI will select the ospf version, and > therefore, by default, not readvertise the BGP version. > > As such placing a juni into that spot results in a different set of bgp > route advertisements, which again, stem from different global route > preference. > > "I can rest assure you that this was not the main intention of this knob > :)" > > Your statement above is incorrect. This is the intended use of the knob. > > > Regards > > > > > -Original Message- > From: Robert Raszuk [mailto:rob...@raszuk.net] > Sent: Wednesday, August 10, 2011 11:29 PM > To: Harry Reynolds > Cc: Keegan Holley; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] load balancing in Route reflector scenario > > Hi Harry, > > > default, differences in route preference cause a JUNI to prefer an > > IGP route while ios prefer the bgp routs over IGP. > > Let's make a clear distinction between preferring eBGP route versus iBGP > route. Talking CSCO here eBGP admin distance is as you say 20 while iBGP as > even the URL provided by yourself says it is 200. > > So keeping in mind that usually hot potato routing is a desired behaviour > preferring EBGP learned path is highly recommended for a given prefix. > > If you say that JUNI is to prefer IGP route over BGP one I am sure you must > be referring to IBGP and not EBGP, but this is exactly the same in both > vendors. > > > W/o this knob replacing a cisco with a juniper can result in > > previously advertised bgp routes no longer being advertised. > > I can rest assure you that this was not the main intention of this knob :) > > Cheers, > R. > > > > > > I always thought that advertise-inactive was to make a juniper act > > like a cisco with regard to BGP route announcements, when, by default, > > differences in route preference cause a JUNI to prefer an IGP route > > while ios prefer the bgp routs over IGP. > > > > In junos, only the active route is readvertised/subject to export > > policy. With advertise-inactive you can make a juniper router, whose > > active route is an IGP route, advertise into BGP the "best bgp path", > > which here is inactive due to the igp route being preferred. > > > > W/o this knob replacing a cisco with a juniper can result in > > previously advertised bgp routes no longer being advertised. > > > > From: > > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080 > > 094823.shtml > > > > eBGP 20 > > > > . . . > > > > OSPF 110 > > > > > > From: > > http://www.juniper.net/techpubs/software/junos/junos64/swconfig64-rout > > ing/html/protocols-overview4.html > > > > OSPF internal route 10 > > > > IS-IS Level 1 internal route 15 . . . > > > > BGP 170 > > > > HTHS. > > > > > > > > > > -Original Message- From: juniper-nsp-boun...@puck.nether.net > > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan > > Holley Sent: Wednesday, August 10, 2011 2:48 PM To: > > rob...@raszuk.net Cc: juniper-nsp@puck.nether.net Subject: Re: > > [j-nsp] load balancing in Route reflector scenario > > > > 2011/8/10 Robert Raszuk > > > >> Hi Keegan, > >> > >> > >> I think the advertise inactive knob turns that off, but I don't know > >> for > >>> sure because I've never tried it. I know it's not supported on > >>> cisco routers. The reason for it is the size of the BGP table. > >>> So if the table is 400k routes
Re: [j-nsp] load balancing in Route reflector scenario
Juniper does not have a specific preference for ebgp vs ibgp. The active route selection process does prefer e over i, so in that regard IOS and JUNI are the same. Where in my message did I say "IBGP"? I was referring to an EBGP route vs an OSPF/IGP route. In which case the cisco will select the EBGP, and readvertise it downstream, while a JUNI will select the ospf version, and therefore, by default, not readvertise the BGP version. As such placing a juni into that spot results in a different set of bgp route advertisements, which again, stem from different global route preference. "I can rest assure you that this was not the main intention of this knob :)" Your statement above is incorrect. This is the intended use of the knob. Regards -Original Message- From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Wednesday, August 10, 2011 11:29 PM To: Harry Reynolds Cc: Keegan Holley; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] load balancing in Route reflector scenario Hi Harry, > default, differences in route preference cause a JUNI to prefer an > IGP > route while ios prefer the bgp routs over IGP. Let's make a clear distinction between preferring eBGP route versus iBGP route. Talking CSCO here eBGP admin distance is as you say 20 while iBGP as even the URL provided by yourself says it is 200. So keeping in mind that usually hot potato routing is a desired behaviour preferring EBGP learned path is highly recommended for a given prefix. If you say that JUNI is to prefer IGP route over BGP one I am sure you must be referring to IBGP and not EBGP, but this is exactly the same in both vendors. > W/o this knob replacing a cisco with a juniper can result in > previously > advertised bgp routes no longer being advertised. I can rest assure you that this was not the main intention of this knob :) Cheers, R. > I always thought that advertise-inactive was to make a juniper act > like a cisco with regard to BGP route announcements, when, by default, > differences in route preference cause a JUNI to prefer an IGP route > while ios prefer the bgp routs over IGP. > > In junos, only the active route is readvertised/subject to export > policy. With advertise-inactive you can make a juniper router, whose > active route is an IGP route, advertise into BGP the "best bgp path", > which here is inactive due to the igp route being preferred. > > W/o this knob replacing a cisco with a juniper can result in > previously advertised bgp routes no longer being advertised. > > From: > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080 > 094823.shtml > > eBGP 20 > > . . . > > OSPF 110 > > > From: > http://www.juniper.net/techpubs/software/junos/junos64/swconfig64-rout > ing/html/protocols-overview4.html > > OSPF internal route 10 > > IS-IS Level 1 internal route 15 . . . > > BGP 170 > > HTHS. > > > > > -Original Message- From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keegan > Holley Sent: Wednesday, August 10, 2011 2:48 PM To: > rob...@raszuk.net Cc: juniper-nsp@puck.nether.net Subject: Re: > [j-nsp] load balancing in Route reflector scenario > > 2011/8/10 Robert Raszuk > >> Hi Keegan, >> >> >> I think the advertise inactive knob turns that off, but I don't know >> for >>> sure because I've never tried it. I know it's not supported on >>> cisco routers. The reason for it is the size of the BGP table. >>> So if the table is 400k routes and you have 5 different ISP's and >>> you advertise every route that would be 2M routes in the table. >>> Since BGP doesn't allow multiple version of the same route in the >>> routing table (separate from the BGP table where incoming routes are >>> stored) you would still only use the original 400K the other 1.8M >>> routes would just go unused unless you manipulated them some how. >>> >> >> Advertise inactive is not about what get's advertised - it is about >> if the best path is advertised or not. And if is decided based on the >> check if the BGP path to be advertised is inserted in the RIB/FIB or >> not. >> > > Oh I see. I have never used that command so thanks. Most of the > above example was what would happen if BGP advertised everything it > learned instead of just the best path or the path in the routing table > btw. > >> >> By default Junos and IOS-XR advertise only those best path in BGP >> which actually are installed into forwarding. Advertising inactive >> knob will overwrite it. >> > > Wouldn't this lead to traffic being blackholed? If all the routes for > a given destination are inactive would this still cause BGP to > advertise a route for them? > >> >> IOS classic/XE (for historical reasons) advertises all best paths >> from BGP table and to enforce it not to advertise what has not been >> installed into RIB/FIB there is knob called "suppress inactive". >> >> Cheers, R. >> >> >> >> > _
Re: [j-nsp] Juniper MX SCBE-MX-R
Yes the new SCB will work with 10.4 but with not it's full potential (confirmed from juniper yesterday) The Junos and the hardware development are weirdly off track Rakesh Shetty 808435 On Aug 11, 2011, at 5:03 AM, "Daniel Roesen" wrote: > On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: >> What I got from juniper is that the enhanced SCB will only be >> supported in 11.4 which is April 2012. > > We're hearing 11.4 is due end of 2011. > >> Even if you use the enhanced SCB today in your mx chassis you are >> only going to get 40G per SCB(same as the existing SCB),but with >> 11.4 you get 80G. > > Are you saying that SCBE would actually work with e.g. 10.4 (in 40G/slot > mode)? I would expect that JUNOS doesn't know the product code yet and > thus won't even power it up... > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX SCBE-MX-R
On Thu, Aug 11, 2011 at 07:16:19PM +1000, Julien Goodwin wrote: > On 08/11/11 19:00, Daniel Roesen wrote: > > On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: > >> What I got from juniper is that the enhanced SCB will only be > >> supported in 11.4 which is April 2012. > > > > We're hearing 11.4 is due end of 2011. > > At the rate Juniper is slipping these days... > > 11.2 finally came out last week, just over a month late. > > Juniper staff at various levels keep assuring me things are being put in > place to improve this, yet the trend is backwards. I'd rather they slip and put out well tested, stable code than to just release what they have on a specific time schedule. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX SCBE-MX-R
On 08/11/11 19:00, Daniel Roesen wrote: > On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: >> What I got from juniper is that the enhanced SCB will only be >> supported in 11.4 which is April 2012. > > We're hearing 11.4 is due end of 2011. At the rate Juniper is slipping these days... 11.2 finally came out last week, just over a month late. Juniper staff at various levels keep assuring me things are being put in place to improve this, yet the trend is backwards. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX SCBE-MX-R
On Wed, Aug 10, 2011 at 11:29:23PM -0400, Rakesh Shetty wrote: > What I got from juniper is that the enhanced SCB will only be > supported in 11.4 which is April 2012. We're hearing 11.4 is due end of 2011. > Even if you use the enhanced SCB today in your mx chassis you are > only going to get 40G per SCB(same as the existing SCB),but with > 11.4 you get 80G. Are you saying that SCBE would actually work with e.g. 10.4 (in 40G/slot mode)? I would expect that JUNOS doesn't know the product code yet and thus won't even power it up... Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
