Hi All, recently I was taking interview and asked one basic question as *"“Why is my BGP route hidden/inactive?”* Interviewer was not aware about what I want to ask and he kept on rolling the dice and revolving around bgp but still not sure what I did asked. I have him another chance and gave him hint do you know *" what is recursive routing?"* He was blank... In 30 mins of interview he was good to answer most of the questions but when we start routing part and started from scratch or from basic he started fumbling... So to get my answer back I gave him another hint and asked *" do you know how router check next hop and what he does if no route"* he gave the answer like what router does when no route but still didn't answer my first question.
So reason I am sharing this thought so that member of this chat if you are going for interview focus on basic of any technology and then look for advance.
Sometimes resume looks impressive and candidate too when we do screening but when we drill as per position people lack basic architecture. *
So reason I am sharing this thought so that member of this chat if you are going for interview focus on basic of any technology and then look for advance.
Sometimes resume looks impressive and candidate too when we do screening but when we drill as per position people lack basic architecture. *
So it's not how much you know, it's all what you know is really you know it*
👍2
Why Are So Many Engineers Confused About Cisco SD-WAN Policies?
"Should I use a Localized Policy, Centralized Policy, Data Policy, Control Policy, App Route Policy, or Traffic Policy?", you're not alone.
In fact, policy design is probably the most confusing part of Cisco SD-WAN.
The reason is simple: most engineers try to memorize policy names instead of understanding where a policy acts in the packet journey.
Think about it. When a packet enters an SD-WAN fabric, many things can happen:
It can be advertised or hidden from routing.
It can be steered to a specific transport.
It can be dropped.
It can be NATed.
It can be QoS marked.
It can be redirected to a service.
It can be controlled before it ever reaches the data plane.
When engineers look only at the policy names, everything sounds similar. When they look at the objective, policy selection becomes much easier.
---
The Real Question Is Not "Which Policy Exists?"
The real question is:
> "At which stage do I want to influence traffic?"
Once you answer that, the correct policy type usually becomes obvious.
---
Method 1: Ask Yourself What You Want To Control
Do you want to control route advertisements?
Examples:
Stop a branch from learning a route.
Prevent a route from being advertised.
Change TLOC advertisement.
Influence route propagation.
Then you're working in the control plane.
Use:
Centralized Control Policy
Think:
> "I am manipulating routing information before traffic forwarding decisions occur."
---
Do you want to control how traffic is forwarded?
Examples:
Send Office365 via MPLS.
Send backups via Internet.
Block specific applications.
Redirect traffic to a firewall.
Then you're working in the data plane.
Use:
Centralized Data Policy
Think:
> "The route already exists. Now I want to control what happens to actual packets."
---
Do you want to choose the best transport path?
Examples:
Voice should use MPLS.
Business applications should avoid links with high latency.
Traffic should fail over when loss exceeds 1%.
Use:
Application Aware Routing (App Route Policy)
Think:
> "I am not changing routes. I am selecting the best WAN transport."
---
Do you want actions only on a single router?
Examples:
Local QoS
ACL
NAT
Local route policies
Use:
Localized Policy
Think:
> "This policy belongs only to one device."
---
Method 2: Follow The Packet Journey
A good trainer often teaches policy selection using a packet's journey.
Step 1: Route Advertisement
Question:
> Should this route even be advertised?
If yes or no:
Control Policy
---
Step 2: Route Installed
Question:
> Route exists. Should traffic use this route?
If yes:
Data Policy
---
Step 3: Transport Selection
Question:
> Which WAN circuit should carry traffic?
If yes:
App Route Policy
---
Step 4: Local Device Functions
Question:
> Do I need NAT, ACL, QoS, or local services?
If yes:
Localized Policy
---
The Biggest Mistake Engineers Make
Many engineers start with:
> "I learned App Route Policy today, so I'll use App Route Policy."
Instead, start with:
> "What business requirement am I trying to solve?"
For example:
Requirement
Voice traffic must use MPLS whenever possible.
Incorrect thinking:
> Which policy do I remember?
Correct thinking:
> I need path selection based on application performance.
Answer:
App Route Policy
---
Requirement
Branch A should not receive Branch B routes.
Correct thinking:
> This is route advertisement control.
Answer:
Control Policy
---
Requirement
Guest users should be blocked from reaching servers.
Correct thinking:
> This is packet filtering.
Answer:
Data Policy
---
Quick Recognition Framework
Whenever a customer gives a requirement, ask these four questions:
Question Policy Type
Am I controlling route advertisements? Control Policy
Am I controlling packet forwarding? Data Policy
Am I selecting WAN transport based on SLA? App Route Policy
Am I configuring something local to a router? Localized Policy
"Should I use a Localized Policy, Centralized Policy, Data Policy, Control Policy, App Route Policy, or Traffic Policy?", you're not alone.
In fact, policy design is probably the most confusing part of Cisco SD-WAN.
The reason is simple: most engineers try to memorize policy names instead of understanding where a policy acts in the packet journey.
Think about it. When a packet enters an SD-WAN fabric, many things can happen:
It can be advertised or hidden from routing.
It can be steered to a specific transport.
It can be dropped.
It can be NATed.
It can be QoS marked.
It can be redirected to a service.
It can be controlled before it ever reaches the data plane.
When engineers look only at the policy names, everything sounds similar. When they look at the objective, policy selection becomes much easier.
---
The Real Question Is Not "Which Policy Exists?"
The real question is:
> "At which stage do I want to influence traffic?"
Once you answer that, the correct policy type usually becomes obvious.
---
Method 1: Ask Yourself What You Want To Control
Do you want to control route advertisements?
Examples:
Stop a branch from learning a route.
Prevent a route from being advertised.
Change TLOC advertisement.
Influence route propagation.
Then you're working in the control plane.
Use:
Centralized Control Policy
Think:
> "I am manipulating routing information before traffic forwarding decisions occur."
---
Do you want to control how traffic is forwarded?
Examples:
Send Office365 via MPLS.
Send backups via Internet.
Block specific applications.
Redirect traffic to a firewall.
Then you're working in the data plane.
Use:
Centralized Data Policy
Think:
> "The route already exists. Now I want to control what happens to actual packets."
---
Do you want to choose the best transport path?
Examples:
Voice should use MPLS.
Business applications should avoid links with high latency.
Traffic should fail over when loss exceeds 1%.
Use:
Application Aware Routing (App Route Policy)
Think:
> "I am not changing routes. I am selecting the best WAN transport."
---
Do you want actions only on a single router?
Examples:
Local QoS
ACL
NAT
Local route policies
Use:
Localized Policy
Think:
> "This policy belongs only to one device."
---
Method 2: Follow The Packet Journey
A good trainer often teaches policy selection using a packet's journey.
Step 1: Route Advertisement
Question:
> Should this route even be advertised?
If yes or no:
Control Policy
---
Step 2: Route Installed
Question:
> Route exists. Should traffic use this route?
If yes:
Data Policy
---
Step 3: Transport Selection
Question:
> Which WAN circuit should carry traffic?
If yes:
App Route Policy
---
Step 4: Local Device Functions
Question:
> Do I need NAT, ACL, QoS, or local services?
If yes:
Localized Policy
---
The Biggest Mistake Engineers Make
Many engineers start with:
> "I learned App Route Policy today, so I'll use App Route Policy."
Instead, start with:
> "What business requirement am I trying to solve?"
For example:
Requirement
Voice traffic must use MPLS whenever possible.
Incorrect thinking:
> Which policy do I remember?
Correct thinking:
> I need path selection based on application performance.
Answer:
App Route Policy
---
Requirement
Branch A should not receive Branch B routes.
Correct thinking:
> This is route advertisement control.
Answer:
Control Policy
---
Requirement
Guest users should be blocked from reaching servers.
Correct thinking:
> This is packet filtering.
Answer:
Data Policy
---
Quick Recognition Framework
Whenever a customer gives a requirement, ask these four questions:
Question Policy Type
Am I controlling route advertisements? Control Policy
Am I controlling packet forwarding? Data Policy
Am I selecting WAN transport based on SLA? App Route Policy
Am I configuring something local to a router? Localized Policy