Required sessions within an AS with and without route reflectors
The BGP commands related to route reflectors includes:
config router bgp
config neighbor
set route-reflector-client {enable | disable}
set route-server-client {enable | disable}
end end
Confederations
Confederations were introduced to reduce the number of BGP advertisements on a segment of the network, and reduce the size of the routing tables. Confederations essentially break up an AS into smaller units. Confederations are defined in RFC 3065 and RFC 1965.
Within a confederation, all routers communicate with each other in a full mesh arrangement. Communications between confederations is more like inter-AS communications in that many of the attributes are changed as they would be for BGP communications leaving the AS, or eBGP.
Confederations are useful when merging ASs. Each AS being merged can easily become a confederation, requiring few changes. Any additional permanent changes can then be implemented over time as required. The figure below shows the group of ASs before merging, and the corresponding confederations afterward as part of the single AS with the addition of a new border router. It should be noted that after merging if the border router becomes a route reflector, then each confederation only needs to communicate with one other router, instead of five others.
AS merging using confederations
Confederations and route reflectors perform similar functions — they both sub-divide large ASes for more efficient operation. They differ in that route reflector clusters can include routers that are not members of a cluster, where routers in a confederation must belong to that confederation. Also, confederations place their confederation numbers in the AS_PATH attribute making it easier to trace.
It is important to note that while confederations essentially create sub-ASs, all the confederations within an AS appear as a single AS to external ASs. Confederation related BGP commands include:
config router bgp
set confederation-identifier <peerid_integer>
end
Hi Mike,
if i configure the following on fortigate1:
config router bgp
set as 65000
set router-id 10.2.2.254
config neighbor
edit “10.2.2.253”
set next-hop-self enable
set remote-as 65000
set send-community6 disable
next
config redistribute “static”
set status enable
end
fortigate2 should get the default route 0.0.0.0 0.0.0.0 from fortigate1 as it is static ?
how can i redistribute the default route(fortigate1) to fortigate2 ?
thanks
regards
There is a really good KB article that explains how to do this. You can find it here
If you want to redistribute static routes you would enable the following
config router bgp
config redistribute static
set status enable
end
end
An example of the config would be like this
config router prefix-list
edit “only_dflt”
config rule
edit 1
set prefix 0.0.0.0 0.0.0.0
unset ge
unset le
next
end
next
end
config router route-map
edit “only_default_route”
config rule
edit 1
set match-ip-address “only_dflt”
next
end
next
end
config router bgp
set as 2
config neighbor
edit 10.142.0.110
set remote-as 1
set route-map-in “only_default_route”
next
end
set router-id 10.142.0.205
end
Let me know if this helped answer your question!
Thanks!
Hi,
thanks for the link and example, got it working!
Regards
Awesome to hear Piccolo!
config router bgp
set as 65041
set router-id 162.53.156.138
config neighbor
edit “10.104.55.1”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
edit “10.104.55.2”
set ebgp-enforce-multihop enable
set soft-reconfiguration enable
set remote-as 64699
set send-community6 disable
next
i am trying to accomplish above but i can see only one neighbour is establish and other is in ACTIVE state…
So you see both neighbors but only one is active?