OSPF increase bandwidth with load-balancingCisco ASA Routing IssueCisco ASA RRI and OSPF redistributionSplit OSPF Area 0 Behavior - What happens?OSPF NSSA load balancingConnecting two OSPF sites both directly and via MPLSTrouble inserting static route into OSPF ASBROSPF Routes not exportingMulti Area OSPF and loopRouter Ethernet port ip no accessible from clientsOSPF NSSA - Type 7 LSA Metric Changes Unexpectedly

Were any of the books mentioned in this scene from the movie Hackers real?

Can only the master initiate communication in SPI whereas in I2C the slave can also initiate the communication?

Can multiple outlets be directly attached to a single breaker?

Is there an academic word that means "to split hairs over"?

Why doesn't Iron Man's action affect this person in Endgame?

Why are solar panels kept tilted?

Mark command as obsolete

Are there any sonatas with only two sections?

Motorola 6845 and bitwise graphics

Is 12 minutes connection in Bristol Temple Meads long enough?

Why weren't the bells paid heed to in S8E5?

Do Grothendieck universes matter for an algebraic geometer?

Wireless headphones interfere with Wi-Fi signal on laptop

How might a landlocked lake become a complete ecosystem?

Holding rent money for my friend which amounts to over $10k?

Unexpected Netflix account registered to my Gmail address - any way it could be a hack attempt?

Ansible: use group_vars directly without with_items

Uh oh, the propeller fell off

Is this possible when it comes to the relations of P, NP, NP-Hard and NP-Complete?

Is it wrong to omit object pronouns in these sentences?

Why does the headset man not get on the tractor?

Why didn't the Avengers use this object earlier?

Why did the metro bus stop at each railway crossing, despite no warning indicating a train was coming?

Could there be a material that inverts the colours seen through it?



OSPF increase bandwidth with load-balancing


Cisco ASA Routing IssueCisco ASA RRI and OSPF redistributionSplit OSPF Area 0 Behavior - What happens?OSPF NSSA load balancingConnecting two OSPF sites both directly and via MPLSTrouble inserting static route into OSPF ASBROSPF Routes not exportingMulti Area OSPF and loopRouter Ethernet port ip no accessible from clientsOSPF NSSA - Type 7 LSA Metric Changes Unexpectedly













1















This is my current setup where i have 40Gbps links between all 4 switches running OSPF using L3 links between them but now i want to double my bandwidth between switches so i am planning to add (dotted links) L3 links and let OSPF load-balance traffic on them, Do you think is there any issue to doing that or this is going to be just fine? ( want second set of eyes )



enter image description here



This is what my ospf config looks on all 4 switches.



interface Ethernet2/10
no switchport
mtu 9216
ip address 192.168.250.9/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown

interface Ethernet2/11
no switchport
mtu 9216
ip address 192.168.250.13/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown









share|improve this question
























  • Be sure you upgrade the links between SW1-2 and SW 3-4

    – Ron Trunk
    7 hours ago











  • Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

    – Satish
    7 hours ago











  • As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

    – Ron Maupin
    3 hours ago











  • @RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

    – Marc 'netztier' Luethi
    3 hours ago











  • @Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

    – Ron Maupin
    3 hours ago















1















This is my current setup where i have 40Gbps links between all 4 switches running OSPF using L3 links between them but now i want to double my bandwidth between switches so i am planning to add (dotted links) L3 links and let OSPF load-balance traffic on them, Do you think is there any issue to doing that or this is going to be just fine? ( want second set of eyes )



enter image description here



This is what my ospf config looks on all 4 switches.



interface Ethernet2/10
no switchport
mtu 9216
ip address 192.168.250.9/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown

interface Ethernet2/11
no switchport
mtu 9216
ip address 192.168.250.13/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown









share|improve this question
























  • Be sure you upgrade the links between SW1-2 and SW 3-4

    – Ron Trunk
    7 hours ago











  • Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

    – Satish
    7 hours ago











  • As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

    – Ron Maupin
    3 hours ago











  • @RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

    – Marc 'netztier' Luethi
    3 hours ago











  • @Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

    – Ron Maupin
    3 hours ago













1












1








1








This is my current setup where i have 40Gbps links between all 4 switches running OSPF using L3 links between them but now i want to double my bandwidth between switches so i am planning to add (dotted links) L3 links and let OSPF load-balance traffic on them, Do you think is there any issue to doing that or this is going to be just fine? ( want second set of eyes )



enter image description here



This is what my ospf config looks on all 4 switches.



