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
[email protected] - 212.655.9344
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
