BGP communities question

Philip disordr at
Tue Jul 29 23:16:48 UTC 2014

Hello Nanog,

I'm fairly new to running my employers multihomed BGP network with our own
Things have been relatively smooth and stable for the past few months.

We have 2 upstream ISP's giving us full routes.
We have a single link to each provider, but I run two BGP sessions over
that single link so I can have router redundancy. My routers are run in an
active-passive configuration.

With ISP-A, they have configured our 2 BGP sessions such that the secondary
session (our passive router), although the BGP session is up, no traffic is
directed there unless the primary router's BGP session goes away. This
prevents asymmetric routing problems with my active/passive config.
ISP-A attributes this config to the fact that we have 2 sessions, but on
the same router, with a config on their router that looks like this:
#show <> running-config interface tenGigE
interface TenGigE0/1/0/7
 description: 10GbE
 service-policy input cust1-in
 service-policy output cust1-out
 ipv4 address
 ipv4 address secondary
 ipv4 verify unicast source reachable-via any allow-self-ping

ISP-B says they aren't able to do this active/passive config without us
getting 2 physical links (kind of opposite what ISP-A is saying)
They recommend that we use local pref and communities to direct traffic to
our primary BGP session and only using the secondary session if the primary

Does that recommendation make sense? Will setting the local pref via ISP-B
community strings accomplish this active/passive traffic split that I'm
looking for?

Looking through the documentation on this providers site about which
community string needs to be set, it seems like I just need to make the
primary router BGP session community string higher than the default, and
the passive router BGP session community string lower than the default and
that will get me the desired behavior.

Is that the proper way of achieving the traffic flows for active / passive
config from provider to my gear?

Thank you,


More information about the NANOG mailing list