- Bronze, 100 points or more
How is everyone doing?
I use DSL for Internet-connectivity.
While tinkering with Modem, I was shocked to find that ip address assigned by isp to my modem is not on the same subnet as its default gateway.
Here is my understanding.
Modem regards R1 which is connected to it as a default-gateway, it means both the modem and R1 should be on the same subnet/network
Below is the modem 's ip address assigned by ISP
Modem Parameter Status
Firmware Version: QAP002-18.104.22.168.9.9-PK5000
Model Number: PK5000
Serial Number: SPAB1301200593
WAN MAC Address: 00:24:7B:AE:CA:19
Downstream Rate: 3072 Kbps
Upstream Rate: 640 Kbps
PPP User Name: [email protected]
ISP Protocol: PPPoE
Encapsulation: LLC Bridged
Modem IP Address: 22.214.171.124
DNS Address #1: 126.96.36.199
DNS Address #2: 188.8.131.52
Below is the routing table at Modem:
valid destination netmask gateway
yES 184.108.40.206 255.255.255.255 0.0.0.0
YES 192.168.0.0 255.255.255.0 0.0.0.0
YES 220.127.116.11 255.0.0.0 0.0.0.0
YES 0.0.0.0 0.0.0.0 18.104.22.168
Now we have 22.214.171.124 as default gateway while modem ip address assigned by isp is 126.96.36.199. These ip addresses are not on the same subnet.
1_How can modem use R1 as default-gateway when both do not share the same subnet ?
thanks and have a great weekend
As an example, this would be a configuration of a PPPoE ATM interface:
pppoe-client dialer-pool-number 1
dialer pool 1
ip address negotiated
And following is a configuration of a PPPoA ATM interface:
encapsulation aal5mux ppp dialer ! or encapsulation aal5snap
dialer pool-member 1
dialer pool 1
ip address negotiated
Let say we have to configure PPPoA on our router, What kind of interface we need on our router i.e simply ATM interface or dsl interface?
Exactly. As soon as the router has a DSL interface, the same interface can be configured either for PPPoA or for PPPoE operation. As the PPPoE is configured on an ATM interface representing the DSL connection, Cisco sometimes likes to call it PPPoEoA (PPPoE on ATM interface) but that's starting to be so confusing I'd rather avoid that particular terminology
So, with a DSL interface built into the router, you directly configure it either for PPPoE or for PPPoA, according to your ISP's recommendations.
Let say ISP in above case uses PPPoA
1)Will our integrated modem/router still create PPPoE frame i.e ATM+PPPoA+Ethernet+PPPOe+PPP+ ip ?
No, with PPPoA, the Ethernet and PPPoE encapsulation/semantics does not come into play. The encapsulation is directly ATM+AAL5+PPP+IP. Depending on the particular encapsulation used by the ISP, an additional SNAP header may come into the sequence (used when AAL5SNAP encapsulation), i.e. ATM+AAL5+SNAP+PPP+IP.
To compare the differences:
PPPoA, AAL5MUX: ATM+AAL5+PPP+IP
PPPoA, AAL5SNAP: ATM+AAL5+SNAP+PPP+IP
PPPoE, AAL5MUX: ATM+AAL5+Ethernet+PPPoE+PPP+IP
PPPoE, AAL5SNAP: ATM+AAL5+SNAP+Ethernet+PPPoE+PPP+IP
This sequence of encapsulations is always upheld, regardless of the type of the network between DSLAM and BRAS. In other words, the sequence of encapsulations depends exclusively on the type of PPP deployment, i.e. PPPoE or PPPoA.
2) Is it possible if ISP can use PPPoE even though ian ATM link is used to connect dslam and BRAS?
Sure. The selection of PPPoE or PPPoA does not depend on the type of network interconnecting the DSLAM and BRAS. It is even expected that the network is fully ATM-based between the DSLAM and the BRAS, and both PPPoE and PPPoA assume that. If the network is IP/MPLS based, some kind of L2VPN technology is used to forward the circuits from DSLAM towards the BRAS (L2TP or MPLS pseudowires).
As always, feel welcome to ask further!
So nice to be in contact with you again. I am well, thanks! How are you?
This is going to be probably a larger answer so please bear with me.
My understaning is ATM is used between modem and dsl(isp)
Things are more complex than that. First of all, with DSL, you have the DSL service provider (DSLSP) and the Internet service provider (ISP). The DSLSP is the entity who usually owns the local loop infrastructure, the DSLAMs and the BRAS. However, the DSLSP does not need to be the provider of internet services - there may be ISPs who do not own their telco infrastructure with local loops and DSLAMs and all the stuff, but you can still access their services using a DSL connection. Therefore, if your ISP is different from your DSLSP, on the BRAS, the data from the customer will be properly encapsulated and forwarded using L2TP from the DSLSP to the appropriate ISP.
I believe that the following PDF is a nice (and in-depth) overview of both DSLAMs, BRASes and the infrastructure between them.
Now, the ATM framing is used on DSL interfaces (AAL5 adaptation layer), between the DSL modem and the DSLAM. However, whether the ATM goes beyond the DSLAM depends very strongly on the type of the DSLAM and the type of network between the DSLAM and the BRAS. In the origins of DSL services, this network was ATM-based. Today, the technology is predominantly IP or MPLS-based, and thus the ATM is used merely on the local loop alone, between the DSL modem and the DSLAM.
The ATM, however, is not used directly in DSL (i.e. the IP packets are not put into ATM cells immediately). The primary reason is the lack of per-user authentication, authorization and accounting in plain ATM - something you need very much in a dial-up kind of service. Because PPP has support for all these functions and also it provides a nice provision for transport of diverse protocols (IPv4, IPv6), it was decided that the user IP traffic will be first encapsulated into PPP and only then these entire PPP datagrams will be chopped into ATM cells and sent through the DSL network.
The operation of the PPP over DSL has two basic modes: either the PPP datagrams are indeed placed into ATM cells directly, and we call this the PPPoA, or PPP-over-ATM. Alternatively, another approach is used where the PPP datagrams are first adapted as if they were to be sent over Ethernet network first (even if they are not!) by encapsulating them into an Ethernet and special 6-byte header (so-called PPPoE header), and these resulting PPP-over-Ethernet frames are then sent through the ATM.
I suggest you have a look on the following discussions about these issues in greater detail:
Besides, I don't see any ethernet cable connecting my dsl modem to ISP. All I see is phone line between my dsl modem and DSL isp. Yet pppOE is used between dsl modem and dsl is
Very quickly, the PPPoE was first developed as a technology to build multiple separate PPP sessions over Ethernet, with no regard to DSL. You simply wanted your PC to have a dedicated PPP session built to some access concentrator but the technology inbetween was Ethernet. The PPPoE provides a mechanism for automatically locating such access concentrator within a broadcast domain and establishing a PPP session to it, along with a way of keeping several PPP sessions originated within the same Ethernet network separate and distinct. For this, a simple software client was installed on PCs that was able to perform the PPP-over-Ethernet communication, i.e. a purely software solution.
When DSL came in, first DSL modems acted like Ethernet/ATM bridges, with the ATM part using DSL physical layer. This setup allowed for using the PPPoE immediately, whereby the DSL modem was simply plugged into the network and the PCs individually started their software PPPoE clients and using that, they connected to the ISP by building a PPPoE session that started on a PC, traversed the Ethernet network, the DSL modem, the entire DSL network and ended up on the aggregation router at the ISP.
Later, when integrated DSL modems/routers became prevalent, the PPPoE software client was integrated into the router's operating system. However, in order to keep the compatibility with older DSL modems and software-based clients on PCs, the routers perform the entire Ethernet+PPPoE+PPP encapsulation inside their operating system although there is no Ethernet port involved anywhere. That's why you are still seeing the PPPoE as the communication mode in your DSL even though there is no Ethernet port related to the DSL technology. The entire chain of encapsulations is ATM+AAL5+Ethernet+PPPoE+PPP+IP+..., quite bloated.
This is a difficult concept. Please feel welcome to ask further!
Welcome to the world of PPP protocol
What you have observed is completely correct. PPP does not think in "subnet" terms (although it is a Layer2 protocol so it should not even think of IP but still, the choice of PPP does have consequences even for IP). Instead, PPP simply assigns (or accepts) any arbitrary IP address to one end of a point-to-point link, any other IP address to the other hand, and that's it. Even though the interfaces are configured with some netmask, for IP-over-PPP it has almost no meaning.
An important help here is the IPCP protocol, one of the supervisory protocols inside PPP to negotiate IP operation over a PPP link. During the NCP phase, both peers inform themselves of their own IP addresses via IPCP, and Cisco routers will then mutually insert a /32 routing table entry to point to the other peer, thereby maintaining the reachability even if the peers are not on the same "subnet" (which, again, has no meaning to PPP links).
Think of this topology: R1 (10.0.0.1/30) --- (192.168.255.254/30) R2. Running debug ppp negotiation on R1 after the PPP interface is brought up yields this output (abbreviated for clarity):
*Mar 1 00:02:47.419: Se1/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 1 00:02:47.419: Se1/0 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 1 00:02:47.419: Se1/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 1 00:02:47.419: Se1/0 IPCP: Address 192.168.255.254 (0x0306C0A8FFFE)
*Mar 1 00:02:47.419: Se1/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar 1 00:02:47.423: Se1/0 IPCP: Address 192.168.255.254 (0x0306C0A8FFFE)
*Mar 1 00:02:47.423: Se1/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 1 00:02:47.423: Se1/0 IPCP: Address 10.0.0.1 (0x03060A000001)
*Mar 1 00:02:47.423: Se1/0 IPCP: State is Open
*Mar 1 00:02:47.423: Se1/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar 1 00:02:47.423: Se1/0 CDPCP: State is Open
*Mar 1 00:02:47.435: Se1/0 IPCP: Install route to 192.168.255.254
The show ip route on R1 furthermore shows:
R1(config-if)#do show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Serial1/0
192.168.255.0/32 is subnetted, 1 subnets
C 192.168.255.254 is directly connected, Serial1/0
R1(config-if)#do ping 192.168.255.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.255.254, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
And as you can see, the ping is working flawlessly although the ends of this PPP link are in totally different subnets. If we run the debug on R2, we will see analogous results with respect to R1's address 10.0.0.1. The key protocol here is the IPCP that helps both peers to mutually learn their addresses and allow the OS of the router to correctly populate the routing table so that the opposite peer's IP address is reachable via the PPP interface.
This ability of PPP to mutually negotiate the addresses on both ends of a PPP link allows for a very efficient usage of IP addresses: the access router uses a single IP address on its PPP access interface (usually configured as a Virtual-Template interface using IP Unnumbered feature to borrow its IP address from a loopback with a /32 mask). Furthermore, the IP addresses to clients will be assigned in a linear increasing manner, ignoring any broadcast/network reserved addresses, for example:
10.0.0.1 - 10.0.0.253 ---> addresses for PPP clients
10.0.0.254 ---> unique address for the access router
The client/router PPP links will then be addressed as:
Customer 1: 10.0.0.1 <---> 10.0.0.254
Customer 2: 10.0.0.2 <---> 10.0.0.254
Customer 3: 10.0.0.3 <---> 10.0.0.254
Customer 254: 10.0.0.254 <---> 10.0.0.254
The notion of a network and broadcast on these types of links is ignored.
Quite a mind-boggling concept, isn't it? Please feel welcome to ask further!