cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3900
Views
36
Helpful
16
Replies

PFR Hub BR and Spoke BR Functions

snarayanaraju
Level 4
Level 4

Hello All - I learned as below

Hub Border Router: PFRv3 is enabled on the WAN interfaces of the BR, Path name and Path ID of the exit interfaces are defined on the Hub BR 

Spoke Border Router: Learns Policy configuration from the Branch MC and the Exit interface are learned automatically

My question is WHY HUB BORDER ROUTER IS ALSO NOT LEARNING THE EXIT INTERFACE FROM THE HUB MC? WHY I HAVE TO DEFINE THE EXIT INTERFACE MANUALLY?

Thanks in advance for help me answering this

SAIRAM 

2 Accepted Solutions

Accepted Solutions

Hello.

first of all I would suggest to review iWAN presentation (and PFR part in details) from cisco live 2014 - search for "TECCRS-2004" in google - I assume it would help you a lot.

When i configure domain path MPLS / INET command under Tunnel Interfaces of HUB-BR, it binds the name MPLS or INET to respective tunnel interface

Correct.

Then, HUB-BRs starts doing smart probes to learn the Link performance metrics (Example: Latency) and provide the data to HUB-MC

not really - metrics are collected from smart probes and from real traffic on the path (please find more details in the presentation) also all the metrics are per channel.

Do BRANCH-BRs do probing ?. If so, i assume it sends the Link performance metrics to BRANCH-MC and based on the traffic-class policy pushed from HUB-BRs, the BRANCH-MC tells the BRANCH-BR which Exit Interface (Tunnel) to use. Correct?

BRs are always doing smart-probes. But they are not the only way to gather metrics. Also monitoring is done on INGRESS direction; correct, that metrics are exported to MC (but only once thresholds are violated or brownout detected).

Correct, that local MC makes routing decision (pdp) and notifies the local BRs that are expected to enforce it.

Exit Interface has been choosed based on the names (MPLS or INET) that we configured in HUB-BRANCH only. How does BRANCH-BRs know these names? because no where i configured the words domain path MPLS in BRANCH-BR

MCs makes routing decision based on policies and information from BRs about available paths to remote site.

