BGP Confederation

[turbo_engine26]

Hello,

Please see attached BGP confederation configuration and Topology. They are taken from "Routing TCP/IP Volume 2" book.

AS 65000 is designed as a backbone AS connected to non-backbone AS 65535, 65534 and 65533. All are member AS's in AS 1200.

I have couple of questions as i think some parts of Sunshine's and Talisman's configurations are incorrect.

1. The next-hop-self keyword is mentioned only for Panorama router, why the keyword wasn't mentioned for Nakiska and Talisman routers? .. As we know, the next hop is preserved throughout the confederation, therefore, next hop self should be configured in all member AS's inside the confederation. The same thing with Talisman, why the next hop keyword wasn't mentioned for Lakeridge and Sunshine?

2. Why the remote-as keyword wasn't mentioned for Panorama in Sunshine's configuration while the keyword was mentioned correctly for every neighbor routers in Talisman's configuration?

3. I don't understand the below statements that are stated in the book, as it conflicts with the rule "MEDs are preserved throughout the confederation"

"AS 65000 can safely send MEDs to AS 65535. A route that includes 65000 in its AS_PATH is not accepted by Sunshine or Talisman, so MEDs sent from those routers to AS 65535 are not seen by other member AS's"

Appreciate your response.

HTH

AM

[Marwan ALshawi]

Hi there

see below:

1- because Nakiska and Talisman routers has only one internal link and one external link ( and if the external link/IP is being advertised in BGP ) by those two routers it is possible not to use the next hop self command as the internal routers will know how to reach this next hope via BGP/IGP if advertised

2- this could be ! a way to enforce the peering over one path but i would assume might be missing as the idea to have two multihomed linkes between the two BGP AS !

3- the statement mention that when you send a route with a changed MED toward AS 65535 from AS 65000 this MED will not be sen by other BGP ASN in this topology because the route from Sunshine for example in AS 65000 to AS 65535 if it comes back via the BGP session to Talisman the route will be discarded because Talisman will see its own ASN 65000 in that route based on BGP loop prevention mechanism

hope this help

[turbo_engine26]

 1- because Nakiska and Talisman routers has only one internal link and one external link ( and if the external link/IP is being advertised in BGP ) by those two routers it is possible not to use the next hop self command as the internal routers will know how to reach this next hope via BGP/IGP if advertised 

As you see in Talisman's config, the confederation eBGP link is not advertised and the same thing with Nikaska. Also, there are no static routes pointing to any next hop's network.

2- this could be ! a way to enforce the peering over one path but i would assume might be missing as the idea to have two multihomed linkes between the two BGP AS ! 

Sorry, your point isn't clear.

3- the statement mention that when you send a route with a changed MED toward AS 65535 from AS 65000 this MED will not be sen by other BGP ASN in this topology because the route from Sunshine for example in AS 65000 to AS 65535 if it comes back via the BGP session to Talisman the route will be discarded because Talisman will see its own ASN 65000 in that route based on BGP loop prevention mechanism 

Clear. thx

HTH

AM

[Marwan ALshawi]

well i think sometimes these configs are sample

as long as the point is clear to you and you understand the when you need to advertise a link or when to use the next hope self command then don't worry a lot about the config sample as it might be not detailed always

it could be sample for describing a certain point or concept but not a configuration guide

about point 2 above i just assumed if the bgp peering not added maybe it was to enforce all the route to use one path but i don't believe it is the case you might be right this part is missing

hope this help

pls rate the helpful post