Re: [j-nsp] Loop-free Alternate Paths for IS-IS Routes
I'm wondering if anyone here has had any experience configuring the loop-free alternate paths for IS-IS in JUNOS, as described in the following drafts: - Internet draft draft-ietf-rtgwg-ipfrr-spec-base-12.txt, Basic Specification for IP Fast-Reroute: Loop-free Alternates - Internet draft draft-ietf-rtgwg-ipfrr-framework-06.txt, IP Fast Reroute Framework And covered in http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/jd0e 44501.html#jd0e44501. I'm looking for general guidance towards implementation, and any caveats which might be experienced in a typical deployment. It seems to me that using this, we can entirely get rid of Fast Reroute, or Link/Node protection within RSVP/MPLS, but perhaps my understanding is a bit off. We have tested this in our lab, and expect to deploy it eventually. It can *not* completely replace Fast Reroute/Link/Node protection, simply because you are dependent on the paths that your IGP can calculate (while MPLS Fast Reroute/Link/Node protection, obviously, can use other paths). What it means in practice is that LFA can not be expected to give you 100% fast reroute coverage for the same topology where MPLS Fast Reroute/Link/Node protection *can* give you full coverage. There is a command to show the coverage. The nice thing about LFA is that it is a completely local optimization, thus you are not dependent on other routers or protocol changes. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Loop-free Alternate Paths for IS-IS Routes
It's new enough you probably won't find too many people with deployment experience outside of lab work. It's something I looked at recently for OSPF and I think it's worth lab testing. It's definitely easier to just turn on OSPF/IS-IS/LDP and forget it than maintain RSVP LSPs. http://www.juniper.net/us/en/community/junos/live/091103/ is a presentation given by Juniper and may answer some of the questions you have. There are topologies where it may not be able to find backup paths where MPLS FRR can, I think that's the biggest drawback. There are ways to mitigate that concern with some static configuration, but you can't just turn it on and have it immediately replace RSVP.Another potential large caveat is lack of SRLG information, if you have multiple WDM circuits riding the same fiber span. Phil On Jan 13, 2010, at 1:48 AM, Stefan Fouant wrote: I'm wondering if anyone here has had any experience configuring the loop-free alternate paths for IS-IS in JUNOS, as described in the following drafts: - Internet draft draft-ietf-rtgwg-ipfrr-spec-base-12.txt, Basic Specification for IP Fast-Reroute: Loop-free Alternates - Internet draft draft-ietf-rtgwg-ipfrr-framework-06.txt, IP Fast Reroute Framework And covered in http://www.juniper.net/techpubs/software/junos/junos95/swconfig-routing/jd0e 44501.html#jd0e44501. I'm looking for general guidance towards implementation, and any caveats which might be experienced in a typical deployment. It seems to me that using this, we can entirely get rid of Fast Reroute, or Link/Node protection within RSVP/MPLS, but perhaps my understanding is a bit off. I'm also curious what experiences others have had with regards to troubleshooting backup paths that might be established as a result of a given failure. Thanks in advance! Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] BGP peer's
Hello experts, I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? Best regards. _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP peer's
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Onam Rubio Sent: Wednesday, January 13, 2010 10:27 AM I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? I'm not sure I fully understand your question. Are you saying you only want to advertise routes to the Primary BGP peer, and only advertise routes to the Secondary in the event of a failure of the Primary peer? Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP peer's
If you want to go the easy way, you can set a higher local preference to your main, and preprend your secondary one. My 2 cent. -- Gregory 2010/1/13 Onam Rubio onamru...@hotmail.com Hello experts, I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? Best regards. _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP peer's
On Wed, Jan 13, 2010 at 09:26:57AM -0600, Onam Rubio wrote: I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? You could set the NO_EXPORT BGP community on the prefixes you advertise to the local BGP peer. That will prevent them from re-advertising those to their upstreams. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP peer's
In my country are 5 ISP and to save internet traffic we make local BGP peering. Before this I have a BGP session for internet redundancy with one of the 5 ISP's. From: sfou...@shortestpathfirst.net To: onamru...@hotmail.com; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] BGP peer's Date: Wed, 13 Jan 2010 10:41:37 -0500 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Onam Rubio Sent: Wednesday, January 13, 2010 10:27 AM I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? I'm not sure I fully understand your question. Are you saying you only want to advertise routes to the Primary BGP peer, and only advertise routes to the Secondary in the event of a failure of the Primary peer? Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP peer's
Accepting the idea that you are having twice the same ISP on two different session but at the same location for redundancy purposes only, you definetly wants to have: 1. Local preference set to a higher value on your primary link. 2. Preprend 3 times with your own AS the IN/OUT paths This way, you have two links always up and running, but you always use the primary and if you preprend it 3 times on the OUT direction, it is really really unlikely that someone will prefer your worst . Additionaly, if your primary session (-link) goes down, the BGP session will flap and the second route will become the new *best* route (as the other one will simply disapear) and your traffic will flow thru your second session (-link) and this will revert when your main session (-link) will come back to working state. -- Gregory 2010/1/13 Onam Rubio onamru...@hotmail.com In my country are 5 ISP and to save internet traffic we make local BGP peering. Before this I have a BGP session for internet redundancy with one of the 5 ISP's. From: sfou...@shortestpathfirst.net To: onamru...@hotmail.com; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] BGP peer's Date: Wed, 13 Jan 2010 10:41:37 -0500 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Onam Rubio Sent: Wednesday, January 13, 2010 10:27 AM I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? I'm not sure I fully understand your question. Are you saying you only want to advertise routes to the Primary BGP peer, and only advertise routes to the Secondary in the event of a failure of the Primary peer? Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ 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] Loop-free Alternate Paths for IS-IS Routes
On Wed, Jan 13, 2010 at 01:48:11AM -0500, Stefan Fouant wrote: I'm wondering if anyone here has had any experience configuring the loop-free alternate paths for IS-IS in JUNOS, as described in the following drafts: I played with it ever-so-briefly on a couple routers. Our network is already running full MPLS with link+node protection, which I belive the documentation said it shouldn't hurt, but what we actually saw was that it caused traffic to be load balanced over both the active AND bypass LSPs with no distinction between them. This was obviously very bad, so we pulled it and haven't played with it since (this was 9.5R3). -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 resilience (VC vs 10GB cross-connect)
Hi Take the following scenario; Several racks - each with a pair of EX3200 switches (cross-connected) - each with separate L3 uplinks back to a pair of aggregation layer EX4200s (so, 1 from each rack switch), all running OSPF. I'm trying to understand if there are any drawbacks in making the two aggregation layer EX4200s a VC - or whether a simple L3 cross-connect using a LAG or the 10Gbps ports makes more sense, factoring in things like resilience, ease of upgrades etc. If you go on the basis the two EX4200s are two distinct switches with a L3 path between them, it is easy for me to visualise how the network will behave and (hopefully) understand how failover scenarios will play out. The obvious disadvantage of this is you are using up vital 10Gbps ports which could be used elsewhere, and it does seem non-sensical given the higher speed VC ports (+ the other VC advantages). I've read the VC Best practice guide and in all their examples, they have two sets of 2-switch VCs at the aggregation layer - which is making me wonder if a single VC (of two switches) and treated as one switch poses more of a risk than simply two distinct switches. I'm guessing if you have two links back from each rack - each to a different member of the VC, then the 'risks' are pretty much the same as having two separate switches? In terms of software upgrades - is it possible to upgrade one member at a time (as you would in a non-VC setup) so as to not interrupt connectivity from the access\rack switches? Are there any other situations\operations on a VC that would take both switches offline - further making it more sense to either have two switches, or two sets of 2 members VCs? Cheers Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 resilience (VC vs 10GB cross-connect)
On Wed, Jan 13, 2010 at 08:32:45PM +, Joe Hughes wrote: I've read the VC Best practice guide and in all their examples, they have two sets of 2-switch VCs at the aggregation layer - which is making me wonder if a single VC (of two switches) and treated as one switch poses more of a risk than simply two distinct switches. I'm guessing if you have two links back from each rack - each to a different member of the VC, then the 'risks' are pretty much the same as having two separate switches? The risks are the same in terms of physical failures, but having a single VC doesn't insulate you from control-plane failures. If you need to sustain a control plane failure and the extra interfaces are worth the cost, don't VC. If that's too expensive, or a control-plane failure isn't something you care about surviving, go with the VC. In terms of software upgrades - is it possible to upgrade one member at a time (as you would in a non-VC setup) so as to not interrupt connectivity from the access\rack switches? Nope - you have to upgrade the whole chassis and reboot it when you do an upgrade. This works quite smoothly. Are there any other situations\operations on a VC that would take both switches offline - further making it more sense to either have two switches, or two sets of 2 members VCs? JUNOS bugs - by far, the #1 source of downtime in our EX4200s VCs. If your aggregation layer is supposed to be HA, I'd keep the two apart. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Richard A Steenbergen Sent: Friday, January 08, 2010 3:21 PM To: Andy Davidson Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] JUNOS On Fri, Jan 08, 2010 at 02:56:32PM +, Andy Davidson wrote: On 8 Jan 2010, at 09:13, Richard A Steenbergen wrote: for example if you hit ctrl-c in the cli anywhere other than at the prompt it locks up the cli process :P Fantastic. :-) I've been trying to replicate this on 9.6R2.11 and can't do this at the edit prompt or the ---(more)--- pause - does this mean it's fixed in this version ? The more prompt is a good place to demo it, but it also happens in the middle of text output even if you | no-more, in the middle of load terminal in config mode, etc. I think it's only in 9.5R3, and is supposedly fixed in 9.5R4, haven't seen it in other versions. I was just able to replicate the bug using JUNOS 10.0r1.8. :( Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 resilience (VC vs 10GB cross-connect)
No, it is currently not possible to upgrade a VC stack one member at a time. I have told my Juniper contacts that this is an important feature for us but so far no luck! --- Martin Levin IT-strategy planning Mölndals stad Från:Joe Hughes joeyconcr...@gmail.com Till:juniper-nsp@puck.nether.net Datum:2010-01-13 21:45 Ärende:[j-nsp] EX4200 resilience (VC vs 10GB cross-connect) Hi Take the following scenario; Several racks - each with a pair of EX3200 switches (cross-connected) - each with separate L3 uplinks back to a pair of aggregation layer EX4200s (so, 1 from each rack switch), all running OSPF. I'm trying to understand if there are any drawbacks in making the two aggregation layer EX4200s a VC - or whether a simple L3 cross-connect using a LAG or the 10Gbps ports makes more sense, factoring in things like resilience, ease of upgrades etc. If you go on the basis the two EX4200s are two distinct switches with a L3 path between them, it is easy for me to visualise how the network will behave and (hopefully) understand how failover scenarios will play out. The obvious disadvantage of this is you are using up vital 10Gbps ports which could be used elsewhere, and it does seem non-sensical given the higher speed VC ports (+ the other VC advantages). I've read the VC Best practice guide and in all their examples, they have two sets of 2-switch VCs at the aggregation layer - which is making me wonder if a single VC (of two switches) and treated as one switch poses more of a risk than simply two distinct switches. I'm guessing if you have two links back from each rack - each to a different member of the VC, then the 'risks' are pretty much the same as having two separate switches? In terms of software upgrades - is it possible to upgrade one member at a time (as you would in a non-VC setup) so as to not interrupt connectivity from the access\rack switches? Are there any other situations\operations on a VC that would take both switches offline - further making it more sense to either have two switches, or two sets of 2 members VCs? Cheers Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 resilience (VC vs 10GB cross-connect)
On Jan 13, 2010, at 12:55 PM, Ross Vandegrift wrote: In terms of software upgrades - is it possible to upgrade one member at a time (as you would in a non-VC setup) so as to not interrupt connectivity from the access\rack switches? Nope - you have to upgrade the whole chassis and reboot it when you do an upgrade. This works quite smoothly. It isn't possible to upgrade one member at a time when it's live, correct. However when you plug in a new member to your VC that isn't running the correct version of code, you can upgrade that one from the existing VC on the fly with no disruptions. Are there any other situations\operations on a VC that would take both switches offline - further making it more sense to either have two switches, or two sets of 2 members VCs? JUNOS bugs - by far, the #1 source of downtime in our EX4200s VCs. If your aggregation layer is supposed to be HA, I'd keep the two apart. I have a two member VC as an agg layer. It's been up and running for over 6 months with zero issues in production. As Ross says, make sure your JUNOS is recommended and stable. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX, HP server NIC teaming
Hi again all,
On Tue, Jan 12, 2010 at 11:30 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:
I'm operating in a bit of an information vacuum here, but I'm trying
to help out some colleagues with a server NIC teaming / EX switch
problem.
Here's an update:
My colleagues revisited the problem last night and disabling IGMP
snooping has 'fixed' the problem.
My question is, why is the switch doing anything but flood non-IP L2
multicasts and why is this traffic subject to the rules of IGMP
snooping? :-)
(The NIC team member interfaces won't be sending IGMP joins -- it's
not IP multicast.)
The previously referenced PR (PR/492704) sounded promising -- does
anyone have any insight into how the fix for that has been/is being
implemented?
If disabling IGMP snooping is indeed the 'best' fix, what does the
list consider the most elegant / least intrusive way of disabling it?
They disabled it for the whole VLAN (set protocols igmp-snooping vlan
server disable) but I'm guessing this means IP multicast traffic will
be flooded to all stations in the VLAN whether they're interested in
the traffic, or not.
The second link (PDF) below seems to indicate IGMP snooping can be
disabled explicitly on individual interfaces like so:
protocols {
igmp {
interface interface-name;
disable;
}
}
Other useful references:
http://kb.juniper.net/index?page=contentid=KB15316actp=LIST
http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/8010061-EN.PDF
cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper EX, HP server NIC teaming
Sorry for the followup on my own post, but..
On Thu, Jan 14, 2010 at 10:59 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote:
The second link (PDF) below seems to indicate IGMP snooping can be
disabled explicitly on individual interfaces like so:
protocols {
igmp {
interface interface-name;
disable;
}
}
I didn't read this properly. This is for IGMP, not IGMP snooping.
cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 802.3ad Question
Hello Mark: I am coming back to this question , i would apreciate your help again ... in the example you mention you said that your bundle is using 3xGE and you have a pretty fair load balance 1:1:1 do you know if there is any requirement about having pair numbers or power of 2 amount of links in a bundle to get a good load balance ? I guess that should depend on the hashing algorithm but of course there is no much info about how it works we are interested to have 6xGE in a bundle ... so , will we get 6Gbps of real throuhput ...? BR Alexi On Mon, Nov 2, 2009 at 1:29 PM, Mark Tinka mti...@globaltransit.net wrote: On Tuesday 03 November 2009 12:25:20 am alexi wrote: Great , thanks Mark ... what JUNOS are you using ? , I´ve heard that it has some issues with load balancing in 8.0 We're running the evil 9.3R2.8 on this box, but will be moving it to 9.5R4 in January 2010. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 802.3ad Question
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of alexi Sent: Wednesday, January 13, 2010 11:45 PM To: mti...@globaltransit.net Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] 802.3ad Question Hello Mark: I am coming back to this question , i would apreciate your help again ... in the example you mention you said that your bundle is using 3xGE and you have a pretty fair load balance 1:1:1 do you know if there is any requirement about having pair numbers or power of 2 amount of links in a bundle to get a good load balance ? I guess that should depend on the hashing algorithm but of course there is no much info about how it works we are interested to have 6xGE in a bundle ... so , will we get 6Gbps of real throuhput ...? The hashing algorithm Juniper uses is proprietary so there isn't much useable information out that, but in my experience I've never seen anything along the lines which would require a LAG to be comprised of multiples of 2 links to get an even load balance. The load balancing tends to get a more even distribution when you've got a large number of flows. Assuming a large number of flows, you should be able to get an even balance across the component links within the 802.3ad LAG bundle. You might also want to consider enabling Layer 4 hashing to get even more granular distribution, if the source and destinations are sparse, but you're using a large number of source and destination ports. HTHs. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] [Fwd: Re: BGP peer's]
Hi, My understanding is that your international bandwidth cost you more than local peers. And local peering is free by exchanging your routes privately using private peer. What I have done in my region for : [we have local internet exchange which is free] A. Outgoing Traffic : - Receive All Local Route Set local local preference while receiving all route from upstream ISP or - Just Receive All Local Route Ask your International ISP to Inject a default route by BGP This would give more space on your memory a simple config. B. Incoming Traffic : - Advertise longer prefix to your local exchange / private peers And ask them to be very careful not to re-advertise your route unless for local exchange route only. Or using community which both of you set it up. - Advertise same prefixes with prepending prefixes to your ISP Upstream Please be careful if Internet routes local routes exchanging in one router, wrong configuration might cause your router to be used as 'unwanted' traffic transit. rgs a. rahman isnaini rangkayo sutan Gregory Agerba wrote: Accepting the idea that you are having twice the same ISP on two different session but at the same location for redundancy purposes only, you definetly wants to have: 1. Local preference set to a higher value on your primary link. 2. Preprend 3 times with your own AS the IN/OUT paths This way, you have two links always up and running, but you always use the primary and if you preprend it 3 times on the OUT direction, it is really really unlikely that someone will prefer your worst . Additionaly, if your primary session (-link) goes down, the BGP session will flap and the second route will become the new *best* route (as the other one will simply disapear) and your traffic will flow thru your second session (-link) and this will revert when your main session (-link) will come back to working state. -- Gregory 2010/1/13 Onam Rubio onamru...@hotmail.com In my country are 5 ISP and to save internet traffic we make local BGP peering. Before this I have a BGP session for internet redundancy with one of the 5 ISP's. From: sfou...@shortestpathfirst.net To: onamru...@hotmail.com; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] BGP peer's Date: Wed, 13 Jan 2010 10:41:37 -0500 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Onam Rubio Sent: Wednesday, January 13, 2010 10:27 AM I have 2 BGP session with the same ISP but one of this one is for the local BGP to save internet traffic, and the other one is for internet redundancy I need to have but session running but my advertisement goes for both of them to internet. Manually y can reject the networks to my uptream providers, Is there a way to do it automatically? I'm not sure I fully understand your question. Are you saying you only want to advertise routes to the Primary BGP peer, and only advertise routes to the Secondary in the event of a failure of the Primary peer? Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ 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 !DSPAM:4b4e01e7285835677216483! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 802.3ad Question
Hello Stefan: Thanks for your answer, this was a costumer question that i think camed from the way how load balancing in Cisco using Ether Channel was done , in that case you had a fixed number of 8 values so the hashing algorithm (using the source ip , mac ... etc) gives you one of those fixed values. So each one of the links in a bundle was identified with one or several of those values ... so in this case you can only have perfect load balance if you are using 2, 4 or 8 links ... any other combination gives you a not even distribution ... this is explained here : http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml I don´t know how this goes in 802.3ad in Juniper ...what do you think ? , have you ever seen examples of good load balancing using 3 , 5 or 6 links in a bundle ? BR Alexi On Thu, Jan 14, 2010 at 2:04 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of alexi Sent: Wednesday, January 13, 2010 11:45 PM To: mti...@globaltransit.net Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] 802.3ad Question Hello Mark: I am coming back to this question , i would apreciate your help again ... in the example you mention you said that your bundle is using 3xGE and you have a pretty fair load balance 1:1:1 do you know if there is any requirement about having pair numbers or power of 2 amount of links in a bundle to get a good load balance ? I guess that should depend on the hashing algorithm but of course there is no much info about how it works we are interested to have 6xGE in a bundle ... so , will we get 6Gbps of real throuhput ...? The hashing algorithm Juniper uses is proprietary so there isn't much useable information out that, but in my experience I've never seen anything along the lines which would require a LAG to be comprised of multiples of 2 links to get an even load balance. The load balancing tends to get a more even distribution when you've got a large number of flows. Assuming a large number of flows, you should be able to get an even balance across the component links within the 802.3ad LAG bundle. You might also want to consider enabling Layer 4 hashing to get even more granular distribution, if the source and destinations are sparse, but you're using a large number of source and destination ports. HTHs. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 802.3ad Question
I had 2x T320 configured each with a bundle of 3x 10GE and traffic was split correctly 33% 33% 33% These has been in place for several years and across several Junos releases. On Thu, 2010-01-14 at 02:57 -0300, alexi wrote: Hello Stefan: Thanks for your answer, this was a costumer question that i think camed from the way how load balancing in Cisco using Ether Channel was done , in that case you had a fixed number of 8 values so the hashing algorithm (using the source ip , mac ... etc) gives you one of those fixed values. So each one of the links in a bundle was identified with one or several of those values ... so in this case you can only have perfect load balance if you are using 2, 4 or 8 links ... any other combination gives you a not even distribution ... this is explained here : http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml I don´t know how this goes in 802.3ad in Juniper ...what do you think ? , have you ever seen examples of good load balancing using 3 , 5 or 6 links in a bundle ? BR Alexi On Thu, Jan 14, 2010 at 2:04 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of alexi Sent: Wednesday, January 13, 2010 11:45 PM To: mti...@globaltransit.net Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] 802.3ad Question Hello Mark: I am coming back to this question , i would apreciate your help again ... in the example you mention you said that your bundle is using 3xGE and you have a pretty fair load balance 1:1:1 do you know if there is any requirement about having pair numbers or power of 2 amount of links in a bundle to get a good load balance ? I guess that should depend on the hashing algorithm but of course there is no much info about how it works we are interested to have 6xGE in a bundle ... so , will we get 6Gbps of real throuhput ...? The hashing algorithm Juniper uses is proprietary so there isn't much useable information out that, but in my experience I've never seen anything along the lines which would require a LAG to be comprised of multiples of 2 links to get an even load balance. The load balancing tends to get a more even distribution when you've got a large number of flows. Assuming a large number of flows, you should be able to get an even balance across the component links within the 802.3ad LAG bundle. You might also want to consider enabling Layer 4 hashing to get even more granular distribution, if the source and destinations are sparse, but you're using a large number of source and destination ports. HTHs. Stefan Fouant, CISSP, JNCIE-M/T www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ 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
