I'm going through Juniper's Day One: Subscriber Managment book and noticing some things explained here are somehow contradictional to real-world configurations.

For example, that's output from the book for dynamic-vlan (service vlan model):

[edit dynamic-profiles DYNINTF-SVLAN-DHCP-INET]
admin@SOUTHPARK# show
interfaces {“$junos-interface-ifd-name” {
 unit “$junos-interface-unit” {
 demux-source inet;
 proxy-arp restricted;
 vlan-id “$junos-vlan-id”;
 family inet {
 unnumbered-address lo0.0 preferred-source-address 12.1.1.1;
 }
 }
 }
}

(excuse me for formatting, it's copied from PDF)

That's what book sys about this config:

"The key difference between this configuration and the one in Chapter 2, of course, is the inclusion of the demux-source inet statement. This instructs Junos to use the IPv4 address of the packet to create a unique subscriber session anchor."

 However, this explanation seems really weird cause all examples I found in documentation states "demux-source" is used on the IP demux interface and not on the dynamic vlan interface. 

 I also have a working configuration without that line:

root# show dynamic-profiles VLAN-demux                        
routing-instances {
    "$junos-routing-instance" {
        interface "$junos-interface-name";
    }
}
interfaces {
    demux0 {
        unit "$junos-interface-unit" {
            vlan-id "$junos-vlan-id";
            family inet {
                unnumbered-address "$junos-loopback-interface";
            }
        }
    }
}

Another thing that's not clear to me is underlying-interface. That's config from the book:

DYNSUB-SVLAN-IPDEMUX {
 interfaces {
 demux0 {
 unit “$junos-interface-unit” {
 demux-options {
 underlying-interface “$junos-underlying-interface”;
 }
 family inet {
 demux-source {
 $junos-subscriber-ip-address;
 }
 }
 }
 }
 }
}

Documentation doesn't state underlying-interface parameter is optional..which, I suppose, means it's required.

Yet here's my config that works perfectly without it:

root# show dynamic-profiles DHCP 
routing-instances {
    "$junos-routing-instance" {
        interface "$junos-interface-name";
    }
}
interfaces {
    demux0 {
        unit "$junos-interface-unit" {
            family inet {
                demux-source {
                    $junos-subscriber-ip-address;
                }
                unnumbered-address "$junos-loopback-interface";
            }
        }
    }
}

 What's the purpose of this line then?

Hi,

Looks like you're using next-generation subscriber-management release starting from 15.1.

In legacy release , you would have received below error messges due to the missing configuration.

Dec  4 17:34:24  TEST /kernel:  TEST dcd[1929]: UI_CONFIGURATION_ERROR: Process: dcd, path: [edit demux0 unit 1073741846], statement: family, Demux underlying-interface must be configured
Dec  4 17:34:33  TEST dcd[1929]: UI_CONFIGURATION_ERROR: Process: dcd, path: [edit demux0 unit 1073741847], statement: family, Demux underlying-interface must be configured
Dec  4 17:34:33  TEST /kernel:  TEST dcd[1929]: UI_CONFIGURATION_ERROR: Process: dcd, path: [edit demux0 unit 1073741847], statement: family, Demux underlying-interface must be configured

Next-generation subscriber-management release has completely new archiecture most of the Junos variable are automatically pulled by the software.

TEST# show dynamic-profiles VLAN-demux
routing-instances {
    "$junos-routing-instance" {
        interface "$junos-interface-name";
    }
}
interfaces {
    demux0 {
        unit "$junos-interface-unit" {
            vlan-id "$junos-vlan-id";
            family inet {
                unnumbered-address "$junos-loopback-interface";
            }
        }
    }
}

TEST# show dynamic-profiles DHCP         
routing-instances {
    "$junos-routing-instance" {
        interface "$junos-interface-name";
    }
}
interfaces {
    demux0 {
        unit "$junos-interface-unit" {
            family inet {
                unnumbered-address "$junos-loopback-interface";
            }
        }
    }
}

TEST# run show subscribers
Interface           IP Address/VLAN ID                      User Name                      LS:RI
demux0.3221395385    100                                                              default:default     
demux0.3221395386   10.110.90.10                            test                      default:default     

TEST# run show subscribers extensive
Type: VLAN
Logical System: default
Routing Instance: default
Interface: demux0.3221395385
Interface type: Dynamic
Underlying Interface: xe-11/0/0
Dynamic Profile Name: VLAN-demux
Dynamic Profile Version: 1
State: Active
Session ID: 329757
PFE Flow ID: 173538
VLAN Id: 100
Login Time: 2017-12-05 20:45:01 IST

Type: DHCP
User Name: test
IP Address: 10.110.90.10
IP Netmask: 255.255.254.0
Primary DNS Address: 8.8.8.8
Secondary DNS Address: 4.2.2.2
Logical System: default
Routing Instance: default
Interface: demux0.3221395386
Interface type: Dynamic
Underlying Interface: demux0.3221395385
Dynamic Profile Name: DHCP
Dynamic Profile Version: 1
MAC Address: 00:19:01:00:00:01
State: Active
Radius Accounting ID: 329758
Session ID: 329758
PFE Flow ID: 173539
VLAN Id: 100
Login Time: 2017-12-05 20:45:01 IST
DHCP Options: len 9
35 01 01 37 04 01 03 3a 3b
IP Address Pool: Pool1

You actually have to configure the multiple address families under the same BGP group. You can't configure the same neighbor under different groups within a routing instance.

Hello,

I can't give you the accurate RIB/FIB numbers as this is a public space and those are internal so I can't share the file.
You can ask your VAR to get your Juniper rep to get his SE to get you in touch with someone from the MX product team who can give you the last tested numbers.

Depending on the Junos version and the Bits 32/64.
Roughly the 4096 are more than 1.5 million and more than 14 million RIB.   {32bit only}
Roughly the -16G are more than 4 million, the RIB depends on the Junos type 32/64 and NSR or not max is 50+ M

The SCB you have are end of life since 2016.
You can still use them to run up to MPC3 and including MPC3.
If you want MPC 4 you need SCBE
If you want MPC7 and above you need SCBE2.

The RE with 16G has only been EOL lately so it is still useful. 

Your MX are fine, however they might have the old backplane connector as was mentioned here so they might not support some cards, etc.
You can look at the parts you ordered if they are 
premium3 it is a new Chassis
premium2 old chassis.

There is also a new MX10003 if you need less real-estate and better power numbers. It can help shave RU and DC costs.

As mentioned by the other person, the line card and the license on it will affect the number of routes but those can be upgraded if not EOL.

I assume based on the SCB and older RE you have some DPCs , those can be thrown out as they will cause compatibility issues and a lot of drama. There is a matrix for them, the SE can give you this too from the internal site.

Talk to your Juniper VAR or your Juniper rep and his RIO.
If they are being useless 
give me a call. I'll fly with you.
Saar Harel 
Myriad Supply
US East Region Partner of the Year three years in a row.

Hi all,

I now have a firm understanding of the NDRA process for IPv6 and have the following quesiton regarding the secondary CPE autoconfig phase of DHCPv6-PD.

I have a working configuration on some Cisco equipment but need to get this working on the MX240.....

LNS configuration (acting as the DHCPv6-PD Server - kind of)

R4(config)#Ipv6 local pool cust-pool1 2001:db8:2:8000::/49 56

R4(config)#Ipv6 dhcp pool ISP-pool

R4(config-dhcpv6)#Prefix-delegation pool cust-pool1 lifetime infinite infinite

R4(config)#int <interface required>

R4(config-if)#Mac-address xxxx.xxxx.xxxx     (Just use this if we want control rather than eui-64 controlling everything)

R4(config-if)#Ipv6 address 2001:db8:2:410::4/64

R4(config-if)#Ipv6 address fe80::4 link-local  (We use this if we want to control everything rather than eui-64)

R4(config-if)#Ipv6 dhcp server ISP-pool

CPE Configuration 

R10(config)#int g2/0

R10(config-if)#ipv6 enable

R10(config-if)#ipv6 address FROM-ISP ::0.0.0.0.1/64  (This means the /56 prefix (The first zero is the 8 bits this customer has to play with regarding subnets, if you like))

R10(config)#int g3/0

R10(config-if)#ipv6 enable

R10(config-if)#ipv6 address FROM-ISP ::1:0:0:0:1/64  (Notice that the leading zero is now a “1”…. If we wanted yet more subnets then that 1 would become a 2 and then 3 etc etc etc)

Could someone please let me know the same command structure to give the same results in Junos?

Also, please confirm if the configuration is on the CPE or the LNS and also the itnerface involved is the L2TP peer tunnel interface (I'm guessing it would be given that this is the only WAN link)....

The actual end result requirement would be that this is dealt with on the RADIUS via a PORTAL for the re-seller...... Again, guessing, this would involve us knowing wht the re-seller has sold the customer (in the way of IPv6) so that we can configure the CPE before shipping....

If anyone has any experience of configuring this on freeRADIUS, anyhelp would be greatly appreciated.

Thanks

Clive

Hi Clive,

Looking at your setup it will be DHCPv6 over PPP.

LNS will be providing IPv4 as well as IPv6 address.  For WAN i.e. NDRA and LAN DHCPv6 PD.

In case you want to assign NDRA/PD from radius, you need below attributes.

NDRA=Framed-IPv6-Pool/Framed-IPv6-Prefix

PD= ERX-ipv6-Delegated-Pool-Name

[root@JTAC-ERX-LINUX-2 raddb]# grep -i delega dictionary.erx
ATTRIBUTE       ERX-IPv6-Delegated-Pool-Name            161     string

Configuration on LNS

TEST# show system services

dhcp-local-server {

    dhcpv6 {

        group TEST {

            authentication {

                password test;

                username-include {

                    user-prefix test;

                }

            }

            dynamic-profile DHCP;

            overrides {

                delegated-pool IAPD-PPPOE-POOL;

            }

            interface si-1/0/0.0;

        }

    }

TEST# show access address-assignment pool IAPD-PPPOE-POOL

family inet6 {

    prefix XXXX:YYYY:AAAA::/40;

    range IAPD-RANGE prefix-length 56;

}

https://www.juniper.net/documentation/en_US/junos/topics/example/dual-stack-pppoe-ndra-dhcpv6-pd.html

https://www.juniper.net/documentation/en_US/junos/topics/concept/subscriber-management-dual-stack-ipv6-design-ndra-dhcpv6-pd.html

https://kb.juniper.net/InfoCenter/index?page=content&id=KB26579
Sample configuration of DHCPv6-PD over Dual Stack LNS (L2TP)

Regards,

Rahul

Hi Rahul,

Thank you for the configuraiton and links.... very much appreciated. I will configure and test...

Again, thanks

Clive

Hi,

Can you share your configuration?

Hi Clive,

Please find few freeradius samples. Hope it helps.

test Cleartext-Password := "test"
     Framed-IP-Address := X.X.X.X,
     Framed-ipv6-Pool := "ipv6-iana-pool",
     ERX-ipv6-Delegated-Pool-Name := "ipv6-pd-pool"

test1 Cleartext-Password := "123"
      Framed-Pool := "IP-Pool",
      Framed-ipv6-Pool := "IPv6-WAN",
      ERX-ipv6-Delegated-Pool-Name := "IPv6-Pool",

test2 Cleartext-Password := "123"
      Framed-IP-Address := "X.Y.Z.X",
      Framed-IPv6-Prefix := "XXXX:YYYY:ZZZZ::/64"

test3 Cleartext-Password := "test"
      Framed-IP-Address := X.X.X.X,
      Framed-ipv6-Pool := "ipv6-iana-pool",
      ERX-ipv6-Delegated-Pool-Name := "ipv6-pd-pool",
      ERX-Ingress-Policy-Name = "16M",
      ERX-Egress-Policy-Name = "16M"

Regards,

Rahul

Hi All

My router MX240 connect to another MX240 via submarine cable and 2 GRE over two upstream provider.

The information as follow is routing table . xe-1/3/2.1 is 10G of submarine cable , and gr-1/1/0.3 is GRE over upstream provider(ISP1).

But I have another GRE over upstream provider(ISP2) , it's interface is gr-2/3/0.2.

My question is how to let gr-2/3/0.2 have higher priority than gr-1/1/0.3 both on protocol LDP & OSPF ?

Althought I set gr-1/1/0.3 as higher metric on OSPF , but the backup path is still gr-1/1/0.3, not gr-2/3/0.2.

LDP seems have no way to controll.

192.168.145.2/32   *[LDP/9] 23:01:02, metric 10

                               > to 192.168.147.34 via xe-1/3/2.1, Push 313776

                                  via gr-1/1/0.3

                                [OSPF/10] 23:01:02, metric 10

                               > to 192.168.147.34 via xe-1/3/2.1

                                  via gr-1/1/0.3

>show configuration protocols ldp

track-igp-metric;

interface gr-1/1/0.3;

interface xe-1/2/2.1 {

    link-protection;

}

interface xe-1/3/2.1 {

    link-protection;

}

interface gr-2/3/0.2;

> show configuration protocols ospf

traffic-engineering;

area 0.0.0.0 {

    interface xe-1/3/2.1 {

        interface-type p2p;

        link-protection;

        metric 5;

        bfd-liveness-detection {

            minimum-interval 100;

        }

    }

    interface gr-2/3/0.2 {

        interface-type p2p;

        metric 25;

        bfd-liveness-detection {

            minimum-interval 100;

        }

    }

    interface gr-1/1/0.3 {

        interface-type p2p;

        metric 100;

        bfd-liveness-detection {

            minimum-interval 100;

        }

     }

}

Good day.

I'm using version 14.1R7.4 and am trying to solve the following problem.

show interfaces ge-1/1/4
vlan-tagging;
native-vlan-id 300;
unit 0 {    family bridge {        interface-mode trunk;        vlan-id-list [300 2121];    }
}
show interfaces xe-2/0/0
unit 0 {    family bridge;
}

show forwarding-options analyzer
test {
    input {        egress {            interface ge-1/1/4.0;        }    }    output {        interface xe-2/0/0.0;    }
}

port 1-1-4 mirror source, port 2-0-0 - destination, I'm trying to use the analyzer.

I take as a basis this documentation - https://www.juniper.net/documentation/en_US/junos/topics/concept/port-mirroring-ex-series-l2.html

But there nothing is said about how the port of destination should be set up, except as a bridge family.

commit check
re0:
[edit interfaces xe-2/0/0 unit 0]
'family'
To configure family bridge on an interface , interface mode (access or trunk) should be specified
error: configuration check-out failed

commit check
re0:
[edit interfaces xe-2/0/0 unit 0 family]
'bridge'
Configuration error. For access interface, please ensure that vlan-id is configured
error: configuration check-out failed

But I do not need there VLANS, this is the usual local mirror. Here's how it works on the EX 3200

show ethernet-switching-options
analyzer span {     input {         ingress {             interface ae3.0;             interface ae4.0;             interface ae5.0;         }     }     output {         interface {             xe-0/1/1.0;         }     }
}
show interfaces xe-0/1/1
unit 0 {     family ethernet-switching;
}

I ask to help how to do the same thing on the MX router or the same thing, but using port mirroring. Please help.

Hello there,

---

rderasse wrote:

Hello,

At this time I get default routes via BGP from transit providers on two sites, running iBGP between the sites (SRX220). 
IXP1 site1 RS1 : 100k routes
IXP1 site1 RS2 : 100k routes
IXP2 site2 RS1 : 50k routes
IXP2 site2 RS2 : 50k routes

SRX220 supports only 32K BGP routes

 https://www.juniper.net/assets/kr/kr/local/pdf/datasheets/1000281-en.pdf

page 8.

---

rderasse wrote:

Here are my questions :
- I think that in each IXP, the two RS send the same routes (same prefix, same next-hop, same AS path). How many routes maximum should I expect to get in the routing table on each site ? Is it 300k even if I import all the routes with the same local preference ?

 

 

---

SRX wil keep all routes even those that are not best, so 300K.

---

rderasse wrote:

 

 

- How many routes in the forwarding table should I expect ? Is it 150k if I get routes to totally different prefixes on each IXP ?

---

Only best routes are getting installed in forwarding table, so 150K. BGP has a well-known path selection algo that always comes up with 1 best route even if there are many candidates for it.

---

rderasse wrote:

- I tried before not to import BGP routes received from neighbor. Back then JTAC told me that it's mandatory that the routes are stored as hidden routes. Is it mandatory that a route received from a neighbor consumes space in the routing table because of that ? No way to totally drop a route and not use memory at all ?

---

The routes are hidden if:

1/ Protocol nexthop is unresolvable

2/ AS_PATH loop is detected with OWN ASN (Loops with OTHER PEOPLE' ASN are not detected).

There will be a small amount of such routes so Your projected memory savings are going to be small as well.

To get rid of such routes + routes rejected by Your import policy, add a line "keep none" to Your BGP config but it does not get rid of not-best routes simply because they are coming as not best in BGP path selection. 

---

rderasse wrote:

- I plan to use for joining the IXPs a SRX345. Does someone has an idea of the convergence time in case a session goes down then up again or a routing process restart ? Would that be a few seconds ? several minutes ?

---

With software-based routers like branch SRX, I would expect at least a few dozen minutes convergence worst case (dropping all routes and relearning them anew). In other scenarios like dropping 1 peer it may be less.

---

rderasse wrote:

- What would be the impact on the traffic of an IXP BGP session going down then up again ? I guess it depends on what routes are removed from the routing table / forwarding table.

---

See above. It depends how many best routes are there from this peer.

---

rderasse wrote:

- More specifically, if one or several IXP BGP sessions goes down, will the traffic continue to flow seamlessly because the default routes I receive from my transit providers will stay in the forwarding table in this case ?

---

Yes, it should flow but You may see suboptimal routing - i.e. if You are in Missouri, Your traffic to LA could be initially forwarded to NY IXP. It will eventually find its way to LA but the delay incurred could be too large for some applications.

HTH

Thx

Alex

I understand you can't share the configuraiton as you mention so forgive me if this is obvious stuff you have already checked.

Since you are using OSPF with LDP, I assume you have RSVP signaling for the sessions and OSPF traffic engineering is turned on.  Your path selection will be limited by two additional factors in addition to the standard OSPF cost.

EROs or explict hops that get configured on the LSP associated with the LDP session.

CSPF calculations on all the available paths unless you have turned CSPF off on the LSP or globally.

---

- More specifically, if one or several IXP BGP sessions goes down, will the traffic continue to flow seamlessly because the default routes I receive from my transit providers will stay in the forwarding table in this case ?

---

Yes, it should flow but You may see suboptimal routing - i.e. if You are in Missouri, Your traffic to LA could be initially forwarded to NY IXP. It will eventually find its way to LA but the delay incurred could be too large for some applications.

HTH

Thx

Alex

---