[j-nsp] ndp traffic reflected
Hello Take a look at this tcpdump: 16:56:54.663623 e6:5d:37:8f:d8:7b > 33:33:ff:a9:dd:f5, ethertype IPv6 (0x86dd), length 86: 2a00:7660:242a:::1 > ff02::1:ffa9:ddf5: ICMP6, neighbor solicitation, who has fe80::222:7ff:fea9:ddf5, length 32 16:56:54.663804 00:22:07:a9:dd:f5 > e6:5d:37:8f:d8:7b, ethertype IPv6 (0x86dd), length 86: fe80::222:7ff:fea9:ddf5 > 2a00:7660:242a:::1: ICMP6, neighbor advertisement, tgt is fe80::222:7ff:fea9:ddf5, length 32 16:56:54.668111 e6:5d:37:8f:d8:7b > 00:22:07:a9:dd:f5, ethertype IPv6 (0x86dd), length 86: fe80::222:7ff:fea9:ddf5 > 2a00:7660:242a:::1: ICMP6, neighbor advertisement, tgt is fe80::222:7ff:fea9:ddf5, length 32 The first line is a mx204 with the MAC e6:5d:37:8f:d8:7b sending a NDP packet to multicast MAC 33:33:ff:a9:dd:f5. The second line is a CPE with MAC 00:22:07:a9:dd:f5 responding to the mx204. So far all is normal. The third line is the mx204 echoing back the reply from the CPE?! What could make the mx204 echo back the NDP response? Also would it not be good practice to use a link local address when querying for link local addresses? Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] wrong IP in traceroutes
Hello
Sometimes we get the wrong IP back in traceroutes. Here is an example:
gigabit@kviknet01:~$ mtr -n -r -c3 185.24.168.181
Start: 2021-05-15T14:58:20+
HOST: kviknet01.ring.nlnog.netLoss% Snt Last Avg Best Wrst StDev
1.|-- 212.237.176.65 0.0% 30.2 0.2 0.2 0.2 0.0
2.|-- 185.107.12.27 0.0% 30.5 0.5 0.4 0.5 0.0
3.|-- 45.145.95.250 0.0% 30.3 0.3 0.3 0.3 0.0
4.|-- 10.10.123.70.0% 3 10.1 12.6 10.1 16.5 3.4
(more hops)
Hop #3 should have been 185.24.168.29. Instead we get 45.145.95.250 which
is unfortunate because that address belongs to a customer and it is not
even within the IP ranges allocated to us. The customer owns his own
address space directly with RIPE.
The interface is this:
admin@gc-edge1# show interfaces ps44
description "Kviknet peering BGP";
anchor-point {
lt-0/0/0;
}
vlan-tagging;
unit 0 {
encapsulation ethernet-vpls;
}
unit 40 {
alias kviknet;
vlan-id 40;
family inet {
address 185.24.168.29/30;
}
family inet6 {
address 2a00:7660:100:26::2/126;
}
}
The IP address from the traceroute is this one:
admin@gc-edge1# show interfaces ps3
anchor-point {
lt-0/0/0;
}
unit 0 {
encapsulation ethernet-ccc;
}
unit 1 {
family inet {
address 45.145.95.250/29;
}
family inet6 {
address 2a00:7660:100:1::2/125;
}
}
The traffic did obviously not go via ps3 as that connects directly to a
single homed customer.
Is this a bug? Can I do something to get a better choice for IP address in
traceroutes? It appears to be linked to the fact this goes via a "ps"
interface.
Thanks,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] evpn irb default gateway
When I add this to the configuration the acx5448 irb will route traffic:
set routing-instances internet routing-options static route 0.0.0.0/1
next-hop 128.0.0.0 resolve no-readvertise
However this does not work:
set routing-instances internet routing-options static route 0.0.0.0/0
next-hop 128.0.0.0 resolve no-readvertise
I can apparently have a working system by splitting my 0.0.0.0/0 into two
halves 0.0.0.0/1 and 128.0.0.0/1. Not very satisfying. There has to be an
explanation and fix?
Regards,
Baldur
Den tor. 13. maj 2021 kl. 00.33 skrev Baldur Norddahl :
> Hello
>
> My evpn with irb on an acx5448 is going ok except for one very strange
> problem. The router refuses to use the default route 0.0.0.0/0 when
> routing traffic via the irb interface.
>
> The router itself will ping just fine:
>
> baldur@formervangen-core3> ping routing-instance internet 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=24.574 ms
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=12.770 ms
> ^C
> --- 8.8.8.8 ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 12.770/18.672/24.574/5.902 ms
>
> baldur@formervangen-core3> show route table internet.inet.0 8.8.8.8
>
> internet.inet.0: 16 destinations, 46 routes (16 active, 0 holddown, 0
> hidden)
> + = Active Route, - = Last Active, * = Both
>
> 0.0.0.0/0 *[BGP/170] 00:11:57, localpref 100, from 10.0.0.248
> AS path: I, validation-state: unverified
> > to 10.99.0.18 via xe-0/0/0.0, Push 17, Push
> 1228(top)
> [BGP/170] 1w2d 20:16:40, localpref 100, from 10.0.0.249
> AS path: I, validation-state: unverified
> > to 10.99.0.18 via xe-0/0/0.0, Push 17, Push
> 1228(top)
> [BGP/170] 1w2d 20:30:50, localpref 100, from 10.0.0.249
> AS path: I, validation-state: unverified
> > to 10.99.0.18 via xe-0/0/0.0, Push 21, Push
> 1223(top)
> [BGP/170] 00:11:46, localpref 100, from 10.0.0.248
> AS path: I, validation-state: unverified
> > to 10.99.0.18 via xe-0/0/0.0, Push 21, Push
> 1223(top)
>
> But done from a host connected to the evpn nothing happens:
>
> root@lab2:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> ^C
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 0 received, 100% packet loss, time 2029ms
>
> However I made a dummy 128.0.0.0/1 route and now I can ping half of the
> internet?
>
> root@lab2:~# ping 185.107.12.60
> PING 185.107.12.60 (185.107.12.60) 56(84) bytes of data.
> 64 bytes from 185.107.12.60: icmp_seq=1 ttl=61 time=0.902 ms
> 64 bytes from 185.107.12.60: icmp_seq=2 ttl=61 time=0.860 ms
> 64 bytes from 185.107.12.60: icmp_seq=3 ttl=61 time=0.898 ms
> ^C
> --- 185.107.12.60 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
> rtt min/avg/max/mdev = 0.860/0.886/0.902/0.018 ms
>
> This 128.0.0.0/1 route looks just the same as the 0.0.0.0/0 route:
>
> baldur@formervangen-core3> show route table internet.inet.0 128.0.0.0/1
> exact
>
> internet.inet.0: 16 destinations, 46 routes (16 active, 0 holddown, 0
> hidden)
> + = Active Route, - = Last Active, * = Both
>
> 128.0.0.0/1*[BGP/170] 00:15:12, localpref 100, from 10.0.0.248
> AS path: I, validation-state: unverified
> > to 10.99.0.18 via xe-0/0/0.0, Push 17, Push
> 1228(top)
>
> The irb interface is simple:
>
> baldur@formervangen-core3> show configuration interfaces irb.15
> virtual-gateway-accept-data;
> family inet {
> address 185.24.168.180/26 {
> virtual-gateway-address 185.24.168.129;
> }
> }
> family inet6 {
> address 2a00:7660:0:24::1044/64 {
> virtual-gateway-address 2a00:7660:0:24::1;
> }
> }
>
> root@lab2:~# ip route
> default via 185.24.168.129 dev v15
> 185.24.168.128/26 dev v15 proto kernel scope link src 185.24.168.181
> root@lab2:~# ip neigh show 185.24.168.129
> 185.24.168.129 dev v15 lladdr 00:00:5e:00:01:01 REACHABLE
>
> I noticed that the host can access everything that formervangen-core3 has
> in the routing table except for 0.0.0.0/0. This includes the 128.0.0.0/1
> static reject route I created on one of the route reflectors.
>
> The rest of the configuration:
>
> baldur@formervangen-core3> show configuration routing-instances server15
> instance-type evpn;
> protocols {
> evpn {
> default-gateway no-gateway-community;
> }
>
[j-nsp] evpn irb default gateway
Hello
My evpn with irb on an acx5448 is going ok except for one very strange
problem. The router refuses to use the default route 0.0.0.0/0 when routing
traffic via the irb interface.
The router itself will ping just fine:
baldur@formervangen-core3> ping routing-instance internet 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=24.574 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=12.770 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.770/18.672/24.574/5.902 ms
baldur@formervangen-core3> show route table internet.inet.0 8.8.8.8
internet.inet.0: 16 destinations, 46 routes (16 active, 0 holddown, 0
hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 00:11:57, localpref 100, from 10.0.0.248
AS path: I, validation-state: unverified
> to 10.99.0.18 via xe-0/0/0.0, Push 17, Push 1228(top)
[BGP/170] 1w2d 20:16:40, localpref 100, from 10.0.0.249
AS path: I, validation-state: unverified
> to 10.99.0.18 via xe-0/0/0.0, Push 17, Push 1228(top)
[BGP/170] 1w2d 20:30:50, localpref 100, from 10.0.0.249
AS path: I, validation-state: unverified
> to 10.99.0.18 via xe-0/0/0.0, Push 21, Push 1223(top)
[BGP/170] 00:11:46, localpref 100, from 10.0.0.248
AS path: I, validation-state: unverified
> to 10.99.0.18 via xe-0/0/0.0, Push 21, Push 1223(top)
But done from a host connected to the evpn nothing happens:
root@lab2:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms
However I made a dummy 128.0.0.0/1 route and now I can ping half of the
internet?
root@lab2:~# ping 185.107.12.60
PING 185.107.12.60 (185.107.12.60) 56(84) bytes of data.
64 bytes from 185.107.12.60: icmp_seq=1 ttl=61 time=0.902 ms
64 bytes from 185.107.12.60: icmp_seq=2 ttl=61 time=0.860 ms
64 bytes from 185.107.12.60: icmp_seq=3 ttl=61 time=0.898 ms
^C
--- 185.107.12.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.860/0.886/0.902/0.018 ms
This 128.0.0.0/1 route looks just the same as the 0.0.0.0/0 route:
baldur@formervangen-core3> show route table internet.inet.0 128.0.0.0/1
exact
internet.inet.0: 16 destinations, 46 routes (16 active, 0 holddown, 0
hidden)
+ = Active Route, - = Last Active, * = Both
128.0.0.0/1*[BGP/170] 00:15:12, localpref 100, from 10.0.0.248
AS path: I, validation-state: unverified
> to 10.99.0.18 via xe-0/0/0.0, Push 17, Push 1228(top)
The irb interface is simple:
baldur@formervangen-core3> show configuration interfaces irb.15
virtual-gateway-accept-data;
family inet {
address 185.24.168.180/26 {
virtual-gateway-address 185.24.168.129;
}
}
family inet6 {
address 2a00:7660:0:24::1044/64 {
virtual-gateway-address 2a00:7660:0:24::1;
}
}
root@lab2:~# ip route
default via 185.24.168.129 dev v15
185.24.168.128/26 dev v15 proto kernel scope link src 185.24.168.181
root@lab2:~# ip neigh show 185.24.168.129
185.24.168.129 dev v15 lladdr 00:00:5e:00:01:01 REACHABLE
I noticed that the host can access everything that formervangen-core3 has
in the routing table except for 0.0.0.0/0. This includes the 128.0.0.0/1
static reject route I created on one of the route reflectors.
The rest of the configuration:
baldur@formervangen-core3> show configuration routing-instances server15
instance-type evpn;
protocols {
evpn {
default-gateway no-gateway-community;
}
}
vlan-id 15;
l3-interface irb.15;
interface xe-0/0/10.15;
vrf-target target:60876:15;
baldur@formervangen-core3> show configuration routing-instances internet
instance-type vrf;
routing-options {
auto-export;
}
interface irb.15;
interface lo0.1;
vrf-target target:60876:0;
inactive: vrf-table-label;
Thanks,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] evpn trouble
We have two datacenter locations each with a mx204 and a pair of acx5448. The mx204 is used for ip transit, peering and subscriber management. The acx5448 is for connecting servers. Remember the mx204 does not have a lot of ports. We also have an outside plant currently with 26 locations, each with an acx710 and a gpon switch from another vendor. This forms a 100G / 25G MPLS backbone with multiple rings and other complex topology. We are currently replacing older MPLS switches from another vendor with the acx710. Juniper managed to bring down the price of both mx204 and acx710 to a level where we could switch from using chinese equipment. I would not say it is exactly cheap however :-). The acx710 box is significantly cheaper than mx204 and I do not think we could afford this project without it. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] evpn trouble
Hello Roger
Thank you for the comment. I will research mac-vrf which is new to me. We
are using MPLS and are migrating from VPLS. The ACX5448 / ACX710 do not
have virtual-switch support (but mac-vrf appears to be available). Aside
from mac-vrf my choices are evpn and evpn-vpws. Apparently subscriber
management, which we use, only supports evpn-vpws at this time.
This thread was about our server / vm hosting setup however. We only have
four server vlans and so I created one evpn instance per vlan.
Customer traffic is q-in-q. Not a problem for evpn-vpws but that has
limitations which may be a problem for me. I wish Juniper had made support
for more than just evpn-vpws as transport interface for "ps" interfaces. I
may be forced to stay with VPLS for the time being.
Thanks,
Baldur
Den tir. 11. maj 2021 kl. 15.45 skrev Roger Wiklund :
> Hi
>
> What data plane are you using, MPLS or VXLAN?
>
> Instance-type evpn is VLAN-Based Service. I.E one VLAN per EVPN instance,
> is this what you want?
> Configuring EVPN with VLAN-Based Service | EVPN User Guide | Juniper
> Networks TechLibrary
> <https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/task/evpn-routing-instance-vlan-based-configuring.html>
>
> If you want to run multiple VLANs in one EVPN instance you can use
> VLAN-Aware Service (instance-type virtual-switch or in default
> virtual-switch) where each VLAN/VNI will have a unique RT.
> Understanding VLAN-Aware Bundle and VLAN-Based Service for EVPN | EVPN
> User Guide | Juniper Networks TechLibrary
> <https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/concept/evpn-vlan-services-overview-qfx-series.html>
>
> With that said from Junos 20.4R1 there's a new mac-vrf instance-type where
> you can more clearly define the different services
> instance-type mac-vrf
> service-type vlan-aware / vlan-based / vlan-bundle
> Microsoft Word - EVPN_VxLAN_MAC-VRF_NCE.docx (juniper.net)
> <https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/EVPN_VxLAN_MAC-VRF.pdf>
>
> Not sure when MX/ACX will gain this feature though.
>
> Regards
> Roger
>
>
>
> On Sat, May 8, 2021 at 12:12 AM Baldur Norddahl wrote:
>
>> Hello
>>
>> I found the answer to this one. On ACX5448 and ACX710 the
>> routing-interface
>> statement does absolutely nothing. Instead you need to use the
>> undocumented
>> l3-interface statement at the same place. On the MX204 platform the
>> l3-interface statement does not exist. I will list the two configs below
>> for those that might need to know.
>>
>> Compare mx204 config:
>>
>> baldur@formervangen-edge1# show routing-instances evpntest
>> instance-type evpn;
>> protocols {
>> evpn {
>> default-gateway advertise;
>> }
>> }
>> vlan-id 20;
>> routing-interface irb.20;
>> interface xe-0/1/7.21;
>> vrf-target target:60876:20;
>>
>> And acx710 / acx5448:
>>
>> baldur@formervangen-core4# show routing-instances evpntest
>> instance-type evpn;
>> protocols {
>> evpn {
>> default-gateway advertise;
>> }
>> }
>> vlan-id 20;
>> l3-interface irb.20;
>> interface xe-0/0/0.20;
>> vrf-target target:60876:20;
>>
>> Regards,
>>
>> Baldur
>> ___
>> 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] evpn trouble
Hello
I found the answer to this one. On ACX5448 and ACX710 the routing-interface
statement does absolutely nothing. Instead you need to use the undocumented
l3-interface statement at the same place. On the MX204 platform the
l3-interface statement does not exist. I will list the two configs below
for those that might need to know.
Compare mx204 config:
baldur@formervangen-edge1# show routing-instances evpntest
instance-type evpn;
protocols {
evpn {
default-gateway advertise;
}
}
vlan-id 20;
routing-interface irb.20;
interface xe-0/1/7.21;
vrf-target target:60876:20;
And acx710 / acx5448:
baldur@formervangen-core4# show routing-instances evpntest
instance-type evpn;
protocols {
evpn {
default-gateway advertise;
}
}
vlan-id 20;
l3-interface irb.20;
interface xe-0/0/0.20;
vrf-target target:60876:20;
Regards,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] evpn trouble
Hello
I am deploying EVPN and while it works, we are having some issues. Here is
the first one:
An EVPN instance configured for testing on a MX204 and an ACX5448 both
running 21.1R1. The have the same exact configuration except for the IP
address of the IRB interface:
baldur@formervangen-core3# show interfaces irb.20
family inet {
address 185.24.168.92/29;
}
[edit]
baldur@formervangen-core3# show routing-instances evpntest
instance-type evpn;
protocols {
evpn;
}
vlan-id 20;
routing-interface irb.20;
interface xe-0/0/42.20;
vrf-target target:60876:20;
[edit]
baldur@formervangen-core3# show interfaces xe-0/0/42
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 20 {
encapsulation vlan-bridge;
vlan-id 20;
}
Also irb.20 is in a layer 3 VRF called "internet".
On the MX204 the interface irb.20 comes online but on the ACX5448 the
irb.20 interface stays in the state hardware-down:
baldur@formervangen-core3# run show interfaces irb.20
Logical interface irb.20 (Index 76) (SNMP ifIndex 563)
Flags: Hardware-Down Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Bandwidth: 1Gbps
Routing Instance: None Bridging Domain: None
Input packets : 0
Output packets: 0
Protocol inet, MTU: 1514
Max nh cache: 10, New hold nh limit: 10, Curr nh cnt: 0, Curr
new hold cnt: 0, NH drop cnt: 0
Flags: Sendbcast-pkt-to-re, Is-Primary
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Destination: 185.24.168.88/29, Local: 185.24.168.92, Broadcast:
185.24.168.95
Protocol multiservice, MTU: Unlimited
In fact I can not get the irb interface to go up at all on the ACX5448
platform. Is IRB unsupported? Without it a lot of EVPN features are not
available.
In our production environment the mx204 routers do not have any servers
directly connected. The irb interface will therefore not come online. But
since the acx5448 switches refuse to have their own irb interfaces, I need
the mx204 to do the task. My solution right now is to add a dummy interface
to the evpn instance on the mx204. Is there a better way? Why did Juniper
not include a knop to bring irb up even without any physical interfaces
active in the vpn?
Thanks,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] arp bug workaround (mx204)
Hello
I finally had time to implement this, but unfortunately I get this error at
commit:
admin@interxion-edge1# commit
error: Underlying interface for vlan/ip demux can't be ps
error: configuration check-out failed
This is on mx204 version 21.1R1.11.
Was something changed to disallow ip demux on top of VPLS ps interfaces? Is
there an alternative to the ps interface? Krasimir appears to have a
successful test, what is the difference?
If you need the full config that I am trying to commit, please send a
direct mail. It contains user IP addresses so I am not happy about having
that on the mailing list.
Thanks,
Baldur
Den tor. 5. nov. 2020 kl. 12.48 skrev Krasimir Avramski :
> Hi Baldur,
>
> Indeed, you are persistent in asking for that issue ;-). The idea is to
> use the RFC1925 6a) - "It is always possible to add another level of
> indirection."
>
> krasi@test# show interfaces ps201 unit 60
> demux-source inet;
> vlan-tags outer 2301 inner 1711;
> family inet {
> unnumbered-address lo0.1;
> }
>
> krasi@test# show interfaces demux0
> unit 60 {
> demux-options {
> underlying-interface ps201.60;
> }
> family inet {
> demux-source {
> 185.24.168.2/32;
> }
> unnumbered-address lo0.1 preferred-source-address 185.24.168.1;
> }
> }
> unit 61 {
> demux-options {
> underlying-interface ps201.60;
> }
> family inet {
> demux-source {
> 212.237.105.194/32;
> }
> unnumbered-address lo0.1 preferred-source-address 212.237.105.1;
> }
> }
>
> krasi@test# show routing-instances internet routing-options
> static {
> route 185.24.168.2/32 {
> qualified-next-hop demux0.60;
> }
> route 212.237.105.194/32 {
> qualified-next-hop demux0.61;
> }
> }
>
> krasi@test# run show interfaces demux0.60 |match "Pref|Under"
> Underlying interface: ps201.60 (Index 528)
> Family Inet Source prefixes, total 1
> Prefix: 185.24.168.2/32
> Preferred source address: 185.24.168.1
>
>
> krasi@test# run show interfaces demux0.61 |match "Pref|Under"
> Underlying interface: ps201.60 (Index 528)
> Family Inet Source prefixes, total 1
> Prefix: 212.237.105.194/32
> Preferred source address: 212.237.105.1
>
> krasi@test# run monitor traffic interface demux0.60 no-resolve
>
> 13:29:05.274236 Out arp who-has 185.24.168.2 tell 185.24.168.1
> 13:29:18.976788 Out arp who-has 185.24.168.2 tell 185.24.168.1
>
> krasi@test# run monitor traffic interface demux0.61 no-resolve
> .
> 13:30:01.788921 Out arp who-has 212.237.105.194 tell 212.237.105.1
> 13:30:15.788642 Out arp who-has 212.237.105.194 tell 212.237.105.1
>
> Btw, you can use only one demux ifl for the extra ip address and set
> appropriate preferred-source-address on ps201.60 and demux0.60
>
> HTH,
> Krasi
>
> On Wed, 4 Nov 2020 at 22:02, Baldur Norddahl wrote:
>
>> Hello
>>
>> I am trying to work around an arp bug in Junos. The issue is as follows:
>>
>> set interfaces ps201 unit 60 vlan-tags outer 2301
>> set interfaces ps201 unit 60 vlan-tags inner 1711
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> set routing-instances internet routing-options static route
>> 185.24.168.2/32
>> qualified-next-hop <http://185.24.168.2/32qualified-next-hop> ps201.60
>> mac-address b4:75:0e:15:38:9e
>> set routing-instances internet routing-options static route
>> 212.237.105.194/32 qualified-next-hop ps201.60 mac-address
>> d8:07:b6:46:7a:31
>> set routing-instances internet interface ps201.60
>> set protocols router-advertisement interface ps201.60
>>
>> The above works but hardcodes the MAC address of the customer. This is
>> necessary because there is no way to make Junos choose the correct source
>> address for ARP requests for both 185.24.168.2/32 and 212.237.105.194/32
>> at
>> the same time. You could do either of the following but not both:
>>
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> preferred-source-address 185.24.168.1
>> set interfaces ps201 unit 60 family inet unnumbered-address lo0.1
>> preferred-source-address 212.237.105.1
>>
>> With 185.24.168.1/24 and 212.237.105.1/24 both being configured on lo0.1.
>>
>> There exists an algorithm, unfortunately only mandatory for IPv6, that
>> automatically chooses the closest available address from the list of
>> possible candidate addresses. But Junos does not implement this for IPv4
>> (unknown if i
[j-nsp] user defined variables from radius
Hello Under "dynamic-profile xxx variables" I can configure user defined variables. I get the impression that somehow these variables can be filled in by radius but how? Radius attributes are to my knowledge predefined. Say I create a variable called "foobar" - what would I do with my freeradius config to supply that variable? Thanks, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] arp bug workaround (mx204)
Den man. 9. nov. 2020 kl. 22.11 skrev Gert Doering : > Hi, > > On Wed, Nov 04, 2020 at 08:55:11PM +0100, Baldur Norddahl wrote: > > So I am searching for work arounds. For example if I could make an ACL > that > > rewrites the vlans matching an IP address, such that the two IPs were on > > two different VLANs, I could solve this by having two interfaces for the > > customer. Alas that does not seem to be possible. > > Why don't you just route the second (and further) IP to the primary IP > as gateway address? Can JunOS not resolve this indirect next-hop? > > In a greenfield deployment I would do exactly that. I am also considering telling future customers that is the only supported way. But a lot of existing customers have a setup with a switch instead of a router, with multiple routers or servers directly connected. A few customers even run VRRP at their end. I have high hopes for the solution outlined by Krasimir. I will report back on that as soon as I can get time to test it. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] arp bug workaround (mx204)
Hello I am trying to work around an arp bug in Junos. The issue is as follows: set interfaces ps201 unit 60 vlan-tags outer 2301 set interfaces ps201 unit 60 vlan-tags inner 1711 set interfaces ps201 unit 60 family inet unnumbered-address lo0.1 set routing-instances internet routing-options static route 185.24.168.2/32 qualified-next-hop ps201.60 mac-address b4:75:0e:15:38:9e set routing-instances internet routing-options static route 212.237.105.194/32 qualified-next-hop ps201.60 mac-address d8:07:b6:46:7a:31 set routing-instances internet interface ps201.60 set protocols router-advertisement interface ps201.60 The above works but hardcodes the MAC address of the customer. This is necessary because there is no way to make Junos choose the correct source address for ARP requests for both 185.24.168.2/32 and 212.237.105.194/32 at the same time. You could do either of the following but not both: set interfaces ps201 unit 60 family inet unnumbered-address lo0.1 preferred-source-address 185.24.168.1 set interfaces ps201 unit 60 family inet unnumbered-address lo0.1 preferred-source-address 212.237.105.1 With 185.24.168.1/24 and 212.237.105.1/24 both being configured on lo0.1. There exists an algorithm, unfortunately only mandatory for IPv6, that automatically chooses the closest available address from the list of possible candidate addresses. But Junos does not implement this for IPv4 (unknown if it does for IPv6). Instead it will always use the primary address from lo0.1 if specified, otherwise a random address. The CPE will ignore ARP requests from the juniper router that have the wrong source address. Our only solution has been to use the mac-address parameter to hardcode the address, which sidesteps the issue by not using ARP. This is also a problem with subscriber management. We use the above configuration for customers that paid for an extra IP address. Often the extra address is from a different series than his original address, because all addresses have been assigned. We can not retroactively fix that as we have an existing customer base and customers do not like to be told to change their static configuration, DNS names etc. So I am searching for work arounds. For example if I could make an ACL that rewrites the vlans matching an IP address, such that the two IPs were on two different VLANs, I could solve this by having two interfaces for the customer. Alas that does not seem to be possible. Anyone have an idea how to create some sort of work around that does not force the MAC address to be hardcoded? Thanks, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] set MED only on empty
Hello Metric zero should work, I do not know why I did not think of that. Thanks, Baldur Den lør. 19. sep. 2020 kl. 21.13 skrev Eduardo Schoedler : > Hi Baldur, > > Try match metric, with some tests you can define empty (maybe zero?). > > > https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-match-conditions-in-routing-policy-terms.html > > > > Regards. > > > Em sáb., 19 de set. de 2020 às 12:59, Baldur Norddahl > escreveu: > >> Hello >> >> >> >> I want to set MED (metric) only when the peer did not specify a MED value. >> >> The idea being that peers that set MED have a reason for their choice, but >> >> if no MED value is set, I am going to set it to MED=(latency_to_peer_in_ms >> >> + 1000). That way we will prefer the route with lowest latency. >> >> >> >> But I can not figure out how to match on no MED value in a policy. There >> >> must be a way to do this? >> >> >> >> Thanks, >> >> >> >> Baldur >> >> ___ >> >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> -- > Eduardo Schoedler > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] set MED only on empty
Hello I want to set MED (metric) only when the peer did not specify a MED value. The idea being that peers that set MED have a reason for their choice, but if no MED value is set, I am going to set it to MED=(latency_to_peer_in_ms + 1000). That way we will prefer the route with lowest latency. But I can not figure out how to match on no MED value in a policy. There must be a way to do this? Thanks, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
On 30.07.2020 10.29, Mark Tinka wrote: The ACX710 was clearly built for one or two mobile network operators. There is no doubt about that. Juniper have been making boxes that support both AC and DC for yonks. Hardened and regular. What's so special about the ACX710? In 2020? To be fair there are more than two Juniper customers world wide that are using 48V DC. To my knowledge DC power is very common in the telco world. What is special about ACX710 is probably the price point. They want a device for a certain market without loosing the ability to sell a higher priced device for another market. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
On 29.07.2020 23.18, Mark Tinka wrote: On 29/Jul/20 20:18, Baldur Norddahl wrote: I am also going to get a few ACX5448 for our datacentre locations. I am still considering getting some AC to DC powersupplies for the ACX710 because the cost saving is considerable. It is not like finding AC to DC devices is hard - every laptop comes with one (yea I know too little voltage). If you are deploying 20, not a major issue. If you're deploying several-hundred or several-thousands units, this is not a small issue. Not going to claim what is or is not a small issue for anyone here. Just saying that one rack unit external power supplies are plentiful and cheap. Like this one (just the first result on Google): https://www.simplypowersupply.com/Rack-Mount-Power-Supply/RCP-1000-48-Meanwell-48Vdc-1000W-Rack-Mount-Power-Supply.aspx We only have two datacentre locations and for those two location I would consider getting something like that. But I am probably going to go with the ACX5448 anyway because I could find a use for the extra 100G ports. The 20 locations are at the incumbents CO locations where 48 volt DC with battery and sometimes generator backup is what you get. You could get 230V AC at these locations but it would be without backup. In the future I might also get some locations in street cabinets, where I would put a standard DC UPS of the kind where you have a couple 12V batteries in series to make up the 48 volt, the equipment connected directly to the battery bank and a charger continuously charging the batteries. This is very cheap and extremely stable. The ACX710 device is environmentally hardened and clearly made for exactly that kind of deployment. I see that ACX710 is not as much made for a specific customer as it is NOT made for a group of customers: the datacenter customers are supposed to buy the more expensive ACX5448. But said datacenter customers can spend one rack unit on an external DC powersupply and go with it anyway. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
I am planning to deploy ACX710 with maybe 20 units (which for us is a huge number). We would have ordered DC in any case, so that is a non issue. We will have them at CO buildings were DC is what you get and maybe in the future in road side cabinets, where DC is the easy way to have some battery backup. I am also going to get a few ACX5448 for our datacentre locations. I am still considering getting some AC to DC powersupplies for the ACX710 because the cost saving is considerable. It is not like finding AC to DC devices is hard - every laptop comes with one (yea I know too little voltage). Our purpose is to replace our MPLS core with new gear that has deep buffers and better support for traffic engineering etc. These will be P and PE routers mostly doing L2VPN. We will have a 100G ring topology of ACX710 devices moving MPLS packets and terminating L2VPN. Seems to be a perfect fit to me. I am not interested in the older ACX devices which lacks buffers and is probably not much better than the gear we want to replace. Regards Baldur ons. 29. jul. 2020 16.25 skrev Mark Tinka : > > > On 29/Jul/20 15:49, Eric Van Tol wrote: > > We ran into this, too. We signed up to beta test at the beginning of > this year and nowhere, not even in discussions with our SE (who also wasn't > told by Juniper), was it mentioned it was a DC-only device. Imagine my > surprise when I received the box and it was DC only. Such a disappointment. > > The messaging we got from them earlier in the year about trying out > their new Metro-E box was that we would be happy with it, considering > that every Metro-E solution they've thrown at us since 2008 has fallen > flat, splat! > > Come game-time, even our own SE was blindsided by this DC-only support > on the ACX710. Proper show-stopper. > > At any rate, the story is that they should be pushing out some new > ACX7xxx boxes from next year, which should have AC support (to you > psych. majors: more for the general public, and not the custom-built > ACX710). > > I'm not sure I can be that patient, so I'm sniffing at Nokia's new > Metro-E product line. The problem is so far, as with Juniper and Cisco, > they've gone down the Broadcom route (some boxes shipping with Qumran, > others with Jericho 2, and on-paper, they are already failing some of > our forwarding requirements. > > It's not easy... > > Mark. > > ___ > 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
[j-nsp] vrrp on a vpls / ps interface
Hello
I noticed that VRRP on a ps interface does not seem to work. Is there
anything I can do about that or is that not supported?
This is on MX204. Exact same configuration is working fine on et-0/0/0.16.
admin@gc-edge1> show configuration interfaces ps2
anchor-point {
lt-0/0/0;
}
flexible-vlan-tagging;
unit 0 {
description Server;
encapsulation ethernet-vpls;
}
unit 16 {
description "Server CGN";
vlan-tags outer 99 inner 16;
family inet {
address 100.127.254.2/24 {
vrrp-group 159 {
virtual-address 100.127.254.1;
priority 10;
preempt;
accept-data;
}
vrrp-group 164 {
virtual-address 100.127.254.7;
priority 10;
preempt;
accept-data;
}
}
}
}
admin@gc-edge1> show vrrp
Interface State Group VR state VR Mode Timer Type Address
et-0/0/0.14 up 161 master Active A 0.113 lcl
10.0.1.159
vip 10.0.1.160
et-0/0/0.14 up 162 backup Active D 2.825 lcl
10.0.1.159
vip 10.0.1.1
mas 10.0.1.158
(etc... ps2.16 is not here)
Thanks,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DHCP relay monitoring
Hello On one of my MX204 routers the DHCP relay crashes after some running time and the process stops. It is not restarted automatically but will start again with the following command: admin@gc-edge1> restart dhcp-service error: Junos Dynamic Host Configuration Protocol process is not running Junos Dynamic Host Configuration Protocol process started, pid 72256 I can open a case with JTAC for the cause of the crash, but I am thinking about how to monitor the relay. None of my current monitoring tools detects this situation and it is actually quite critical. With no relay the customers DHCP lease may expire. To a certain extend the customers will be using unicast to the DHCP server and not many will feel it right away, but soon enough we will have customers that can not get online after rebooting their CPE etc. What options do we have for monitoring running processes on the router? Are there other processes than DHCP that should be monitored too? Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] what do do with bug reports
Hello What am I supposed to do with glaring bugs? Are Juniper interested in knowing those or don't they care? In this case I found out that 19.1 behaves badly if you set [system services subscriber-management overrides interfaces family inet receive-gratuitous-arp]. The setting is supposed to enable updating the ARP table when receiving gratuitous ARP from clients. Instead it makes the router reply to those ARP packets, which causes the clients to reject the address. Packet monitor (somewhat shortened): 07:41:05.677882 bpf_flags 0x03, In Juniper PCAP Flags [no-L2, In] -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:xx:xx:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 255, id 0, offset 0, flags [none], proto: UDP (17), length: 319) 185.24.168.248.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 291, xid 0x1b632c2a, Flags [Broadcast] (0x8000) Your-IP 212.237.x.237 DHCP-Message Option 53, length 1: ACK -original packet- 34:21:09:x:x:e1 > Broadcast, ethertype 802.1Q (0x8100), length 4294967292: vlan 301, p 0, ethertype 802.1Q, vlan 545, p 0, ethertype ARP, arp who-has 212.237.x.237 tell 212.237.x.237 07:41:05.686691 bpf_flags 0x00, Out -original packet- e6:5d:37:84:53:17 > 34:21:09:x:x:e1, ethertype ARP (0x0806), length 4294967292: arp reply 212.237.x.237 is-at e6:5d:37:84:53:17 07:41:05.689680 bpf_flags 0x03, In -original packet- PFE proto 2 (ipv4): (tos 0x0, ttl 64, id 24111, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 34:21:09:x:x:e1, length 548, xid 0x1b632c2a, Flags [Broadcast] (0x8000) DHCP-Message Option 53, length 1: Decline ^C 8 packets received by filter The part that is plain wrong is "arp reply 212.237.x.237 is-at e6:5d:37:84:53:17". NO! 212.237.x.237 is actually at 34:21:09:x:x:e1 and by responding to this, the router causes the client to believe something else is using the address. Therefore the client sends Decline back to the DHCP server. Proxy-arp settings makes no difference at all. Doesn't matter if you have it entirely disabled or set to proxy-arp restricted. However disabling receive-gratuitous-arp makes the router stop doing this. If I made a case for this I am sure they will just tell me to disable receive-gratuitous-arp which is exactly what I did. I am just curious if there is any way to report bugs that I will live with as is. It is still clearly something that should get fixed. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
On 22.05.2020 12.42, Baldur Norddahl wrote: However I also need this on a 'ps' interface to support auto configuration with subscriber management. I tried replicating the configuration from xe-0/1/7.424 on ps1.424 and that configuration is accepted by the router but does nothing. Auto configuration does query the radius server. I then tried ethernet-vpls on ps1.0 which works but now I am missing the outer vlan tag. The above should read "Auto configuration does NOT query the radius server". Sorry. Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
Hello
I got this working by changing VPLS encapsulation from tagged to raw and
this config:
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
vpls {
encapsulation-type ethernet;
## 'no-control-word' was inherited from group 'POI-VPLS'
no-control-word;
## 'mac-statistics' was inherited from group 'POI-VPLS'
mac-statistics;
mesh-group 1 {
vpls-id 424;
neighbor 10.9.124.0;
}
}
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
vlan-id all;
interface xe-0/1/7.424;
interface ps1.0;
interface ps1.424; ## 'ps1.424' is not defined
[edit]
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
encapsulation vlan-vpls;
vlan-tags outer 424 inner-range 1-4000;
}
I now get double tagged frames out on interface xe-0/1/7:
10:29:34.667573 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 350: vlan 424, p 0, ethertype 802.1Q, vlan 201, p 0,
ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from 00:22:07:4d:7b:0d, length 300
However I also need this on a 'ps' interface to support auto
configuration with subscriber management. I tried replicating the
configuration from xe-0/1/7.424 on ps1.424 and that configuration is
accepted by the router but does nothing. Auto configuration does query
the radius server. I then tried ethernet-vpls on ps1.0 which works but
now I am missing the outer vlan tag.
baldur@formervangen-edge1# show interfaces ps1
apply-groups AUTO-PS;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation ethernet-vpls;
}
inactive: unit 424 {
encapsulation vlan-vpls;
vlan-tags outer 424 inner-range 1-4000;
}
Packet counters on ps1.424 is counting output packages but
auto-configure is not triggered.
Is there a trick to get the full q-in-q double tagged headers back in
this case?
Thanks,
Baldur
Full config of ps1:
baldur@formervangen-edge1# show interfaces ps1 | display inheritance brief
## 'anchor-point' was inherited from group 'AUTO-PS'
anchor-point {
## 'lt-0/0/0' was inherited from group 'AUTO-PS'
lt-0/0/0;
}
## 'flexible-vlan-tagging' was inherited from group 'AUTO-PS'
flexible-vlan-tagging;
## 'auto-configure' was inherited from group 'AUTO-PS'
auto-configure {
## 'stacked-vlan-ranges' was inherited from group 'AUTO-PS'
stacked-vlan-ranges {
## 'USER-ACCESS-TEST' was inherited from group 'AUTO-PS'
dynamic-profile USER-ACCESS-TEST {
## 'any' was inherited from group 'AUTO-PS'
accept any;
ranges {
## 'any,any' was inherited from group 'AUTO-PS'
any,any;
}
}
## 'authentication' was inherited from group 'AUTO-PS'
authentication {
## 'any' was inherited from group 'AUTO-PS'
packet-types any;
## '$ABC123' was inherited from group 'AUTO-PS'
password "$ABC123";
## 'username-include' was inherited from group 'AUTO-PS'
username-include {
## 'qqvlan' was inherited from group 'AUTO-PS'
user-prefix qqvlan;
## 'vlan-tags' was inherited from group 'AUTO-PS'
vlan-tags;
}
}
## 'access-profile' was inherited from group 'AUTO-PS'
## 'rad' was inherited from group 'AUTO-PS'
access-profile rad;
}
## 'vlan-ranges' was inherited from group 'AUTO-PS'
vlan-ranges {
## 'USER-ACCESS-TEST' was inherited from group 'AUTO-PS'
dynamic-profile USER-ACCESS-TEST {
## 'any' was inherited from group 'AUTO-PS'
accept any;
ranges {
## 'any' was inherited from group 'AUTO-PS'
any;
}
}
## 'authentication' was inherited from group 'AUTO-PS'
authentication {
## 'any' was inherited from group 'AUTO-PS'
packet-types any;
## '$ABC123' was inherited from group 'AUTO-PS'
password "$ABC123";
## 'username-include' was inherited from group 'AUTO-PS'
username-include {
## 'qvlan' was inherited from group 'AUTO-PS'
user-prefix qvlan;
## 'vlan-tags' was inherited from group 'AUTO-PS'
vlan-tags;
}
}
## 'access-profile' was inherited from group 'AUTO-PS'
## 'rad' was inherited from group 'AUTO-PS'
access-profile rad;
}
}
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation ethernet-vpls;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
On 20.05.2020 15.04, Mark Tees wrote:
Assuming 00:22:07:4d:7b:0d is the MAC behind the Juniper and the PCAP
is on NIC of the host connected to the ZTE.
At a guess the ZTE doing something different on ingress than what I am
thinking here.
If you can verify by PCAP on MPLS interface it would be handy to see
what each side is doing in each direction. Juniper MX operations in
this regards have usually been pretty explicit.
Not so easy to interpret but here is a capture of the MPLS packet sent
by the ZTE device. The capture device (a Linux box with bridge) is
sitting in between those the ZTE switch and the Juniper MX204. They
would not usually be directly connected like this, but I am in the lab.
Frame 60: 368 bytes on wire (2944 bits), 368 bytes captured (2944 bits)
Ethernet II, Src: Zte_ba:ef:84 (0c:12:62:ba:ef:84), Dst:
JuniperN_8f:dc:73 (e4:5d:37:8f:dc:73)
MultiProtocol Label Switching Header, Label: 238, Exp: 0, S: 1, TTL: 255
1110 1110 = MPLS Label: 238
000. = MPLS Experimental Bits: 0
...1 = MPLS Bottom Of Label Stack: 1
= MPLS TTL: 255
Data (350 bytes)
Data: 0022074d7b0d810001a881c908004500...
[Length: 350]
ff ff ff ff ff ff 00 22 07 4d 7b 0d 81 00 01 a8 ÿÿ.".M{¨
0010 81 00 00 c9 08 00 45 00 01 48 00 00 00 00 40 11 ...É..E..H@.
0020 79 a6 00 00 00 00 ff ff ff ff 00 44 00 43 01 34 y¦.D.C.4
0030 be 52 01 01 06 00 79 b3 e8 65 2b 95 00 00 00 00 ¾Ry³èe+.
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 ..."
0050 07 4d 7b 0d 00 00 00 00 00 00 00 00 00 00 00 00 .M{.
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 ..c.
0120 53 63 35 01 01 39 02 02 40 37 0e 01 03 06 0c 0f Sc5..9..@7..
0130 1c 2a 2b 42 43 80 84 85 d4 3c 15 45 47 33 30 30 .*+BC...Ô<.EG300
0140 41 2d 57 55 32 31 55 41 43 2d 49 4e 54 45 4e 4f A-WU21UAC-INTENO
0150 0c 0b 49 6e 74 65 6e 6f 5f 37 42 30 41 ff ..Inteno_7B0Aÿ
I pasted that stuff into the packet decoder at https://hpd.gasmi.net/
and surprisingly found out that both outer and inner vlan is present. I
thought it would not transmit the outer vlan. Still does not explain why
I am having trouble then.
I need to go home now but I clearly need to investigate more.
Regards,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS q-in-q
I tried this and we got closer but it is replacing both inner and outer
tags now:
12:48:27.320821 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 350: vlan 424, p 0, ethertype 802.1Q, vlan 424, p 0,
ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from 00:22:07:4d:7b:0d, length 300
That should have been outer 424 inner 201.
The config:
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
encapsulation vlan-vpls;
vlan-id 424;
input-vlan-map pop;
output-vlan-map push;
}
[edit]
baldur@formervangen-edge1# commit
commit complete
[edit]
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
vpls {
## 'ethernet-vlan' was inherited from group 'POI-VPLS'
encapsulation-type ethernet-vlan;
## 'no-control-word' was inherited from group 'POI-VPLS'
no-control-word;
## 'mac-statistics' was inherited from group 'POI-VPLS'
mac-statistics;
mesh-group 1 {
vpls-id 424;
neighbor 10.9.124.0;
}
}
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
interface xe-0/1/7.424;
Regards,
Baldur
On 20.05.2020 14.25, Mark Tees wrote:
You need to get rid of the vlan-id off the routing-instance.
End result I think should be similar to this:
Logical interface ge-1/0/6.888 (Index 650) (SNMP ifIndex 830)
Flags: Up SNMP-Traps 0x0 VLAN-Tag [ 0x8100.888 ] In(pop) Out(push
0x8100.888) Encapsulation: VLAN-VPLS
Yours is pushing 424 on ingress. Unless, you want to be matching on
both tags all you need is this:
set routing-instances VPLS instance-type vpls
set routing-instances VPLS interface ge-1/0/6.888
set interfaces ge-1/0/6 unit 888 encapsulation vlan-vpls
set interfaces ge-1/0/6 unit 888 vlan-id 888
set interfaces ge-1/0/6 unit 888 input-vlan-map pop
set interfaces ge-1/0/6 unit 888 output-vlan-map push
You don't need to say anything about inner tags unless you are wanting
to do an operation on them? It sound like your remote side/ZTE does
the same as what I have mentioned above.
On Wed, 20 May 2020 at 22:13, Baldur Norddahl wrote:
Hello
I am trying the suggestion received so far and now have this configuration:
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
encapsulation vlan-vpls;
vlan-tags outer 424;
input-vlan-map {
push;
vlan-id 424;
}
output-vlan-map pop;
}
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
vpls {
## 'ethernet-vlan' was inherited from group 'POI-VPLS'
encapsulation-type ethernet-vlan;
## 'no-control-word' was inherited from group 'POI-VPLS'
no-control-word;
## 'mac-statistics' was inherited from group 'POI-VPLS'
mac-statistics;
mesh-group 1 {
vpls-id 424;
neighbor 10.9.124.0;
}
}
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
## 'inner-all' was inherited from group 'POI-VPLS'
vlan-id inner-all;
interface xe-0/1/7.424;
baldur@formervangen-edge1# run show interfaces xe-0/1/7
Physical interface: xe-0/1/7, Enabled, Physical link is Up
Interface index: 176, SNMP ifIndex: 541
Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
Flow control: Enabled, Speed Configuration: Auto
Pad to minimum frame size: Disabled
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
CoS queues : 8 supported, 8 maximum usable queues
Schedulers : 0
Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
Input rate : 0 bps (0 pps)
Output rate: 1384 bps (0 pps)
Active alarms : None
Active defects : None
PCS statistics Seconds
Bit errors 3
Errored blocks 3
Interface transmit statistics: Disabled
Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
Input packets : 14
Output packets: 66
Protocol vpls, MTU: 1522
Flags: Is-Primary
Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
Re: [j-nsp] VPLS q-in-q
Hello
I am trying the suggestion received so far and now have this configuration:
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
encapsulation vlan-vpls;
vlan-tags outer 424;
input-vlan-map {
push;
vlan-id 424;
}
output-vlan-map pop;
}
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
vpls {
## 'ethernet-vlan' was inherited from group 'POI-VPLS'
encapsulation-type ethernet-vlan;
## 'no-control-word' was inherited from group 'POI-VPLS'
no-control-word;
## 'mac-statistics' was inherited from group 'POI-VPLS'
mac-statistics;
mesh-group 1 {
vpls-id 424;
neighbor 10.9.124.0;
}
}
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
## 'inner-all' was inherited from group 'POI-VPLS'
vlan-id inner-all;
interface xe-0/1/7.424;
baldur@formervangen-edge1# run show interfaces xe-0/1/7
Physical interface: xe-0/1/7, Enabled, Physical link is Up
Interface index: 176, SNMP ifIndex: 541
Link-level type: Flexible-Ethernet, MTU: 1522, MRU: 1530, LAN-PHY
mode, Speed: 10Gbps, BPDU Error: None, Loop Detect PDU Error: None,
MAC-REWRITE Error: None, Loopback: None, Source filtering: Disabled,
Flow control: Enabled, Speed Configuration: Auto
Pad to minimum frame size: Disabled
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
CoS queues : 8 supported, 8 maximum usable queues
Schedulers : 0
Current address: e4:5d:37:8f:dc:7a, Hardware address: e4:5d:37:8f:dc:7a
Last flapped : 2020-05-20 11:14:05 CEST (02:54:05 ago)
Input rate : 0 bps (0 pps)
Output rate : 1384 bps (0 pps)
Active alarms : None
Active defects : None
PCS statistics Seconds
Bit errors 3
Errored blocks 3
Interface transmit statistics: Disabled
Logical interface xe-0/1/7.424 (Index 82) (SNMP ifIndex 607)
Flags: Up SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.424 ] Native-vlan-id:
424 In(push .424) Out(pop) Encapsulation: VLAN-VPLS
Input packets : 14
Output packets: 66
Protocol vpls, MTU: 1522
Flags: Is-Primary
Logical interface xe-0/1/7.32767 (Index 111) (SNMP ifIndex 605)
Flags: Up SNMP-Traps 0x4004000 VLAN-Tag [ 0x.0 ] Encapsulation:
ENET2
Input packets : 426
Output packets: 456
Protocol multiservice, MTU: Unlimited
Flags: None
However the behaviour did not change. I am stilling receiving only
single tagged frames:
12:11:09.996863 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
It appears the vlan map is completely ignored.
Regards,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VPLS q-in-q
Hello
I am trying to enable transport of q-in-q double tagged frames over VPLS
through our MX204. The remote end is a switch of another brand (ZTE) and
it has some limitations. The outer vlan tag is not transported so I need
the MX204 to add it back before processing. However I can not figure out
how to do this.
My test configuration:
baldur@formervangen-edge1# show routing-instances poi-formervangen |
display inheritance brief
protocols {
vpls {
## 'ethernet-vlan' was inherited from group 'POI-VPLS'
encapsulation-type ethernet-vlan;
## 'no-control-word' was inherited from group 'POI-VPLS'
no-control-word;
## 'mac-statistics' was inherited from group 'POI-VPLS'
mac-statistics;
mesh-group 1 {
vpls-id 424;
neighbor 10.9.124.0;
}
}
}
## 'vpls' was inherited from group 'POI-VPLS'
instance-type vpls;
vlan-id 424;
interface xe-0/1/7.424;
baldur@formervangen-edge1# show interfaces xe-0/1/7
flexible-vlan-tagging;
native-vlan-id 424;
encapsulation flexible-ethernet-services;
unit 424 {
encapsulation vlan-vpls;
vlan-id 424;
}
I have a client injecting some traffic on the remote switch using outer
vlan 424 and inner vlan 201. Remember outer vlan is not transported, so
the L2VPN would only receive single tagged frames with vlan 201. I need
the MX204 to add outer vlan 424 and transmit packets with outer vlan 424
and inner vlan on interface xe-0/1/7. But instead I get this:
11:10:02.303264 00:22:07:4d:7b:0d > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 346: vlan 201, p 0, ethertype IPv4, 0.0.0.0.68 >
255.255.255.255.67: BOOTP/DHCP, Request from 00:22:07:4d:7b:0d, length 300
This is a tcpdump on a Linux server. Vlan 424 is not added and we just
get singled tagged vlan 201 packets :-(.
I have tried all sort of combinations including input and
output-vlan-map but with no success. Anyone have some pointers on how to
accomplish this?
Thanks,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] static arp with unnumbered-address
Hi Krasimir
Exactly what I was looking for. Thanks. Will try it as soon as possible.
Regards
Baldur
tor. 13. feb. 2020 22.53 skrev Krasimir Avramski :
> Hello,
>
> The static arp assignments are possible by borrowing the idea from
> subscriber management access or access-internal routes (subs management
> will do that automatically upon subscriber dhcp binding):
>
> krasi@test# show interfaces ge-0/0/0
> flexible-vlan-tagging;
> encapsulation flexible-ethernet-services;
> unit 10 {
> vlan-tags outer 402 inner 1016;
> family inet {
> unnumbered-address lo0.1;
> }
> }
> krasi@test# show routing-instances internet routing-options
> access-internal {
> route 1.1.1.1/32 {
> qualified-next-hop ge-0/0/0.10 {
> mac-address 00:11:11:11:11:11;
> }
> }
> }
>
> krasi@test# run show route table internet protocol access-internal
> internet.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
> 1.1.1.1/32 *[Access-internal/12] 00:03:51
> > to #0 0.11.11.11.11.11 via ge-0/0/0.10
>
> krasi@test# run show arp no-resolve vpn internet
> MAC Address Address Interface Flags
> 00:11:11:11:11:11 1.1.1.1 ge-0/0/0.10 permanent
>
> HTH,
> Krasi
>
>
> On Thu, 13 Feb 2020 at 15:09, Baldur Norddahl wrote:
>
>> Den tor. 13. feb. 2020 kl. 13.12 skrev Alexander Arseniev <
>> arsen...@btinternet.com>:
>>
>> > Hello,
>> > So. this whole setup is built for saving 2 IP from each /26, correct?
>> >
>>
>> No the purpose is to avoid needing to use a /30 minimum per customer. Lets
>> say we have subnet 192.0.2.0/26:
>>
>> 192.0.2.0 network - unusable
>> 192.0.2.1 default gateway for customers
>> 192.0.2.2 customer1 unit 10 vlan 10
>> 192.0.2.3 customer2 unit 11 vlan 11
>> 192.0.2.4 customer3 unit 12 vlan 12
>> etc
>> 192.0.2.63 broadcast - unusable
>>
>> So each customer is on a different vlan also called the customer vlan
>> (CVLAN) model (actual deployment uses q-in-q). We use /32 routes to each
>> customer, however the customer believes he is part of a /26. This is so
>> multiple customers can share the same gateway IP address.
>>
>> The IP waste is related to the size of the subnet. In this case we choose
>> a
>> /26 which means we lose 3 IPs out of 64. The alternative without using
>> unnumbered address would look like this:
>>
>> 192.0.2.0 network IP unit 10 vlan 10
>> 192.0.2.1 gateway unit 10 vlan 10
>> 192.0.2.2 customer1 unit 10 vlan 10
>> 192.0.2.3 broadcast unit 10 vlan 10
>> 192.0.2.4 network unit 11 vlan 11
>> 192.0.2.5 gateway unit 11 vlan 11
>> 192.0.2.6 customer2 unit 11 vlan 11
>> 192.0.2.7 broadcast unit 11 vlan 11
>> etc
>>
>> Each customer would then live inside his very own /30 and done like that
>> it
>> would probably just work. Nobody wants to do it like that anymore. The
>> waste is 75%.
>>
>> Regards,
>>
>> Baldur
>>
>>
>>
>> > If You reconsider and decide You can afford to waste 2/64 = 3% of Your
>> > IPv4 address estate, then on the face of it, looks like perfect use case
>> > for EVPN with its /32 routes auto-created from ARP.
>> > You can assign multiple 1st IPs from multitude of /26 to each EVPN IRB
>> > interface with proper /26 netmask instead of tinkering with
>> > unnumbered-address.
>> > And if You export these /32 into Your iBGP, the /32 will be routed to
>> > according to usual iBGP rules (local pref|metric etc).
>> > Thanks
>> > Alex
>> >
>> > -- Original Message --
>> > From: "Baldur Norddahl"
>> > To: "Juniper List"
>> > Sent: 13/02/2020 09:50:34
>> > Subject: Re: [j-nsp] static arp with unnumbered-address
>> >
>> > >Hi Alex
>> > >
>> > >Thanks for the reply. Ok I managed to make a bad example. This is
>> actually
>> > >from our running configuration and all the routes are /32 routes. The
>> > issue
>> > >is that the customers have all been assigned IPv4 addresses from random
>> > >subnets. The subnets are usually sized /26 and the first address is
>> > >configured on the router loopback interface, such that customers can
>> use
>> > it
>> > >as the default gateway using proxy arp.
>> > >
>> > >The problem is that arp is not working correctly. When selecting the
>> > source
>> > >address
Re: [j-nsp] static arp with unnumbered-address
Den tor. 13. feb. 2020 kl. 13.12 skrev Alexander Arseniev <
arsen...@btinternet.com>:
> Hello,
> So. this whole setup is built for saving 2 IP from each /26, correct?
>
No the purpose is to avoid needing to use a /30 minimum per customer. Lets
say we have subnet 192.0.2.0/26:
192.0.2.0 network - unusable
192.0.2.1 default gateway for customers
192.0.2.2 customer1 unit 10 vlan 10
192.0.2.3 customer2 unit 11 vlan 11
192.0.2.4 customer3 unit 12 vlan 12
etc
192.0.2.63 broadcast - unusable
So each customer is on a different vlan also called the customer vlan
(CVLAN) model (actual deployment uses q-in-q). We use /32 routes to each
customer, however the customer believes he is part of a /26. This is so
multiple customers can share the same gateway IP address.
The IP waste is related to the size of the subnet. In this case we choose a
/26 which means we lose 3 IPs out of 64. The alternative without using
unnumbered address would look like this:
192.0.2.0 network IP unit 10 vlan 10
192.0.2.1 gateway unit 10 vlan 10
192.0.2.2 customer1 unit 10 vlan 10
192.0.2.3 broadcast unit 10 vlan 10
192.0.2.4 network unit 11 vlan 11
192.0.2.5 gateway unit 11 vlan 11
192.0.2.6 customer2 unit 11 vlan 11
192.0.2.7 broadcast unit 11 vlan 11
etc
Each customer would then live inside his very own /30 and done like that it
would probably just work. Nobody wants to do it like that anymore. The
waste is 75%.
Regards,
Baldur
> If You reconsider and decide You can afford to waste 2/64 = 3% of Your
> IPv4 address estate, then on the face of it, looks like perfect use case
> for EVPN with its /32 routes auto-created from ARP.
> You can assign multiple 1st IPs from multitude of /26 to each EVPN IRB
> interface with proper /26 netmask instead of tinkering with
> unnumbered-address.
> And if You export these /32 into Your iBGP, the /32 will be routed to
> according to usual iBGP rules (local pref|metric etc).
> Thanks
> Alex
>
> -- Original Message --
> From: "Baldur Norddahl"
> To: "Juniper List"
> Sent: 13/02/2020 09:50:34
> Subject: Re: [j-nsp] static arp with unnumbered-address
>
> >Hi Alex
> >
> >Thanks for the reply. Ok I managed to make a bad example. This is actually
> >from our running configuration and all the routes are /32 routes. The
> issue
> >is that the customers have all been assigned IPv4 addresses from random
> >subnets. The subnets are usually sized /26 and the first address is
> >configured on the router loopback interface, such that customers can use
> it
> >as the default gateway using proxy arp.
> >
> >The problem is that arp is not working correctly. When selecting the
> source
> >address for ARP requests, the router is picking a random IP address from
> >the loopback interface instead of the IP address from the subnet that
> >matches what the customer expects. This can be fixed by using:
> >
> >family inet {
> > unnumbered-address lo0.1 preferred-source-address a.b.c.1;
> > }
> >
> >However this does not fix the issue for customers having multiple IP
> >addresses assigned from different subnets. And they are usually using a
> >switch to connect multiple devices, so just routing IP address #2 to IP #1
> >is no good.
> >
> >We come from another platform where this was not a problem. The other
> >platform (ZTE) would do the right thing and do ARP using the correct
> source
> >address without us needing to do anything. The IP addresses have been
> >assigned and used by the customers for years, so we can not just simply
> >change the allocation scheme. It seems Juniper is not truly into a world
> >where wasting addresses with old school /30 to a customer that only needs
> a
> >/32 is not working for us poor sods that were not born into plenty of
> IPv4.
> >
> >Since I do not have any hopes for getting a fix for IP source selection
> for
> >ARP, I was thinking about ways to work around the problem. I believe I
> >could argue to the customers, that they need to register their MAC address
> >with us for each assigned IP. That way the router would not need to do
> ARP.
> >But apparently it is impossible to manually set static arp for interfaces
> >that use unnumbered-address.
> >
> >Regards,
> >
> >Baldur
> >
> >
> >
> >Den tor. 13. feb. 2020 kl. 08.30 skrev Alexander Arseniev <
> >arsen...@btinternet.com>:
> >
> >> Hello,
> >> Firstly, Your example configuration with static /24 routes and
> >> qualified-NH to IFL does not commit - even after fixing the host
> portion -
> >> with error message "subnet routes are not allowed with MAC NH".
> >>
Re: [j-nsp] static arp with unnumbered-address
Hi Alex
Thanks for the reply. Ok I managed to make a bad example. This is actually
from our running configuration and all the routes are /32 routes. The issue
is that the customers have all been assigned IPv4 addresses from random
subnets. The subnets are usually sized /26 and the first address is
configured on the router loopback interface, such that customers can use it
as the default gateway using proxy arp.
The problem is that arp is not working correctly. When selecting the source
address for ARP requests, the router is picking a random IP address from
the loopback interface instead of the IP address from the subnet that
matches what the customer expects. This can be fixed by using:
family inet {
unnumbered-address lo0.1 preferred-source-address a.b.c.1;
}
However this does not fix the issue for customers having multiple IP
addresses assigned from different subnets. And they are usually using a
switch to connect multiple devices, so just routing IP address #2 to IP #1
is no good.
We come from another platform where this was not a problem. The other
platform (ZTE) would do the right thing and do ARP using the correct source
address without us needing to do anything. The IP addresses have been
assigned and used by the customers for years, so we can not just simply
change the allocation scheme. It seems Juniper is not truly into a world
where wasting addresses with old school /30 to a customer that only needs a
/32 is not working for us poor sods that were not born into plenty of IPv4.
Since I do not have any hopes for getting a fix for IP source selection for
ARP, I was thinking about ways to work around the problem. I believe I
could argue to the customers, that they need to register their MAC address
with us for each assigned IP. That way the router would not need to do ARP.
But apparently it is impossible to manually set static arp for interfaces
that use unnumbered-address.
Regards,
Baldur
Den tor. 13. feb. 2020 kl. 08.30 skrev Alexander Arseniev <
arsen...@btinternet.com>:
> Hello,
> Firstly, Your example configuration with static /24 routes and
> qualified-NH to IFL does not commit - even after fixing the host portion -
> with error message "subnet routes are not allowed with MAC NH".
> Secondly, You could have second static 198.51.100.0/24 resolve via 1st
> /32:
> set routing-instances internet routing-options static route 192.0.2.11/32
> qualified-next-hop et-0/0/0.2766
> set routing-instances internet routing-options static route
> 198.51.100.0/24 next-hop 192.0.2.11 resolve
> Thanks
> Alex
>
> -- Original Message --
> From: "Baldur Norddahl"
> To: "Juniper List"
> Sent: 12/02/2020 23:04:37
> Subject: [j-nsp] static arp with unnumbered-address
>
> Hello
>
> How do you program in a static arp entry on an interface that is using
> family inet unnumbered-address ?
>
> Eg.:
>
> interface ps1 {
> unit 2766 {
> proxy-arp restricted;
> vlan-tags outer 402 inner 1016;
> family inet {
> unnumbered-address lo0.1;
> }
> }
> }
> routing instance internet routing-options {
> interface et-0/0/0.2766;
> static {
> route 192.0.2.11/24 {
> qualified-next-hop et-0/0/0.2766;
> }
> route 198.51.100.22/24 {
> qualified-next-hop et-0/0/0.2766;
> }
>
> It is not possible to have the juniper router do correct arp in this case.
> You can have the 192.0.2.0/24 range working or you can have the
> 198.51.100.0/24 working using preferred source address but not both. So I
> figured I could get away with simply hard coding the arp entry. However
> static arp is in the family inet address subtree so can not be specified
> here. Seriously ?
>
> Regards,
>
> Baldur
> ___
> 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
[j-nsp] static arp with unnumbered-address
Hello
How do you program in a static arp entry on an interface that is using
family inet unnumbered-address ?
Eg.:
interface ps1 {
unit 2766 {
proxy-arp restricted;
vlan-tags outer 402 inner 1016;
family inet {
unnumbered-address lo0.1;
}
}
}
routing instance internet routing-options {
interface et-0/0/0.2766;
static {
route 192.0.2.11/24 {
qualified-next-hop et-0/0/0.2766;
}
route 198.51.100.22/24 {
qualified-next-hop et-0/0/0.2766;
}
It is not possible to have the juniper router do correct arp in this case.
You can have the 192.0.2.0/24 range working or you can have the
198.51.100.0/24 working using preferred source address but not both. So I
figured I could get away with simply hard coding the arp entry. However
static arp is in the family inet address subtree so can not be specified
here. Seriously ?
Regards,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] arp from correct IP address
Yes subscriber management has a lot of small but important things that are not quite "done". Juniper should put on a task force to get all the bugs sorted out. Could be a great system if they allow it to be. For me the trouble with this is that without functioning ARP the customer becomes "MAC locked". If he wants to upgrade his equipment, he has to call us so we can clear his session. We have two routers and sometimes a user somehow manages to register with different MAC addresses on the two. Needless to say that creates a lot of trouble that will not sort itself out. With functioning ARP I believe the wrong MAC address would be corrected soon enough without intervention. I wish I could just have a user defined radius variable and use that instead of $junos-preferred-source-address. My script that generates that radius configuration could easily calculate the correct source address and program that in with the other radius variables for each user. I am not creating a JTAC case on this before I have a fix for my other JTAC cases (IPv6 is broken, dynamic VLAN with IP demux on top is broken, DHCP combined with non-DHCP is likely also broken). So far I got IPv4 fixed (access-internal routes ignored, work around use access routes), so they do work on the problems I report. Regards, Baldur Den man. 27. jan. 2020 kl. 04.53 skrev Chris Kawchuk : > Ran into the same bug. > > $junos-preffered-source-address for an unnumbered for BNG functions does > NOT return the "closest/must suitable address" based on the IP+Subnet that > was given the subscriber... contrary to the BNG template doucmentation. It > just defaults the actual loopback of the router. (the dynamic template that > gets created against a demux0. subscriber says $preffered of "NONE") > > This means that things like Subscriber "ARP liveliness detection" doesn't > work/cant work. (since the subscriber won't arp-respond to an ARP requests > where the source isn't in the local subnet) > > I've had a JTAC case open on this for 8 months. Sent full configs, built a > full lab for them (so they could trigger it remotely), self full PCAPs. > > MX204 + JunOS 18.3R + BNG (DHCP/IPoE naturally) > > Also on MX80 w/same code - so it's the BNG code, not the platform doing it. > > - Ck. > > > > > On 25 Jan 2020, at 10:27 pm, Baldur Norddahl wrote: > > Hello > > I have a problem where some customer routers refuse to reply to arp from > our juniper mx204. The arp will look like this: > > 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248 > > The problem is that this should have been "tell 185.24.169.1" because the > client is in the 185.24.169.0/24 subnet. The interface is > "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and > 185.24.169.1 among many others. A Linux box would select the nearest > address but apparently junos does not know how to do this. > > Tried adding in "preferred-source-address $junos-preferred-source-address" > but this just results in "preferred-source-address NONE" and does nothing. > Also there is zero documentation on how junos will fill in that variable. > > Is there a solution to this? Is there a radius variable I can set with the > preferred source address? > > Regards, > > Baldur > ___ > 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
[j-nsp] arp from correct IP address
Hello I have a problem where some customer routers refuse to reply to arp from our juniper mx204. The arp will look like this: 11:57:46.934484 Out arp who-has 185.24.169.60 tell 185.24.168.248 The problem is that this should have been "tell 185.24.169.1" because the client is in the 185.24.169.0/24 subnet. The interface is "unnumbered-address lo0.1" with lo0.1 having both 185.24.168.248 and 185.24.169.1 among many others. A Linux box would select the nearest address but apparently junos does not know how to do this. Tried adding in "preferred-source-address $junos-preferred-source-address" but this just results in "preferred-source-address NONE" and does nothing. Also there is zero documentation on how junos will fill in that variable. Is there a solution to this? Is there a radius variable I can set with the preferred source address? Regards, Baldur ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Non-dhcp users with subscriber management
Hello
I am new to Juniper MX. I successfully managed to configure customer
vlan with dynamic profiles for dhcp users. I attached the important
parts of the configuration at the end of this message.
In the real network we are using q-in-q double tagged vlans, but to make
thing simple I am working with single tagged vlans for my lab. We have
customers vlan, which is each customer has a unique vlan combination.
My configuration will first cause a radius server to be queried for the
validity of the vlan. Then the DHCP server is queried and finally the
subscriber is active. This is working now.
The problem is that I want customers to be able to configure without
using DHCP. Each customer has a static IP configuration. When using DHCP
the customer will always get the same IP address. We then tell the user
that he can optionally use DHCP. Or he can use a static configuration if
he likes that better.
This is an existing ISP network working as described. We are working to
replace the old BRAS with Juniper MX204. So it would be nice if we can
keep it working like it is today.
I am a bit stuck on where to go from here. Most of the examples I find
are all assuming DHCP. I am thinking that it should be possible to
supply the customer IP address via Radius instead of DHCP.
If needed, I could find out which users are using static configuration
without DHCP and then have Radius return something different for those
users.
Anyone have some advice for me?
Regards,
Baldur
The working DHCP configuration:
system {
services {
subscriber-management {
maintain-subscriber {
interface-delete;
}
enable;
}
}
dynamic-profile-options {
versioning;
}
}
chassis {
network-services enhanced-ip;
}
access-profile rad;
interfaces {
et-0/0/0 {
flexible-vlan-tagging;
auto-configure {
vlan-ranges {
dynamic-profile DYNINTF-1VLANS-DHCP-INET {
accept any;
ranges {
any;
}
}
authentication {
password 12345678;
username-include {
user-prefix vlan;
vlan-tags;
}
}
access-profile rad;
}
}
lo0 {
unit 0 {
family inet {
address 1.2.3.4/32;
}
}
}
}
forwarding-options {
dhcp-relay {
server-group {
dhcp-group-1 {
1.2.3.5;
}
}
active-server-group dhcp-group-1;
group dhcp-group-1 {
relay-option-82;
interface et-0/0/0.0;
}
}
}
access {
radius-server {
1.2.3.6 {
secret "xxx"; ## SECRET-DATA
source-address 1.2.3.4;
}
}
profile rad {
accounting-order radius;
authentication-order radius;
radius {
authentication-server 1.2.3.6;
accounting-server 1.2.3.6;
options {
revert-interval 0;
}
}
accounting {
order radius;
immediate-update;
update-interval 15;
}
}
}
dynamic-profiles {
DYNINTF-1VLANS-DHCP-INET {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
proxy-arp restricted;
vlan-id "$junos-vlan-id";
family inet {
unnumbered-address lo0.0;
}
}
}
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] subscriber management not inserting any routes
Hello
I am having trouble with subscriber management not inserting any routes.
Information is picked up from radius, such as this:
baldur@interxion-edge1> show subscribers
Interface IP Address/VLAN ID User
Name LS:RI
demux0.3221225472 195.192.249.104 vlan.1970-37
default:internet
demux0.3221225473 195.192.249.69 vlan.1970-77
default:internet
...
baldur@interxion-edge1> show interfaces demux0.3221225472
Logical interface demux0.3221225472 (Index 536870919) (SNMP ifIndex
20007)
Flags: Up VLAN-Tag [ 0x8100.1970 0x8100.37 ] Encapsulation: ENET2
Demux:
Underlying interface: xe-0/1/1 (Index 168)
Bandwidth: 0
Input packets : 3342925
Output packets: 0
Protocol inet, MTU: 1500
Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new
hold cnt: 0, NH drop cnt: 0
Flags: Unnumbered
Donor interface: lo0.1 (Index 329)
Addresses, Flags: Is-Primary
Local: 185.24.168.248
baldur@interxion-edge1> show route 195.192.249.104
internet.inet.0: 769284 destinations, 771001 routes (769284 active, 0
holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
195.192.249.64/26 *[BGP/170] 4w5d 12:58:36, MED 0, localpref 100, from
185.24.171.254
AS path: ?, validation-state: unverified
> to 10.10.124.2 via xe-0/1/0.0, Push 164140, Push
16467(top)
---
The subscriber interface is receiving packets but never sends anything
out. Also no route is added although the router seems to be aware of the
intended subscriber IP address. The route shown above is a /26 to
another router. I am expecting the subscriber management system to
override that with a /32 for this specific subscriber.
My setup is like this:
interfaces {
xe-0/1/1 {
flexible-vlan-tagging;
auto-configure {
stacked-vlan-ranges {
dynamic-profile Auto-VLAN-Demux {
accept inet;
ranges {
1970-1970,any;
}
access-profile prof1;
}
authentication {
password "$ABC123";
username-include {
user-prefix vlan;
vlan-tags;
}
}
access-profile prof1;
}
}
}
}
dynamic-profiles {
Auto-VLAN-Demux {
routing-instances {
"$junos-routing-instance" {
interface "$junos-interface-name";
}
}
interfaces {
demux0 {
unit "$junos-interface-unit" {
demux-source inet;
demux {
inet {
address source;
auto-configure {
address-ranges {
dynamic-profile DHCP-IP-Demux {
network 0.0.0.0/0;
}
authentication {
password ABC123;
username-include {
user-prefix ip;
interface-name;
source-address;
}
}
}
}
}
}
vlan-tags outer "$junos-stacked-vlan-id" inner
"$junos-vlan-id";
demux-options {
underlying-interface "$junos-underlying-interface";
}
family inet {
unnumbered-address lo0.1;
}
}
}
}
}
}
---
What am I missing here? I have tried a ton of stuff but never succeeded
in getting any outgoing packets towards the subscriber.
Regards,
Baldur
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
