(taken from: http://puck.nether.net/bgp/juniper-config.html )
Due to the ease of configuring bgp, it is easy to leave out critical steps that will result in some unintended consequences. There are a number of cases that exist persistently in the routing tables where some small network is actually connecting two “larger” networks together for some routes/prefixes for various reasons.
As a result of this, and the ease of these errors/mistakes, we wanted to provide a few simple examples that would ease most networks configuration needs and provide a common reference.
These examples cover a few basic bgp related topics, including:
- UNDER CONSTRUCTION.
protocols { bgp { group eBGP-to-customer { type external; metric-out igp; export [ customer-out ]; remove-private; neighbor 1.2.3.4 { description "Customer AS267"; out-delay 1; import [ customer-in AS267-in ]; peer-as 267; } } } } policy-options { policy-statement customer-in { term default { then { local-preference 220; next policy; } } } policy-statement peer-in { term default { then { community set comm-peer; local-preference 200; next policy; } } } policy-statement transit-in { term default { then { community set comm-transit; local-preference 180; next policy; } } } policy-statement customer-out { term customer-routes { from community [ comm-customer comm-peer comm-transit ]; then accept; } } policy-statement peer-out { term peer-routes { from community [ comm-customer ]; then accept; } } policy-statement transit-out { term peer-routes { from community [ comm-customer ]; then accept; } } policy-statement AS267-in { term match-exact { from { route-filter 0/0 exact reject; route-filter 204.42.252.0/22 exact; } then { community add comm-customer; next policy; } } then reject; } community comm-customer members XXX:220; community comm-peer members XXX:200; community comm-transit members XXX:180 }