[j-nsp] Hidden IPv6 Route inside BGP - but why?
Hello, we have a problem with a IPv6 route in the lab, which is hidden for us. What could be the reason for that? In the most documents we can only find information around next-hop unusable but this does not seem to be the reason for us. Following excerpt has been grabbed from one of our machines: m...@ourmachine show route table inet6.0 2001:4178::/32 hidden extensive inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147 hidden) 2001:4178::/32 (1 entry, 0 announced) BGP /-101 Next hop type: Indirect Next-hop reference count: 147 Source: :::xxx Next hop type: Router, Next hop index: 1355 Next hop: ::xxx::: via xe-1/2/0.0, selected Protocol next hop: xxx:::fc1 Indirect next hop: fa12958 1048605 State: Hidden Int Ext Local AS: OurAS Peer AS: OurAS Age: 4:50:19Metric2: 10 Task: BGP_OurAS.xxx:::fc1+179 AS path: 8767 15456 I Localpref: 100 Router ID: x.x.x.x Indirect next hops: 1 Protocol next hop: :::fc1 Metric: 10 Indirect next hop: fa12958 1048605 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: ::xxx:xxx:: via xe-1/2/0.0 xxx:::xxx/128 Originating RIB: inet6.0 Metric: 10 Node path count: 1 Forwarding nexthops: 1 Nexthop: ::xxx:xxx:: via xe-1/2/0.0 Is there something pointing to a reason or a solution for this? Kind regards, Hendrik ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] equal-cost, multi-next-hop static routes
A router of my acquaintance in Toronto has:
jab...@agg01.tor-switch show version | grep Base
JUNOS Base OS boot [8.5R4.3]
JUNOS Base OS Software Suite [8.5R4.3]
jab...@agg01.tor-switch
and also
routing-options {
static {
route 69.165.166.240/28 next-hop [ 69.165.167.156
69.165.167.20 ];
}
forwarding-table {
export load-balancing-policy;
}
}
policy-options {
policy-statement load-balancing-policy {
then {
load-balance per-packet;
}
}
}
The idea is to do some crude load-sharing of outbound traffic from
this router towards 69.165.166.240/28. Both 69.165.167.156
69.165.167.20 are reachable via interface/connected routes.
The router only ever seems to select one next-hop. Interface counters
elsewhere confirm that only one path is being used for traffic towards
the customer.
jab...@agg01.tor-switch show route 69.165.166.240/28 detail
inet.0: 326067 destinations, 886829 routes (325604 active, 70
holddown, 453765 hidden)
69.165.166.240/28 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 262255
Next-hop reference count: 3
Next hop: 69.165.167.20 via ae0.146
Next hop: 69.165.167.156 via ae0.115, selected
State: Active Int Ext
Local AS: 5645
Age: 4d 18:54:21
Task: RT
Announcement bits (4): 0-KRT 2-RT 5-BGP RT Background
6-Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch
jab...@agg01.tor-switch show route 69.165.167.20 detail
inet.0: 326088 destinations, 886857 routes (325655 active, 47
holddown, 453807 hidden)
69.165.167.16/29 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 2
Next hop: via ae0.146, selected
State: Active Int
Local AS: 5645
Age: 4d 19:09:55
Task: IF
Announcement bits (3): 2-RT 5-BGP RT Background 6-
Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch show route 69.165.167.156 detail
inet.0: 326096 destinations, 886861 routes (325655 active, 55
holddown, 453813 hidden)
69.165.167.152/29 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 2
Next hop: via ae0.115, selected
State: Active Int
Local AS: 5645
Age: 4d 19:06:28
Task: IF
Announcement bits (3): 2-RT 5-BGP RT Background 6-
Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch
What am I missing?
Joe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] equal-cost, multi-next-hop static routes
On Mon, Jul 20, 2009 at 11:02:31AM -0400, Joe Abley wrote:
A router of my acquaintance in Toronto has:
load-balance per-packet;
The idea is to do some crude load-sharing of outbound traffic from this
router towards 69.165.166.240/28. Both 69.165.167.156 69.165.167.20 are
reachable via interface/connected routes.
per-packet really means per flow. It may be that all the flows
you've looked at happen to be hashing one way. You can modify the
hash-key to include layer 4 information:
[edit forwarding-options hash-key]
family inet {
layer-3;
layer-4;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] L2VPN not forwarding
Hi all,
I am attempting to test out an L2VPN that connects two GE interfaces on two
separate J2320 routers via MPLS over GRE. I have the MPLS tunnel up and
working and can ping using the 'ping mpls l2vpn' command. My problem is when I
connect my devices to each GE port on the 2320s, I am unable to ping across.
Here's the relevant portions of the configs:
J2320-1:
ge-0/0/0 {
mtu 1560;
unit 0 {
family inet {
mtu 1532;
address 172.16.1.2/30;
}
}
}
gr-0/0/0 {
unit 1 {
tunnel {
source 10.0.0.3;
destination 10.0.0.4;
ttl 10;
}
family inet {
mtu 1500;
address 172.20.100.2/30;
}
family mpls;
}
}
ge-0/0/1 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
}
}
...
rsvp {
interface gr-0/0/0.1;
}
mpls {
label-switched-path to_j2320-2 {
to 10.0.0.4;
}
interface gr-0/0/0.1;
interface ge-0/0/1.0;
}
bgp {
group test {
local-address 10.0.0.3;
family l2vpn {
signaling;
}
export ibgp;
peer-as 65000;
neighbor 10.0.0.4;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0 {
passive;
}
interface gr-0/0/0.1 {
metric 65000;
}
}
}
layer2-test {
instance-type l2vpn;
interface ge-0/0/1.0;
route-distinguisher 10.0.0.3:65000;
vrf-import l2vpn-import;
vrf-export l2vpn-export;
protocols {
l2vpn {
encapsulation-type ethernet;
no-control-word;
site j2320-top {
site-identifier 1;
interface ge-0/0/1.0 {
remote-site-id 2;
}
}
}
}
}
J2320-2:
interfaces {
ge-0/0/0 {
mtu 1560;
unit 0 {
family inet {
mtu 1532;
address 172.16.2.2/30;
}
}
}
gr-0/0/0 {
unit 1 {
tunnel {
source 10.0.0.4;
destination 10.0.0.3;
ttl 10;
}
family inet {
mtu 1500;
address 172.20.100.1/30;
}
family mpls;
}
}
ge-0/0/1 {
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
}
}
}
protocols {
rsvp {
interface gr-0/0/0.1;
}
mpls {
label-switched-path to_j2320-1 {
to 10.0.0.3;
}
interface gr-0/0/0.1;
interface all;
}
bgp {
group test {
local-address 10.0.0.4;
family l2vpn {
signaling;
}
export ibgp;
peer-as 65000;
neighbor 10.0.0.3;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-0/0/0.0;
interface gr-0/0/0.1 {
metric 65000;
}
}
}
}
routing-instances {
layer2-test {
instance-type l2vpn;
interface ge-0/0/1.0;
route-distinguisher 10.0.0.4:65000;
vrf-import l2vpn-import;
vrf-export l2vpn-export;
protocols {
l2vpn {
encapsulation-type ethernet;
no-control-word;
site j2320-bot {
site-identifier 2;
interface ge-0/0/1.0 {
remote-site-id 1;
}
}
}
}
}
}
I'm pretty sure I'm missing something obvious, but this is the first time I've
messed with L2VPNs.
thanks,
evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hidden IPv6 Route inside BGP - but why?
Hello, thanks for your comment! We are not using a RR at the edge of this scenario but the problem is located on another location. 1. The routes are received from a RR and advertised to one of our core systems. 2. From here the routes are propageted to our iBGP which is IPv6 enabled. All received routes are usable at this location (at the RR). Our other systems, which are getting the prefixes via iBGP aren't able to install the routes into the table inet6.0 - but there is no hint like unusable next-hop. Excerpt from the machine connected to the RR: m...@machine1 show route table inet6.0 2001:7b0::/32 inet6.0: 422 destinations, 424 routes (180 active, 0 holddown, 242 hidden) + = Active Route, - = Last Active, * = Both 2001:7b0::/32 *[BGP/170] 3d 09:34:37, MED 101, localpref 100, from 2001:7f8::1a27:5051:c09d AS path: 8881 I to 2001:7f8::22b1:192:80 via ge-7/1/0.0 Excerpt from the machine meshed in the iBGP: m...@machine2 show route table inet6.0 2001:7b0::/32 hidden inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147 hidden) + = Active Route, - = Last Active, * = Both 2001:7b0::/32 [BGP ] 11:39:05, MED 101, localpref 100, from 2001:4110::fc1 AS path: 8881 I to fe80::214:f6ff:fea4:9df2 via xe-1/2/0.0 Does this help us to get a step forward with this problem? Thanks in advance, Hendrik Am 20.07.2009 um 16:34 schrieb Andy Wu: are you using RR ? make sure your RR has routes for PE's loopback address in inet.3 table, or inet6.3 table , ( by placing RR in LSP path , or create a static 0/0 route and put into inet.3 / inet6.3 table ) , otherwise RR won't reflect the routes and all IPv6 routes are shown as hidden On Mon, Jul 20, 2009 at 10:05 AM, Hendrik Kahmann hendrik.kahm...@ewetel.de wrote: Hello, we have a problem with a IPv6 route in the lab, which is hidden for us. What could be the reason for that? In the most documents we can only find information around next-hop unusable but this does not seem to be the reason for us. Following excerpt has been grabbed from one of our machines: m...@ourmachine show route table inet6.0 2001:4178::/32 hidden extensive inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147 hidden) 2001:4178::/32 (1 entry, 0 announced) BGP /-101 Next hop type: Indirect Next-hop reference count: 147 Source: :::xxx Next hop type: Router, Next hop index: 1355 Next hop: ::xxx::: via xe-1/2/0.0, selected Protocol next hop: xxx:::fc1 Indirect next hop: fa12958 1048605 State: Hidden Int Ext Local AS: OurAS Peer AS: OurAS Age: 4:50:19Metric2: 10 Task: BGP_OurAS.xxx:::fc1+179 AS path: 8767 15456 I Localpref: 100 Router ID: x.x.x.x Indirect next hops: 1 Protocol next hop: :::fc1 Metric: 10 Indirect next hop: fa12958 1048605 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: ::xxx:xxx:: via xe-1/2/0.0 xxx:::xxx/128 Originating RIB: inet6.0 Metric: 10 Node path count: 1 Forwarding nexthops: 1 Nexthop: ::xxx:xxx:: via xe-1/2/0.0 Is there something pointing to a reason or a solution for this? Kind regards, Hendrik ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hidden IPv6 Route inside BGP - but why?
I assume that the related protocol and indirect forwarding next hops are
reachable?
I'd issue a show route resolution unresolved just to be sure.
Is there any chance you have an import policy filtering that route? IIRC,
import route filters result in a hidden routes.
[edit]
regr...@vpn04# run show route 2.2.2.2 table inet.0 hidden
inet.0: 36 destinations, 37 routes (34 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
2.2.2.2/32 [BGP ] 00:00:07, localpref 100, from 10.255.14.181
AS path: I
via so-1/0/0.0, label-switched-path to_r1
[edit]
regr...@vpn04# show policy-options policy-statement test
from {
route-filter 2.2.2.2/32 exact;
}
then reject;
regr...@vpn04# show protocols bgp
traceoptions {
file bgp_r4 size 10m;
flag all detail;
}
group int {
type internal;
local-address 10.255.14.174;
import test;
family inet {
unicast;
}
family inet-vpn {
unicast;
multicast;
}
neighbor 10.255.14.181;
neighbor 10.255.14.175;
}
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Hendrik Kahmann
Sent: Monday, July 20, 2009 1:52 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Hidden IPv6 Route inside BGP - but why?
Hello,
thanks for your comment!
We are not using a RR at the edge of this scenario but the problem is located
on another location.
1. The routes are received from a RR and advertised to one of our core systems.
2. From here the routes are propageted to our iBGP which is IPv6 enabled. All
received routes are usable at this location (at the RR).
Our other systems, which are getting the prefixes via iBGP aren't able to
install the routes into the table inet6.0 - but there is no hint like unusable
next-hop.
Excerpt from the machine connected to the RR:
m...@machine1 show route table inet6.0 2001:7b0::/32
inet6.0: 422 destinations, 424 routes (180 active, 0 holddown, 242
hidden)
+ = Active Route, - = Last Active, * = Both
2001:7b0::/32 *[BGP/170] 3d 09:34:37, MED 101, localpref 100,
from 2001:7f8::1a27:5051:c09d
AS path: 8881 I
to 2001:7f8::22b1:192:80 via ge-7/1/0.0
Excerpt from the machine meshed in the iBGP:
m...@machine2 show route table inet6.0 2001:7b0::/32 hidden
inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147
hidden)
+ = Active Route, - = Last Active, * = Both
2001:7b0::/32 [BGP ] 11:39:05, MED 101, localpref 100, from
2001:4110::fc1
AS path: 8881 I
to fe80::214:f6ff:fea4:9df2 via xe-1/2/0.0
Does this help us to get a step forward with this problem?
Thanks in advance,
Hendrik
Am 20.07.2009 um 16:34 schrieb Andy Wu:
are you using RR ? make sure your RR has routes for PE's loopback
address in inet.3 table, or inet6.3 table , ( by placing RR in LSP
path , or create a static 0/0 route and put into inet.3 / inet6.3
table ) , otherwise RR won't reflect the routes and all IPv6 routes
are shown as hidden
On Mon, Jul 20, 2009 at 10:05 AM, Hendrik Kahmann
hendrik.kahm...@ewetel.de
wrote:
Hello,
we have a problem with a IPv6 route in the lab, which is hidden for
us. What could be the reason for that? In the most documents we can
only find information around next-hop unusable but this does not
seem to be the reason for us.
Following excerpt has been grabbed from one of our machines:
m...@ourmachine show route table inet6.0 2001:4178::/32 hidden
extensive
inet6.0: 184 destinations, 189 routes (37 active, 0 holddown, 147
hidden)
2001:4178::/32 (1 entry, 0 announced)
BGP /-101
Next hop type: Indirect
Next-hop reference count: 147
Source: :::xxx
Next hop type: Router, Next hop index: 1355
Next hop: ::xxx::: via xe-1/2/0.0,
selected
Protocol next hop: xxx:::fc1
Indirect next hop: fa12958 1048605
State: Hidden Int Ext
Local AS: OurAS Peer AS: OurAS
Age: 4:50:19Metric2: 10
Task: BGP_OurAS.xxx:::fc1+179
AS path: 8767 15456 I
Localpref: 100
Router ID: x.x.x.x
Indirect next hops: 1
Protocol next hop: :::fc1 Metric: 10
Indirect next hop: fa12958 1048605
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: ::xxx:xxx:: via
xe-1/2/0.0
xxx:::xxx/128 Originating RIB: inet6.0
Metric: 10 Node path
count: 1
Forwarding nexthops: 1
Re: [j-nsp] equal-cost, multi-next-hop static routes
Hi,
You should really do
show route forwarding-table destination 69.165.166.240/28 detail|extensive
show route only shows the RPD's (routing process) view of the route.
Load balancing policy is applied when the routes are installed in the
kernel forwarding-table (same as PFE forwarding-table). Only there you
can see the 2 next-hops for the route.
The other problem of router using only one agg ethernet link while
forwarding traffic is related to load balance hash calculation which in
turn depends on the traffic type. If source/destination pairs are not
varying much, router may not yield good hash values.
Another thing to add is, if you are using multiple agg ethernet links
for load balancing, you might want to try this knob.
set forwarding-options load-balance indexed-next-hop
Depending upon the release this knob may or may not be hidden. This knob
produces better hashing results for load balancing over multiple agg
ethernet links.
Thanks,
Nilesh.
Joe Abley wrote:
A router of my acquaintance in Toronto has:
jab...@agg01.tor-switch show version | grep Base
JUNOS Base OS boot [8.5R4.3]
JUNOS Base OS Software Suite [8.5R4.3]
jab...@agg01.tor-switch
and also
routing-options {
static {
route 69.165.166.240/28 next-hop [ 69.165.167.156
69.165.167.20 ];
}
forwarding-table {
export load-balancing-policy;
}
}
policy-options {
policy-statement load-balancing-policy {
then {
load-balance per-packet;
}
}
}
The idea is to do some crude load-sharing of outbound traffic from
this router towards 69.165.166.240/28. Both 69.165.167.156
69.165.167.20 are reachable via interface/connected routes.
The router only ever seems to select one next-hop. Interface counters
elsewhere confirm that only one path is being used for traffic towards
the customer.
jab...@agg01.tor-switch show route 69.165.166.240/28 detail
inet.0: 326067 destinations, 886829 routes (325604 active, 70
holddown, 453765 hidden)
69.165.166.240/28 (1 entry, 1 announced)
*Static Preference: 5
Next hop type: Router, Next hop index: 262255
Next-hop reference count: 3
Next hop: 69.165.167.20 via ae0.146
Next hop: 69.165.167.156 via ae0.115, selected
State: Active Int Ext
Local AS: 5645
Age: 4d 18:54:21
Task: RT
Announcement bits (4): 0-KRT 2-RT 5-BGP RT Background
6-Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch
jab...@agg01.tor-switch show route 69.165.167.20 detail
inet.0: 326088 destinations, 886857 routes (325655 active, 47
holddown, 453807 hidden)
69.165.167.16/29 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 2
Next hop: via ae0.146, selected
State: Active Int
Local AS: 5645
Age: 4d 19:09:55
Task: IF
Announcement bits (3): 2-RT 5-BGP RT Background 6-
Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch show route 69.165.167.156 detail
inet.0: 326096 destinations, 886861 routes (325655 active, 55
holddown, 453813 hidden)
69.165.167.152/29 (1 entry, 1 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 2
Next hop: via ae0.115, selected
State: Active Int
Local AS: 5645
Age: 4d 19:06:28
Task: IF
Announcement bits (3): 2-RT 5-BGP RT Background 6-
Resolve tree 1
AS path: I
AS path: Recorded
jab...@agg01.tor-switch
What am I missing?
Joe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
