Tuesday, June 5, 2012

Frame Relay Pseudo Broadcasts -- The IRC Explanation

You can all blame Jeremy Gaddis for this being a Blog post. Taken from #cciestudy on irc.freenode.net.

19:04 < system5> jdsilva: you talking about my question as to whether psudo-broadcasting is
                 done as part of the routing protocol code or as part of the frame relay
                 implementation code?
19:05 < jdsilva> I don't know...  I didn't read any of the wall of text from you in my window
19:05 < jdsilva> was Pandom asking somethign related to a question you asked?
19:05 < system5> jdsilva: nope, two unrelated questions
19:05 < jdsilva> ok
19:06 < jdsilva> I was responding to Pandom
19:06 < system5> jdsilva: mine is a frame relay question I'm researching, his was about P2p
19:06 < jdsilva> I just sat down, and it was the latest thing I saw
19:07 < system5> jdsilva: the whole frame relay "pseudo broadcast" thing for routing updates
                 isn't something I really understand at the low level yet as in I don't
                 understand all the low level pieces of how it works
19:07 < jdsilva> there isn't a lot to it
19:07 < system5> I know that it does work and how to configure it, but I don't understand the
                 how or why it works
19:07 < jdsilva> the same frame is sent out every DLCI
19:07 < jdsilva> esy
19:07 < jdsilva> easy
19:08 < system5> jdsilva: it would need to look at the subnets and inverse arp though right? to
                 decide which DLCI's to forward out to?
19:08 < jdsilva> frame is at layer 2, it doesn't care about subnets
19:09 < jdsilva> it's operating on that multipoint interface, be it the physical, or a
19:09 < system5> jdsilva: and which part of the router manages the pseudo broadcasting? does
                 the routing protocol pseudo broadcast to make up for an inadequacy in frame
                 relay? or does frame relay pseudobroadcast to trick the routing protocol?
19:09 < jdsilva> again, a routing protocol is up in layer 3
19:09 < jdsilva> totally irrelevant
19:10 < system5> ok so frame relay does the pseudo broadcasting to trick the routing protocol,
                 got it, because FR is in L2 and the IGP is in L3
19:10 < jdsilva> not just the routing protocol
19:10 < jdsilva> ok, go back to a blank slate for a second
19:10 < jdsilva> just you, floating in nothingness
19:10 < jdsilva> no frame, no routing protocols
19:10 < jdsilva> :P
19:10 < system5> jdsilva: k
19:11 < jdsilva> ok, add back in frame relay, but ONLY frame relay
19:11 < system5> k
19:11 < jdsilva> no layer 3 nonsense
19:11 < jdsilva> you have a multipoint frame relay interface
19:11 < system5> now all that matters is the DLCI because it's the L2 address, like mac address
                 is for ethernet :-)
19:11 < jdsilva> it's frame relay becuase it's set to encapsulate exiting frame with headers as
                 defined by the frame relay forum
19:12 < jdsilva> yes, for the most part that's correct
19:12 < jdsilva> they do work very differently, but that's not really important here
19:12 < jdsilva> also for right now there's no inverse arp
19:12 < jdsilva> so only static frame mappings
19:13 < jdsilva> so we have a multipoint interface that knows to get to send out dlci
                 1, and to get to send out dlci 2
19:13 < jdsilva> (to keep it simple)
19:13 < system5> k
19:14 < jdsilva> so, now a packet is dispatched to the interface from the routing processor in
                 the router
19:14 < jdsilva> so all "routing" is now down
19:14 < Pandom> I get up to make a coffee and bam. One sec.
19:14 < jdsilva> or whatever process occurred to get the packet to the interface
19:14 < system5> Pandom: dude you are interrupting his awesome frame relay explanation
19:14 < jdsilva> it's irrelevant
19:15 < jdsilva> the interface receives the packet, and sees that the destination is a broadcat
19:15 < jdsilva> or a multicasst, or whatever
19:15 < jdsilva> it needs to go to more than one place
19:15 < jdsilva> that's really all it sees, it needs to go to more than one place
19:15 < jdsilva> so it makes copies of the packet
19:16 < jdsilva> it makes one copy for each dlci configured with pseudo broadcast enabled, as
                 defined in the frame maps
19:16 < jdsilva> so in our case, it makes two copies: for dlci 1 and dlci 2
19:16 < jdsilva> it then encapsulates both packets, one with a dst dlci of 1, and one with a
                 dst dlci or 2
19:17 < jdsilva> (that's not reaaly right, but it's good enough for now)
19:17 < jdsilva> and then it sends the two frames, one at a time
19:17 < jdsilva> two layer 2 unicasts
19:17 < jdsilva> to each dlci
19:18 < jdsilva> the layer 3 headers will still have the layer 3 multicast dst in the hedes
19:18 < jdsilva> but since there's no such thing as a broadcast or multicast in Frame it can't
                 send one
19:18 < jdsilva> so it sends one unicast for each dlci, to simulate a broadcast
19:18 < jdsilva> done
19:18 < jdsilva> life goes on