DSL aggregation on M-Series

[sporkman]

Hello all,

I'm looking to replace an aging Cisco 7206-VXR with something from the M-Series.  We are small enough that we need to do everything on one box, including aggregating DSL customers.  Our config is pretty basic, we have two upstream ISPs that we take default and customer routes from via BGP (these are both ethernet handoffs in a datacenter), we have an OC-3 ATM backhaul into Covad for DSL, some metro-ethernet (each customer on a vlan), and then local servers.

It looks like any M-series can do the bulk of that with no big surprises, but the DSL side of things appears like it might be a bit tricky.

Our DSL config is very simple since we do NOT do PPPoE.  All circuits are either DHCP or static IP.  Hopefully a snippet of the two types of configs we do will make sense.

First an RFC1483 "routed" customer:

interface Loopback6
description loopback for 216.220.x.0/24 sdsl/routed adsl
ip address 216.220.x.1 255.255.255.0
interface ATM3/0.10004 point-to-point
ip unnumbered Loopback6
pvc 0/10004
 encapsulation aal5snap
ip route 216.220.x.4 255.255.255.255 ATM3/0.10004

 And an RFC1483 bridged customer:

interface Loopback7
description loopback for 216.220.x.0/24 bridged adsl
ip address 216.220.x.1 255.255.255.0
interface ATM3/0.10023 point-to-point
ip unnumbered Loopback7
atm route-bridged ip  SECRET SAUCE HERE
pvc 0/10023
 encapsulation aal5snap
ip route 216.220.x.23 255.255.255.255 ATM3/0.10023

I've been looking at the docs for the ATM interfaces here, and I'm just finding them a bit to brief to help me with this translation from Cisco.  I'm fairly certain that the routed config is supported on either ATM1 or ATM2 interfaces, but the bridged config is a bit of a mystery.  In Cisco parlance, they call this "RBE" or "Route Bridged Encapsulation".

Any help?

Thanks,

Charles 

[stuartb]

Hello

Well I can't directly answer your questions but I can, I hope, provide you with some further reference points:

1) IOS to JunOS translator:

https://i2j.juniper.net/release/index.jsp

You do need a valid login to Juniper's website to do this.

2) All the technical configuration documentation is freely available. Do not go for the hardware section, but focus on the JunOS section. 

This link takes you to the 9.3 Documentation for JunOS:

http://www.juniper.net/techpubs/software/junos/junos93/index.html

I would suggest the "Network Interfaces" Guide. Below is a direct link to the ATM configuration section of that guide:

http://www.juniper.net/techpubs/software/junos/junos93/swconfig-network-interfaces/configuring-atm-interfaces.html#id-10744229

 HTH

Stuart.

[sporkman]

Yeah, I have no login, so no translator.  That's kind of disappointing, especially from a pre-sales perspective.

I have been looking at the link you posted, but it's not quite answering my question.

Thanks! 

[stuartb]

OK, here is another link:

http://www.juniper.net/techpubs/software/junos/junos93/swref-hierarchy/supported-standards-for-atm-interfaces.html#hierarchy-summary-standards-interfaces-atm

That link shows the software RFC/standards support for ATM interfaces in 9.3 and it says:

"

The JUNOS software substantially supports the following ATM standards:

• International Telecommunication Union–Telecommunication Standardization (ITU-T) Recommendation I.432.3, B-ISDN user-network interface - Physical layer specification: 1544 kbit/s and 2048 kbit/s operation
• RFC 1483, Multiprotocol Encapsulation over ATM Adaptation Layer 5 (routed protocol data units [PDUs] only)
• RFC 2225, Classical IP and ARP over ATM (responses only)
• RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5 (routed PDUs and Ethernet bridged PDUs only)"

Now IIRC 1483 is the RFC people quote for DSL, but I believe 2684 superseded.

As always it's best to check with your SE or Partner SE.

[Loup2]

Hi Charles

