Routing

last person joined: 3 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Traffic Engineering Options and Design

     
    Posted 07-16-2014 09:53

    I am trying to learn much more about MPLS than I currently know and I've read through the MPLS Day One booklet a couple of times, but I've got at least one nagging question.  I understand the difference between the different MPLS traffic-engineering options (bgp-igp, mpls-forwarding, etc.), but I'd like to know whether it's required to match throughout the entire domain or if it can be configured "safely" on a node-by-node basis.  In other words, let's say I have 'mpls-forwarding' configured on my P routers and 'bgp-igp' configured on my PE routers.  What problems might I expect to run into, if any?



  • 2.  RE: Traffic Engineering Options and Design

    Posted 07-16-2014 10:53

    Hello there,

     


    @evt wrote:

      In other words, let's say I have 'mpls-forwarding' configured on my P routers and 'bgp-igp' configured on my PE routers.  What problems might I expect to run into, if any?


    This is very good example.

    Let's say You have PE1, PE2 and PE3.

    IGP is OSPFv2.

    PE1 has 1 RSVP LSP to PE3 lo0.0. PE1 has "bgp-igp" knob enabled.

    PE2 has 1 RSVP LSP to PE3 lo0.0.  PE2 has "mpls-forwarding" knob enabled.

    PE1 and PE2 are in AS 65535 and are both eBGP peering with ASBR100.

    ASBR100 is in AS 65536.

     

    Now, if You want to announce PE3 lo0.0 IP address to ASBR100 from both PE1 and PE2, You would construct Your eBGP export policy differently:

    - on PE1, You will match on RSVP route because RSVP route will be active in inet.0 . RSVP does not support tags so You are restricted in Your match conditions.

    - Additionally, if You have Fast Reroute enabled on PE1 LSP, when FRR triggers, RSVP route metric does not change so if You want to set BGP MED outbound based on RSVP route metric, the MED will likely stay equal the shortest IGP path metric.

    - on PE2, You will match on OSPF route because OSPF route will be used for routing, RSVP route will be used only for forwarding. OSPFv2 supports tags so You have wider range of match conditions available.

    - taking same BGP MED example above and applying to PE2, when OSPF route metric changes, the BGP MED will change immediately.

    I am sure others will also come up  with more examples.

    HTH

    Thanks
    Alex



  • 3.  RE: Traffic Engineering Options and Design

     
    Posted 07-17-2014 07:34

    Thanks for the response, that's an interesting scenario.  After reading some more, it seems to me that it's possible to have every router in the domain configured differently, but it's not advised because traffic would be handled differently on every router along the path of a given 'flow'.  That would certainly make for a troubleshooting nightmare.

     

    I've got another question about this - are there equivalent options in IOS?



  • 4.  RE: Traffic Engineering Options and Design
    Best Answer

    Posted 07-17-2014 07:52

    Hello,

     


    @evt wrote:

    Thanks for the response, that's an interesting scenario.  After reading some more, it seems to me that it's possible to have every router in the domain configured differently, but it's not advised because traffic would be handled differently on every router along the path of a given 'flow'.  


    Correct but only when "every router in a domain" is an MPLS PE. MPLS P routers do not install LSP tailend routes in inet.3, they use only mpls.0 table for label switching. Hence, changing "bgp" to "bgp-igp" to "mpls-forwarding" and vice versa on MPLS P router has no effect on transit packets: if a packet comes in as IP to MPLS P router, it will be routed as IP (provided there is a valid route to destination), if packet comes in as MPLS it will be switched provided valid label entry exists in mpls.0, etc

    Changing these knobs on MPLS P router does have an effect of starting/stopping to impose a label on the control traffic travelling beyond single hop.

     


    @evt wrote:

     

    I've got another question about this - are there equivalent options in IOS?


    AFAIK, IOS does not even have a concept of different route tables so the answer is no.

    IOS-XE/XR may be different.

    HTH

    Thanks
    Alex

     

     

     

     



  • 5.  RE: Traffic Engineering Options and Design

     
    Posted 07-17-2014 08:02

    Of course, you are right.  I am not sure why I was thinking about hop-by-hop behavior - synaptic misfire.  Thanks for the clarity.