Branch-BRs learns the colours from discovery smart probes sent from Hub BR to the branch (new branch/site-id is learnt by Hub MC via EIGRP SAFI). You will see from presentation, that smart probes are always sourced from site-id and destined to site-id (that are MCs' loopbacks) and BR are obliged to catch the probes (udp src-port 18000 dst-port 19000) and use.

PS: you need to remember, that any violation from CVD may lead to unsupported design and PFR/iWAN may start behaving unexpectedly (that is why it's extreamly important to read CVD before you start planning PFRv3 for your network)

Most commonly seen issues are:

  • branch announces back (with worse metric) prefixes learnt from WAN interface,
  • branch terminates single WAN colour twice on different BRs;
  • a hub has two tunnels terminated on a single box (BR) - actually your example with Tu20 and Tu30 (if from single box) is the case;
  • Hub BR RIB points to LAN interface to reach a branch;
  • backdoor link (non-PFR enabled) between branch and a Hub;
  • per-tunnel QoS (on Hub BR) remarking traffic;
  • Hub or transit Hub MC missing "site-prefix" configuration;
  • scaling issues (like G2 devices as Hub MC/BR and etc.);
  • etc.

View solution in original post

Hello.

Please do not put new questions into old thread.

But - PFRv3 won't manipulate any metrics. Traffic may come to any of the routers. If the exit interface is on another BR, the traffic will be sent to that BR over mGRE tunnel (auto-tunnel created between all BRs on site).

View solution in original post

16 Replies 16

Sairam,

Can you restate your question as I for one am not understanding your question.  Can you also provide cli show results where you manually have to define exit interface on the hub border etc.

If you have your answer already can you post your results.

Thanks

Hi Russell - Thanks for your response.

My question: In a Hub and Spoke scenario, what is the difference between Hub Border Router and Branch Border Router? As per configurations, i am defining the Exit interfaces in the Hub Border Router whereas i donot do that in Branch Border Router. Why so?

Sairam

I am still a bit confused on exactly where you are defining the exit interface on the hub br and not on the branch br.  Can you post a config snippit.  I however think I know the answer but let me know what you think after reading the link below.  Smart Probes.  The way I read the section is that smart probes server a few functions.  The hub BR sending out the smart probes sounds like the start of the discovery process for PfR.  Let me know what you think.

http://docwiki.cisco.com/wiki/PfRv3:Technology_Overview

Hello Russell - Sorry if i am not explaining my question better way you to understand

This is the explanation from Cisco:

Hub Border Router: This is a border router at the hub-site. This is the device where WAN interface terminates. PfRv3 is enabled on these interfaces. There could be one or more WAN interface on the same device. There can be one or more Hub BRs. On the Hub Border Routers, PfRv3 must be configured with: The path name on external interfaces

Branch Border Router: This is a border router at the branch-site. There is no configuration other than enabling of PfR Border Router functionality on the device. The WAN interface that terminates on the device is/are detected automatically.

My understanding: Branch Border Router interact with Branch-MC. Branch-MC interact with Hub-MC. Branch-MC gets the configuration from Hub-MC and act as the decision maker for Branch-Border by getting the traffic/Link metrics from Branch-MC

My Question: What is the role of Hub-Border Router in this scenario?

Thanks / SAIRAM  

The border routers (hub and branch) run the smart probe discovery and monitor processes. That info feeds up to the local MC and Hub-MC.  I think the the role of the Hub-Border Router defines the path name and manages the initial dynamic discovery of the branch routers on the opposite end of any number of tunnels.  

This discussion does have me looking at my own configs.  All of the configs I have see to date have the same 'domain IWAN path MPLS' on the tunnel interfaces in both the hub and branch configurations.  It is this statement on the interface that binds the tunnel interface to the PfR domain instance and path name be it hub or branch.

This is what I was assuming and could be off but...  After the tunnel is up the hub BR discovery process verifies that the BR on the other end of the tunnel has the same PfR domain and path name configured on the interface.  If so flags it as a valid path and tells the hub-MC of the path.  The branch-MC hears the same info from the branch-BR to add the path. The Hub-MC has to hear from both the hub-BR and the branch-MC that the path is valid.  I think the 'domain IWAN path MPLS'  this has to be on both Hub and branch BR tunnel interfaces.  (that only makes the statement 'On the Hub Border Routers, PfRv3 must be configured with: The path name on external interfaces. confusing as this is defined on both sides)

interface Tunnel100
description DMVPN-MPLS
ip address 192.168.100.11 255.255.255.0
.
.
.
domain IWAN path MPLS path-id 1  

*TAC told me that path-id # is only required for transit-BR configs and can be omitted otherwise

The section on Branch Border Router....WAN interfaces being detected automatically leads me to believe that the role of the Hub-BR is in fact to be the discovery initiator.

long winded sorry.

Thank for your time. I noticed in my configuration, we define "domain path MPLS path-id 11" only in HUB-BORDER routers under tunnel interface. This command is not there at BRANCH-BORDER router.

I will remove that config on Monday from the branch, test and update you.  There is so much documentation on this but it does not seem 100% consistent at times.

Hello, everybody.

"domain path ..." command is "legal" on Hub BR; it is NOT supported on branch BRs and acknowledged by TAC as misconfiguration.

You may need "path-id" if you are running transit site feature (having transit site or have more than one Hub BR attached to the same tunnel).

Configuration is done on Hub BRs only, as Hub[s] is/are a central location and subject to manual configuration.

At the same time spoke BRs should have typical configuration (for deployment purposes) and thus do not have it and are expected to discover "colour" per smart probes.

So, the role of HubBR here is to send smart probes and signal interface colour (in iWAN 2.0) and available next-hop labels (for iWAN 2.1).

Hub BR does not learn the colour from Hub MC and this is a just decision from developers.

Btw:

>>After the tunnel is up the hub BR discovery process verifies that the BR on the other end of the tunnel has the same PfR domain and path name configured on the interface

BRs do not do anything like this.

Thanks.

PS: Hub BR does not do "initial dynamic discovery", but new branch sites are "discovered" by MC through EIGRP SAFI.

PS: I work in TAC, supporting PFRv3, so feel free to ask other questions.

Vasilii, thank you very much for your clarification and correction.

Thank you Vasillii. Here is my understanding learned from your comments. PLEASE CORRECT ME, if needed. Thanks in advance.

Thank for reading my comments patiently. Appreciate if you could shed some lights on WHAT IS THE COMMUNICATION HAPPENING BETWEEN BRANCH-BR and HUB-BRs

My understanding:

Hub-BR:

Interface Tunnel 20

  description ## connected to MPLS ##

  domain path MPLS path-id 11

Interface Tunnel 30

  description ## connected to INTERNET ##

  domain path INET path-id 22

1)  When i configure domain path MPLS / INET command under Tunnel Interfaces of HUB-BR, it binds the name MPLS or INET to respective tunnel interface

2)  Then, HUB-BRs starts doing smart probes to learn the Link performance metrics (Example: Latency) and provide the data to HUB-MC

QUESTION:

1) Do BRANCH-BRs do probing ?. If so, i assume it sends the Link performance metrics to BRANCH-MC and based on the traffic-class policy pushed from HUB-BRs, the BRANCH-MC tells the BRANCH-BR which Exit Interface (Tunnel) to use. Correct?