interface Ethernet2/10
no switchport
mtu 9216
ip address 192.168.250.9/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown

interface Ethernet2/11
no switchport
mtu 9216
ip address 192.168.250.13/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown









share|improve this question
















This is my current setup where i have 40Gbps links between all 4 switches running OSPF using L3 links between them but now i want to double my bandwidth between switches so i am planning to add (dotted links) L3 links and let OSPF load-balance traffic on them, Do you think is there any issue to doing that or this is going to be just fine? ( want second set of eyes )



enter image description here



This is what my ospf config looks on all 4 switches.



interface Ethernet2/10
no switchport
mtu 9216
ip address 192.168.250.9/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown

interface Ethernet2/11
no switchport
mtu 9216
ip address 192.168.250.13/30
no ip ospf passive-interface
ip router ospf 100 area 0.0.0.0
no shutdown






cisco switch ospf






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 4 hours ago









Zac67

34.8k22572




34.8k22572










asked 7 hours ago









SatishSatish

1,98112563




1,98112563












  • Be sure you upgrade the links between SW1-2 and SW 3-4

    – Ron Trunk
    7 hours ago











  • Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

    – Satish
    7 hours ago











  • As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

    – Ron Maupin
    3 hours ago











  • @RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

    – Marc 'netztier' Luethi
    3 hours ago











  • @Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

    – Ron Maupin
    3 hours ago

















  • Be sure you upgrade the links between SW1-2 and SW 3-4

    – Ron Trunk
    7 hours ago











  • Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

    – Satish
    7 hours ago











  • As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

    – Ron Maupin
    3 hours ago











  • @RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

    – Marc 'netztier' Luethi
    3 hours ago











  • @Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

    – Ron Maupin
    3 hours ago
















Be sure you upgrade the links between SW1-2 and SW 3-4

– Ron Trunk
7 hours ago





Be sure you upgrade the links between SW1-2 and SW 3-4

– Ron Trunk
7 hours ago













Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

– Satish
7 hours ago





Oh yes.. forgot to add that in diagram. good catch! but otherwise do you see any issue to just bring up L3 Link and handover to OSFP ?

– Satish
7 hours ago













As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

– Ron Maupin
3 hours ago





As I recall, you do a lot with VoIP. You could end up with a lot of out-of-order packets that would absolutely kill VoIP.

– Ron Maupin
3 hours ago













@RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

– Marc 'netztier' Luethi
3 hours ago





@RonMaupin I would argue that CEF/ECMP handles "flows" pretty well and will prevent out-of-order delivery of VoIP streams nicely, by assigning a given flow to the same egress interface consistently.

– Marc 'netztier' Luethi
3 hours ago













@Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

– Ron Maupin
3 hours ago





@Marc'netztier'Luethi, that really depends. Routing protocol per-packet load balancing can really mess up real-time protocols. I was actually thinking of your layer-3 channel suggestion because that will certainly provide per-flow balancing.

– Ron Maupin
3 hours ago










2 Answers
2






active

oldest

votes


















2














As these are Point-to-Point links, I would consider using the outage to configure each /30 interface with ip ospf network point-to-point. (New and existing links). This reduces the hello and dead timers. This configuration also reduces the need to negotiate a DR and BDR.



Lastly, I would verify the OSPF neighbor states and routing tables, before and after the cutover. You should see ECMP routes after the cutovers and the appropriate neighborships.