Unfortunattely Juniper docs are not so crowded with examples !

Here is a config that I have just tested in front of a C box that is working on an M7i with an OC3 interface.

It is working for your first example and I am not sure that I will find something for your (routed bridged) second one?

interfaces {
    at-0/1/0 {
        atm-options {
            pic-type atm2;
            vpi 0;
        }
        unit 0 {
            encapsulation atm-snap;
            multipoint;
            family inet {
                address 216.220.0.1/24 {
                    multipoint-destination 216.220.0.4 vci 0.100;
                }
            }
        }
    }
}

I hope this will be usefull

Regards

Alain

[davidjdv]

Hello Charles,

I have to admit that the Juniper documentation is a bit lacking in examples for this type of configuration but the equivalent of RBE is ether-over-atm-llc encapsulation. Here's an example:

at-6/2/0 {
  atm-options {
    vpi 0 maximum-vcs 200;
  }
  unit 0 {
    encapsulation ether-over-atm-llc;
    vci 0.120;
    family inet {
      mtu 1500;
      address 10.11.12.13/24;
    }
  }
}

With this type of encapsulation, the router will drop all incoming packets which are not IP or ARP. It ignores the destination MAC address (ie: it does not seek to validate it). It supports ARP (in order to bind the correct DMAC for outgoing packets) but only associates one MAC address with the ATM interfaces and thus always uses the same SMAC for outgoing packets.

HTH,

/david 

Message Edited by davidjdv on 01-19-2009 11:50 AM

[Loup2]

Thanks to David for this information

Charles I did validate this on my lab with this Cisco config in front of Juniper M7i (direct OC3 ATM interfaces).

Kind regards

Alain

_

________________________________________________

CISCO 

interface ATM1/0.1 point-to-point
 ip address 216.220.0.4 255.255.255.0
 atm route-bridged ip
 pvc 0/100
  encapsulation aal5snap
 !
!
ip route 216.220.0.1 255.255.255.255 ATM1/0.1

_________________________________________________

JUNIPER 

interfaces {
    at-0/1/0 {
        atm-options {
            pic-type atm2;
            vpi 0;
        }
        unit 0 {
            encapsulation ether-over-atm-llc;
            vci 0.100;
            family inet {
                address 216.220.0.1/24;
            }
        }
    }

}

routing-options {
    static {
        /* Optionnal route as ARP request occurs */
        route 216.220.0.4/32 next-hop at-0/1/0.0;
    }
}
_________________________________________________

[sporkman]

Thanks so much...  These examples look good.

In the example below, can I put a "loopback" interface that multiple clients on different PVCs can use as a gateway, and am I getting the syntax right in making additional interfaces?:

interfaces {
    at-0/1/0 {
        atm-options {
            pic-type atm2;
            vpi 0;
        }
        unit 0 {
            encapsulation ether-over-atm-llc;
            vci 0.100;
            family inet {
                address 216.220.0.1/24;
            }
        }
    }

} 

ie:

interfaces {
    at-0/1/0 {
        atm-options {
            pic-type atm2;
            vpi 0;
        }
        unit 0 {
            encapsulation ether-over-atm-llc;
            vci 0.100;
            family inet {
                unnumbered loopback X;  <<<-----
            }
       unit 1 {

            encapsulation ether-over-atm-llc;
            vci 0.101;
            family inet {
                unnumbered loopback X;  <<<-----
            }

unit 2 {
            encapsulation ether-over-atm-llc;
            vci 0.102;
            family inet {
                unnumbered loopback X;  <<<-----

            } 

}
    }

} 

And then:

routing-options {
    static {
        /* Optionnal route as ARP request occurs */
        route 216.220.0.2/32 next-hop at-0/1/0.0;

        route 216.220.0.3/32 next-hop at-0/1/0.1;

        route 216.220.0.4/32 next-hop at-0/1/0.2;
    }
}

Also, is DHCP supported here?

Thanks!

Charles