EBGP in JNCIP book
Hi, I have a question regarding EBGP config.
In JNCIP book, EBGP section, r1 peer to p1:
I think the config below only tag the routes orginated from AS1492, how about AS1492's customer?
term tag-p1 {
from as-path peer-1;
then {
community add peer-1;
as-path-prepend "64512 64512";
}
}
}
as-path peer-1 ".* 1492";
In JNCIP book, EBGP section, r1 peer to p1:
I think the config below only tag the routes orginated from AS1492, how about AS1492's customer?
term tag-p1 {
from as-path peer-1;
then {
community add peer-1;
as-path-prepend "64512 64512";
}
}
}
as-path peer-1 ".* 1492";
Comments
-
Aldur
Member Posts: 1,460
that policy will only prepend routes that start in AS1492. To get routes that p1 may be getting from another peer you would need to use the following as path regex.
as-path peer-1 ".* 1492 .*"
That will match any route that has 1492 in the as path."Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender -
zrcheng
Member Posts: 44 ■■□□□□□□□□
agree, just wonder the requirment:
Prepend 64512 64512 to all routes received from P1. Ensure that transit providers do not receive these AS numbers. -
Aldur
Member Posts: 1,460
Prepend 64512 64512 to all routes received from P1. Ensure that transit providers do not receive these AS numbers.
I see what your saying there, I would recommend using the ".* 1492 .*" as path regex to make sure you tag all routes received from p1 even if they don't originate in AS 1492."Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender -
zoidberg
Member Posts: 365 ■■■■□□□□□□
"1492 .*" would prolly be better. anything coming from p1 should have 1492 at the start of the as-path anyways. depending on which level you placed your policy, the leading .* could catch 1492 routes coming from other peers or transits and then subsequently prepend them as well. pretty small risk though as most would apply this directly to the neighbor or group and not the protocol... but you never know.
technically, seeing you're prepending everything, you should even be able to get away without the from clause, or use something like from bgp neighbor x.x.x.x. of course, that defeats the purpose of the exercise here in making as-path policies. there's gotta be 80 different ways to do just one thing :P
i think it's just a typo in the book, ".* 1492" instead of "1492 .*". i saw some threads a few months back about harry compiling a new errata for the book. not sure where that's at though. -
Aldur
Member Posts: 1,460
"1492 .*" would prolly be better. anything coming from p1 should have 1492 at the start of the as-path anyways. depending on which level you placed your policy, the leading .* could catch 1492 routes coming from other peers or transits and then subsequently prepend them as well.
Ahhh good point, I always apply the policy at the neighbor level or at the group level if there is just one ebgp neighbor. "1492 .*" would be better since no matter where you applied the policy you'd be safe."Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender -
kingcobra.guo
Member Posts: 8 ■□□□□□□□□□
"1492 .*" would prolly be better. anything coming from p1 should have 1492 at the start of the as-path anyways. depending on which level you placed your policy, the leading .* could catch 1492 routes coming from other peers or transits and then subsequently prepend them as well. pretty small risk though as most would apply this directly to the neighbor or group and not the protocol... but you never know.
technically, seeing you're prepending everything, you should even be able to get away without the from clause, or use something like from bgp neighbor x.x.x.x. of course, that defeats the purpose of the exercise here in making as-path policies. there's gotta be 80 different ways to do just one thing :P
i think it's just a typo in the book, ".* 1492" instead of "1492 .*". i saw some threads a few months back about harry compiling a new errata for the book. not sure where that's at though.
i think “.* 1492” would be best,
p1 may prepend as to some routes(who knows? because we can not view P1 config), and "1492 .*" will not match these routes. -
Aldur
Member Posts: 1,460
kingcobra.guo wrote: »i think “.* 1492” would be best,
p1 may prepend as to some routes(who knows? because we can not view P1 config), and "1492 .*" will not match these routes.
The problem with ".* 1492" is it will only accept routes that start on P1 and will reject routes that are passed through P1. There is a good chance that P1 is acting as a transit router for other routes and accepting routes with ".* 1492" as path only would kill those other routes.
True, P1 could be prepending as paths on to the routes but you could easily see this with a "show route-received protocol bgp x.x.x.x" and adjust your import policy from there.
A quick and dirty way to work around this would be to use the ".* 1492 .*" which would catch the 1492 AS anywhere in the path. As as discussed earlier in this thread, as long as you apply this at the neighbor level, or group level if there is just one neighbor then it will have no unwanted effects."Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender -
kingcobra.guo
Member Posts: 8 ■□□□□□□□□□
The problem with ".* 1492" is it will only accept routes that start on P1 and will reject routes that are passed through P1.
...
A quick and dirty way to work around this would be to use the ".* 1492 .*" which would catch the 1492 AS anywhere in the path. ...
".* 1492" will only tag routes that start on P1 ;
if the requirement is " tag routes received from P site", “.* 1492 .*” would be best; but the requirement is "tag routes originated in p site"
