Just found you, brushing up for a job interview, great use of real life scenario's, this is what these inexperienced youngsters need, had to have a giggle when you mentioned T1 link definitely showing your age not sure your audience will get it though
Nice video! So lets say the high speed link goes down and now we need to send/receive all the traffic via the backup link. Do we need to remove the community values from our backup router so that the Random company now sends us traffic via the cheap link? Can we automate this using IP SLA or is it done manually?
Hey, Antonio! Thanks for watching! In the case of the high-speed link going doing, the route over the high speed link would be removed from the BGP table after the hold-time expires. Once that route is gone, all traffic will automatically be routed over the backup link! This will take around 180 seconds (or 3 minutes) based on the BGP default timers (which means you'll have 3 minutes of outage since people will be trying to route over a downed link before it's fully removed). This isn't perfect, of course, but it is done by design as BGP is dealing with so many routes, you wouldn't want to continually be changing the global routing table because of faulty flapping links which would be a nightmare haha. After 3 minutes has gone, BGP has enough confidence to say that this path is not in use, and will then choose the next best path, (the slow backup link)! Routing logic still applies here. Despite us trying to make that path very undesirable through our BGP policy, when it's the only available route, it's therefore the best route! However, as soon as the high-speed link comes back up, BGP reintroduces that path back into the routing table and will again become the preferred path! It all happens automatically and there is no need to remove any community values, etc :) I will say, however, that whilst the default timers of BGP are by design very slow. You can change them should you require faster convergence, by typing for example: "router bgp 100 neighbor 2.2.2.2 remote 200 neighbor 2.2.2.2 timers 5 15" This would change the keepalive timer to 5 seconds and the hold to 15. So in that case of the above example, the failover to the slower link would have in 15 seconds, rather than 3 minutes. Hope that helps! -John
Hey, JC! I didn't realise that the configs hadn't saved. I've reuploaded the file, and the configs seem to be saved this time. Let me know if you have any problems! You can download the new file here: www.dropbox.com/s/dxohw9rot4gaaxu/_Exports_unetlab_export-20191028-181011.zip?dl=0 Hope that helps :) -John
@@JCSantiago I exported them from my main Windows machine and then was able to import the topology and saved configs onto my Linux machine without any issue, so hopefully it'll be the same for you!
@@IPvZero I've had a chance to try out the lap. It's a great lab and it's perfect for learning what your video covered! Thank you for sharing. My follow up question is that once the lab is over, I try to do a traceroute from R2 to 8.8.8.8 but it hangs with 32 * * *. However, if I do the traceroute from R3 it works perfectly. If I do the traceroute from R1 it sends it to R2 and then all I get are * * *. Could this caused by an asymmetrical route?
@@JCSantiago Hey JC! Thanks very much! Re: your traceroutes. The pings sourced from R1 and R2 should fail since none of their connected networks are advertised into BGP. Whereas with R3, it's 140.140.140.0/24 is advertised. You'll notice when I'm pinging/tracerouting from R3 I'm using the extended traceroute so I can specify the source as 140.140.140.1 so that the routers know where to send the return traffic. If I just ping or traceroute from R3 without specifying the source address as the 140 network, it should also fail! For example, all the routers in the topology will have a BGP route for the 140.140.140.0 in their routing table. But if you do a "show ip route" on the Random router etc, it won't have a route for any of the 10.1.1.0/30, 10.2.2.0/30, 10.0.0.0/30 or the networks connected to the ISPs 14.45.0.0, and 14.23.0.0 networks. So when the router looks up the address of where to send the return traffic, there's no entry and the traffic is basically blackholed! EDIT: If you wanna ping from them you can advertise their networks into BGP. Go into either R1/R2, or either ISP router and advertise the 14.45.0.0 and 14.23.0.0 networks respectively. Bare in mind they won't have the same routing policy applied as the 140.140.140.0 network since the Prefix List for the Community tag is only targeting that network specfiically. Hope that helps :) -John
Hey, JC! Thanks for watching. I have just logged into my EVE-NG and exported the lab for you :) You can download it here: www.dropbox.com/s/liakaxrierymgr1/_Exports_unetlab_export-20191011-105531.zip?dl=0 If you have any problems importing it, let me know! -John
@@JCSantiago No problem, man! The Router image I am using is: vios-adventerprisek9-m.vmdk.SPA.156-1.T The Switch image is: vios_l2-adventerprisek9-m.03.2017.qcow2 Both downloaded from my Cisco VIRL account. I've found that both work excellently with no issues. Definitely would recommend! :) -John
![Stromae, Pomme - “Ma Meilleure Ennemie” (from Arcane Season 2) [Official Visualizer]](http://i.ytimg.com/vi/1F3OGIFnW1k/mqdefault.jpg)
Very good video, thank you for sharing.
Best Explanation, Thanks!
You are the best sir. Clear and concise
Just found you, brushing up for a job interview, great use of real life scenario's, this is what these inexperienced youngsters need, had to have a giggle when you mentioned T1 link definitely showing your age not sure your audience will get it though
Nice... great video, and great explanation. !
This is the best video available on the entire internet. Thank you very much.
Thank you so much, Enrique! Really glad to hear your feedback!!! :)
-John
@@IPvZero Thank you John. You've got a new suscriber.
@@enriquegabriel7708 Thanks man. Really appreciate the support :)
wow i will say it 10000 x what you learn depends on the teacher. This guys rocks!
Thanks so much Robert! :)
Thanks. That was a great explination!
Thanks, Collin! Really appreciate it! :)
Nice video! So lets say the high speed link goes down and now we need to send/receive all the traffic via the backup link. Do we need to remove the community values from our backup router so that the Random company now sends us traffic via the cheap link? Can we automate this using IP SLA or is it done manually?
Hey, Antonio! Thanks for watching!
In the case of the high-speed link going doing, the route over the high speed link would be removed from the BGP table after the hold-time expires. Once that route is gone, all traffic will automatically be routed over the backup link! This will take around 180 seconds (or 3 minutes) based on the BGP default timers (which means you'll have 3 minutes of outage since people will be trying to route over a downed link before it's fully removed). This isn't perfect, of course, but it is done by design as BGP is dealing with so many routes, you wouldn't want to continually be changing the global routing table because of faulty flapping links which would be a nightmare haha.
After 3 minutes has gone, BGP has enough confidence to say that this path is not in use, and will then choose the next best path, (the slow backup link)!
Routing logic still applies here. Despite us trying to make that path very undesirable through our BGP policy, when it's the only available route, it's therefore the best route!
However, as soon as the high-speed link comes back up, BGP reintroduces that path back into the routing table and will again become the preferred path!
It all happens automatically and there is no need to remove any community values, etc :)
I will say, however, that whilst the default timers of BGP are by design very slow.
You can change them should you require faster convergence, by typing for example:
"router bgp 100
neighbor 2.2.2.2 remote 200
neighbor 2.2.2.2 timers 5 15"
This would change the keepalive timer to 5 seconds and the hold to 15. So in that case of the above example, the failover to the slower link would have in 15 seconds, rather than 3 minutes.
Hope that helps!
-John
@@IPvZero Thanks for the detailed answer. It cleared my doubt.
Thanks again for the lab, I got it working in Eve-NG. I did notice that eve-ng didn't save any of the configs. Would you be able to share them?
Hey, JC! I didn't realise that the configs hadn't saved. I've reuploaded the file, and the configs seem to be saved this time. Let me know if you have any problems!
You can download the new file here: www.dropbox.com/s/dxohw9rot4gaaxu/_Exports_unetlab_export-20191028-181011.zip?dl=0
Hope that helps :)
-John
@@IPvZero Thank you, Ill give it a shot.
@@JCSantiago I exported them from my main Windows machine and then was able to import the topology and saved configs onto my Linux machine without any issue, so hopefully it'll be the same for you!
@@IPvZero I've had a chance to try out the lap. It's a great lab and it's perfect for learning what your video covered! Thank you for sharing. My follow up question is that once the lab is over, I try to do a traceroute from R2 to 8.8.8.8 but it hangs with 32 * * *. However, if I do the traceroute from R3 it works perfectly. If I do the traceroute from R1 it sends it to R2 and then all I get are * * *. Could this caused by an asymmetrical route?
@@JCSantiago Hey JC! Thanks very much!
Re: your traceroutes. The pings sourced from R1 and R2 should fail since none of their connected networks are advertised into BGP. Whereas with R3, it's 140.140.140.0/24 is advertised. You'll notice when I'm pinging/tracerouting from R3 I'm using the extended traceroute so I can specify the source as 140.140.140.1 so that the routers know where to send the return traffic. If I just ping or traceroute from R3 without specifying the source address as the 140 network, it should also fail! For example, all the routers in the topology will have a BGP route for the 140.140.140.0 in their routing table. But if you do a "show ip route" on the Random router etc, it won't have a route for any of the 10.1.1.0/30, 10.2.2.0/30, 10.0.0.0/30 or the networks connected to the ISPs 14.45.0.0, and 14.23.0.0 networks. So when the router looks up the address of where to send the return traffic, there's no entry and the traffic is basically blackholed!
EDIT: If you wanna ping from them you can advertise their networks into BGP. Go into either R1/R2, or either ISP router and advertise the 14.45.0.0 and 14.23.0.0 networks respectively. Bare in mind they won't have the same routing policy applied as the 140.140.140.0 network since the Prefix List for the Community tag is only targeting that network specfiically.
Hope that helps :)
-John
Would you be willing share the Eve-NG lab for this video?
Hey, JC! Thanks for watching.
I have just logged into my EVE-NG and exported the lab for you :)
You can download it here: www.dropbox.com/s/liakaxrierymgr1/_Exports_unetlab_export-20191011-105531.zip?dl=0
If you have any problems importing it, let me know!
-John
@@IPvZero Thats awesome, thank you John. What vIOS do you do you recommend?
@@JCSantiago No problem, man!
The Router image I am using is: vios-adventerprisek9-m.vmdk.SPA.156-1.T
The Switch image is: vios_l2-adventerprisek9-m.03.2017.qcow2
Both downloaded from my Cisco VIRL account.
I've found that both work excellently with no issues.
Definitely would recommend!
:)
-John