New answers tagged bgp
6
As mentioned by Ron, you can use no-export (Don't advertise to any eBGP peers) or no-advertise (Don't advertise to iBGP or eBGP peers) to achieve this. However, this may strain scalability issues if bringing on another eBGP peer which you do wish to advertise these to.
What I'd recommend is applying an inbound route-map/policy-statement on AS200/DUT for the ...
1
There are well-known communities called no-export and no-advertise that you can use to tag prefixes to prevent them from being advertised to a different AS or even different internal routers.
Use a route-map to tag the incoming prefixes as you want.
5
Yes, absolutely; there are a variety of ways to accomplish this. I'll suggest two just to give you some inspiration.
Match Protocol option
On your route-map toward the BGP neighbors, you can match protocol connected in a stanza to determine whether you propagate those routes. For example:
route-map to-isp deny 100
description don't announce my connected ...
4
Yes.
It will be dependent on the exact operating system that runs on the router, but generally redistribution is configured on the router level. I.E. apply to all peers.
You can however filters routes that are announced to peers based on various criteria, and especially communities.
So one way of doing this is:
apply a route-map on the "redistribute ...
0
Few points:
The show output above is actually showing multipathing, it is confusing indeed.
You could see:
Accepted Multipath and Accepted MultipathContrib for secondary (this has some further consequences in BGP processing)
In order to validate, take a look at the forwarding table, e.g
show route forwarding-table destination 1.1.1.1/32 (should show both ...
1
If you do show route 1.1.1.1/32 extensive you should see another field Junos calls protocol next-hop which may be less confusing. In the output you've pasted, it is listing all selected, adjacent next-hops, which are determined by resolving the next-hops to the protocol next-hop.
For example, if the protocol next-hop 198.51.100.100 is several layer-3 hops ...
0
I assume you care about BGP state following that of interface.
Since BFD can't be used you are out of options for sub-second liveliness detection, which brings you to BGP keepalives. Both platforms support 1 sec intervals (on Junos you'd configure hold-time of 3 which is 3x1sec), with 3x multiplier, you are down to 3 sec. Not necessarily a great idea, and ...
-1
Take a look at EEM, otherwise known as embedded event manager. You can configure an applet that takes a specific action (...including downing an interface) when a given even occurs (such as your upstream interface going down). There are examples in the link provided, but the basic idea is that you'll configure an interface tracking group that will watch ...
-1
"Link State Tracking" is the feature you seek. I'm not sure it's supported on NX-OS, or that switch.
SUMMARY STEPS
1. configure terminal
2. link state track [ number ]
3. interface [ interface-id ]
4. link state group [ number ] {upstream | downstream}
5. end
Configuring Link State Tracking (1)
Configuring Link State Tracking (2)
0
If your transit providers are willing to configure BFD with you, yes. That's its intended use.
Top 50 recent answers are included
