[j-nsp] EBGP multihop, prevent next-hop self on advertisement to an IBGP peer
Bourgeois, Jacob (Jake)** CTR **
bourgeois at alcatel-lucent.com
Wed Mar 28 14:58:40 EST 2007
This is expected behavior. Remember that l3vpn is meant to tunnel traffic
inside labels, and by default when ibgp NH is found in inet3, router knows
to push a label on it and send to remote PE. If NH were found to be the CE
address space, you have no tunnel built to it, therefore no label is pushed,
and 9 times out of 10, your router doesn't know how to route some remote
customers traffic.
See section 4.2.2 of rfc 2547 where this is explained.
Thanks and Regards,
Jake Bourgeois
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Anton Smith
Sent: Wednesday, March 28, 2007 6:09 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] EBGP multihop, prevent next-hop self on advertisement to an
IBGP peer
Hi all,
I am having a problem with a J series router. I have a network as below:
R1---mp-ibgp----R2----multihop-ebgp----R3
The ebgp session between R2 and R3 is a normal EBGP multihop session.
Let us say that it is between a PE and another box located somewhere on
the internet.
The mp-ibgp session between R1 and R2 is used for advertising vpnv4
prefixes.
The BGP session between R2 and R3 terminates inside a VRF on R2.
My problem is that R2 is rewriting the next-hop for the routes from R3
when it advertises them on to R1.
I am definitely not setting next-hop self anywhere on R2.
When I show received routes for the routes from R3, I get the following
output:
admin at j-peering-gw1> show route receive-protocol bgp z.z.z.z
<snip>
vrf-internet.inet.0: 216203 destinations, 363085 routes (216203 active,
0 holddown, 2 hidden)
Prefix Nexthop MED Lclpref AS path
* x.x.x.x/19 z.z.z.z 0 12345 I
At this stage, the next-hop, z.z.z.z is intact and is the desired
next-hop that I want advertised on to R1.
When I show route extensive, things also *seem* (to me) to be ok
(apologies if the following output is not very clean, I have also
sanitised it a bit to replace IP addresses):
admin at j-peering-gw1> show route table vrf-internet x.x.x.x/19 extensive
------------------------------------------------------------------------
vrf-internet.inet.0: 216037 destinations, 362760 routes (216037 active,
0 holddown, 2 hidden)
x.x.x.x/19 (1 entry, 1 announced)
TSI:
Page 0 idx 0 Type 1 val c4b5f30
*BGP Preference: 170/-101
Next-hop reference count: 4
Source: z.z.z.z
Next hop: 172.17.100.26 via fe-0/0/0.0, selected
Label operation: Push 493, Push 109(top)
Protocol next hop: z.z.z.z
Indirect next hop: 8884af8 264765
State: <Active Ext>
Peer AS: 12345
Age: 23:48:05 Metric: 0 Metric2: 1
Task: BGP_39532.z.z.z.z+37854
Announcement bits (3): 0-BGP RT Background 1-KRT
2-Resolve tree 2
AS path: 12345I
Communities: 1234:1234
Localpref: 100
Router ID: 5.6.7.8
Indirect next hops: 1
Protocol next hop: z.z.z.z Metric: 1
Indirect next hop: 8884af8 264765
Indirect path forwarding next hops: 1
Next hop: 172.17.100.26 via fe-0/0/0.0
10.0.0.0/30 Originating RIB: vrf-internet.inet.0
Metric: 1 Node path
count: 1
Indirect nexthops: 1
Protocol Nexthop: 3.3.3.3 Metric: 1
Push 493
Indirect nexthop: 89fae04 264578
Indirect path forwarding nexthops: 1
Nexthop: 172.17.100.26 via
fe-0/0/0.0
3.3.3.3/32 Originating RIB: inet.3
Metric: 1
Node path count: 1
Forwarding nexthops: 1
Nexthop: 172.17.100.26 via
fe-0/0/0.0
-----------------------------------------------------------------------
The protocol next-hop looks correct, z.z.z.z.
However, when I show advertised routes towards R1, I see that the
next-hop has been changed:
admin at j-peering-gw1> show route advertising-protocol bgp 4.4.4.4
x.x.x.x/19 extensive
vrf-internet.inet.0: 216241 destinations, 363161 routes (216241 active,
0 holddown, 2 hidden)
* x.x.x.x/19 (1 entry, 1 announced)
BGP group route-reflectors type Internal
Route Distinguisher: 1111:1111
VPN Label: 107440
Nexthop: Self
Flags: Nexthop Change
MED: 0
Localpref: 100
AS path: [4321] 12345 I
Communities: 1234:1234 target:1111:1111
Notice the lines that read "Nexthop: Self" and "Flags: Nexthop Change".
The flag seems strange to me, does anybody know what it means?
Nowhere in my policies do I set next-hop self:
admin at j-peering-gw1> show configuration | match next-hop
admin at j-peering-gw1>
I have tried configuring, under the multihop bgp section, the parameter
'no-nexthop-change' but this does not have any effect ( I have set this
both for the ibgp group and the ebgp group to no avail ).
This behaviour seems unexpected to me - as though the box is
automatically setting next-hop self for some reason. Normally in all of
my experience (albeit with plain ibgp/ebgp setups) you need to
explicitly turn on next-hop self.
Does anybody have any idea why this is happening? My suspicion is it is
definitely something to do with multihop bgp.
Any help much appreciated, since at present I am completely stuck. And I
am aware that under normal circumstances this would be desirable
behaviour, but in this particular instance I have a specific requirement
that the next-hop not be changed.
Best regards,
Anton
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list