BGP Dual-AS, prepend-as and replace-as

Unanswered Question
Oct 8th, 2009
User Badges:

Hi guys, i'm here trying a scenario and got some questions, picture this:


R1------R2------R3

AS......AS......AS

100.....200.....300

.....(old 99)


R1 is in AS 100

R2 is in AS 200 (but used to be in AS 99)

R3 is in AS 300


In R2, the peering with R1 is configured with:


neighbor "R1" local-as 99 no-prepend replace-as dual-as


And the peering of R2 with R3 is:


neighbor "R3" local-as 99 no-prepend replace-as


R1 is configured to be peering with R2 using the real AS, (200). But R3 is configured to be peering with R2 using the old, or local AS (99).


Here is the thing, as soon as R1-R2 peering is up, the peering between R2-R3 goes down, then it goes up and R1-R2 goes down, so basically, only one peering is up at a time (R1-R2 or R2-R3).


There are some logs in the routers mentioning "invalid or corrupr as-path" and something about "bad attributes". Cheking the neighbor advertise-ments and routes learned, i learnd that for some reason, R2 is advertising to R1 what it learned from R1, and advertising R3 what it learned from R3. Again, debuging noticed that this, although unusual, is not a problem because R1 and R3 just ignore the advertisments because they see thery AS in the updates..


BUT.. in that debug i noticed a message talking about "enforce as-path first". This is a BGP feature that requires that an update coming from a neighbor in AS X, needs to have AS X as the first as-path hop, which seams fare. But why is this validation failing?


For some reason, R3 is receiving from R2, the routes advertised from R1, with a first hop of AS 100 (the real AS), when it should be AS 99, so of course, the validation fails. The same thing goes to R1 receiving from R2 routes generated in R3 with a first hop of AS 99, when it was expecting a first hop of AS 100 (because that what is configured in R1.. neighbor R2 remote-as 100).


So.. issuing the command "no bgp enforce-first-as" in R1 OR R3, solved the problem.


But this seems very strange.. why does the peering of R2 and R3 affects the peering with R2 and R1? Why is R2 doing route feedback to R1 and R3?


And most important, why is R2, for example, announcing to R3 the routes from R1 with a first hop of AS 100? The option "replace-as" should take down this AS100 and replace it with a AS 99 right??? that is the purpose of the option.


My wild guess is that there must be some kind of order and rules for this two options (replace and dual-as), that says:


My peering with R1 says has the option "no-prepend" so to any route learned from R1 I will not prepend the AS 100. So when I announce it to R3, i cannot replace this AS100 with the AS99 that R3 is expecting" .. or something like that :S


Help! very confused :P


thanks in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
omarmontes Thu, 10/08/2009 - 11:27
User Badges:

PS: the dots in the "diagram" are just to put some spaces between the AS notes :P

omarmontes Thu, 10/08/2009 - 11:33
User Badges:

God i got the numbers wrong (confussed AS 100 where it should be 200), here is the corrected part :S.. and sorry for all the mess:




###############


For some reason, R3 is receiving from R2, the routes advertised from R1, with a first hop of AS 200 (the real AS), when it should be AS 99, so of course, the validation fails. The same thing goes to R1 receiving from R2 routes generated in R3 with a first hop of AS 99, when it was expecting a first hop of AS 200 (because that what is configured in R1.. neighbor R2 remote-as 200).


So.. issuing the command "no bgp enforce-first-as" in R1 OR R3, solved the problem.


But this seems very strange.. why does the peering of R2 and R3 affects the peering with R2 and R1? Why is R2 doing route feedback to R1 and R3?


And most important, why is R2, for example, announcing to R3 the routes from R1 with a first hop of AS 200? The option "replace-as" should take down this AS200 and replace it with a AS 99 right??? that is the purpose of the option.


My wild guess is that there must be some kind of order and rules for this two options (replace and dual-as), that says:


My peering with R1 says has the option "no-prepend" so to any route learned from R1 I will not prepend the AS 200. So when I announce it to R3, i cannot replace this AS200 with the AS99 that R3 is expecting" .. or something like that :S


Help! very confused :P


thanks in advance!

Copied from cisco site:

The replace-as keyword is used to prepend only the local autonomous-system number (as configured with the ip-address argument) to the AS_PATH attribute. The autonomous-system number from the local BGP routing process is not prepended.


Without digging any deeper into it, my guess is that something is happening with the prefixes for BGP neighbor addresses.

Anyway, take a look at the local-as command aswell. It also only prepend and not swaps the AS.

Giuseppe Larosa Thu, 10/08/2009 - 20:59
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Omar,

there are many options in the

neighbor .. local-as


see


http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp3.html#wp1014448


and config guide


http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_neighor_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1054577



I agree with Oskar that you are probably advertising BGP next-hops of session1 on session2 and viceversa and this can cause an unwanted interaction.


if you like you can post your configs and some show to see what is happening in your lab setup.


Hope to help

Giuseppe



omarmontes Thu, 10/08/2009 - 21:07
User Badges:

Thanks for replying guys..


Not sure what you mean exactly by " advertising BGP next-hops of session 1 on session2" But for starters, BGP is only advertising loopback interfaces, and all the IGP (and of course, next-hop reachability) is in charge of EIGRP.


So if you meant that maybe I was adverising for example the link between R2 and R3, to R1 via BGP, this is not the case. The transit networks are just adversited by EIGRP.

Actions

This Discussion