Hi
For the MPLS L3VPN the answer is that the next hop attribute needs to be
an address from the default VRF and if the peering is happening in a VRF
context, there is no address from the default VRF you could use as next
hop other than self.
This can be rather inconvenient as there are advan
I'd like to add that one major advantage is limiting next-hops, thus
labels in your network. This is not just theoretical concern but there
are plenty of practical networks using practical hardware where you
simply cannot expose all next-hops to every node.
On 1 December 2017 at 17:30, Ken Chase
On an IX, without next-hop-self peer A leaking peer B's routes they receive to
C will have C send direct to B on the IX (assuming flat layer 3 addressing,
and not multiple little /30s or /96s everywhere or something - do any
exchanges do that?)
This may seem more efficient than sending C's traffic
> Section 9.1.2.1 of RFC 4271 seems to address this.
> A few points from that section:
> - The BGP NEXT_HOP can not recursively resolve (directly or indirectly)
> through the BGP route.
> - Only the longest matching route should be considered when resolving the
> BGP NEXT_HOP.
> - Do not consi
On Sep 30, 2010, at 3:37 PM, Randy Bush wrote:
> it seems it gets the bgp route for 147.28.0.0/16 and then can not
> resolve the next hop. it would not recurse to the default exit.
>
> of course it was solved by
>
>ip route 147.28.0.0 255.255.0.0 42.666.77.11
>
> but i do not really under
On Sep 30, 2010, at 5:37 PM, Randy Bush wrote:
> i was recently bitten by a cousin of this
>
> research router getting an ebgp multi-hop full feed from 147.28.0.1
> (address is relevant)
>
> it is on a lan with a default gateway 42.666.77.11 (address not
> relevant), so it has
>
>ip route
On Sep 30, 2010, at 4:57 PM, Randy Bush wrote:
>>> it seems it gets the bgp route for 147.28.0.0/16 and then can not
>>> resolve the next hop. it would not recurse to the default exit.
>>>
>>> of course it was solved by
>>>ip route 147.28.0.0 255.255.0.0 42.666.77.11
>>> but i do not real
>> it seems it gets the bgp route for 147.28.0.0/16 and then can not
>> resolve the next hop. it would not recurse to the default exit.
>>
>> of course it was solved by
>> ip route 147.28.0.0 255.255.0.0 42.666.77.11
>> but i do not really understand in my heart why i needed to do this.
>
>
> it seems it gets the bgp route for 147.28.0.0/16 and then can not
> resolve the next hop. it would not recurse to the default exit.
>
> of course it was solved by
> ip route 147.28.0.0 255.255.0.0 42.666.77.11
> but i do not really understand in my heart why i needed to do this.
Neither do
On Thu, Sep 30, 2010 at 11:56:06PM +0100, Heath Jones wrote:
>
> Its interesting, I was heavy into cisco years back and then juniper
> for a while. Going back to cisco now is great (always good for me to
> keep my exposure up), but there is just so much unclear in it's CLI.
> It wasn't until go
>> show bgp ipv4 unicast 100.10.0.0/16 why-chosen
>> Would be insanely useful.
> Been in JUNOS "show route" since day one, and IMHO is easily in the top
> 10 list of why I still buy Juniper instead of Cisco despite all the
> $%^&*ing bugs these days.
Its interesting, I was heavy into cisco years
On Thu, Sep 30, 2010 at 07:01:19AM -0700, Leo Bicknell wrote:
> I have suggested more than a few times to vendors that the command:
>
> show bgp ipv4 unicast 100.10.0.0/16 why-chosen
>
> Would be insanely useful.
Been in JUNOS "show route" since day one, and IMHO is easily in the top
10 list of
> last time severall years ago on cisco I used a route-map to rewrite the
> next-hop.
> route-map xx-in permit 10
> set ip next-hop 42.666.77.11
> route-map xx-out permit 10
> set ip next-hop x.x.x.x
>
> neighbor 147.28.0.1 remote-as yyy
> neighbor 147.28.0.1 ebgp-multihop 8
> neighbo
i was recently bitten by a cousin of this
research router getting an ebgp multi-hop full feed from 147.28.0.1
(address is relevant)
it is on a lan with a default gateway 42.666.77.11 (address not
relevant), so it has
ip route 0.0.0.0 0.0.0.0 42.666.77.11
massive flapping results.
it seem
Because the path was broken everytime the bgp session was established and
rewriting the routing table with more specific routes?
- Original Message -
From: "Randy Bush"
To: "North American Network Operators Group"
Sent: Thursday, 30 September, 2010 2:37:43 PM
Subje
i was recently bitten by a cousin of this
research router getting an ebgp multi-hop full feed from 147.28.0.1
(address is relevant)
it is on a lan with a default gateway 42.666.77.11 (address not
relevant), so it has
ip route 0.0.0.0 0.0.0.0 42.666.77.11
massive flapping results.
it se
On Thu, 2010-09-30 at 07:01 -0700, Leo Bicknell wrote:
> I have suggested more than a few times to vendors that the command:
>
> show bgp ipv4 unicast 100.10.0.0/16 why-chosen
>
> Would be insanely useful.
+1 for that, in a similar manner to packet-tracer on ASAs.
Peter
In a message written on Thu, Sep 30, 2010 at 10:49:17AM +0100, Heath Jones
wrote:
> Is there an easy way to see which iBGP routes are not being selected
> due to next-hop not being in IGP?
I have suggested more than a few times to vendors that the command:
show bgp ipv4 unicast 100.10.0.0/16 why
Cheers Jeff.
I thought i'd give that a go, but it doesnt seem to be working for some reason!
(This is without next-hop in IGP)
AS5000_LA#show ip bgp
BGP table version is 3, local router ID is 10.0.0.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r
Yes, I believe the command is "show ip bgp rib-failure". This shows routes that
are in the BGP table, theoretically eligible to be used as actual
traffic-forwarding routes, but are failing to be inserted into the Routing
Information Base (RIB) for one reason or another. I don't have a lab router
20 matches
Mail list logo
