I'm designing a network for a customer based on a standard L3VPN 2547bis, local OSPF instances, core IGP is OSPF and MP-BGP full mesh ibgp peering between the PE routes.
The problem is that the customer has constraints on the inter PE bandwidth over their CWDM and whilst need to have more than 1GE do not want to go to the logical 10GE interface.
How will / or will it work over multiple Gig-Eths. Brain storming with colleagues the following, if left as multiple GIG-Eths OSPF will load share across the paths, BGP will select one path, probably down to Site of Origin, which means that using LDP an MPLS path for the VPN will be set up across only one of the Gig-Ethernets? Or if we specified mult-path in BGP would it load-share and how would the traffic flows be mapped, label/next hop still one path and thus restricted to 1GE?
So we put it into a 802.3ad bundle, one IGP route, one BGP route, but how does the Label distribution work and LSP as again the micro-flow will be label outgoing physical interface? Also does it depend on the hashing algorithm for the bundle or a hashing algorithm on LSP?
Path setup is a signaling protocol to reserve the resources for a traffic flow and to establish the LSP for a traffic flow. Resource Reservation Protocol (RSVP) is used for this purpose and has been enhanced with TE extensions for carrying labels and building the LSP. An alternative to RSVP for MPLS TE is constrained routing with Label Distribution Protocol (LDP), but Cisco devices do not support this protocol.
load sharing with MPLS works pretty much the same as with plain IP. The underlying reason is, that in both cases (LFIB or FIB) CEF is in charge of forwarding traffic.
As you might know session-based load sharing is default with CEF. This is also true for MPLS label-switching, because a Cisco LSR will look behind the top label up to the TCPheader to achieve this. Do not misunderstand me, this sort of investigation is only done to allow session based load sharing even for customer sessions. It is working like a hash algorithm.
So with several pathes of equal metric to reach the BGP next hop from a PE, your IGP (and CEF) will do the load balancing as usual with BGP recursive lookup. There is no SoO involved for this. it will even load share traffic between two PEs, where all traffic is sent to a single BGP next hop.
In case you are using an etherchannel, load sharing happens on OSI layer2, so has nothing to do with MPLS at all. OSPF and MPLS will see only one interface - the channel. 802.3ad (?) will then be responsible for distribution of traffic accross the different physical links.
In any case it is most likely, that a single flow will be restricted to 1 GE. Keep this in mind when testing your final solution. You need a couple of sessions to "see" the combined bandwitdh.
Thanks for that, after some more discussions with some of my colleagues in the states we have decided to go with RSVP-TE, with each Gig-E protected by a back-up path between BGP speakers. If one link goes down we would have 3 equal cost IGP routes which would load share but only provide 3 GE bandwidth on the link and 1 longer via the second path so will have to play with some variances to emulate an unequal cost load-sharing (Like EIGRP).
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...