Previous Table of Contents Next


Frequently Asked Questions

QIf my IBGP peers are not directly connected, do I have to use EBGP multihop?

A—No. There is no restriction on IBGP peers to be connected. EBGP multihop is for EBGP only.

QShould I inject my BGP routes into the IGP for synchronization to take effect?

A—No. Injecting the BGP into your IGP is not recommended. You should turn the synchronization off. Make sure that this will not result in reachability problems inside your AS.

QDoes listing my IGP routes via the network command rather than redistributing the IGP into BGP give my BGP routes more stability?

A—No. In both methods, the fluctuation of your IGP routes will translate in fluctuation in your BGP routes. The network command only gives you better control and less worry about what your IGP might carry into BGP if you use redistribution.

QDo I have to list my connected interfaces by using the network command?

A—If you want the directly connected subnets to be reachable via BGP, then you can advertise them; if not, you don't have to.

QI have two border routers talking EBGP to my provider and IBGP internally. If I list my IGP routes via the network command on both routers, would that create a loop on the IBGP session?

A—No, you will not create a loop. Actually, doing so gives you more redundancy. If one of your border routers fails, the other border router will still announce the same networks.

QWhat happens if I use next-hop-self on my EBGP peers?

A—Next-hop-self is used between IBGP peers. Using it between EBGP peers is a not an option because the next hop is always the IP address of the EBGP neighbor.

QI need to receive only a few updates from my neighbor; can I filter on my side of the link?

A—Yes, you can. Ask your neighbor to send you only the routes you need to minimize unnecessary link bandwidth usage and unnecessary route fluctuations. At the same time, use filtering on your end to protect yourself from potential accidents where your neighbor sends you more routes than you are expecting.

QMy provider needs me to send him different local preference on different links; is that possible?

A—No. Local preference is defined inside the AS and is not carried on EBGP sessions.

QI am receiving MED from my provider that is influencing my traffic in a way that conflicts with my IGP. What do I do?

A—If receiving MEDs is causing you problems, call your provider and ask him to stop sending MEDs. Or, you can set MED to 0 on your end of the session.

QI am connected to multiple providers. On some occasions, my AS gets hit with an enormous amount of traffic that does not belong to my AS. What could be wrong?

A—You might be advertising routes that you receive from one provider to other providers. Other ASs might be using your AS as transit for their traffic. Make sure that you advertise only your routes to your providers.

QI am multihomed to the same provider. Do I have to worry about advertising the routes I learn from one link back on the second link?

A—BGP on your provider's end will detect that the routes it is receiving from you have passed through its AS already and will ignore them. Nevertheless, this is bad practice. You should not overload the links and routers with useless information; make sure that you send your own routes only.

QI am a provider, and I have given one of my customers a private AS number. Now, the customer wants to have a different connection with another provider. What would happen if he keeps using a private AS number?

A—This would be an illegal configuration. After you advertise this customer's network to the Internet, you are stripping the private AS number and announcing the routes as if they originated from your own AS. If the second provider does the same thing, then the customer's networks will have two origins—your AS and the AS of the other provider—and that is illegal.

QI am connected to one provider in San Francisco, and I am advertising my routes via BGP. I am connecting to another provider in LA. Should I get a different AS number?

A—If both the SF and LA networks fall under the same administration and have the same policies with other ASs, then they belong in the same AS. Remember that dividing networks via BGP is to define the boundaries of administration and policy. Geographical location is not the deciding factor.

References

[1] RFC 1321 The MD5 Message-Digest Algorithm

[2] RFC 1997 BGP Communities Attribute


Previous Table of Contents Next