share|improve this answer






























    1














    There's two ways to do that.



    • your proposed way, by adding a second link with its own /30 or /31,
      making sure that OSPF installs multiple equal cost routes in the
      routing table, and let CEF's ECMP (EqualCostMultiPath) forwaring handle the
      packet pushing and the distribution of flows across the set
      of available links. CEF/ECMP uses a different load sharing logic than Port-Channel, and can handle uneven numbers of links a lot better than Port-Channels do. See Ivan Pepelniak's Blog post for reference.


    • use L3 Port-Channels: move the IP and routing configuration to a port-channel object (which does not have the "switchport" command), and join the given interfaces to that object. Let Port-Channel load distribution logic handle the distribution of flows.


    Your proposed idea is more L3/routing oriented, scaling it might have some issues: You will use lot of /30 or /31s. You can scale in odd numbers, but you'll have to configure a new link and possibly subnet for every scaling step (or go ip unnumbered). ules for Port-Channels apply (e.g. keep number of links in powers of 2).



    On the other hand, L3 Port-Channels don't need more IP subnets and don't actually touch your given routing configuration logic. Port-Channel is a bit more "Nexus style", as the whole history of Nexus switches is based on the VPC concept (which does not quite apply here, I'll admit). Scaling of additional links is easier - just add two more, without touching any IP or routing configuration.



    ADDON-1: And oh yes, by all means DO follow TDurden's advice to configure point-to-point on the ... ehm.. point-to-point links (really bad pun, I'll admit)



    CAVEAT-1: When using port-channels ensure that you select a load-balancing strategy that fits the expected communication patterns for the given link. When connecting a router to a router (essentially only two MAC addresses on the link), then "Src/Dst MAC" might not have the desired results... For reference, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.2(x)



    ADDON-2:
    On Nexus 9000, with ECMP/CEF, the load-sharing algorithm can be configured to include L4 properties: ip load-sharing address source-destination port source-destination See Configuring Load-Sharing in the Unicast FIB from the Unicast Routing configuration gude.



    CAVEAT-2 When using L3-Port-Channels, keep an eye on the "bandwidth" property of the port-channel interface when a member link goes down. Depending on hardware/software platform, the bandwidth of the port-channel interface might get reduced accordingly, and OSPF might react to that by increasing the given link's cost. This might have (un)intended consequences for the topology.






    share|improve this answer

























      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "496"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f59114%2fospf-increase-bandwidth-with-load-balancing%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      2














      As these are Point-to-Point links, I would consider using the outage to configure each /30 interface with ip ospf network point-to-point. (New and existing links). This reduces the hello and dead timers. This configuration also reduces the need to negotiate a DR and BDR.



      Lastly, I would verify the OSPF neighbor states and routing tables, before and after the cutover. You should see ECMP routes after the cutovers and the appropriate neighborships.






      share|improve this answer



























        2














        As these are Point-to-Point links, I would consider using the outage to configure each /30 interface with ip ospf network point-to-point. (New and existing links). This reduces the hello and dead timers. This configuration also reduces the need to negotiate a DR and BDR.



        Lastly, I would verify the OSPF neighbor states and routing tables, before and after the cutover. You should see ECMP routes after the cutovers and the appropriate neighborships.






        share|improve this answer

























          2












          2








          2







          As these are Point-to-Point links, I would consider using the outage to configure each /30 interface with ip ospf network point-to-point. (New and existing links). This reduces the hello and dead timers. This configuration also reduces the need to negotiate a DR and BDR.



          Lastly, I would verify the OSPF neighbor states and routing tables, before and after the cutover. You should see ECMP routes after the cutovers and the appropriate neighborships.






          share|improve this answer













          As these are Point-to-Point links, I would consider using the outage to configure each /30 interface with ip ospf network point-to-point. (New and existing links). This reduces the hello and dead timers. This configuration also reduces the need to negotiate a DR and BDR.



          Lastly, I would verify the OSPF neighbor states and routing tables, before and after the cutover. You should see ECMP routes after the cutovers and the appropriate neighborships.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 3 hours ago









          TDurdenTDurden

          1,0991313




          1,0991313





















              1














              There's two ways to do that.



              • your proposed way, by adding a second link with its own /30 or /31,
                making sure that OSPF installs multiple equal cost routes in the
                routing table, and let CEF's ECMP (EqualCostMultiPath) forwaring handle the
                packet pushing and the distribution of flows across the set
                of available links. CEF/ECMP uses a different load sharing logic than Port-Channel, and can handle uneven numbers of links a lot better than Port-Channels do. See Ivan Pepelniak's Blog post for reference.


              • use L3 Port-Channels: move the IP and routing configuration to a port-channel object (which does not have the "switchport" command), and join the given interfaces to that object. Let Port-Channel load distribution logic handle the distribution of flows.


              Your proposed idea is more L3/routing oriented, scaling it might have some issues: You will use lot of /30 or /31s. You can scale in odd numbers, but you'll have to configure a new link and possibly subnet for every scaling step (or go ip unnumbered). ules for Port-Channels apply (e.g. keep number of links in powers of 2).



              On the other hand, L3 Port-Channels don't need more IP subnets and don't actually touch your given routing configuration logic. Port-Channel is a bit more "Nexus style", as the whole history of Nexus switches is based on the VPC concept (which does not quite apply here, I'll admit). Scaling of additional links is easier - just add two more, without touching any IP or routing configuration.



              ADDON-1: And oh yes, by all means DO follow TDurden's advice to configure point-to-point on the ... ehm.. point-to-point links (really bad pun, I'll admit)



              CAVEAT-1: When using port-channels ensure that you select a load-balancing strategy that fits the expected communication patterns for the given link. When connecting a router to a router (essentially only two MAC addresses on the link), then "Src/Dst MAC" might not have the desired results... For reference, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.2(x)



              ADDON-2:
              On Nexus 9000, with ECMP/CEF, the load-sharing algorithm can be configured to include L4 properties: ip load-sharing address source-destination port source-destination See Configuring Load-Sharing in the Unicast FIB from the Unicast Routing configuration gude.



              CAVEAT-2 When using L3-Port-Channels, keep an eye on the "bandwidth" property of the port-channel interface when a member link goes down. Depending on hardware/software platform, the bandwidth of the port-channel interface might get reduced accordingly, and OSPF might react to that by increasing the given link's cost. This might have (un)intended consequences for the topology.






              share|improve this answer





























                1














                There's two ways to do that.



                • your proposed way, by adding a second link with its own /30 or /31,
                  making sure that OSPF installs multiple equal cost routes in the
                  routing table, and let CEF's ECMP (EqualCostMultiPath) forwaring handle the
                  packet pushing and the distribution of flows across the set
                  of available links. CEF/ECMP uses a different load sharing logic than Port-Channel, and can handle uneven numbers of links a lot better than Port-Channels do. See Ivan Pepelniak's Blog post for reference.


                • use L3 Port-Channels: move the IP and routing configuration to a port-channel object (which does not have the "switchport" command), and join the given interfaces to that object. Let Port-Channel load distribution logic handle the distribution of flows.


                Your proposed idea is more L3/routing oriented, scaling it might have some issues: You will use lot of /30 or /31s. You can scale in odd numbers, but you'll have to configure a new link and possibly subnet for every scaling step (or go ip unnumbered). ules for Port-Channels apply (e.g. keep number of links in powers of 2).



                On the other hand, L3 Port-Channels don't need more IP subnets and don't actually touch your given routing configuration logic. Port-Channel is a bit more "Nexus style", as the whole history of Nexus switches is based on the VPC concept (which does not quite apply here, I'll admit). Scaling of additional links is easier - just add two more, without touching any IP or routing configuration.



                ADDON-1: And oh yes, by all means DO follow TDurden's advice to configure point-to-point on the ... ehm.. point-to-point links (really bad pun, I'll admit)



                CAVEAT-1: When using port-channels ensure that you select a load-balancing strategy that fits the expected communication patterns for the given link. When connecting a router to a router (essentially only two MAC addresses on the link), then "Src/Dst MAC" might not have the desired results... For reference, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.2(x)



                ADDON-2:
                On Nexus 9000, with ECMP/CEF, the load-sharing algorithm can be configured to include L4 properties: ip load-sharing address source-destination port source-destination See Configuring Load-Sharing in the Unicast FIB from the Unicast Routing configuration gude.



                CAVEAT-2 When using L3-Port-Channels, keep an eye on the "bandwidth" property of the port-channel interface when a member link goes down. Depending on hardware/software platform, the bandwidth of the port-channel interface might get reduced accordingly, and OSPF might react to that by increasing the given link's cost. This might have (un)intended consequences for the topology.






                share|improve this answer



























                  1












                  1








                  1







                  There's two ways to do that.



                  • your proposed way, by adding a second link with its own /30 or /31,
                    making sure that OSPF installs multiple equal cost routes in the
                    routing table, and let CEF's ECMP (EqualCostMultiPath) forwaring handle the
                    packet pushing and the distribution of flows across the set
                    of available links. CEF/ECMP uses a different load sharing logic than Port-Channel, and can handle uneven numbers of links a lot better than Port-Channels do. See Ivan Pepelniak's Blog post for reference.


                  • use L3 Port-Channels: move the IP and routing configuration to a port-channel object (which does not have the "switchport" command), and join the given interfaces to that object. Let Port-Channel load distribution logic handle the distribution of flows.


                  Your proposed idea is more L3/routing oriented, scaling it might have some issues: You will use lot of /30 or /31s. You can scale in odd numbers, but you'll have to configure a new link and possibly subnet for every scaling step (or go ip unnumbered). ules for Port-Channels apply (e.g. keep number of links in powers of 2).



                  On the other hand, L3 Port-Channels don't need more IP subnets and don't actually touch your given routing configuration logic. Port-Channel is a bit more "Nexus style", as the whole history of Nexus switches is based on the VPC concept (which does not quite apply here, I'll admit). Scaling of additional links is easier - just add two more, without touching any IP or routing configuration.



                  ADDON-1: And oh yes, by all means DO follow TDurden's advice to configure point-to-point on the ... ehm.. point-to-point links (really bad pun, I'll admit)



                  CAVEAT-1: When using port-channels ensure that you select a load-balancing strategy that fits the expected communication patterns for the given link. When connecting a router to a router (essentially only two MAC addresses on the link), then "Src/Dst MAC" might not have the desired results... For reference, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.2(x)



                  ADDON-2:
                  On Nexus 9000, with ECMP/CEF, the load-sharing algorithm can be configured to include L4 properties: ip load-sharing address source-destination port source-destination See Configuring Load-Sharing in the Unicast FIB from the Unicast Routing configuration gude.



                  CAVEAT-2 When using L3-Port-Channels, keep an eye on the "bandwidth" property of the port-channel interface when a member link goes down. Depending on hardware/software platform, the bandwidth of the port-channel interface might get reduced accordingly, and OSPF might react to that by increasing the given link's cost. This might have (un)intended consequences for the topology.






                  share|improve this answer















                  There's two ways to do that.



                  • your proposed way, by adding a second link with its own /30 or /31,
                    making sure that OSPF installs multiple equal cost routes in the
                    routing table, and let CEF's ECMP (EqualCostMultiPath) forwaring handle the
                    packet pushing and the distribution of flows across the set
                    of available links. CEF/ECMP uses a different load sharing logic than Port-Channel, and can handle uneven numbers of links a lot better than Port-Channels do. See Ivan Pepelniak's Blog post for reference.


                  • use L3 Port-Channels: move the IP and routing configuration to a port-channel object (which does not have the "switchport" command), and join the given interfaces to that object. Let Port-Channel load distribution logic handle the distribution of flows.


                  Your proposed idea is more L3/routing oriented, scaling it might have some issues: You will use lot of /30 or /31s. You can scale in odd numbers, but you'll have to configure a new link and possibly subnet for every scaling step (or go ip unnumbered). ules for Port-Channels apply (e.g. keep number of links in powers of 2).



                  On the other hand, L3 Port-Channels don't need more IP subnets and don't actually touch your given routing configuration logic. Port-Channel is a bit more "Nexus style", as the whole history of Nexus switches is based on the VPC concept (which does not quite apply here, I'll admit). Scaling of additional links is easier - just add two more, without touching any IP or routing configuration.



                  ADDON-1: And oh yes, by all means DO follow TDurden's advice to configure point-to-point on the ... ehm.. point-to-point links (really bad pun, I'll admit)



                  CAVEAT-1: When using port-channels ensure that you select a load-balancing strategy that fits the expected communication patterns for the given link. When connecting a router to a router (essentially only two MAC addresses on the link), then "Src/Dst MAC" might not have the desired results... For reference, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide, Release 9.2(x)



                  ADDON-2:
                  On Nexus 9000, with ECMP/CEF, the load-sharing algorithm can be configured to include L4 properties: ip load-sharing address source-destination port source-destination See Configuring Load-Sharing in the Unicast FIB from the Unicast Routing configuration gude.



                  CAVEAT-2 When using L3-Port-Channels, keep an eye on the "bandwidth" property of the port-channel interface when a member link goes down. Depending on hardware/software platform, the bandwidth of the port-channel interface might get reduced accordingly, and OSPF might react to that by increasing the given link's cost. This might have (un)intended consequences for the topology.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 2 hours ago

























                  answered 3 hours ago









                  Marc 'netztier' LuethiMarc 'netztier' Luethi

                  4,7961420




                  4,7961420



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Network Engineering Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f59114%2fospf-increase-bandwidth-with-load-balancing%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Log på Navigationsmenu

                      Wonderful Copenhagen (sang) Eksterne henvisninger | NavigationsmenurSide på frankloesser.comWonderful Copenhagen

                      Detroit Tigers Spis treści Historia | Skład zespołu | Sukcesy | Członkowie Baseball Hall of Fame | Zastrzeżone numery | Przypisy | Menu nawigacyjneEncyclopedia of Detroit - Detroit TigersTigers Stadium, Detroit, MITigers Timeline 1900sDetroit Tigers Team History & EncyclopediaTigers Timeline 1910s1935 World Series1945 World Series1945 World Series1984 World SeriesComerica Park, Detroit, MI2006 World Series2012 World SeriesDetroit Tigers 40-Man RosterDetroit Tigers Coaching StaffTigers Hall of FamersTigers Retired Numberse