[j-nsp] DSL Aggregation - ATM vs. ATM2

[Charles Sprickman]

Hello all,

Hopefully this is one of the last "pre sales" questions I'll have.

The *most* complicated thing we're doing on the Cisco now that we'd like 
to emulate on a Juniper is DSL aggregation.  Even that, by most standards, 
is pretty simple.  We do not do PPPoE or PPPoA.  We do straight bridged 
and routed RFC1483.  The routed config is very, very simple, and best 
explained by a config snippet.

We grab a /24 for DSL WAN IPs and put what the customer will see as their 
WAN-side gateway on a loopback interface:

interface Loopback6
  description loopback for 216.220.x.0/24 sdsl
  ip address 216.220.x.1 255.255.255.0

Each customer comes in on their own pvc which is setup as a subinterface 
on the OC-3:

interface ATM3/0.10004 point-to-point
  ip unnumbered Loopback6
  pvc 0/10004
   encapsulation aal5snap
  !

Lastly, we point a static route at the same subinterface:

ip route 216.220.x.4 255.255.255.255 ATM3/0.10004

That's it.  Very simple, and it "just works".  If a customer trys to grab 
the wrong WAN IP, they don't knock anyone else off, etc.

The above config is what we generally do for SDSL or SOHO ADSL folks with 
an actual xDSL "router" as a CPE.

For residential or SOHO ADSL that use a simple bridging CPE, the 
configuration is basically identical except for one config line in the 
ATM subinterface config:

interface ATM3/0.1163 point-to-point
  ip unnumbered Loopback1
  atm route-bridged ip  <<<<---- SECRET SAUCE HERE
  pvc 0/1163
   encapsulation aal5snap
  !

The above is what Cisco calls "route bridged encapsulation" or some such 
thing.  It is a very cool feature that replaced the old model using BVI 
interfaces which had a whole slew of problems including sending broadcasts 
where they shouldn't, letting customers grab as many IPs as they could, 
and letting them steal each other's IPs if you didn't do static ARP 
entries for everyone.

So given the above, are those configs possible in JunOS?  And if they are, 
can I get away with the non-ATM2 card?  What interesting stuff does ATM2 
add that might be useful for our very narrow application?

That's the bulk of my question...  But if anyone here has done DSL agg. on 
both C and J, here's some more:

We have four other special cases, one of which may go away at some point.

The first is the same as the last snippet for a RFC1483 bridged setup, but 
instead of using a loopback interface, we specify an IP and mask which 
allows us to "bridge" a small subnet to the customer.

The second is what our DSL partner, Covad, calls "VOA" or "Voice Optimized 
Access".  Basically they'll build out two pvcs to the customer and set the 
data pvc as UBR and the voice pvc to vbr-nrt.  I don't see any issues on 
the Juniper side with that...

The third is a customer that does some multicast.  He has a circuit where 
he streams video, then his "customers" all get ADSL circuits that plug 
into set-top boxes.  All for russian TV apparently.  The only thing I add 
to those subinterfaces is "ip pim sparse-mode" and everything works.  Any 
issues with multicast on Juniper + ATM?

And the last is the one that should go away shortly.  Covad did not 
officially support bonding their T1 circuits until very recently.  We came 
up with a hackish way to do it.  Covad's T1s run frame relay encaps facing 
the customer and the DSLAM does a (crappy) FR <-> ATM conversion.  On the 
CPE we run multilink over frame relay and then on our end we run multilink 
over ATM.  It works, but it's messy and doesn't scale.  I understand that 
we would need a "services" PIC that handles multilink ppp, and I'm betting 
that costs quite a bit.  Covad claims that 1Q 2009 will bring us a bonded 
service where their new dslams do the bonding and we get a single pvc. 
Problem solved if they're on schedule.

Thanks,

Charles

___
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet - www.bway.net
spork at bway.net - 212.655.9344