2) Exit Interface has been choosed based on the names (MPLS or INET) that we configured in HUB-BRANCH only. How does BRANCH-BRs know these names? because no where i configured the words domain path MPLS in BRANCH-BR

thanks

SAIRAM

Hello.

first of all I would suggest to review iWAN presentation (and PFR part in details) from cisco live 2014 - search for "TECCRS-2004" in google - I assume it would help you a lot.

When i configure domain path MPLS / INET command under Tunnel Interfaces of HUB-BR, it binds the name MPLS or INET to respective tunnel interface

Correct.

Then, HUB-BRs starts doing smart probes to learn the Link performance metrics (Example: Latency) and provide the data to HUB-MC

not really - metrics are collected from smart probes and from real traffic on the path (please find more details in the presentation) also all the metrics are per channel.

Do BRANCH-BRs do probing ?. If so, i assume it sends the Link performance metrics to BRANCH-MC and based on the traffic-class policy pushed from HUB-BRs, the BRANCH-MC tells the BRANCH-BR which Exit Interface (Tunnel) to use. Correct?

BRs are always doing smart-probes. But they are not the only way to gather metrics. Also monitoring is done on INGRESS direction; correct, that metrics are exported to MC (but only once thresholds are violated or brownout detected).

Correct, that local MC makes routing decision (pdp) and notifies the local BRs that are expected to enforce it.

Exit Interface has been choosed based on the names (MPLS or INET) that we configured in HUB-BRANCH only. How does BRANCH-BRs know these names? because no where i configured the words domain path MPLS in BRANCH-BR

MCs makes routing decision based on policies and information from BRs about available paths to remote site.

Branch-BRs learns the colours from discovery smart probes sent from Hub BR to the branch (new branch/site-id is learnt by Hub MC via EIGRP SAFI). You will see from presentation, that smart probes are always sourced from site-id and destined to site-id (that are MCs' loopbacks) and BR are obliged to catch the probes (udp src-port 18000 dst-port 19000) and use.

PS: you need to remember, that any violation from CVD may lead to unsupported design and PFR/iWAN may start behaving unexpectedly (that is why it's extreamly important to read CVD before you start planning PFRv3 for your network)

Most commonly seen issues are:

  • branch announces back (with worse metric) prefixes learnt from WAN interface,
  • branch terminates single WAN colour twice on different BRs;
  • a hub has two tunnels terminated on a single box (BR) - actually your example with Tu20 and Tu30 (if from single box) is the case;
  • Hub BR RIB points to LAN interface to reach a branch;
  • backdoor link (non-PFR enabled) between branch and a Hub;
  • per-tunnel QoS (on Hub BR) remarking traffic;
  • Hub or transit Hub MC missing "site-prefix" configuration;
  • scaling issues (like G2 devices as Hub MC/BR and etc.);
  • etc.

Thank you Vasilli - I will revert if i have any questions, after reading the Presentation you suggested

Hello Vasili - This is a new question in the old thread. 

In dual Branch Router scenario, if Primary Link MPLS degrades and as per MC policy the Secondary Internet Link has to become the preferred path, what PFRv3 do to update the RIB or EIGRP topology table?

How does the L3 switch RIB (see the attached diagram) know to prefer Internet Router instead of MPLS Router?

Thanks / SAIRAM

Hello.

Please do not put new questions into old thread.

But - PFRv3 won't manipulate any metrics. Traffic may come to any of the routers. If the exit interface is on another BR, the traffic will be sent to that BR over mGRE tunnel (auto-tunnel created between all BRs on site).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card