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
Hello everyone,
Question, what are the true benefits to using the next-hop self feature,
doesn't matter what vendor.
Most information I see is just to make sure you have reach-ability for external
routes via IBGP, but what if all your IBGP knows the eBGP links?
Is there a added benefit to usi
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
>
> On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva)
> wrote:
>
> > Segment routing (SR) could/would certainly work with single-stack v6
> > and enable MPLS forwarding.
>
> Certainly, but based on the Paris meeting, it was not high up on
On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva)
wrote:
> Segment routing (SR) could/would certainly work with
> single-stack v6 and enable MPLS forwarding.
Certainly, but based on the Paris meeting, it was not high
up on the agenda.
So we will, likely, have to rely on other solutions
Mark,
> about leveraging SR to push native IPv6 support into MPLS,
Segment routing (SR) could/would certainly work with single-stack v6 and enable
MPLS forwarding.
Cheers,
Rajiv
> On May 5, 2014, at 3:36 AM, "Mark Tinka" wrote:
>
>> On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:
on.
Cheers,
Rajiv
> On May 3, 2014, at 5:29 AM, "Måns Nilsson" wrote:
>
> Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices
> IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600
> Quoting Chris Grundemann (cgrundem...@gmail.com):
&
Randy Bush writes:
>> Ah, so you're in the camp that a /10 given to one organization for
>> their private use would have been better than reserving that /10 for
>> _everyone_ to use. We'll have to agree to disagree there.
>
> you forced an rfc allocation. that makes public space, and is and wil
On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:
> You mean the SR right?
No, I mean:
draft-george-mpls-ipv6-only-gap-05
The draft looks at issues that need to be fixed for MPLS to
run in a single-stack IPv6 network.
Of course, there is other work that is looking at fixing
L
> > Ideally, we would have a solution where an entire MPLS infrastructure
> > could be built without v4 space, demoting
> > v4 to a legacy application inside a VRF, but the MPLS standards wg
> > seems content with status quo.
>
> There is work ongoing in the MPLS IETF WG on identifying the gaps th
On Saturday, May 03, 2014 11:26:27 AM Måns Nilsson wrote:
> Ideally, we would have a solution where an entire MPLS
> infrastructure could be built without v4 space, demoting
> v4 to a legacy application inside a VRF, but the MPLS
> standards wg seems content with status quo.
There is work ongoing
> Ah, so you're in the camp that a /10 given to one organization for
> their private use would have been better than reserving that /10 for
> _everyone_ to use. We'll have to agree to disagree there.
you forced an rfc allocation. that makes public space, and is and will
be used as such. you want
On 5/3/14, 10:36 AM, Chris Grundemann wrote:
> On Sat, May 3, 2014 at 3:58 AM, Randy Bush wrote:
>> a good number of us use that kinky /10 behind home nats and encourage
>> everyone to do so. it was a sick deal and should be treated as such,
>> just more 1918.
>
> A good number of folks use othe
On Sat, May 3, 2014 at 3:58 AM, Randy Bush wrote:
> a good number of us use that kinky /10 behind home nats and encourage
> everyone to do so. it was a sick deal and should be treated as such,
> just more 1918.
A good number of folks use other folks IP space in all kinds of
strange and kinky way
On Sat, May 3, 2014 at 3:26 AM, Måns Nilsson wrote:
> The fact that you need v4 space to build a MPLS backbone is a very good
> reason to not waste a /10 on CGN crap.
Ah, so you're in the camp that a /10 given to one organization for
their private use would have been better than reserving that /1
a good number of us use that kinky /10 behind home nats and encourage
everyone to do so. it was a sick deal and should be treated as such,
just more 1918.
randy
Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices
IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting
Chris Grundemann (cgrundem...@gmail.com):
> Would you expound a bit on what you mean here? I don't quite follow but I
> am very
Hi Mans,
On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson wrote:
> This is a field where v4 next-hops are essential to make things
> work. In that context, allocating 100.64.0.0/10 to CGN was
> especially un-clever...
>
Would you expound a bit on what you mean here? I don't quite follow but I
am ve
Hi Adam,
Works just fine on any relatively modern router.
Cheers,
Jeff
-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk]
Sent: Tuesday, October 23, 2012 12:31 AM
To: nanog@nanog.org
Subject: MP-BGP next hop tracking delay 0
I was wondering whether you have some
I was wondering whether you have some experience with setting of the next
hop tracking delay value for BGP to 0 for critical changes please
There's gonna be only a few prefixes registered with BGP so far, around 150+
adam
> 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
Charlottesville, VA
From: Heath Jones [hj1...@gmail.com]
Sent: Thursday, September 30, 2010 5:49 AM
To: nanog@nanog.org
Subject: BGP next-hop
Hi all,
Is there an easy way to see which iBGP routes are not being selected
due to next-hop not being in IGP?
Before
Hi all,
Is there an easy way to see which iBGP routes are not being selected
due to next-hop not being in IGP?
Before and after IGP route added shown below, note both are marked as valid..
-- BEFORE IGP--
AS5000_LA#show ip bgp
BGP table version is 5, local router ID is 10.0.0.5
Status codes: s s
39 matches
Mail list logo
